De la blockchain au LLM, une interprétation approfondie de l'évolution et des défis de la technologie d'indexation des données

Depuis que Satoshi Nakamoto a décidé d'intégrer un message dans le bloc de genèse, la structure de données de la chaîne Bitcoin a subi une série de changements.

J'ai commencé à étudier en profondeur le développement de la blockchain en 2022, et le premier livre que j'ai lu était "Mastering Ethereum". Ce livre est excellent et m'a fourni une compréhension approfondie des principes fondamentaux d'Ethereum et de Blockchain. Cependant, du point de vue d'aujourd'hui, certaines des techniques de développement du livre sont devenues quelque peu obsolètes. Les étapes préliminaires impliquent l'exécution d'un nœud sur un ordinateur portable personnel, même pour le portefeuille dApp, nécessitant le téléchargement d'un nœud léger par lui-même. Cela reflète le modèle de comportement des premiers développeurs et pirates dans l'écosystème de développement de la blockchain entre 2015 et 2018.

En 2017, nous n'avions aucun fournisseur de services de nœud. Du point de vue de l'offre et de la demande, leur fonction principale est d'effectuer des transactions en raison de l'activité limitée des utilisateurs. Cela signifie que la maintenance ou l'hébergement d'un nœud complet vous-même n'est pas trop lourd, car il n'y a pas beaucoup de demandes RPC à traiter et les demandes de transfert sont peu fréquentes. La plupart des premiers utilisateurs d'Ethereum sont des geeks de la technologie. Ces premiers utilisateurs ont une compréhension approfondie du développement de la blockchain et sont habitués à maintenir directement les nœuds Ethereum, à créer des transactions et à gérer des comptes via la ligne de commande ou un environnement de développement intégré.

Par conséquent, nous pouvons observer que les premiers projets ont généralement une UI/UX très propre. Certains de ces projets n'ont même pas d'interface et l'activité des utilisateurs est assez faible. Les caractéristiques de ces projets sont principalement déterminées par deux facteurs : le comportement des utilisateurs et la structure des données de la chaîne.

L'essor des fournisseurs de nœuds

Alors que de plus en plus d'utilisateurs sans expérience en programmation rejoignent le réseau blockchain, l'architecture technique des applications décentralisées a également changé. Le mode d'origine d'hébergement des nœuds par les utilisateurs est progressivement passé à l'hébergement des nœuds par les parties au projet

Les gens ont tendance à choisir les services d'hébergement de nœuds, principalement parce que la croissance rapide des données sur la chaîne fait augmenter progressivement le coût des nœuds d'hébergement personnels au fil du temps.

Cependant, l'auto-hébergement des nœuds par les équipes de projet reste un défi pour les développeurs de petits projets, nécessitant des investissements de maintenance continus et des coûts matériels. Par conséquent, ce processus complexe d'hébergement de nœuds est généralement confié à des entreprises spécialisées dans la maintenance de nœuds. Il convient de mentionner que le moment de la construction à grande échelle et de la collecte de fonds de ces entreprises coïncide avec la tendance à la hausse des services infonuagiques dans l'industrie technologique nord-américaine.

| Projet | Catégorie | Établi depuis | | --- | --- | --- | | Alchimie | Nœuds | 2017 | | Infura | Nœuds | 2016 | | NowNodes | Nœuds | 2019 | | Nœuds rapides | Nœuds | 2017 | | Ancre | nœuds | 2017 | | ChainStack | Nœuds | 2018 |

Le simple fait d'héberger des nœuds à distance ne peut pas résoudre complètement le problème, surtout maintenant que des protocoles connexes tels que DeFi et NFT émergent. Les développeurs doivent faire face à de nombreux problèmes de données, car les données fournies par les nœuds de la blockchain eux-mêmes sont appelées données brutes, qui ne sont ni standardisées ni nettoyées. Les données qu'il contient doivent être extraites, nettoyées et chargées.

