Résumé

Bienvenue dans la série « Crypto : Tragédie des biens communs » de GCC Research.

Cette série met en lumière les principaux biens publics de la blockchain—ces piliers fondamentaux de l’écosystème crypto qui, peu à peu, s’éloignent des principes de décentralisation. Bien qu’indispensables à Web3, ces ressources sont confrontées à des déficits d’incitation, des défis de gouvernance et des risques de centralisation. Cet écart entre l’idéal décentralisé et la redondance nécessaire à la robustesse réelle met l’ensemble du secteur sous tension.

Ce chapitre explore l’une des applications Ethereum les plus emblématiques : Polymarket et ses outils d’indexation de données. Depuis le début de l’année, Polymarket a multiplié les controverses—manipulation d’oracles autour des chances électorales de Trump, paris sur les terres rares ukrainiennes, ou encore spéculations sur la couleur du costume de Zelensky—plaçant la plateforme au centre de l’attention. L’importance des fonds engagés rend ces polémiques immanquables.

Mais ce « marché de prédiction décentralisé » phare est-il véritablement décentralisé là où c’est essentiel—à l’étage de l’indexation des données ? Pourquoi des infrastructures décentralisées telles que The Graph peinent-elles à s’imposer ? À quoi devrait ressembler une solution d’indexation publique réellement utilisable et durable ?

I. Conséquences en chaîne d’une panne d’un service centralisé d’indexation de données

En juillet 2024, Goldsky—plateforme d’infrastructure blockchain en temps réel dédiée aux développeurs Web3, offrant indexation, sous-graphes et streaming de données—a connu une panne de six heures. Ce dysfonctionnement a affecté une grande partie de l’écosystème Ethereum : les frontends DeFi n’affichaient plus ni positions ni soldes, les marchés de prédiction tels que Polymarket ne présentaient plus les données à jour, et de nombreux projets semblaient tout simplement inutilisables aux yeux des utilisateurs.

Ce type de défaillance est précisément ce que les applications décentralisées doivent empêcher. La philosophie même de la blockchain vise l’élimination de tout point de défaillance unique. L’incident Goldsky a révélé une faille : si les blockchains sont conçues pour la décentralisation, l’essentiel de l’infrastructure qui alimente les applications on-chain est encore très centralisée.

À la racine du problème, l’indexation et la requête des données blockchain s’apparentent à des biens publics numériques—non exclusifs, non rivaux—que les utilisateurs attendent gratuits ou quasi gratuits. Or, leur maintien nécessite des investissements continus en matériel, stockage, bande passante et ingénierie. Faute de modèle économique durable, le secteur évolue vers un scénario de monopole : un fournisseur qui prend l’avantage en performance et en capital devient le point de passage unique pour les développeurs, générant ainsi une nouvelle dépendance systémique. Gitcoin et d’autres structures rappellent que « l’infrastructure open source génère des milliards de valeur, mais ses créateurs n’arrivent même pas à rembourser leur prêt immobilier. »

La conclusion s’impose : le monde décentralisé a besoin d’initiatives urgentes—financement des biens publics, redistribution des incitations ou modèles communautaires—pour diversifier l’infrastructure Web3 et éviter de nouvelles centralisations. Nous encourageons les concepteurs de DApp à privilégier des approches local-first et les communautés techniques à imaginer des DApps capables de résister aux pannes d’indexeurs—garantissant ainsi une continuité d’usage même hors ligne.

II. D’où proviennent vraiment les données de votre DApp ?

Pour saisir les implications d’incidents comme celui de Goldsky, il faut comprendre le fonctionnement des DApps. L’utilisateur lambda ne distingue que le contrat on-chain et le frontend graphique : il consulte Etherscan pour vérifier ses transactions, et utilise l’interface pour interagir avec les contrats. Mais d’où le frontend tient-il ses données ?

L’importance critique des services de récupération de données

