Pourquoi Web3 n’arrive pas à lire — ForkLog

# Pourquoi Web3 ne sait pas lire

Il y a encore quelques années, l’industrie débattait de la façon d’augmenter la bande passante des blockchains. Aujourd’hui, de nombreux réseaux sont déjà capables de traiter des dizaines de milliers d’opérations, et certains annoncent des centaines de milliers. Pourtant, il s’est avéré que l’écriture des données dans une blockchain n’est que la moitié du problème. Il faut encore les trouver, les indexer, les vérifier et les livrer aux applications.

Ainsi, la vitesse de génération des données a parfois commencé à dépasser les capacités d’infrastructure pour les traiter. Comment, dans ce contexte, la blockchain évolue — ForkLog l’a analysé.

Plus vite, donc plus longtemps

Il y a une dizaine d’années, le développement des blockchains était décrit à travers la soi-disant trilémme de la scalabilité. Selon cette idée, les réseaux doivent trouver un compromis entre sécurité, décentralisation et performance. Mais en 2026, il devient évident que même si le problème de bande passante est partiellement résolu, un nouveau défi apparaît.

À lui seul, le blockchain n’a pas d’interfaces utilisateur. Ce rôle est assuré par diverses applications. Et elles doivent, en retour, recevoir constamment des données :

• les soldes des adresses ;
• l’historique des transactions ;
• l’état des smart contracts ;
• les événements et les logs ;
• l’analytics marché ;
• les données pour la gestion des risques ;
• les messages inter-réseaux.

Plus le réseau fonctionne vite, plus il faut traiter de données de ce type

Parmi les utilisateurs, il existe une croyance répandue : si l’information est enregistrée dans la blockchain, alors il suffit de la récupérer. En pratique, c’est exactement l’inverse. Lire des données « brutes » directement depuis la blockchain en temps réel est un processus lent, coûteux et techniquement complexe. Dans l’écosystème Web3, une couche d’infrastructure intermédiaire, qui relie les wallets aux applications dapp, est largement utilisée.

Par exemple, pour qu’une application-wallet affiche le solde de l’utilisateur en quelques fractions de seconde, elle s’adresse à des fournisseurs RPC, à des indexeurs, à des plateformes d’analyse, à des serveurs de cache, à des bases de données spécialisées, etc.

Le processus fonctionne comme suit :

1. Collecte des données : Des programmes spécialisés « lisent » en continu la blockchain au fur et à mesure de l’apparition des nouveaux blocs.
2. Indexation (structuration) : Ils analysent (découpent) ces données et les répartissent dans des bases de données classiques, très rapides (par exemple PostgreSQL ou ClickHouse). Là, elles sont structurées sous une forme pratique : « Adresse — Liste de tous ses tokens ».
3. Réponse instantanée : Le wallet reçoit une réponse déjà prête et filtrée depuis le cache, en quelques millisecondes.

En fait, la plupart des applications Web3 populaires fonctionnent via une couche supplémentaire de traitement de l’information. Imaginez : si la blockchain traite 50 000 opérations par seconde, et que des millions de wallets envoient en même temps des requêtes RPC pour mettre à jour les écrans. Les serveurs des fournisseurs ne tiennent pas cette charge. Lire, indexer et trier des données pour l’utilisateur est une tâche de calcul des plus complexes. Les indexeurs et les services d’accès aux données prennent souvent du retard sur l’état actuel du réseau de quelques blocs, car le traitement, la structuration et la livraison des données demandent du temps supplémentaire. Et ce n’est pas seulement une question de « mauvaise infrastructure », même si c’est évidemment le cas aussi. C’est un conflit plus profond entre les architectures Web2 et Web3

Les utilisateurs et les applications interagissent avec la blockchain aussi activement et souvent que, dans l’internet traditionnel, on interagit avec une réponse instantanée. Quand vous faites défiler le fil d’une application de réseau social, l’application fait des milliers de requêtes par seconde à un serveur pour mettre à jour les likes, les commentaires et les images. Dans Web2, les bots de trading peuvent interroger les serveurs des bourses des millions de fois par minute. Les serveurs Google ou Amazon tiennent facilement le rythme, car ils sont centralisés : les données sont, en gros, dans une immense base unique, d’où elles peuvent être copiées instantanément sur des milliers de serveurs miroirs à travers le monde.

La blockchain fonctionne autrement : elle n’est pas conçue pour ce type de configuration matérielle. Jusqu’à récemment, le principal frein de la vitesse dans la blockchain était la logique mathématique et la cryptographie. Il fallait obliger des milliers d’ordinateurs dans le monde entier à parvenir rapidement à un accord (consensus) sur le fait qu’une transaction est valide. Les développeurs ont résolu ce problème en « apprenant » aux machines à exécuter en parallèle et en séparant consensus et exécution. Par exemple, Solana, Monad et Aptos prennent en charge l’exécution parallèle de transactions indépendantes, contrairement au modèle séquentiel classique d’Ethereum. Dans le cas de Monad, l’ordre de validation des transactions et leur exécution sont particulièrement clairement séparés, tandis que, dans Solana et Aptos, le parallélisme est implémenté via l’architecture runtime et la gestion des conflits par état.

