Quiconque a déjà essayé de construire des applications distribuées (dApps) sur la blockchain (Ethereum) serait d’accord : bien que la blockchain soit conceptuellement assez proches des bases de données, interroger des bases de données est complètement différent du fait d’interroger une blockchain.

Pourquoi il est difficile d’interroger les données sur la blockchain. Image : Jésus Rodriguez

Tout d’abord, il y a des problèmes de performance notables avec le stockage des données sur la blockchain. Cela a beaucoup à voir avec la nature distribuée des blockchain, et une pénalité imposée par la combinaison des protocoles de consensus et le chiffrement.

Les bases de données seraient également lentes si elles étaient constituées d’un réseau de nœuds dans lequel chaque nœud conserveraient une copie complète de l’ensemble de la base de données, et chaque transaction devait être vérifiée par chaque nœud. C’est pourquoi les gens expérimentent diverses approches pour utiliser la blockchain comme base de données, y compris la modification de la structure de blockchain.

The Graph fait quelque chose de différent : il laisse la blockchain telle qu’elle est, mais propose un moyen d’indexer et d’interroger efficacement les données qui y sont stockées en utilisant GraphQL.

Interroger la blockchain

En fait, la performance n’est qu’une partie du problème de la récupération des données des blockchain. C’est pire encore. La blockchain n’a pas de langage de requête. Oui, vous avez bien compris, il n’y a pas de langage de requête. Imaginez une base de données sans langage de requête ! Comment pourriez-vous en tirer ce dont vous avez besoin ? Comment les gens construisent-ils des dApps, vraiment ? Avec beaucoup d’efforts, et un code ad-hoc.Comme le souligne Jesus Rodriguez dans ce billet, l’accès des données de la blockchain est un défi principalement pour trois raisons : décentralisation, opacité et stockage séquentiel des données. Il reste donc quelques choix :

Ecrire du code personnalisé pour localiser les données dont ils ont besoin sur les blockchain, et soit répéter ces appels (coûteux) chaque fois qu’ils ont besoin des données, soit récupérer les données une fois et les stocker dans une base de données hors blockchain, et construire un index pour pointer vers les données de la blockchain originale.

C’est là qu’intervient The Graph. The Graph est un protocole décentralisé d’indexation et d’interrogation des données de la blockchain. Mais c’est plus qu’un protocole : The Graph a également une implémentation, qui est open source et utilise GraphQL.

GraphQL est un langage de requête open source pour les APIs, développé par Facebook. GraphQL gagne en popularité et est utilisé pour accéder aux bases de données également; comme Prisma ou FaunaDB.

ZDNet a eu un entretien avec les co-fondateurs de The Graph, Yaniv Tal, responsable du projet et Brandon Ramirez, responsable de la recherche.

Pour Yaniv Tal, actuellement, les équipes travaillant sur dApps doivent écrire une tonne de code personnalisé et déployer des serveurs d’indexation propriétaires afin de servir efficacement les applications. Et comme tout ce code est personnalisé, il n’y a aucun moyen de vérifier que l’indexation a été faite correctement ou d’externaliser ce calcul vers une infrastructure publique.

En définissant une façon normalisée de faire cette indexation et de répondre aux requêtes de manière déterministe, ajoute Tal, les développeurs pourront exécuter leur logique d’indexation sur une infrastructure publique ouverte où la sécurité peut être renforcée.

The Graph a ouvert tous ses principaux composants, y compris : Graph Node (implémentation d’un nœud d’indexation intégré à Rust), Graph TS (aides de AssemblyScript pour la construction de mappings), et Graph CLI (outils en ligne de commande pour accélérer le développement).

The Graph, un protocole open source et son implémentation

Selon Yaniv Tal, l’essentiel de ce que The Graph a fait est de définir une façon déterministe de faire l’indexation. Graph Node définit une abstraction en utilisant Postgres :

« Tout ce dont vous avez besoin pour exécuter un sous-graphe est open source. Pour l’instant, nous utilisons Postgres comme moteur de stockage. Graph Node définit une abstraction que nous implémentons en utilisant Postgres et nous nous réservons le droit de modifier la base de données sous-jacente à l’avenir. Nous avons écrit beaucoup de code, mais c’est du code open source, donc rien de tout ça n’est propriétaire. »

Le sous-graphique auquel Yaniv Tal se réfère ici est simplement une partie de la blockchain utilisée pour stocker des données pour des dApps spécifiques. Définir un sous-graphique est la première étape pour utiliser The Graph. Des sous-graphiques pour les protocoles et les dApps populaires sont déjà utilisés et peuvent être parcourus à l’aide du Graph Explorer, qui fournit une interface utilisateur pour exécuter des requêtes GraphQL pour des contrats intelligents ou des dApps spécifiques.

