Quicknode

5 mars 2019 — 7 min de lecture

Qu'est-ce que The Graph ? Comment créer un sous-graphe ? Et en quoi cela peut-il aider mon dApp ?

La plupart Ethereum comportent deux volets dans leur infrastructure (version simplifiée) :

• Front-end (exécuté dans le navigateur)

• Un Ethereum (interface avec le réseau ETH)

Lorsqu'une transaction est effectuée sur Ethereum, elle génère des événements. Le front-end surveille ces événements et met à jour l'interface utilisateur en conséquence. Les dApps peuvent effectuer certains types de requêtes auprès d'un Ethereum afin d'afficher des données sur le front-end.

Mais les dApps ne peuvent pas se contenter uniquement de transactions, d'événements et de ces requêtes minimales. Pour offrir une expérience utilisateur complète, une dApp doit au moins traiter ses propres données, afficher l'activité d'un utilisateur donné, établir un profil utilisateur, présenter des statistiques et proposer de multiples fonctionnalités… Comment pouvons-nous faire tout cela aujourd'hui ?

Un certain nombre d'équipes de développement de dApps s'y emploient en mettant au point leurs propres solutions sur mesure : elles extraient les données de la blockchain, suivent les événements et les transactions, puis les stockent dans une base de données centralisée classique. Mais notre objectif sur le Web3, c'est bien de réduire au minimum la dépendance à la confiance, n'est-ce pas ?

Pour résumer le problème —

Qu'est-ce que The Graph ?

L'équipe de Graph s'attache à résoudre ce problème en développant un protocole décentralisé qui s'appuiera sur des nœuds Graph chargés de traiter Ethereum et de les stocker sous forme de données indexées que les dApps pourront interroger via un endpoint API.

Ces index (« sous-graphes ») sont actuellement hébergés par l'équipe de The Graph. À l'avenir, cependant, ces index seront hébergés sur un réseau entièrement décentralisé de nœuds Graph.

Comment fonctionne The Graph ?

Allons plus loin et voyons comment fonctionne réellement The Graph :

• Les dApps (via leurs contrats intelligents) génèrent Ethereum , qui déclenchent des événements.

• Les nœuds Graph analysent chaque Ethereum à la recherche d'événements.

• Graph Nodes recherche les événements correspondant à votre sous-graphe dans Ethereum et exécute les gestionnaires de mappage que vous avez fournis. Ce mappage détermine la manière dont les données sont stockées et mises à jour dans Graph Nodes.

• Votre dApp peut interroger ces données via les API GraphQL, qui sont traduites par Graph Nodes afin de récupérer les données indexées.

Alors, qu'est-ce qu'on attend ? Créons un Subgraph !

Créer un sous-graphe

Utilisons un exemple de contrat intelligent issu du projet Truffle et créons un sous-graphe.

Explorateur de graphes

Grâce à Graph Explorer, vous pouvez explorer d'autres sous-graphes créés par la communauté. Il est également possible d'effectuer des requêtes sur ces sous-graphes via l'interface utilisateur de Graph Explorer.

Nous devons créer un compte sur Graph Explorer et obtenir un jeton d'accès, qui sera utilisé lors du déploiement de notre sous-graphe sur les nœuds Graph (hébergés par l'équipe The Graph). Créons donc un compte sur Graph Explorer.

Créez un sous-graphe à l'aide de l'interface utilisateur de Graph Explorer et nommez-le «exemple ».