Supposons que vous développez un protocole de prêt affichant les positions, les marges et les dettes des utilisateurs. Une implémentation naïve consisterait à interroger la blockchain directement depuis le frontend. Or, la plupart des contrats n’autorisent pas la récupération globale de toutes les positions pour une adresse donnée—mais plutôt via identifiant de position. Pour afficher toutes les positions d’un utilisateur, il faut donc récupérer l’intégralité des positions ouvertes puis sélectionner les siennes—ce qui revient à fouiller manuellement des millions d’entrées. Techniquement faisable, mais bien trop lent et inefficace. Même sur des serveurs backend, cette opération peut nécessiter plusieurs heures pour les grands projets DeFi.

Il faut donc une infrastructure dédiée. Les fournisseurs comme Goldsky proposent des services d’indexation qui optimisent l’accès aux données. Le schéma ci-dessous illustre les différents types de données prises en charge pour les applications.

Certains demanderont : The Graph ne propose-t-il pas un indexeur de données décentralisé pour Ethereum ? En quoi diffère-t-il de Goldsky, et pourquoi tant de projets DeFi lui préfèrent-ils ce dernier ?

Comment s’articulent The Graph, Goldsky et SubGraph

Clarifions les principaux concepts techniques :

• SubGraph : framework destiné aux développeurs, il permet d’agréger et de lire les données on-chain pour affichage sur le frontend.
• The Graph : plateforme leader de récupération décentralisée des données, ayant créé le framework SubGraph basé sur AssemblyScript. Les développeurs utilisent SubGraph pour capter les événements de contrats et les enregistrer dans une base interrogeable via GraphQL ou SQL.
• Les opérateurs SubGraph exécutent ces frameworks. The Graph et Goldsky sont tous deux des fournisseurs hébergés de projets SubGraph, le code devant tourner in fine sur des serveurs. Ci-dessous, un extrait de la documentation Goldsky :

Pourquoi plusieurs opérateurs SubGraph ?

Parce que le framework se limite à l’extraction et à l’écriture des données en base—sans définir la circulation ni l’émission. Chaque opérateur gère ces aspects à sa discrétion.

Certains introduisent des modifications et des optimisations propres. The Graph utilise maintenant Firehouse pour accélérer l’indexation ; chez Goldsky, le runtime SubGraph est propriétaire.

The Graph s’impose comme place de marché décentralisée d’opérateurs SubGraph. Par exemple, le subgraph Uniswap v3 est pris en charge par de multiples opérateurs, conférant à The Graph son statut de plateforme collective où le code SubGraph est soumis et pris en charge par plusieurs prestataires.

Modèle tarifaire de Goldsky

Goldsky fonctionne, en qualité de service SaaS centralisé, selon une tarification « à la ressource ». Les ingénieurs connaissent ce système. Voici le calculateur de prix Goldsky :

Modèle tarifaire de The Graph

The Graph adopte une approche originale : les frais de requête et les incitations sont intégrés à la tokenomics du GRT. Aperçu :

• Chaque requête sur un SubGraph partage les frais comme suit : 1 % de GRT brûlé ; 10 % pour le pool des curateurs ; environ 89 % pour les Indexers et Delegators, par algorithme.
• Les Indexers doivent staker au minimum 100 000 GRT, risquant des pénalités en cas de mauvaise réponse. Les Delegators stakent du GRT auprès des Indexers pour accéder au pool de récompense de 89 %.
• Les Curators (majoritairement des développeurs) signalent leur intérêt en stakant du GRT sur une courbe de bonding associée à leur SubGraph. Plus le staking est important, plus la ressource indexeur mobilisée croît. La communauté recommande de staker entre 5 000 et 10 000 GRT pour garantir l’indexation.

Frais de requêtes :

Pour interroger The Graph, il faut un compte développeur, une clé API et prépayer en GRT, la facturation se faisant à la requête.

Frais de signal :

Pour qu’un SubGraph soit indexé, il doit faire l’objet d’un staking GRT pour « signaler » sa valeur aux opérateurs. Seul un seuil significatif (ex. 10 000 GRT) incite les Indexers à traiter le SubGraph en production.