Au final, on peut valider des dizaines de milliers de transactions par seconde (TPS). Mais c’est là que se cache le piège.

Historiquement, la blockchain exécutait directement quatre fonctions :

• exécution des transactions ;
• consensus ;
• stockage des données ;
• fourniture d’accès aux données.

L’augmentation des performances augmente simultanément la charge sur ces quatre fonctions. Le système commence à générer des données plus vite que l’infrastructure ne peut les lire, ce qui crée le fameux indexer gap.

Dans la documentation de Helius — l’un des plus grands fournisseurs d’infrastructure de l’écosystème Solana — il est indiqué noir sur blanc que la structure séquentielle de la blockchain convient bien pour garantir l’intégrité des données et une forte bande passante, mais qu’elle rend les requêtes historiques lentes et inefficaces. C’est pourquoi la plupart des entreprises sont contraintes de construire leurs propres indexeurs et des bases de données distinctes au-dessus de la blockchain.

Les analystes de ChainScore Labs qualifient l’indexer gap de l’un des problèmes clés de l’écosystème Solana. D’après leurs estimations, les approches traditionnelles d’indexation gèrent mal l’architecture d’un réseau où la fréquence élevée des blocs et l’exécution parallèle des transactions créent un flux massif de données.

Le résultat est le suivant : le réseau peut confirmer les opérations presque instantanément, mais les applications ont besoin de beaucoup plus de temps pour traiter les conséquences de ces opérations.

Les vitesses Web3 se heurtent à une physique banale (et pas seulement)

Plus précisément : à la bande passante des processeurs, des disques durs et des câbles réseau. Il s’est avéré que la scalabilité de la blockchain n’est pas égale à la scalabilité de l’infrastructure qui l’entoure. Et il faut le résoudre au plus vite

Imaginons un réseau avec 100 000 TPS. Il ne faut pas seulement enregistrer la transaction, mais aussi :

• conserver l’état ;
• mettre à jour les index ;
• répondre aux requêtes des wallets ;
• servir les bots ;
• servir les analystes ;
• servir les moteurs de recherche ;
• servir les agents IA.

Ainsi, une forte bande passante crée une concurrence pour les ressources entre le consensus, l’exécution des transactions et les services d’infrastructure au-dessus du réseau.

Le développement parallèle de certaines technologies impliquées force à traiter ce problème dès maintenant. Pour un humain, un délai de quelques secondes, voire de quelques minutes, peut tout à fait être toléré. Pour les agents IA, les systèmes de trading et les services autonomes, ce n’est plus le cas. Si une machine prend des décisions à partir de données on-chain, alors une information obsolète signifie une erreur, une perte de capacité, ou même une perte financière directe.

En parallèle, dans une documentation mise à jour pour 2026, la Ethereum Foundation indique que les nœuds d’archive demandent entre 3 et 12 ТБ d’espace disque, et que la synchronisation initiale peut durer jusqu’à un mois même avec du matériel suffisamment puissant. La limite vient de la vitesse des SSD, de la quantité de mémoire et des performances du processeur.

De plus, les développeurs de Geth décrivent séparément l’ancienne modélisation du stockage d’archives, où la taille de la base d’Ethereum pouvait dépasser 20 ТБ et la synchronisation durait des mois. C’est précisément pour cela qu’il a fallu créer une nouvelle architecture de stockage path-based.

Autrement dit, oui : le « matériel », les processeurs, la bande passante du réseau, le CPU — ce sont bien de vraies limites physiques dans la course à la croissance de l’information. Mais elles ne sont pas les seules. Les serveurs modernes peuvent déjà traiter d’énormes volumes de données. La vraie question est : combien faut-il que paient les milliers d’acteurs indépendants du réseau pour cela ?

Par exemple, si une participation complète à l’écosystème nécessite des dizaines de téraoctets de SSD, des centaines de gigaoctets de RAM, des canaux de communication coûteux, alors le nombre d’opérateurs d’infrastructure diminue inévitablement. C’est ainsi qu’émerge une nouvelle centralisation.

En théorie, on peut traiter les données, mais il sera impossible de le faire à la fois à faible coût et de façon décentralisée. Le coût du traitement de l’information commence à augmenter plus vite que le coût des transactions elles-mêmes.

Comment le marché a réagi

Les participants à la course comprennent déjà que les gagnants seront les réseaux capables de transformer plus vite, plus simplement et plus fiablement les transactions en informations disponibles. Et, au cours de l’année en cours, le marché a déplacé de façon inattendue son attention vers le passage à des blockchains modulaires.