Nous devons maintenant installer Graph-CLI sur notre système (j'utilise Ubuntu 16.10) :

sudo yarn global add @graphprotocol/graph-cli

Créons un sous-graphe d'exemple à l'aide de la commande ci-dessous :

graph init buddies2705/example-subgraph example-subgraph// Command Syntax 
graph init <GITHUB_USER>/<SUBGRAPH_NAME> <DIRECTORY>

// Here Direcotry is optional, if you don't pass it it will create a directory with SUBGRAPH_NAME

Installons les dépendances et générons les mappages :

//Install Dependencies
 yarn
//Generate Mappings
yarn codegen

Configurons l'authentification à l'aide d'un jeton d'accès (nous pouvons obtenir ce jeton d'accès depuis le tableau de bord de Graph Explorer) :

graph auth https://api.thegraph.com/deploy/<ACCESS_TOKEN>

Nous pouvons désormais déployer notre sous-graphe dans Graph Explorer à l'aide de la commande ci-dessous :

graph deploy     --debug     --node https://api.thegraph.com/deploy/ ipfs ipfs    buddies2705/example

//You can see we are using buddies/example where "buddies2705" is my //github username and "example" is our subgraph name create using //Graph explorer UI.

Ouvrez maintenant Graph Explorer : vous pourrez alors voir votre sous-graphe. Vous pouvez également interroger votre sous-graphe à l'aide de l'interface utilisateur de Graph Explorer. Vous pouvez également consulter les points de terminaison permettant d'interagir par programmation avec votre sous-graphe.

Dans les coulisses

Allons plus loin et voyons ce qui s'est passé « en coulisses ». Nous avions un projet Truffle avec un Gravity.sol contrat, qui consiste simplement à créer un Gravatar (votre avatar sur Internet) sur Ethereum.

Ce contrat génère deux événements

• NewGravatar — Lorsqu'un nouveau Gravatar est créé

• Gravatar mis à jour — Lorsqu'un Gravatar existant est mis à jour

événement NewGravatar(uint id, address owner, string displayName, string imageUrl) ;

événement UpdatedGravatar(uint id, address owner, string displayName, string imageUrl) ;

Si nous indexons ces deux événements « Data », nous pourrons répondre à des requêtes telles que :

• Combien de Gravatars ont été créés l'année dernière ?

• Combien de Gravatars sont mis à jour en moyenne chaque jour ?

• Quels sont les 10 meilleurs services d'hébergement d'images pour tous nos Gravatars ? (Ce sera IPFS )

• Quels sont les noms les plus courants pour les Gravatars ?

Certaines de ces requêtes doivent être exécutées sur l'intégralité des données du contrat depuis le moment où celui-ci a été déployé, ce qui n'est pas possible avec les requêtes web3 habituelles. Vous avez besoin de données indexées.

Avec The Graph, vous pouvez créer des mappages pour indexer ces données, qui seront stockées dans le magasin de données (actuellement Postgres). Voyons donc comment ces mappages sont créés :

Fichiers importants

Examinons tout d'abord le subgraph.yaml, qui définit toutes les correspondances :

specVersion : 0.0.1
description : Gravatar pour Ethereum
référentiel :gravity
schéma :
  fichier : ./schema.graphql
sources de données :
  - kind : ethereum
    name : Gravity
   network : mainnet
   source :
      address : '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
      abi : Gravity
   mapping :
      kind : ethereum
      apiVersion : 0.0.1
      language : wasm/assemblyscript
      entities :
        - Gravatar
      abis :
        - name : Gravity
         file : .Gravity.json
      gestionnaires d'événements :
        - événement : NewGravatar(uint256, adresse, chaîne, chaîne)
          gestionnaire : handleNewGravatar
        - événement : UpdatedGravatar(uint256, adresse, chaîne, chaîne)
          gestionnaire : handleUpdatedGravatar
      fichier : ./src/mapping.ts

Examinons les champs importants de ce fichier :

dataSources: Les sources de données contiendront tous les contrats intelligents que vous souhaitez suivre. (Dans notre cas, il n'y en a qu'un seul).

Tous les autres champs sont intuitifs, voyons donc gestionnaires d'événements champ, qui définit nos correspondances :

gestionnaires d'événements: dans ce champ, nous allons définir nos correspondances. Nous allons ajouter des événements et des fonctions qui géreront ces événements. Par exemple, nous définissons handleNewGravatar pour notre NewGravatar événement.

fichier : Ce champ contiendra notre fichier de mappage comprenant les fonctions de gestion des événements, à savoir mapping.ts dans notre cas.

mapping.ts C'est là que vous implémentez les gestionnaires d'événements… Ces gestionnaires d'événements s'exécuteront chaque fois que nos événements Gravatar seront déclenchés, créant ainsi des entités et les enregistrant dans le magasin, comme nous l'avons décrit dans nos fonctions de gestion d'événements.

import { NewGravatar, UpdatedGravatar } from './types/Gravity/Gravity'
import { Gravatar } from './types/schema'

export function handleNewGravatar(event: NewGravatar): void {
  let gravatar = new Gravatar(event.params.id.toHex())
  gravatar.owner = event.params.owner
  gravatar.displayName = event.params.displayName
  gravatar.imageUrl = event.params.imageUrl
  gravatar.save()
}

export function handleUpdatedGravatar(event: UpdatedGravatar): void {
  let id = event.params.id.toHex()
  let gravatar = Gravatar.load(id)
  if (gravatar == null) {
    gravatar = new Gravatar(id)
  }
  gravatar.owner = event.params.owner
  gravatar.displayName = event.params.displayName
  gravatar.imageUrl = event.params.imageUrl
  gravatar.save()
}

Comme vous pouvez le constater, nous importons deux fichiers, Gravity.ts et Schema.ts— ces deux fichiers sont générés lorsque nous exécutons générateur de code Yarn. Ces fichiers contiennent types, qui facilitent l'utilisation des contrats, des événements et des entités. Nous disposons également d'un schema.graphql, qui contiendra des entités.

type Gravatar @entity {  
    id: ID!  
    owner: Bytes!  
    displayName: String! 
    imageUrl: String!
}

Notre schema.ts Le fichier est généré à l'aide de ceci schema.graphql et notre Gravity.ts Le fichier est généré à partir du contrat intelligent Gravity.sol .

Cela fait beaucoup de concepts liés à GraphQL. Si vous ne connaissez pas GraphQL, consultez cette page; cela dit, il est possible de créer un sous-graphe basique même avec une connaissance minimale de GraphQL.

Créez un sous-graphe pour votre dApp

Si vous exploitez une dApp, vous avez sans doute déjà été confronté à ce problème lié aux données.

Vous trouverez ci-dessous les étapes à suivre pour créer un sous-graphe personnalisé pour votre dApp (comme indiqué ci-dessus).

• Installer Graph-CLI et les autres dépendances

• Créer un fichier subgraph.yaml

• Créer schema.graphql

• Générer des fichiers de schéma

• Créer un fichier de mappage avec les gestionnaires d'événements

Commandes utiles

Graph-CLI propose des commandes utiles que vous pouvez enregistrer dans le fichier package.json.

Conclusion

Le principal atout que l'on ne reconnaît pas encore à fond, c'est que l'infrastructure Web3 permettra la mise en place d'applications Internet autonomes, capables de fonctionner dans un avenir prévisible sans nécessiter aucune maintenance.

La décentralisation et la réduction au minimum de la dépendance à des tiers constituent un problème difficile à résoudre. L'équipe de The Graph s'efforce d'y parvenir et de mettre en place un élément essentiel de l'infrastructure des dApps. Si vous développez une dApp évolutive, vous devriez vous intéresser au protocole The Graph !

Vous avez besoin d'aide pour votre projet ou vous avez des questions ? Contactez-nous via ce formulaire, sur TwitterQuicknode, ou envoyez-nous un message sur Discord!