Lorsque The Graph a été lancé en juillet 2018, Yaniv Tal a mentionné qu’ils lanceraient un nœud local, un service hébergé, puis un réseau entièrement décentralisé. Le réseau hybride est une version du protocole qui comble l’écart entre le service hébergé, qui est principalement centralisé, et le protocole entièrement décentralisé.

Aperçu de l’architecture du protocole The Graph pour interroger la blockchain

Les utilisateurs peuvent exécuter leur propre instance de The Graph, ou ils peuvent utiliser le service hébergé. Cela nous amène inévitablement à nous interroger sur le modèle d’affaires utilisé par The Graph, car l’exploitation d’un service hébergé coûte de l’argent.

Selon Ramirez, le modèle d’affaires de The Graph est celui du token, qui démarrera quand ils lanceront le réseau hybride. Les nœuds d’indexation, qui sont utilisés pour indexer un ensemble de données particulier, pourront être utilisés sur le marché de l’extraction de données pour cet ensemble de données. Le paiement en jetons sera nécessaire pour utiliser les différentes fonctions du service.

Le service hébergé ingère des blocs d’Ethereum, surveille les « triggers », et exécute des mappings WASM, qui mettent à jour le magasin Postgres. Il n’y a actuellement aucune garantie d’exactitude pour le service hébergé, car vous devez faire confiance à The Graph en tant tiers de confiance.

Dans le réseau hybride, il y aura des garanties de sécurité sur le fait que les données soient correctes, et dans le réseau entièrement décentralisé, il y aura également des garanties de chiffrement. L’objectif serait d’assurer la transition de tous les utilisateurs du service hébergé vers le réseau hybride une fois qu’il sera lancé, bien que Ramirez ait dit qu’ils ne le feraient pas d’une manière qui perturberait les utilisateurs existants.

Utilisation de GraphQL avec dApps

Désormais GraphQL est populaire, et c’est certainement mieux que de n’avoir aucun langage de requête du tout. Mais il y a aussi quelques idées fausses très répandues à ce sujet, et il est bon d’en être conscient lorsque l’on considère l’utilisation de The Graph. Une partie importante de GraphQL, ajoutée relativement récemment, est son SDL (Schema Definition Language). Cela peut permettre aux outils de centrer le processus de développement autour d’un schéma GraphQL.

Les développeurs peuvent créer leur modèle de domaine en SDL, puis l’utiliser non seulement pour valider le JSON renvoyé par GraphQL, mais aussi pour générer du code, en mode MDD (Model Driven Development). Dans tous les cas, l’utilisation de GraphQL ne supprime pas « par magie » la complexité du mappage dans de nombreuses API. Il se contente de l’abstraire et de le transposer dans le résolveur GraphQL.

Donc, à moins qu’il n’y ait un mécanisme d’automatisation / maintenance de mapping, l’équipe qui utilise les APIs abstraites via GraphQL peut avoir une meilleure expérience, mais c’est aux dépens de l’équipe qui maintient les maps d’APIs. Il n’y a rien de tel qu’un déjeuner gratuit, et il en va de même pour la blockchain.

D’autant plus que les contrats intelligents ne peuvent pas à ce stade être pilotés par GraphQL Schema. Vous devez d’abord créer un contrat intelligent, puis le schéma GraphQL et son résolveur. Cela donne un aller-retour fastidieux pour mettre à jour le schéma et le résoudre chaque fois que le contrat intelligent change. Ramirez l’a reconnu et a expliqué le processus d’accès aux données des contrats intelligents via GraphQL :

« Le schéma GraphQL est utilisé pour exprimer un modèle de données pour les entités, qui sera indexé dans le cadre d’un sous-graphique. Il s’agit d’un schéma de lecture, qui n’est exposé qu’à la deuxième couche, et non dans les contrats intelligents eux-mêmes. Ethereum n’a pas la sémantique pour exprimer des modèles de données riches avec des entités et des relations, ce qui est une des raisons pour lesquelles les projets trouvent l’interrogation d’Ethereum via The Graph particulièrement utile ».

« Si l’ABI d’un contrat intelligent changeait de façon frauduleuse, cela pourrait nécessiter une mise à jour des mappages s’ils s’appuyaient sur les parties de l’interface, mais ce n’est pas un problème spécifique aux Graph, car toute application ou service récupérant des données directement depuis ce contrat intelligent aurait des problèmes similaires ».

