Souvent surnommé le “Google des blockchains”, The Graph permet de collecter facilement des informations importantes sur une blockchain donnée. Aujourd’hui, nous allons étudier son fonctionnement un peu plus en profondeur.
Il existe différents rôles au sein du réseau The Graph : nous commencerons par celui des indexeurs, qui sont les bibliothécaires des bases de données distribuées d’aujourd’hui.
Cet article vous est proposé dans le cadre d’une campagne de communication éducative, et soutenue par The Graph.
The Graph, le Google des blockchains
The Graph est un protocole décentralisé qui permet d’indexer et de requêter des données issues des blockchains, à commencer par celle d’Ethereum. Les développeurs en tous genres – applications décentralisées, agrégateurs de données – ont en effet besoin d’extraire les informations qui les intéressent, et ce n’est pas une tâche facile.
Le flux des données sur The Graph
De nombreux smart contracts stockent leurs données sur Ethereum. Bien que l’on ait un accès en lecture à ces derniers, il n’est pas toujours possible de regrouper, trier ou croiser les données qui nous intéressent.
The Graph répond précisément à ce besoin. Le protocole permet ainsi d’indexer de nombreuses données blockchain de façon performante, et de les requêter facilement. Les données des smart contracts sont indexées dans des sous-graphes (subgraphs), puis elles peuvent être retrouvées grâce à une API GraphQL – d’où le nom. En effet, GraphQL est un langage de requêtes et un environnement d’exécution bien connu.
Concrètement, pour un smart contract donné, The Graph permet de définir quels sont les événements à observer et à stocker dans un sous-graphe. La mapping (la cartographie des données à indexer) est également définie dans la description du sous-graphe, appelée le manifeste.
Architecture du réseau The Graph
Le réseau The Graph est composé de différents acteurs ayant chacun leur rôle, présentés dans un précédent article. Endosser l’un de ces rôles nécessite plus ou moins de bagage technique. Chaque acteur est incité économiquement à remplir son rôle au mieux via le jeton utilitaire de The Graph, le GRT.
- Le consommateur (généralement un développeur) soumet ses requêtes pour récupérer les données désirées ;
- L’indexeur est chargé de collecter les données blockchain, de les ordonner et de répondre aux requêtes ;
- Le curateur est chargé de signaler aux indexeurs les sous-graphes à indexer ;
- Le délégant est un détenteur de GRT qui participe au processus d’indexation confiant ses jetons aux indexeurs ;
- Le pêcheur cherche à renforcer la sécurité du réseau en détectant les fautes et les requêtes incorrectes ;
- Enfin, l’arbitre est chargé de déterminer l’issue d’un conflit lorsqu’une requête est contestée.
Pour comprendre comment fonctionne le protocole, il faut explorer ces différents rôles en détails. Pour commencer, notre article sera focalisé sur les indexeurs.
Les indexeurs, les nœuds opérateurs de The Graph
Les indexeurs sont donc les nœuds opérateurs du réseau : nous pourrions les voir comme des bibliothécaires, chargés d’indexer les données utiles aux développeurs. Contrairement aux bibliothécaires du monde physique, ils ne sont pas récompensés uniquement par un salaire fixe.
Staking et récompenses
Pour opérer un nœud d’indexation sur The Graph (Graph Node), il faut placer sous séquestre des jetons GRT : c’est le mécanisme du staking. Le minimum requis est de 100 000 GRT (ce qui nous fait près de 75000$ à l’heure d’écriture). Les récompenses de staking sont alors de deux types :
- L’inflation annuelle définie par le protocole, qui est de 3 % ;
- Les frais de requêtes.
La preuve d’indexation (POI)
Afin d’attester du service rendu par un indexeur, il existe un mécanisme appelé preuve d’indexation (proof of indexing ou POI). Cette preuve permet au réseau de vérifier qu’un indexeur est bien en train d’indexer les sous-graphes qui lui sont alloués. De la sorte, si une POI répond aux critères de la charte d’arbitrage, l’indexeur recevra sa récompense. Les récompenses sont évidemment proportionnelles au stake de l’indexeur.
Les POI doivent être soumises au réseau dès le premier bloc de la période correspondant pour chaque allocation. Les périodes durent 24 heures, et le nombre de périodes maximal pour chaque allocation est 28. Les indexeurs peuvent alors recevoir leurs récompenses manuellement à la fin d’une période, ou attendre le nombre maximum.
Une POI est donc un message signé par l’indexeur, généré durant l’indexation d’un sous-graphe depuis sa genèse, puis mis à jour à chaque changement d’état du sous-graphe. Les POI sont donc différentes selon les indexeurs. Ces derniers étant en compétition, il n’est ainsi pas du tout dans leur intérêt de colluder pour forger de fausses POI en espérant récupérer une récompense sans travail.
Frais de requêtes sur The Graph
Les utilisateurs paient des frais pour utiliser les services des indexeurs. Contrairement à une API classique opérée par un service centralisé, The Graph propose un marché aux requêtes. Les indexeurs sont ainsi en concurrence pour offrir leurs services au meilleur prix. Ce prix est donc déterminé par la bande-passante et la quantité de calcul nécessaires pour répondre à une requête donnée. Si un indexeur tombe, le reste du réseau absorbe la demande.
Les frais sont collectés par les passerelles lors de la fermeture d’une allocation, puis placés dans un coffre spécifique à chaque sous-graphe. Le modèle de récompense incite les indexeurs à verrouiller un stake proportionnel aux frais qu’ils vont collecter via une fonction spécifique – la fonction de production de Cobbs-Douglas.
Les récompenses provenant des frais de requêtes sont ainsi proportionnelles à la contribution de l’indexeur au sein du pool ET à la quantité de GRT alloués au sous-graphe (leur stake). Des canaux de paiement conditionnels permettent de gérer la collecte des frais et le versement des récompenses.
Les indexeurs peuvent récolter les récompenses après la fermeture d’une allocation; cependant, il existe une période de contestation, durant laquelle il est possible de mettre en doute la qualité de leur travail.
Les contestations
Il faut pouvoir vérifier que l’indexeur a correctement traité les données de son sous-graphe. En effet, un indexeur malicieux pourrait tenter de collecter ses récompenses sans pour autant travailler correctement (indexer un sous-graphe incorrect ou ne pas l’indexer du tout).
Il est alors possible de contester à la fois les requêtes et les allocations d’un indexeur. On appelle “pêcheur” (fisherman) celui qui lance une procédure de contestation. Son rôle est de renforcer la sécurité du réseau; il est incité financièrement car il récupère une partie des fonds des indexeurs pénalisés dans le cas où il a détecté une faute.
Mais attention, cela a un coût : il faut d’abord placer sous séquestre 10 000 GRT. Il y aura alors trois issues :
- Si le fisherman a tort, son stake de 10 000 GRT est brûlé, et l’indexeur n’est pas pénalisé ;
- En cas d’égalité, le fisherman récupère son stake et l’indexeur n’est pas pénalisé ;
- Si l’indexeur a tort, il sera pénalisé (slashed) : il perd une partie de son stake. La moitié revient au fisherman, et l’autre moitié est brûlée.
Mécanisme d’arbitrage
C’est un système d’arbitrage on-chain qui permet de déterminer l’issue d’un conflit, via le protocole de gouvernance de The Graph. Il y a deux types de contestations :
- Premièrement, la contestation à attestation unique : dans ce cas, le fisherman fournit une requête et l’attestation (la POI) de l’indexeur. Si l’indexeur a mal exécuté la requête, il est puni et perd donc une parte de son stake via le slashing. Il faut bien veiller à ce que le fisherman reçoive moins que la quantité de fonds “slashés” : en effet, les indexeurs pourraient se “slasher” eux-mêmes…
- Deuxièmement, la contestation à attestations conflictuelles : ici, le fisherman fournit au réseau deux attestations provenant de deux indexeurs différents pour une même requête. Si les deux attestations ne correspondent pas, on peut être sûr que l’un, ou les deux indexeurs, a ou ont commis une faute.
La charte d’arbitrage permet à l’arbitre de prendre en compte les erreurs de requêtes dues à un bug logiciel ou autres facteurs qui pourraient mener à un slashing injuste.
On ne peut contester une requête ou une allocation que durant une certaine fenêtre temporelle : 7 pour les requêtes et 56 pour les allocations.
Les preuves d’indexation sont le premier mécanisme permettant de vérifier l’intégrité du travail d’un indexeur. Mais il existe aussi un second mécanisme, appelé oracle de disponibilité du sous-graphe (Subgraph Availability Oracle) qui permet de s’assurer que chaque indexeur a bien créé un manifeste pour son sous-graphe.
En effet, en cas d’absence de manifeste, l’arbitre ne pourrait pas régler les contestations relatives à ce sous-graphe, et les indexeurs ne pourraient plus compétiter pour ce dernier. L’oracle observe donc les points de terminaison IPFS afin de vérifier que le manifeste est bien disponible.
Infrastructure et spécifications techniques pour indexeurs
Les indexeurs doivent avoir une infrastructure capable d’assurer le bon fonctionnement de leurs services. Il y a 4 niveaux d’exigence quant à la configuration matérielle du nœud : petit, standard, medium et grand.
Configuration matérielle requise
| Configuration | CPU (base de données) | Mémoire vive en Go (base de données) | Taille du disque (To) | CPU (machines virtuelles) | Mémoire vive (machines virtuelles) |
| Petit | 4 | 8 | 1 | 4 | 16 |
| Standard | 8 | 30 | 1 | 12 | 48 |
| Moyen | 16 | 64 | 2 | 32 | 64 |
| Grand | 72 | 468 | 3,5 | 48 | 184 |
Il faut bien entendu veiller à sécuriser le wallet du nœud opérateur. De même, il faut utiliser un pare-feu, afin de ne pas exposer les ports administrateur et les accès à la base de données.
Composants
Un nœud opérateur est connecté aux nœuds EVM d’Ethereum, aux nœuds IPFS (pour la collecte des données), et à sa base de données Postgres, mais aussi à d’autres composants facilitant ses interactions avec le réseau :
- Base de données PostgreSQL : c’est ici que l’indexeur stocke les données des sous-graphes, ainsi que les règles d’indexation.
- Point de terminaison Ethereum : qu’il s’agisse d’un simple client Ethereum ou d’instances multiples, il s’agit d’exposer une API JSON-RPC.
- Nœud IPFS : les métadonnées des sous-graphes sont stockées sur l’IPFS. Il n’est pas nécessaire pour l’indexeur de maintenir son propre nœud IPFS.
- Service d’indexation : il permet de recevoir les communication externes au réseau, de partager les modèles de coût, les statuts de l’indexation, de transporter les requêtes des passerelles au nœud The Graph, et de gérer les canaux de paiement avec les passerelles.
- Agent d’indexation : il facilite les interactions des indexeurs on-chain (enregistrement sur le réseau, déploiement des sous-graphes, gestion des allocations).
Pour une meilleure scalabilité, il faut veiller à séparer les nœuds dédiés aux requêtes de ceux dédiés à l’indexation.
Déploiement
La liste des ports utilisés par chacun des composants est disponible dans la documentation. Il faut faire très attention à verrouiller les ports d’administration (y compris le point de terminaison JSON-RPC du nœud Graph et les points de terminaison de gestion de l’indexeur).
La documentation décrit également la procédure pas-à-pas pour déployer l’infrastructure serveur sur Google Cloud avec Terraform.
Quand au nœud The Graph, il s’agit d’une implémentation Rust. Il faut disposer de Rust, de PostgreSQL et d’IPFS. Pour les indexeurs sous Ubuntu, il faudra installer quelques paquets supplémentaire. L’interface en lignes de commande de l’indexeur est disponible ici.
Participer à la sécurisation de The Graph sans bagage technique
Les simples détenteurs de jetons GRT ont tout intérêt à participer à la sécurisation du réseau ! En effet, en délégant leur jetons aux indexeurs, ils toucheront aussi une partie des récompenses. Cela permet à leurs jetons GRT de ne pas être dilués et d’apporter leur pierre à l’édifice.
Dans l’article suivant, nous vous détaillerons le procédé de délégation. Nous pourrons ensuite explorer plus en détails les rôles de curateur et de développeur pour le réseau The Graph. Stay tuned !
