Tragédie des biens communs en chiffrement : le dilemme de l'indexation des données du marché de prévision
Résumé
Bienvenue dans la série "Tragédie des biens communs". Cette série se concentre sur les "biens publics" qui se trouvent à des points critiques dans le monde du chiffrement, mais qui perdent progressivement leur sens. Ces infrastructures sont souvent confrontées à un manque d'incitations, à un déséquilibre de la gouvernance et même à une centralisation progressive.
Dans ce numéro, nous nous concentrons sur l'une des applications les plus remarquables de l'écosystème Ethereum : Polymarket et son outil d'indexation de données. Autour des événements tels que la victoire de Trump et la manipulation des oracles concernant le commerce des terres rares en Ukraine, Polymarket est souvent devenu le centre de l'attention médiatique. Cependant, ce produit représentant le "marché de prévision décentralisé", sa clé de base - l'indexation des données - a-t-elle vraiment réalisé la décentralisation ? Pourquoi des infrastructures publiques comme The Graph n’ont-elles pas pu jouer le rôle attendu ? Quelle forme devrait avoir un bien public d'indexation de données véritablement utilisable et durable ?
I. Réactions en chaîne provoquées par la panne de la plateforme de données centralisée
En juillet 2024, Goldsky a connu un incident de panne de six heures, entraînant la paralysie d'une grande partie des projets de l'écosystème Ethereum. L'interface DeFi ne pouvait pas afficher les données de position et de solde des utilisateurs, le marché de prévision Polymarket ne pouvait pas afficher les données correctes, et d'innombrables projets semblaient totalement inutilisables aux yeux des utilisateurs.
Cela ne devrait pas se produire dans le monde des applications décentralisées. L'objectif initial de la conception de la technologie blockchain n'est-il pas d'éliminer le point de défaillance unique ? L'incident Goldsky a révélé un fait troublant : bien que la blockchain elle-même ait été rendue aussi décentralisée que possible, l'infrastructure utilisée par les applications construites sur la chaîne contient souvent une multitude de services centralisés.
L'indexation et la recherche des données blockchain appartiennent aux "produits publics numériques non exclusifs et non concurrentiels". Les utilisateurs s'attendent souvent à des frais gratuits ou très bas, mais cela nécessite en réalité un investissement continu en matériel, stockage, bande passante et main-d'œuvre opérationnelle. En l'absence d'un modèle de rentabilité durable, une concentration où "le gagnant prend tout" peut émerger : tant qu'un fournisseur de services obtient un avantage de premier arrivé en termes de vitesse et de capital, les développeurs ont tendance à diriger tout le trafic de requêtes vers ce service, créant ainsi une dépendance unique.
Cela nous avertit que le monde décentralisé a un besoin urgent d'enrichir la diversité de l'infrastructure Web3 par le financement de biens publics, la redistribution ou des initiatives dirigées par la communauté, sinon des problèmes de centralisation apparaîtront. Nous appelons les développeurs de DApp à construire des produits prioritaires pour le local, et nous appelons également la communauté technique à tenir compte des situations d'échec des services de récupération de données lors de la conception de DApp, afin de garantir que les utilisateurs puissent interagir avec les projets même sans infrastructure de récupération de données.
Deux, exploration des sources de données Dapp
Pour comprendre l'émergence d'événements comme celui de Goldsky, nous devons plonger dans les mécanismes de fonctionnement derrière les DApp. Pour les utilisateurs ordinaires, une DApp est généralement composée de deux parties : un contrat sur la chaîne et une interface frontale. Mais d'où proviennent réellement les données affichées sur l'interface utilisateur ?
Nécessité des services de récupération de données
Prenons l'exemple de la construction d'un contrat de prêt, qui doit afficher la situation des positions des utilisateurs ainsi que la marge et la dette de chaque position. Lire directement ces données sur la chaîne n'est souvent pas réalisable en pratique, car les contrats ne fournissent généralement que des fonctions pour interroger des données spécifiques en utilisant l'ID de position. Pour afficher la situation des positions des utilisateurs sur le frontend, il est nécessaire de récupérer toutes les positions dans le système, puis de filtrer celles qui appartiennent à l'utilisateur actuel. Ce processus, même s'il s'appuie directement sur un nœud local exécuté sur le serveur, nécessite souvent plusieurs heures.
Il est donc nécessaire d'introduire des infrastructures pour accélérer l'acquisition de données. Des entreprises comme Goldsky fournissent justement ces services d'indexation de données.
TheGraph / La relation entre Goldsky et SubGraph
SubGraph est un cadre de développement utilisé pour lire et agréger les données en chaîne, puis afficher ces données sur le front-end. TheGraph et Goldsky sont en fait tous deux des hébergeurs de SubGraph. Les programmes développés avec le cadre SubGraph doivent être exécutés sur un serveur, et différents opérateurs ont des stratégies et des solutions techniques différentes.
Le modèle de tarification de Goldsky
Goldsky adopte un modèle de facturation basé sur l'utilisation des ressources, qui est la méthode de facturation la plus courante pour les plateformes SaaS sur Internet.
Le modèle de tarification de TheGraph
TheGraph a un ensemble de frais qui diffèrent des méthodes de facturation habituelles, liés à l'économie des jetons GRT. Cela inclut des frais de requête à la pièce et des frais de mise en jeu de Signal.
Les dilemmes auxquels les développeurs sont confrontés
Pour la plupart des développeurs, l'utilisation de TheGraph est relativement compliquée. Il y a principalement deux problèmes :
Incertitude sur le nombre de GRT à staker et le temps nécessaire pour attirer les opérateurs.
La complexité de la comptabilité et de la gestion des coûts
En comparaison, choisir Goldsky est plus simple, le mode de facturation est compréhensible, et il peut presque être utilisé immédiatement, ce qui réduit considérablement l'incertitude. Cela a conduit à une situation où il y a une dépendance envers un seul produit pour les services d'indexation et de recherche de données blockchain.
Trois, solutions existantes
ponder
ponder est un logiciel de service de récupération de données simple, offrant une bonne expérience de développement et un déploiement facile. Ses avantages incluent:
Sans dépendance des fournisseurs
Bonne expérience de développement
Meilleures performances
Le chemin de commercialisation de ponder correspond à la "théorie de l'isolement", en réalisant une tarification par l'imposition de frais à certaines populations homogènes.
philosophie de développement local-first
Dans le développement de la blockchain, le concept de local-first peut être réalisé de cette manière :
Mettre en cache les données clés
Conception de la fonction de dégradation
Ce design peut considérablement améliorer la résilience de l'application, évitant ainsi que l'application ne soit inutilisable après un effondrement du service de récupération de données.
Quatrième, conclusion
L'incident de panne de Goldsky sonne l'alarme pour l'écosystème. Bien que la blockchain elle-même possède des caractéristiques de décentralisation et de résistance aux points de défaillance uniques, l'écosystème d'applications construit sur celle-ci dépend encore fortement des services d'infrastructure centralisés, ce qui entraîne des risques systémiques pour l'ensemble de l'écosystème.
Cet article discute des raisons pour lesquelles TheGraph n'est pas largement utilisé, présente le cadre d'auto-hébergement de ponder comme option d'urgence, et explore la philosophie de développement local-first. Nous appelons davantage de développeurs à se concentrer sur l'infrastructure de récupération de données, à essayer de construire des services décentralisés ou à concevoir des cadres permettant à l'interface utilisateur de DApp de fonctionner même sans service de récupération de données.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
6 J'aime
Récompense
6
4
Reposter
Partager
Commentaire
0/400
FloorPriceWatcher
· Il y a 21h
Eh bien, l'index est si difficile à gérer ?
Voir l'originalRépondre0
Fren_Not_Food
· Il y a 21h
Grand capital contrôlant le marché de prévision, je rigole.
Voir l'originalRépondre0
DaisyUnicorn
· Il y a 21h
Blockchain data petit jardinier, cherchant toute la journée une petite marguerite décentralisée qui va fleurir~
Voir l'originalRépondre0
SatoshiNotNakamoto
· Il y a 22h
Donc, le marché a été stabilisé par des arnaques en septembre.
Polymarket et son dilemme : le problème de la décentralisation de l'index des données du marché de prévision
Tragédie des biens communs en chiffrement : le dilemme de l'indexation des données du marché de prévision
Résumé
Bienvenue dans la série "Tragédie des biens communs". Cette série se concentre sur les "biens publics" qui se trouvent à des points critiques dans le monde du chiffrement, mais qui perdent progressivement leur sens. Ces infrastructures sont souvent confrontées à un manque d'incitations, à un déséquilibre de la gouvernance et même à une centralisation progressive.
Dans ce numéro, nous nous concentrons sur l'une des applications les plus remarquables de l'écosystème Ethereum : Polymarket et son outil d'indexation de données. Autour des événements tels que la victoire de Trump et la manipulation des oracles concernant le commerce des terres rares en Ukraine, Polymarket est souvent devenu le centre de l'attention médiatique. Cependant, ce produit représentant le "marché de prévision décentralisé", sa clé de base - l'indexation des données - a-t-elle vraiment réalisé la décentralisation ? Pourquoi des infrastructures publiques comme The Graph n’ont-elles pas pu jouer le rôle attendu ? Quelle forme devrait avoir un bien public d'indexation de données véritablement utilisable et durable ?
I. Réactions en chaîne provoquées par la panne de la plateforme de données centralisée
En juillet 2024, Goldsky a connu un incident de panne de six heures, entraînant la paralysie d'une grande partie des projets de l'écosystème Ethereum. L'interface DeFi ne pouvait pas afficher les données de position et de solde des utilisateurs, le marché de prévision Polymarket ne pouvait pas afficher les données correctes, et d'innombrables projets semblaient totalement inutilisables aux yeux des utilisateurs.
Cela ne devrait pas se produire dans le monde des applications décentralisées. L'objectif initial de la conception de la technologie blockchain n'est-il pas d'éliminer le point de défaillance unique ? L'incident Goldsky a révélé un fait troublant : bien que la blockchain elle-même ait été rendue aussi décentralisée que possible, l'infrastructure utilisée par les applications construites sur la chaîne contient souvent une multitude de services centralisés.
L'indexation et la recherche des données blockchain appartiennent aux "produits publics numériques non exclusifs et non concurrentiels". Les utilisateurs s'attendent souvent à des frais gratuits ou très bas, mais cela nécessite en réalité un investissement continu en matériel, stockage, bande passante et main-d'œuvre opérationnelle. En l'absence d'un modèle de rentabilité durable, une concentration où "le gagnant prend tout" peut émerger : tant qu'un fournisseur de services obtient un avantage de premier arrivé en termes de vitesse et de capital, les développeurs ont tendance à diriger tout le trafic de requêtes vers ce service, créant ainsi une dépendance unique.
Cela nous avertit que le monde décentralisé a un besoin urgent d'enrichir la diversité de l'infrastructure Web3 par le financement de biens publics, la redistribution ou des initiatives dirigées par la communauté, sinon des problèmes de centralisation apparaîtront. Nous appelons les développeurs de DApp à construire des produits prioritaires pour le local, et nous appelons également la communauté technique à tenir compte des situations d'échec des services de récupération de données lors de la conception de DApp, afin de garantir que les utilisateurs puissent interagir avec les projets même sans infrastructure de récupération de données.
Deux, exploration des sources de données Dapp
Pour comprendre l'émergence d'événements comme celui de Goldsky, nous devons plonger dans les mécanismes de fonctionnement derrière les DApp. Pour les utilisateurs ordinaires, une DApp est généralement composée de deux parties : un contrat sur la chaîne et une interface frontale. Mais d'où proviennent réellement les données affichées sur l'interface utilisateur ?
Nécessité des services de récupération de données
Prenons l'exemple de la construction d'un contrat de prêt, qui doit afficher la situation des positions des utilisateurs ainsi que la marge et la dette de chaque position. Lire directement ces données sur la chaîne n'est souvent pas réalisable en pratique, car les contrats ne fournissent généralement que des fonctions pour interroger des données spécifiques en utilisant l'ID de position. Pour afficher la situation des positions des utilisateurs sur le frontend, il est nécessaire de récupérer toutes les positions dans le système, puis de filtrer celles qui appartiennent à l'utilisateur actuel. Ce processus, même s'il s'appuie directement sur un nœud local exécuté sur le serveur, nécessite souvent plusieurs heures.
Il est donc nécessaire d'introduire des infrastructures pour accélérer l'acquisition de données. Des entreprises comme Goldsky fournissent justement ces services d'indexation de données.
TheGraph / La relation entre Goldsky et SubGraph
SubGraph est un cadre de développement utilisé pour lire et agréger les données en chaîne, puis afficher ces données sur le front-end. TheGraph et Goldsky sont en fait tous deux des hébergeurs de SubGraph. Les programmes développés avec le cadre SubGraph doivent être exécutés sur un serveur, et différents opérateurs ont des stratégies et des solutions techniques différentes.
Le modèle de tarification de Goldsky
Goldsky adopte un modèle de facturation basé sur l'utilisation des ressources, qui est la méthode de facturation la plus courante pour les plateformes SaaS sur Internet.
Le modèle de tarification de TheGraph
TheGraph a un ensemble de frais qui diffèrent des méthodes de facturation habituelles, liés à l'économie des jetons GRT. Cela inclut des frais de requête à la pièce et des frais de mise en jeu de Signal.
Les dilemmes auxquels les développeurs sont confrontés
Pour la plupart des développeurs, l'utilisation de TheGraph est relativement compliquée. Il y a principalement deux problèmes :
En comparaison, choisir Goldsky est plus simple, le mode de facturation est compréhensible, et il peut presque être utilisé immédiatement, ce qui réduit considérablement l'incertitude. Cela a conduit à une situation où il y a une dépendance envers un seul produit pour les services d'indexation et de recherche de données blockchain.
Trois, solutions existantes
ponder
ponder est un logiciel de service de récupération de données simple, offrant une bonne expérience de développement et un déploiement facile. Ses avantages incluent:
Le chemin de commercialisation de ponder correspond à la "théorie de l'isolement", en réalisant une tarification par l'imposition de frais à certaines populations homogènes.
philosophie de développement local-first
Dans le développement de la blockchain, le concept de local-first peut être réalisé de cette manière :
Ce design peut considérablement améliorer la résilience de l'application, évitant ainsi que l'application ne soit inutilisable après un effondrement du service de récupération de données.
Quatrième, conclusion
L'incident de panne de Goldsky sonne l'alarme pour l'écosystème. Bien que la blockchain elle-même possède des caractéristiques de décentralisation et de résistance aux points de défaillance uniques, l'écosystème d'applications construit sur celle-ci dépend encore fortement des services d'infrastructure centralisés, ce qui entraîne des risques systémiques pour l'ensemble de l'écosystème.
Cet article discute des raisons pour lesquelles TheGraph n'est pas largement utilisé, présente le cadre d'auto-hébergement de ponder comme option d'urgence, et explore la philosophie de développement local-first. Nous appelons davantage de développeurs à se concentrer sur l'infrastructure de récupération de données, à essayer de construire des services décentralisés ou à concevoir des cadres permettant à l'interface utilisateur de DApp de fonctionner même sans service de récupération de données.