« Généralement, apporter des changements importants à une API avec une utilisation réelle est une mauvaise idée. Et il est très peu probable que cela se produise dans le monde des contrats intelligents une fois expédiés en production et largement utilisés (ce qui va à l’encontre de l’objectif) ».

« Une partie de la « magie » de The Graph est que nous générons automatiquement un « schéma de lecture » et des résolveurs basés sur votre modèle de données. Nul besoin de maintenir quoi que ce soit d’autre que le schéma du modèle de données et les mappages, qui ne devraient pas avoir besoin de changer souvent. Nous ajoutons également la prise en charge des résolveurs personnalisés pour les utilisateurs plus avancés. »

Perspectives d’avenir

Bien que The Graph n’ait pas encore atteint sa pleine maturité, il a déjà parcouru un long chemin en peu de temps. Il est déjà considéré comme un élément important de la pile Web3. Outre la transition vers une mise en œuvre entièrement décentralisée, nous nous demandions ce qu’il y avait d’autre dans la feuille de route.

La vision de The Graph est de rendre le développement de dApps sur les blockchain aussi simple que le développement d’applications standard l’est aujourd’hui.

Qu’en est-il des mutations, c’est-à-dire offrir à dApps la possibilité d’écrire également des données dans la blockchain via GraphQL ? M. Ramirez a indiqué que cela fait partie de la feuille de route, mais qu’il s’agira en fin de compte d’une préoccupation du côté du client :

« Le protocole ne peut pas signer une transaction au nom des utilisateurs sur la base d’une mutation. Au lieu de cela, les développeurs dApp écriront une mutation contre une API GraphQL locale qui générera alors une transaction à signer avec la clé privée de l’utilisateur. »

Ramirez a ajouté que The Graph peut indexer toutes les données qui sont sur la chaîne, par exemple celles qui sont fournies par Oracles via Chainlink. En outre, dit-il, Chainlink Oracles peut également décider de fournir un flux de données qui est tiré d’un abonnement GraphQL via The Graph, donc l’intégration fonctionne dans les deux sens.

Et qu’en est-il des bases de données hors chaîne ? Une dApp peut vouloir y stocker certaines de ses données pour des raisons de cache, de confidentialité, de performance ou autres. Nous nous demandions s’il s’agissait d’un scénario que The Graph a rencontré et ce qu’il recommanderait dans ce cas. La réponse de Ramirez est que si une application utilise des bases de données centralisées hors chaîne, alors elles ne sont plus techniquement une « dApp » :

« Cependant, ils pourraient toujours utiliser The Graph via l’assemblage de schémas pour composer leurs sources de données décentralisées et centralisées. Ceci est en train de devenir un modèle commun dans l’écosystème GraphQL. Si les autres magasins de données sont également décentralisés, ils pourraient également utiliser The Graph à cette fin. Par exemple, aujourd’hui, nous prenons en charge l’indexation des données hors chaîne dans IPFS, et prévoyons d’ajouter la prise en charge d’autres blockchain à l’avenir. »

En conclusion de la discussion, Ramirez a souligné que leur vision est de décentraliser complètement la pile des applications Internet, en se concentrant principalement sur les dApps opérationnels. Pour un certain nombre de raisons, a-t-il ajouté, GraphQL est plus logique stratégiquement pour atteindre cet objectif. SQL est aussi à l’ordre du jour, et il pourrait encore être très utile pour d’autres cas d’utilisation secondaires, mais pour le moment, ils restent concentrés sur la mission principale.

Quant à savoir si GraphQL peut être utilisé pour l’analyse aussi, Ramirez a dit que bien que l’expression d’une requête analytique utilisant la sémantique GraphQL est possible, il n’a pas encore vu trop d’exemples de cela :

« Je pourrais imaginer quelque chose de similaire à la requête DSL d’Elastic exprimée en GraphQL plutôt qu’en JSON, qui je pense pourrait être faite pour être assez ergonomique. Il y a aussi la question de savoir si c’est ainsi que les analystes et les ingénieurs de données veulent écrire des requêtes de style analytique de cette façon plutôt qu’en utilisant simplement SQL. »

Article « The Graph: An open-source query protocol for blockchains, using GraphQL » traduit et adapté par ZDNet.fr

Source Article from https://www.zdnet.fr/actualites/the-graph-un-protocole-de-requete-open-source-pour-la-blockchain-utilisant-graphql-39885897.htm#xtor=RSS-1
Source:ZDNet News