Par exemple, supposons que je sois développeur d'un projet NFT et que je souhaite effectuer des transactions NFT ou afficher des NFT. Ensuite, mon frontal doit lire les données NFT dans le compte personnel EOA en temps réel. NFT n'est en fait qu'une forme standardisée de jeton. Posséder un NFT signifie que je possède un jeton avec un identifiant unique généré par le contrat NFT, et l'image du NFT est en fait des métadonnées, qui peuvent être des données SVG ou un lien vers une image sur IPFS. Bien que le client Geth d'Ethereum fournisse des instructions d'indexation, pour certains projets avec de grandes exigences frontales, il n'est pas pratique de demander Geth en continu, puis de revenir au frontal. Pour certaines fonctions, telles que l'enchère d'ordres et l'agrégation de transactions NFT, elles doivent être réalisées hors chaîne pour collecter les instructions des utilisateurs, puis soumettre ces instructions à la chaîne au moment opportun.

Par conséquent, une simple couche de données est née. Afin de répondre aux exigences de temps réel et de précision des utilisateurs, la partie projet doit créer sa propre base de données et ses propres fonctions d'analyse de données.

**Comment l'indexeur de données a-t-il évolué ? **

Démarrer un projet est généralement une affaire relativement simple. Vous avez une idée, fixez des objectifs, trouvez les meilleurs ingénieurs et construisez un prototype fonctionnel, qui comprend généralement un frontal et quelques contrats intelligents.

Cependant, il est assez difficile de rendre le projet à l'échelle. Il faut réfléchir profondément à la structure de conception dès le premier jour du projet. Sinon, vous pouvez rapidement rencontrer des problèmes, que j'appelle généralement des "problèmes de givrage".

J'ai emprunté ce terme au film "Iron Man", et il semble très approprié pour décrire la situation de la plupart des startups. Lorsque les startups se développent rapidement (attirent beaucoup d'utilisateurs), elles rencontrent souvent des problèmes parce qu'elles ne l'avaient pas prévu au départ. Dans le film, le méchant ne s'attendait jamais à ce que son équipement de guerre vole dans l'espace car il n'a pas tenu compte du "problème de givrage". De même, pour les développeurs de nombreux projets Web3, le "problème de blocage" implique de faire face au fardeau accru de l'adoption massive par les utilisateurs. Cela exerce une forte pression sur le côté serveur car le nombre d'utilisateurs augmente considérablement. Il existe également des problèmes liés à la blockchain elle-même, tels que des problèmes de réseau ou des arrêts de nœuds.

La plupart du temps, c'est un problème de backend. Par exemple, dans certains protocoles de jeu blockchain, cette situation n'est pas rare. Lorsqu'ils prévoyaient d'ajouter plus de serveurs et d'embaucher plus d'ingénieurs de données pour analyser les données sur la chaîne, ils n'avaient pas prévu qu'autant d'utilisateurs participeraient. Le temps qu'ils s'en rendent compte, il était trop tard. Et ces problèmes techniques ne peuvent pas être résolus simplement en ajoutant plus d'ingénieurs back-end. Comme je l'ai déjà dit, ces considérations devraient être intégrées au plan dès le départ.

Le deuxième problème consiste à ajouter de nouvelles blockchains. Vous avez probablement évité les problèmes côté serveur en premier lieu et embauché un groupe de bons ingénieurs. Cependant, vos utilisateurs peuvent ne pas être satisfaits de la blockchain actuelle. Ils veulent que votre service fonctionne également sur d'autres chaînes populaires comme les chaînes zk ou les chaînes L2. La structure de votre projet pourrait ressembler à ceci :

Dans ce type de système, vous avez un contrôle total sur vos données, ce qui permet une meilleure gestion et une sécurité accrue. Le système limite les demandes d'appel, réduit le risque de surcharge et augmente l'efficacité. Et la configuration est compatible avec le frontal, garantissant une intégration et une expérience utilisateur transparentes.

Cependant, les coûts d'exploitation et de maintenance se multiplient, ce qui peut mettre à rude épreuve vos ressources. Ajouter une nouvelle blockchain à chaque fois nécessite un travail répété, qui peut être chronophage et inefficace. La sélection de données à partir de grands ensembles de données peut réduire les temps de requête, ce qui pourrait ralentir le processus. En raison de problèmes de réseau de blockchain tels que les retours en arrière et les réorganisations, les données peuvent être entachées, compromettant l'intégrité et la fiabilité des données.