Si la première génération de réseaux essayait d’exécuter toutes les tâches en même temps, la nouvelle génération répartit les responsabilités entre des couches spécialisées. Au lieu d’un seul réseau, on a vu apparaître des couches distinctes :

• execution layer — niveau d’exécution (ou de traitement) ;
• settlement layer — niveau de règlement (d’aboutissement) ;
• consensus layer — niveau de consensus ;
• data availability layer — niveau de disponibilité des données.

Les développeurs comparent ce processus à l’évolution des data centers. Avant, un seul serveur remplissait toutes les fonctions à la fois. Aujourd’hui, les calculs, le stockage et les services réseau sont mis à l’échelle indépendamment les uns des autres

L’un des secteurs qui a le plus rapidement pris de la valeur sur le marché, ce sont les réseaux DA. À première vue, l’idée semble étrange : pourquoi créer une blockchain distincte pour le stockage temporaire des données d’une autre blockchain ? Mais c’est exactement ce qui se passe. Dans l’architecture modulaire, l’exécution des transactions et le stockage des données peuvent exister séparément. Le Rollup publie les données dans une couche DA externe, et non dans le réseau principal. Cela permet de réduire considérablement le coût de la scalabilité et d’augmenter la bande passante.

Il y a encore quelques années, le RPC était considéré comme un détail technique. Aujourd’hui, c’est l’un des éléments les plus importants de la cryptoinfrastructure. En mai 2026, Triton One, conjointement avec Solana Foundation, a publié une annonce mise à jour de RPC 2.0 — une nouvelle approche de construction de l’architecture de lecture des données dans le réseau

L’idée clé consiste à séparer l’accès à l’état actuel du réseau et à son historique. Pour cela, deux modules indépendants sont introduits : l’un indexe l’état des comptes en temps réel, le second optimise le travail avec les données historiques. Au lieu d’un balayage complet de la blockchain, le système construit des index adaptatifs pour les requêtes spécifiques des applications, ce qui réduit la latence et le coût de traitement.

Ainsi, Triton et Solana cherchent à éliminer plusieurs limitations systémiques : l’architecture monolithique RPC coûteuse et inefficace des nœuds, un ensemble étroit de requêtes standards JSON-RPC, et la dépendance des développeurs à leurs propres solutions ou à des solutions propriétaires pour travailler avec les données. Dans le nouveau modèle, la lecture se met à l’échelle séparément du consensus, et l’accès à l’historique devient plus rapide grâce à l’utilisation de stockage par colonnes et de données pré-triées.

Le projet s’appuie sur des outils déjà déployés dans l’écosystème — y compris la transmission en flux des données depuis les validateurs (Geyser, Yellowstone gRPC) et des solutions pour le traitement de l’historique. Toute l’infrastructure est distribuée avec du code source ouvert, et son développement est coordonné avec la participation de Solana Foundation.

En conséquence, Solana essaie en pratique de passer d’un RPC « universel » à une infrastructure de données modulaire et spécialisée, qui est censée réduire les barrières pour les développeurs et rendre le travail avec les données de la blockchain comparable en confort à celui des bases de données traditionnelles.

La modularité résout-elle le problème ?

Si Solana parvient à standardiser la couche de lecture, cela pourrait renforcer sa position comme réseau disposant d’une infrastructure applicative développée, et pas seulement d’une forte bande passante. Mais en même temps, cela intensifie la concurrence avec les fournisseurs RPC indépendants et les plateformes d’infrastructure, qui devront soit s’adapter à ce nouveau standard, soit proposer des services supplémentaires au-dessus.

L’architecture modulaire élimine une partie des limitations d’infrastructure, mais les transfère dans d’autres couches du système. On comprend la volonté de réduire les coûts et de simplifier l’accès aux données dont dépendent DeFi, NFT, wallets, l’analytics et les outils de conformité. Cependant, il semble que, dans la nature même de Web3, il existe un effet de complexification en cascade : résoudre un problème crée inévitablement de nouveaux défis.

Le nouveau schéma exigera sans ambiguïté une surcouche d’infrastructure plus complexe : avec des indexeurs, des entrepôts, un cache, des pipelines distincts et de nouveaux points de défaillance. Au lieu d’une couche RPC unique et simple, l’écosystème pourrait se retrouver avec plusieurs implémentations parallèles, des optimisations incompatibles, et une dépendance encore plus forte envers les fournisseurs d’infrastructure. Dans ce cas, formellement, une architecture ouverte ne signifie pas forcément un modèle d’accès réellement ouvert et pratique pour tous.

Pour l’instant, nous en sommes à une étape où le marché est passé de la concurrence sur la capacité à extraire les données du réseau à la course pour créer les premiers produits à partir de ces données. Qui paiera et combien — nous le saurons probablement très bientôt