Feuille de route du stockage Ethereum : défis et opportunités
TechFlow SélectionTechFlow Sélection
Feuille de route du stockage Ethereum : défis et opportunités
La demande croissante de stockage pose d'importants défis aux nœuds Ethereum.
Dédié à des analyses Web3 approfondiesRédaction : EthStorage
Résumé
-
La demande croissante en stockage pose un défi majeur aux nœuds Ethereum.
-
En raison des limitations de stockage, certains clients ont commencé à supprimer les données historiques, entraînant une incohérence entre les comportements de stockage des nœuds complets du réseau.
-
Afin d'assurer la cohérence entre tous les clients, la suppression des données historiques est en cours de normalisation via EIP-4444 et EIP-4844.
-
Par conséquent, la récupération de l'état le plus récent d'une L1 ou d'une L2 par relecture des données historiques nécessite désormais des services centralisés hors protocole, ce qui pousse à explorer des solutions plus décentralisées et compatibles avec Ethereum.
-
Le réseau Portal d'Ethereum est un réseau pair-à-pair léger et décentralisé, conçu pour tous types de données Ethereum, y compris les données historiques. Spécialement pensé pour les appareils aux ressources limitées, il fournit des services JSON-RPC Ethereum. Les réseaux historique et Beacon sont presque prêts.
-
Le réseau EthStorage est un réseau modulaire de stockage incitatif dédié aux données BLOBs de l’EIP-4844. Pour stocker un BLOB, l'utilisateur appelle la méthode put() du contrat de stockage sur la L1 en fournissant des ETH comme frais de stockage, et le hachage du BLOB est enregistré sur la chaîne. Au fil du temps, ces frais seront progressivement distribués aux fournisseurs de stockage ayant soumis des preuves valides de stockage hors chaîne. Le testnet d’EthStorage fonctionne actuellement sur le réseau Sepolia d’Ethereum, et plusieurs participants de la communauté ont déjà réussi à prouver leur stockage local.
-
Les prochaines étapes incluent le développement d’un réseau d’état Ethereum décentralisé, la mise en œuvre de preuves de stockage pour des données de taille variable, ainsi qu’un accès décentralisé direct depuis les navigateurs.
Remerciements : Merci à Piper Merriam (EF), Karthik Raju (Polychain) et Qiang (EthStorage) pour leurs retours sur cet article.
Contexte
Le 22 octobre 2023, Peter Szilágyi, responsable principal du développement de Go-Ethereum (Geth), a exprimé publiquement ses inquiétudes sur Twitter. Il a souligné que bien que le client Geth conserve toutes les données historiques, d'autres clients Ethereum tels que Nethermind et Besu peuvent être configurés pour supprimer certaines données historiques (comme les blocs et en-têtes passés). Cette divergence compromet l'uniformité du comportement des clients et crée une situation injuste pour Geth. Cela a déclenché un vif débat au sein de la communauté Ethereum autour du problème de stockage dans la feuille de route du réseau.
Défis liés au stockage
Pourquoi Nethermind et Besu ont-ils choisi d'arrêter de stocker les données historiques ? Quel est le problème sous-jacent à cette décision ? De notre point de vue, deux raisons principales se distinguent :
-
Les exigences de stockage des clients Ethereum deviennent de plus en plus élevées.
-
Il n'existe aucune incitation ni sanction protocolaire pour le stockage des données historiques d’Ethereum.
La première raison découle de la pression croissante sur les ressources liée à l’exécution d’un client Ethereum. Pour mieux comprendre ces besoins, le diagramme circulaire ci-dessous montre la répartition du stockage d’un nouveau nœud Geth au bloc 18 779 761, le 13 décembre 2023.
Comme indiqué :
-
Taille totale du stockage : 925,39 Go
-
Données historiques (blocs / reçus de transactions) : environ 628,69 Go
-
Données d’état dans l’arbre de Merkle Patricia (MPT) : environ 269,74 Go
La deuxième raison est l’absence d’incitations ou de sanctions protocolaires pour le stockage des blocs historiques. Bien que le protocole exige que les nœuds conservent toutes les données historiques, il ne prévoit aucun mécanisme pour encourager ce stockage ni sanctionner ceux qui s’y soustraient. Le stockage et le partage des données historiques deviennent donc purement altruistes, et les opérateurs de clients peuvent librement supprimer ou modifier ces données sans aucune conséquence. En comparaison, les validateurs doivent maintenir localement et mettre à jour l’état complet afin d’éviter les pénalités (slashings) liées à la proposition ou validation de blocs invalides.
Par conséquent, lorsque le coût du stockage devient trop élevé, il n’est pas surprenant que certains opérateurs de nœuds choisissent de supprimer les données historiques. Sans celles-ci, les clients peuvent réduire considérablement leurs besoins de stockage, passant d’environ 1 To à environ 300 Go.
Illustration : Configuration Nethermind permettant d’exécuter un nœud sans blocs historiques — économie actuelle d’environ 460 Go de stockage
Avec la mise à niveau imminente de la disponibilité des données (DA) d’Ethereum, ce défi va s’accentuer. La voie vers une scalabilité accrue de la DA Ethereum commence avec l’EIP-4844 intégré au fork DenCun, introduisant un objet binaire volumineux (BLOB) de taille fixe et un modèle de frais indépendant appelé blobGasPrice. Chaque BLOB étant fixé à 128 Ko, l’EIP-4844 autorise jusqu’à 6 BLOBs par bloc. Pour augmenter le débit de données, Ethereum prévoit d’utiliser un code Reed-Solomon 1D, permettant initialement 32 BLOBs par bloc, puis 256 en pleine capacité.
Si la couche DA d’Ethereum fonctionnait à pleine capacité (256 BLOBs par bloc), elle recevrait environ 80 To de données annuelles, un volume largement supérieur aux capacités de stockage de la majorité des nœuds.
Feuille de route du stockage Ethereum et ses conséquences
Publication de la feuille de route Ethereum par Vitalikvia Twitter, mentionnant que « Purge » concerne principalement le stockage
L’augmentation constante des coûts de stockage attire l’attention des chercheurs de l’écosystème Ethereum. Pour résoudre ce problème et garantir l’uniformité entre tous les clients, des propositions visant à formaliser la suppression des données historiques sont en cours d’élaboration. Deux propositions principales se distinguent :
-
EIP-4444 : Limiter les données historiques dans les clients d’exécution : Cette proposition permet aux clients de supprimer les blocs dont l’âge dépasse un an. En supposant une taille moyenne de bloc de 100 Ko, cela limite les données historiques à environ 250 Go (100K * (3600 * 24 * 365) / 12, avec un intervalle de bloc = 12 secondes).
-
EIP-4844 : Transactions de BLOBs shardisées : L’EIP-4844 supprime les BLOBs âgés de plus de 18 jours. Comparé à l’EIP-4444, cette approche est plus radicale, limitant la taille des BLOBs historiques à environ 100 Go ((18 * 3600 * 24) * 128K * 6 / 12, avec un intervalle de bloc = 12 secondes).
Quelles sont les conséquences de la suppression des données historiques sur tous les clients ? La principale est que les nouveaux nœuds ne peuvent plus synchroniser l’état le plus récent via le mode « full sync », qui consiste à exécuter toutes les transactions depuis le bloc de genèse. À la place, ils doivent utiliser « snap sync » ou « state sync » pour récupérer directement l’état le plus récent depuis un autre nœud Ethereum. Cette méthode est déjà implémentée dans Geth et utilisée par défaut.
De même, cette contrainte affecte également toutes les L2 : les nouveaux nœuds L2 ne peuvent plus synchroniser complètement l’état le plus récent en rejouant toutes les transactions depuis la genèse L2. De plus, comme les nœuds L1 ne conservent pas l’état L2, la méthode « snap sync » ne peut pas dériver l’état L2 le plus récent à partir de la L1, ce qui contrevient à l’hypothèse fondamentale de sécurité héritée par les L2. La solution attendue repose alors sur des services tiers comme Infura, Etherscan ou les projets L2 eux-mêmes pour stocker les données historiques ou des copies d’état. Il s’agit d’une solution centralisée, réalisée hors protocole et par des incitations indirectes.
La question centrale que nous souhaitons explorer est la suivante :
-
Pouvons-nous trouver de meilleures solutions décentralisées pour le stockage et l’accès aux données ?
-
Est-il possible de concevoir des solutions compatibles avec Ethereum, dotées d’incitations directes intégrées au protocole (par exemple, via des contrats sur la L1) ?
-
Sur cette base, pouvons-nous proposer une solution entièrement décentralisée et directement incitative au sein du protocole pour le stockage Ethereum ?
Solutions
Solution 1 : Réseau Portal d’Ethereum
Le réseau Portal d’Ethereum est un réseau d’accès léger et décentralisé conçu pour interagir avec le protocole Ethereum. Il propose des interfaces JSON-RPC Ethereum telles que eth_call ou eth_getBlockByNumber, en transformant les requêtes JSON-RPC en requêtes P2P vers une table de hachage distribuée (DHT), similaire au réseau IPFS. Contrairement à IPFS, qui permet de stocker tout type de données mais est vulnérable au spam, le réseau P2P Portal héberge exclusivement des données Ethereum telles que les en-têtes de blocs historiques ou les transactions, grâce à une technologie intégrée de vérification par client léger.
Une caractéristique clé du réseau Portal est sa conception légère et sa compatibilité avec les appareils aux ressources limitées. Il peut fonctionner sur des nœuds disposant de quelques mégaoctets de stockage et d’une faible mémoire, favorisant ainsi la décentralisation. Même un téléphone portable ou un Raspberry Pi pourrait rejoindre le réseau et contribuer à la disponibilité des données Ethereum.
Le développement du réseau Portal s’inscrit dans la diversité des clients Ethereum, avec des implémentations en Rust, JavaScript et Nim. Le réseau Beacon et le réseau historique sont déjà disponibles, tandis que le réseau d’état est en cours de développement. À noter que le réseau Portal ne propose pas d’incitation directe au stockage — tous les nœuds fonctionnent sur un mode altruiste.
Illustration : Client Rust du réseau Portal (Trin) en fonctionnement avec une limite de stockage de 100 Mo
Solution 2 : Réseau EthStorage
Le réseau EthStorage est un réseau de stockage décentralisé et incitatif, spécialisé dans le stockage des BLOBs de l’EIP-4844, financé par le projet ESP.
-
Faible niveau de confiance : Contrairement aux solutions existantes nécessitant un pont de données centralisé, EthStorage s’appuie sur le consensus d’Ethereum et adopte un modèle de confiance 1/m reposant sur des nœuds de stockage EthStorage accessibles sans permission. Le processus de stockage d’un BLOB est le suivant : l’utilisateur signe une transaction contenant le BLOB et appelle la méthode put(key, blob_idx) du contrat de stockage. Ce dernier enregistre alors le hachage du BLOB sur la chaîne. Par la suite, les fournisseurs de stockage téléchargent et conservent directement les BLOBs depuis le réseau DA d’Ethereum, évitant ainsi toute dépendance à un pont centralisé.
-
Adéquation entre coût du stockage et incitations : Lors de l’appel à la méthode put(), la transaction doit inclure des frais de stockage (via msg.value) vers le contrat. Une fois qu’un nœud de stockage hors chaîne a soumis et validé une preuve de stockage, ces frais sont progressivement distribués au fil du temps. Comparé au modèle actuel où les frais sont payés une seule fois au validateur proposant le bloc, cette distribution progressive suit un modèle de flux de trésorerie actualisé — basé sur l’hypothèse que le coût du stockage diminuera relativement au prix de l’ETH. Cette innovation majeure d’EthStorage garantit une adéquation entre les frais perçus et la contribution effective des nœuds au stockage.
-
Preuve de stockage : Inspirée de l’échantillonnage de disponibilité des données, la preuve de stockage dans EthStorage cible les BLOBs conservés sur une période donnée. Pour valider efficacement ces échantillons sur la chaîne, EthStorage exploite pleinement les dernières avancées en matière de contrats intelligents et de technologie SNARK.
-
Accès sans permission : Tout nœud de stockage dans EthStorage peut être rémunéré s’il conserve les données et soumet régulièrement des preuves de stockage sur la chaîne.
Du point de vue de la blockchain modulaire, EthStorage agit comme une couche L2 de stockage pour Ethereum, mais facture des frais de stockage plutôt que des frais de transaction. En indexant les hachages des BLOBs sur la chaîne, EthStorage constitue une couche modulaire de stockage pour Ethereum, améliorant la scalabilité du stockage et réduisant les coûts (objectif : environ 1 000 fois moins chers).
Sur le plan technique, EthStorage est déjà intégré à l’EIP-4844 sur le testnet Sepolia d’Ethereum. Nous avons réalisé des tests de charge combinant EthStorage et Sepolia, notamment l’écriture de plusieurs centaines de Go de BLOBs. Plus de 100 participants communautaires ont rejoint le réseau et ont réussi à prouver leur stockage local.
Le principal avantage du réseau EthStorage réside dans son incitation directe et décentralisée construite au-dessus d’Ethereum — à notre connaissance, une fonctionnalité pionnière. Toutefois, sa limitation actuelle est d’être conçu uniquement pour des BLOBs de taille fixe.
Tableau de bord d’EthStorage sur le testnet Sepolia d’Ethereum
Perspectives futures
Bien que le stockage Ethereum n’ait pas encore attiré l’attention principale, il joue un rôle crucial dans l’écosystème. Avec la croissance rapide du réseau, la disponibilité et l’accessibilité des données Ethereum deviennent des défis critiques. Les réseaux Portal et EthStorage en sont encore à leurs débuts, et plusieurs axes stratégiques à long terme méritent une attention soutenue :
-
Réseau décentralisé d’accès à faible latence aux données d’état Ethereum. Accéder de manière décentralisée et vérifiable à l’état Ethereum est une tâche essentielle mais complexe. Avec un modèle DHT classique, l’interrogation d’informations de compte nécessite souvent plusieurs requêtes vers différents nœuds P2P pour récupérer les nœuds internes de l’arbre trie. Cela entraîne généralement des délais importants. L’optimisation de l’accès en exploitant la structure de l’arbre d’état est donc cruciale. Le réseau d’état, bientôt lancé par Portal, vise précisément à résoudre ce problème.
-
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
Ajouter aux favorisPartager sur les réseaux sociauxAuteurEthStorage