Les projets sont conçus pour refléter les membres de votre équipe. Ajouter plus de nœuds et essayer de construire un système axé sur le backend signifie que vous devez embaucher plus d'ingénieurs pour faire fonctionner ces nœuds et décoder les données brutes.

Ce modèle est similaire aux débuts d'Internet, lorsque les plates-formes de commerce électronique et les développeurs d'applications ont choisi de construire leurs propres installations IDC (Internet Data Center). Cependant, le coût va de pair avec la complexité de la conception du programme à mesure que les demandes des utilisateurs augmentent et que l'état du réseau blockchain explose. De plus, cette approche entrave l'expansion rapide du marché. Certaines chaînes de blocs publiques hautes performances nécessitent des opérations de nœud gourmandes en matériel, tandis que la synchronisation et le nettoyage des données consomment des ressources humaines et des coûts en temps.

Si vous essayez de créer un marché NFT basé sur la blockchain ou un jeu cool, n'est-il pas surprenant que 65 % des membres de votre équipe soient des ingénieurs backend et de données ?

** Peut-être que les développeurs se demanderont pourquoi personne ne décode et ne transmet ces données en chaîne pour eux afin qu'ils puissent se concentrer sur la création de meilleurs produits. **

** Je crois que c'est pourquoi les indexeurs sont là. **

Afin de réduire la difficulté d'accès aux applications Web3 et aux réseaux blockchain, de nombreuses équipes de développement, dont nous, choisissent d'intégrer des étapes telles que la maintenance des nœuds d'archivage, l'ETL de données en chaîne (extraire, transformer, charger) et les appels de base de données. Ces tâches nécessitaient à l'origine que l'équipe de projet se maintienne, mais maintenant, ils ont réalisé des opérations intégrées en fournissant des données multi-chaînes et des API de nœuds.

Avec l'aide de ces API, les utilisateurs peuvent personnaliser les données en chaîne en fonction de leurs besoins. Cela couvre tout, des métadonnées NFT populaires, à la surveillance de l'activité en chaîne d'adresses spécifiques, au suivi des données de transaction de pools de liquidités de jetons spécifiques. Je fais souvent référence à cette approche dans le cadre de la structure des projets Web3 modernes.

Le financement et la construction des projets de couche de données et de couche d'indexation seront principalement réalisés en 2022. Je crois que les pratiques commerciales de ces projets de couche d'indexation et de couche de données sont étroitement liées à la conception de leur architecture de données sous-jacente, en particulier à la conception de systèmes OLAP (On-Line Analytical Processing). L'adoption d'un moteur de base adapté est la clé pour optimiser les performances de la couche d'indexation, notamment en améliorant la vitesse d'indexation et en garantissant sa stabilité. Les moteurs couramment utilisés incluent Hive, Spark SQL, Presto, Kylin, Impala, Druid, ClickHouse, etc. Parmi elles, ClickHouse est une puissante base de données largement utilisée dans les sociétés Internet, elle a été open-source en 2016 et a reçu un financement de 250 millions de dollars américains en 2021.

Par conséquent, l'émergence d'une nouvelle génération de bases de données et d'architectures améliorées d'optimisation des index de données a conduit à la création de la couche d'index de données Web3. Cela permet aux entreprises de ce domaine de fournir des services d'API de données de manière plus rapide et plus efficace.

Cependant, la construction de l'indexation des données en chaîne est toujours entourée de deux nuages sombres.

Deux nuages sombres

Le premier nuage noir concerne l'impact de la stabilité du réseau blockchain côté serveur. Bien que le réseau blockchain ait une forte stabilité, ce n'est pas le cas lors de la transmission et du traitement des données. Par exemple, des événements tels que des réorganisations (reorgs) et des rollbacks (rollbacks) de la blockchain peuvent poser des problèmes à la stabilité des données de l'indexeur.

Une réorganisation de la blockchain se produit lorsque les nœuds perdent temporairement la synchronisation, ce qui entraîne l'existence simultanée de deux versions différentes de la blockchain. De telles situations peuvent être déclenchées par des pannes du système, des retards du réseau ou même un comportement malveillant. Lorsque les nœuds se resynchroniseront, ils convergeront vers une seule chaîne officielle, et les blocs alternatifs précédents "fourchus" seront ignorés.