Pendant les phases de test, le déploiement peut se faire gratuitement via l’opérateur de staging de The Graph, hors production. Pour la mise en production, le SubGraph doit être publié sur le réseau, et les Indexers décident eux-mêmes de le prendre en charge selon les signaux stakés.

Pourquoi la tarification basée sur le token déroute développeurs et comptables

Pour de nombreux projets, le processus The Graph est complexe. L’achat de GRT est trivial pour les équipes Web3, mais le processus de curation s’avère long et incertain. Les principaux points d’achoppement :

• Manque de visibilité : difficile pour les développeurs d’estimer le montant de GRT à staker ou le délai d’indexation.
• Complexité comptable : la tokenomics complique le suivi des coûts et la classification des dépenses.

« Centralisé, c’est vraiment plus simple ? »

Pour la plupart des développeurs, Goldsky est bien plus simple : la tarification est transparente, le service est immédiat dès paiement, et l’incertitude quasi nulle. Cette facilité a entraîné une forte dépendance à un fournisseur unique dans Web3.

La tokenomics du GRT chez The Graph part d’une logique vertueuse, mais sa complexité décourage et ne devrait pas reposer sur l’utilisateur final—le staking de curation notamment gagnerait à être géré via une interface de paiement classique.

Ce point de vue est partagé : Paul Razvan Berg, ingénieur smart contract renommé et fondateur de Sablier, a publiquement critiqué l’expérience utilisateur du publishing SubGraph et du paiement GRT comme particulièrement insatisfaisante.

III. Solutions existantes en cas d’interruption d’indexeurs de données

Comment l’écosystème peut-il répondre au point de défaillance unique que représente l’indexation de données ? Comme vu précédemment, les développeurs peuvent se tourner vers The Graph, mais doivent accepter le staking et la curation GRT pour payer l’API.

De nombreuses alternatives existent dans l’écosystème EVM : voir The State of EVM Indexing sur Dune, EVM Indexing Tools Overview sur rindexer, et ce fil récent.

Nous n’aborderons pas ici la cause technique de la panne Goldsky ; selon leur rapport d’incident, Goldsky réserve ces détails à ses clients entreprises. Le rapport pointe un problème lors de l’écriture des données indexées en base, résolu grâce à AWS.

Voici quelques options alternatives :

• ponder : outil d’indexation open source, simple, convivial et facile à déployer. Les développeurs peuvent l’auto-héberger sur une infrastructure louée.
• local-first : philosophie de développement où une DApp reste utilisable même en absence de connexion réseau. En blockchain, l’utilisateur doit bénéficier d’une expérience qualitative s’il est connecté à la chaîne, même si les indexeurs sont hors service.

Ponder : l’indexation DIY

Pourquoi recommander ponder ?

• Indépendance totale : initialement créé par un développeur indépendant, ponder nécessite seulement un endpoint RPC Ethereum et une base Postgres—pas de service géré imposé.
• Excellente expérience développeur : écrit en TypeScript, reposant sur la librairie Viem, ponder est très agréable à prendre en main (témoignage de l’auteur).
• Performances solides.

Ponder évolue rapidement, ce qui peut créer des ruptures sur des déploiements anciens. Pour plus d’informations techniques et bonnes pratiques, consulter la documentation officielle.

Ponder amorce récemment une stratégie commerciale inspirée de la « théorie de la séparation » (déjà exposée dans un article antérieur).

En résumé : les biens publics bénéficient à tous, mais leur monétisation peut exclure les utilisateurs marginaux et diminuer le bien-être collectif (non optimal au sens de Pareto). Une tarification différenciée maximiserait théoriquement le surplus, mais sa mise en œuvre est difficile et coûteuse. Selon la théorie de la séparation, on peut isoler un groupe homogène, le facturer, et laisser les autres utilisateurs gratuits.

Application chez ponder :