Au moment où la réorganisation se produit, l'indexeur peut avoir traité des données à partir de blocs qui ont finalement été rejetés, polluant la base de données. Par conséquent, les indexeurs doivent s'adapter à cette situation, en supprimant les données sur les chaînes invalides et en retraiteant les données sur les chaînes nouvellement acceptées.

De tels ajustements peuvent entraîner une utilisation accrue des ressources et potentiellement retarder la disponibilité des données. Dans les cas extrêmes, des réorganisations de blocs fréquentes ou à grande échelle peuvent avoir un impact important sur la fiabilité et les performances des services qui dépendent des indexeurs, y compris les applications Web3 qui utilisent des API pour récupérer des données.

De plus, nous sommes confrontés à des problèmes de compatibilité des formats de données et de diversité des normes de données sur les réseaux blockchain.

Dans le domaine de la technologie blockchain, il existe de nombreux réseaux différents, chacun avec ses propres normes de données uniques. Par exemple, il existe des chaînes compatibles EVM (Ethereum Virtual Machine), des chaînes non EVM et des chaînes zk (zero-knowledge), chacune ayant sa propre structure et son propre format de données.

C'est sans aucun doute un grand défi pour les indexeurs. Afin de fournir des données utiles et précises via les API, les indexeurs doivent être capables de gérer ces divers formats de données. Cependant, comme il n'existe pas de norme universelle pour les données de la blockchain, différents indexeurs peuvent utiliser différentes normes API. Cela peut entraîner des problèmes de compatibilité des données, où les données extraites et transformées à partir d'un indexeur peuvent ne pas être utilisables dans un autre système.

De plus, au fur et à mesure que les développeurs explorent ce monde multi-chaînes, ils sont souvent confrontés au défi de gérer ces différentes normes de données. Une solution qui fonctionne pour un réseau blockchain peut ne pas fonctionner pour un autre, ce qui rend difficile le développement d'applications pouvant interagir avec plusieurs réseaux.

En effet, les défis auxquels est confrontée l'industrie de l'indexation de la blockchain rappellent deux problèmes non résolus en physique identifiés par Lord Kelvin au début du XXe siècle, qui ont finalement donné naissance à des domaines révolutionnaires tels que la mécanique quantique et la thermodynamique.

Face à ces défis, l'industrie a en effet pris certaines mesures, telles que l'introduction de la latence ou l'intégration du streaming dans le pipeline Kafka, et même la mise en place d'un consortium de normes pour renforcer l'industrie de l'indexation de la blockchain. Ces mesures sont actuellement en mesure de répondre à l'instabilité des réseaux blockchain et à la diversité des normes de données, afin que les indexeurs puissent fournir des données précises et fiables.

Cependant, tout comme l'avènement de la théorie quantique a révolutionné notre compréhension du monde physique, nous pouvons également envisager des moyens plus radicaux d'améliorer l'infrastructure de données de la blockchain.

** Après tout, l'infrastructure existante, avec ses entrepôts de données et ses piles bien organisés, peut sembler trop parfaite et trop belle pour être vraie. **

Alors, ** Y a-t-il un autre moyen ? **

Trouver des modèles

Revenons au sujet initial sur l'émergence des fournisseurs de nœuds et des indexeurs, et considérons un problème particulier. Pourquoi les opérateurs de nœuds ne sont-ils pas apparus en 2010, mais les indexeurs sont soudainement apparus en grand nombre et ont reçu beaucoup d'investissements en 2022 ?

Je crois que mon article ci-dessus a partiellement répondu à ces questions. Cela est dû à l'utilisation généralisée des technologies de cloud computing et d'entreposage de données dans l'industrie du logiciel, et pas seulement dans le domaine du chiffrement.

Dans le monde du cryptage, quelque chose de spécial s'est également produit, en particulier lorsque les normes ERC20 et ERC721 sont devenues populaires dans les médias publics. De plus, l'été DeFi a rendu les données en chaîne plus compliquées. Diverses transactions d'appel sont acheminées sur différents contrats intelligents, au lieu de simples données de transaction comme au début, le format et la complexité des données en chaîne ont subi des changements et une croissance surprenants.

Bien que dans la communauté des crypto-monnaies, il ait toujours été souligné de se séparer de la technologie Web2 traditionnelle, mais ce que nous ne pouvons ignorer, c'est que le développement de l'infrastructure de crypto-monnaie repose sur un développement continu et des percées dans les domaines des mathématiques, de la cryptographie, de la technologie cloud et du big data. . . Semblable à la structure traditionnelle chinoise à mortaise et tenon, les différents composants de l'écosystème de la crypto-monnaie sont étroitement liés.

Le progrès et l'application novatrice de la science et de la technologie seront toujours liés par certains principes objectifs. Par exemple, sans le support de base de la technologie de chiffrement à courbe elliptique, notre écosystème de crypto-monnaie ne peut pas exister aujourd'hui. De même, l'application pratique des preuves à connaissance nulle n'aurait pas été possible sans l'important document de recherche sur les preuves à connaissance nulle publié par le MIT en 1985. Nous voyons donc une tendance intéressante. ** La large application et l'expansion des fournisseurs de services de nœuds sont basées sur la croissance rapide des services cloud mondiaux et de la technologie de virtualisation. ** Dans le même temps, Le développement de la couche de données sur la chaîne est basé sur le développement vigoureux d'excellentes architectures et services de base de données open source,** ces architectures sont les solutions de données que de nombreux produits de business intelligence compter sur ces dernières années **. Ce sont tous des prérequis techniques que les startups doivent remplir pour atteindre la viabilité commerciale. En ce qui concerne les projets Web3, ceux qui utilisent une infrastructure avancée ont tendance à avoir un avantage sur ceux qui s'appuient sur des architectures obsolètes. L'érosion de la part de marché d'OpenSea par des échanges NFT plus rapides et plus conviviaux en est un exemple frappant.

De plus, nous pouvons également voir une tendance évidente : l'intelligence artificielle (IA) et la technologie LLM ont progressivement mûri et ont la possibilité d'une large application.

**Par conséquent, une question importante émerge : comment l'IA modifiera-t-elle le modèle de données sur la chaîne ? **

Voyance

Prédire l'avenir est toujours semé d'embûches, mais nous pouvons explorer les réponses possibles en comprenant les problèmes rencontrés dans le développement de la blockchain. **Les développeurs ont une demande claire de données en chaîne : ce dont ils ont besoin, ce sont des données en chaîne précises, opportunes et faciles à comprendre. **

L'un des problèmes auxquels nous sommes actuellement confrontés est que des requêtes SQL complexes sont nécessaires pour obtenir ou afficher certaines données par lots. C'est pourquoi la fonctionnalité SQL open source fournie par Dune est si populaire dans la communauté crypto. Les utilisateurs n'ont pas besoin d'écrire SQL pour créer des graphiques à partir de zéro, ils n'ont qu'à bifurquer et modifier l'adresse du contrat intelligent auquel ils veulent prêter attention, puis ils peuvent créer les graphiques dont ils ont besoin. Cependant, cela reste encore trop compliqué pour l'utilisateur moyen qui ne souhaite visualiser les données de liquidité ou de largage que sous certaines conditions.

À mon avis, la première étape pour résoudre ce problème consiste à utiliser le LLM et le traitement du langage naturel.

Nous pouvons créer une interface de "requête de données" plus centrée sur l'utilisateur et tirer parti des techniques LLM. Dans les cas existants, les utilisateurs doivent utiliser des langages de requête complexes tels que SQL ou GraphQL pour extraire les données en chaîne correspondantes de l'API ou des studios. Cependant, en utilisant LLM, nous pouvons introduire une manière plus intuitive et plus humaine de poser des questions. De cette manière, les utilisateurs peuvent exprimer leurs questions en "langage naturel", et LLM les traduira en requêtes appropriées et fournira aux utilisateurs les réponses dont ils ont besoin.