• Le déploiement requiert des compétences techniques (configuration du endpoint RPC et de la base de données).
• Une maintenance régulière s’impose (usage de proxy pour équilibrage de charge et récupération de données en thread)—tâches parfois délicates pour certains profils.
• Ponder propose aujourd’hui un déploiement automatisé via Marble : l’utilisateur soumet son code pour un déploiement en un clic.

Cette stratégie « sépare » les utilisateurs en quête de simplicité (prêts à payer pour Marble) et les auto-hébergés qui continuent d’utiliser ponder librement.

Ponder versus Goldsky :

• Les outils open source et auto-hébergés comme ponder séduisent les petits projets autonomes.
• Les projets plus ambitieux, exigeant disponibilité et performance, optent pour des services managés tels que Goldsky.

Chaque modèle présente des vulnérabilités. La panne de Goldsky démontre l’utilité de maintenir un indexeur ponder en secours. Il est aussi crucial de vérifier la fiabilité des réponses RPC : safe a récemment signalé un incident lié à des données RPC invalides ayant provoqué un crash d’indexeur. Rien n’atteste que la panne Goldsky en soit due, mais ce risque existe.

Le paradigme local-first en développement

Le concept local-first suscite de nombreux débats. Il exige notamment :

• Une disponibilité hors ligne
• Une collaboration multi-client

Les discussions techniques évoquent souvent les CRDT (Conflict-free Replicated Data Types)—structures de données permettant de résoudre automatiquement les conflits en modification distribuée. Ce sont des protocoles de consensus légers qui assurent la cohérence sur différents appareils.

Dans la blockchain, ces exigences sont plus souples : l’objectif clé est de garantir à l’utilisateur une expérience minimale même sans indexeur backend, puisque la blockchain garantit la cohérence multi-client.

En pratique, les DApps local-first peuvent :

• Mettre en cache localement les informations importantes (soldes, positions), permettant à l’utilisateur de consulter son dernier état connu même en cas de panne d’indexeur.
• Opter pour une dégradation élégante—récupérer certaines données essentielles via RPC lorsque l’indexeur est indisponible, pour afficher des données on-chain en temps réel partiel.

Cette approche accroît fortement la résilience des applications. À terme, l’idéal serait que chaque utilisateur exécute son propre nœud local et interroge les données via des outils comme TrueBlocks. Pour creuser le sujet de l’indexation décentralisée et locale, voir le fil Literally no one cares about decentralized frontends and indexers.

IV. Conclusion

La panne de six heures de Goldsky a tiré la sonnette d’alarme pour tout l’écosystème Web3. Si les blockchains sont conçues pour la décentralisation et la résilience, la plupart des projets applicatifs reposent encore sur des infrastructures centralisées pour leurs données—ce qui expose l’ensemble à de nouveaux risques systémiques.

Cet article a exposé pourquoi The Graph, malgré sa reconnaissance, peine à convaincre à cause de la complexité de la tokenomics GRT et de ses frictions pour les développeurs. Nous avons présenté des stratégies pour une indexation de données plus robuste—en invitant les développeurs à conserver en backup des frameworks auto-hébergés comme ponder, tout en saluant l’innovation commerciale de ponder. Enfin, nous avons détaillé le paradigme local-first et incité les concepteurs de DApp à garantir une expérience utilisateur même en cas d’indisponibilité des indexeurs.

De plus en plus de développeurs Web3 identifient les points de défaillance uniques de l’indexation de données comme un véritable chantier prioritaire. GCC encourage la communauté à relever ce défi d’infrastructure centrale et invite à expérimenter des indexeurs décentralisés ou à concevoir des frameworks qui assurent la continuité des frontends de DApp, même hors ligne.

Avertissement :

1. Reproduction issue de TechFlow. Les droits d’auteur demeurent la propriété de l’auteur initial, shew. Pour toute demande relative à la republication, contactez l’équipe Gate Learn.
2. Avertissement : Les propos et opinions de cet article restent ceux de l’auteur et ne constituent en aucun cas des conseils d’investissement.
3. Les traductions Gate Learn ne peuvent être recopiées, diffusées ou plagiées sans attribution à Gate.com.