Du point de vue des développeurs, l'intelligence artificielle peut également optimiser l'analyse des événements contractuels sur la chaîne et le décodage ABI. Actuellement, les détails de nombreux contrats DeFi obligent les développeurs à les analyser et à les décoder manuellement. Cependant, si l'intelligence artificielle est introduite, nous pouvons améliorer considérablement diverses techniques de désassemblage de contrats et récupérer rapidement l'ABI correspondant. Combinée à un grand modèle de langage (LLM), cette configuration peut analyser intelligemment les signatures de fonction et gérer efficacement divers types de données. De plus, lorsque le système est combiné avec le cadre de traitement "stream computing", il peut traiter l'analyse des données de transaction en temps réel pour répondre aux besoins immédiats des utilisateurs.

D'un point de vue plus global, l'objectif d'un indexeur est de fournir aux utilisateurs des données précises. Comme je l'ai déjà souligné, un problème potentiel avec la couche de données en chaîne est que des éléments de données individuels sont dispersés dans différentes bases de données d'indexation et isolés les uns des autres. Afin de répondre aux divers besoins en données, certains concepteurs choisissent d'intégrer toutes les données de la chaîne dans une base de données, afin que les utilisateurs puissent sélectionner les informations requises à partir d'un ensemble de données unique. Certains protocoles choisissent de n'inclure que certaines données, telles que les données DeFi et les données NFT. Mais le problème des normes de données incompatibles existe toujours. Parfois, les développeurs doivent extraire des données de plusieurs sources et les reformater dans leur propre base de données, ce qui augmente sans aucun doute leur charge de maintenance. De plus, ils ne peuvent pas migrer rapidement vers un autre fournisseur en cas de problème avec un fournisseur de données.

Alors, comment LLM et AI peuvent-ils résoudre ce problème ? LlamaIndex m'a fourni une révélation. Que se passe-t-il si les développeurs n'ont pas besoin d'un indexeur, mais utilisent un service proxy déployé (agent) pour lire directement les données brutes sur la chaîne ? Cet agent combine les technologies d'indexeur et de LLM. Du point de vue de l'utilisateur, il n'a pas besoin de connaître quoi que ce soit sur l'API ou le langage de requête, il lui suffit de poser des questions et d'obtenir un retour instantané.

Équipé de la technologie LLM et de l'intelligence artificielle, Agent comprend et traite les données brutes et les convertit dans un format facile à comprendre pour les utilisateurs. Cela élimine le besoin pour les utilisateurs de faire face à des API complexes ou à des langages de requête, et ils peuvent simplement poser des questions en langage naturel et obtenir des commentaires en temps réel. Cette fonctionnalité augmente l'accessibilité et la convivialité des données, attirant une base d'utilisateurs plus large pour accéder aux données en chaîne.

De plus, le mode de service d'agent (Agent) résout le problème d'incompatibilité des normes de données. Puisqu'il a été conçu avec la capacité d'analyser et de traiter des données brutes en chaîne, il peut s'adapter à différents formats et normes de données. Par conséquent, les développeurs n'ont pas besoin de reformater les données provenant de différentes sources, ce qui réduit leur charge de travail.

Bien sûr, il ne s'agit que d'une spéculation sur la trajectoire de développement future des données en chaîne. Mais dans le domaine de la technologie, ce sont souvent ces idées et théories audacieuses qui sont à l'origine des progrès révolutionnaires. Nous devons nous rappeler que, qu'il s'agisse de l'invention de la roue ou de la naissance de la blockchain, toutes les avancées majeures partent d'une hypothèse ou d'une idée "folle" de quelqu'un.

Alors que nous acceptons le changement et l'incertitude, nous sommes également mis au défi de repousser continuellement les limites du possible. Dans ce contexte, nous envisageons un monde où la combinaison de l'IA, du LLM et de la blockchain engendrera un domaine technologique plus ouvert et inclusif.

Chainbase soutient cette vision et s'engage à en faire une réalité.

Notre mission chez Chainbase est de créer une infrastructure de données cryptées ouverte, conviviale, transparente et durable. Notre objectif est de simplifier l'utilisation de ces données par les développeurs, en éliminant le besoin d'une refactorisation complexe de la pile technologique backend. De cette façon, nous espérons inaugurer un avenir dans lequel la technologie non seulement sert les utilisateurs, mais les responsabilise.

Cependant, je dois préciser que ce n'est pas notre feuille de route. Il s'agit plutôt de ma réflexion personnelle sur le développement et les progrès récents des données en chaîne dans la communauté en tant que représentant des relations avec les développeurs.