Résumé

• Les demandes croissantes de stockage présentent des défis importants pour les nœuds Ethereum.
• Certains clients ont commencé à élaguer les données historiques en raison de contraintes de stockage, ce qui entraîne des comportements de stockage incohérents parmi les nœuds complets du réseau.
• Pour garantir l'alignement de tous les clients, la taille des données historiques est normalisée dans l'EIP-4444 et l'EIP-4844
• Par conséquent, la récupération de l'état L1 ou L2 le plus récent en rejouant des données historiques repose sur des services centralisés en dehors du protocole, ce qui incite à explorer des solutions plus décentralisées alignées sur Ethereum
• Le réseau Ethereum Portal est un réseau P2P léger et décentralisé pour tous les types de données Ethereum, y compris les données historiques. Il est conçu pour les appareils à ressources limitées et fournit un service JSON-RPC Ethereum. Le réseau historique et le réseau de balises sont presque prêts à être utilisés.
• Le réseau de stockage EthStorage est un réseau de stockage modulaire incentivé pour les BLOBs EIP-4844. Pour stocker un BLOB, un utilisateur appelle le contrat de stockage L1mettre()méthode avec le hachage BLOB et des frais en ETH. Les frais seront progressivement distribués aux fournisseurs de stockage lors de la soumission d'une preuve valide de stockage de BLOBs hors chaîne au fil du temps. Le testnet EthStorage fonctionne sur le testnet Ethereum Sepolia avec plusieurs participants de la communauté prouvant avec succès leur stockage local.
• Les futures initiatives comprennent le développement d'un réseau d'État décentralisé, la mise en œuvre de la preuve de stockage pour des données de taille dynamique et un accès décentralisé directement depuis les navigateurs.

Remerciements : Un grand merci à Piper Merriam de l'EF, Karthik Raju de Polychain, Qiang d'EthStorage pour avoir donné leur avis sur l'article.

Arrière-plan

Le 22 octobre 2023, Péter Szilágyi, le célèbre responsable du développement de Go-Ethereum (Geth), a exprimé ses profondes préoccupations sur Twitter. Il a souligné que tandis que les clients Geth conservent toutes les données historiques, d'autres clients Ethereum comme Nethermind et Besu peuvent être configurés pour fonctionner sans certaines données historiques d'Ethereum, telles que les corps de blocs et les en-têtes historiques. Cela rend tous les clients incohérents et est injuste pour Geth. Cela a suscité des discussions intenses et des débats autour du problème de stockage d'Ethereum dans la feuille de route d'Ethereum.

Le défi de stockage

Pourquoi Nethermind et Besu choisissent-ils d'arrêter de stocker des données historiques? Quels problèmes sous-tendent cette décision? De mon point de vue, il y a deux causes profondes principales:

• Les exigences de stockage pour un client Ethereum deviennent de plus en plus exigeantes.
• Il n'y a pas d'incitatif ou de pénalité en protocole pour stocker les données historiques d'Ethereum.

La première raison découle de l'escalade des exigences de stockage pour exécuter un client Ethereum. Pour approfondir les exigences spécifiques, le diagramme circulaire suivant illustre la répartition des coûts de stockage pour un nouveau nœud Geth, au bloc 18,779,761 le 13 décembre 2023.

Comme le montre la photo :

• Exigence totale en matière de stockage : 925.39 Go
• Données historiques (blocs/reçus) : Environ 628,69 Go
• État dans l'arbre de Patricia Merkle (MPT) : Environ 269,74 Go

La deuxième raison est l'absence d'incitations ou de pénalités dans le protocole pour stocker les blocs historiques. Alors que le protocole impose aux nœuds de stocker toutes les données historiques, il ne prévoit aucun mécanisme pour encourager le stockage ou pénaliser le non-respect. Stocker et partager des données historiques par les nœuds devient purement altruiste, et un nœud est libre d'élaguer toutes les données historiques sans encourir de conséquences néfastes. En revanche, les validateurs, par exemple, doivent maintenir le dernier état complet pour éviter de proposer/voter pour un bloc invalide, risquant la perte d'incitations dans les deux cas.

Par conséquent, lorsque le coût de stockage devient un fardeau substantiel pour un nœud, il n'est pas surprenant que certains opérateurs de nœuds choisissent de tailler les données historiques. Le choix de fonctionner sans données historiques peut entraîner des économies de coûts de stockage importantes, les réduisant d'environ 1 To à environ 300 Go.

Illustration : La configuration de Nethermined pour exécuter un nœud sans les corps de blocs historiques - économisant environ 460 Go de coûts de stockage pour le moment.

Le défi du stockage devrait s'intensifier avec la prochaine mise à niveau de la disponibilité des données Ethereum (DA). Le cheminLe processus de mise à l'échelle complète de l'Ethereum DA commence avec l'EIP-4844 à DenCun, introduisant un objet binaire de taille fixe (BLOB) accompagné d'un modèle de frais indépendant connu sous le nom de blobGasPrice. Chaque BLOB est fixé à 128 Ko et l'EIP-4844 permet à chaque bloc de contenir jusqu'à 6 BLOBs. Pour améliorer la scalabilité des données, le plan prévoit la mise en œuvre du code de Reed-Solomon 1D, permettant 32 BLOBs par bloc initialement et atteignant éventuellement 256 BLOBs par bloc à pleine échelle.

Avec l'opération de données Ethereum DA à pleine capacité avec 256 BLOB par bloc, un an de réseau Ethereum DA est prévu pour accepter environ 80 To de données, dépassant les capacités de stockage de la plupart des nœuds Ethereum.

Feuille de route de stockage Ethereum et conséquence

Vitaliktweetde la feuille de route d'Ethereum, dans laquelle le Purge traite principalement du stockage.

Les coûts croissants de stockage ont attiré l'attention des chercheurs au sein de l'écosystème Ethereum. Pour y remédier et garantir l'alignement entre tous les clients, plusieurs propositions sont en développement pour élaguer explicitement le stockage. Les deux principales propositions sont :

1. EIP-4444: Données historiques liées dans les clients d'exécution: Cette proposition permet à un client de tailler les blocs historiques datant de plus d'un an. En supposant une taille moyenne de bloc de 100K, les données de bloc historiques sont plafonnées à environ 250 Go (100K (3600 24 * 365) / 12, étant donné que le temps de bloc = 12s).
2. EIP-4844 : Transactions de BLOB de fragment : EIP-4844 supprime les BLOBs datant de plus de 18 jours. Il s'agit d'une approche plus agressive par rapport à l'EIP-4444, plafonnant la taille historique des BLOB à environ 100 Go ((18360024) 128K 6 / 12, étant donné le temps de bloc = 12s).

Quelle est la conséquence de l'élagage des données historiques de tous les clients? La principale est qu'un nouveau nœud ne peut pas se synchroniser avec le dernier état via une "synchronisation complète" - une synchronisation pour rejouer les transactions depuis le bloc de genèse jusqu'au dernier bloc. Au lieu de cela, nous devons recourir à une "synchronisation instantanée" ou "synchronisation d'état" pour synchroniser le dernier état à partir des pairs Ethereum. Cette approche est déjà implémentée dans Geth et s'exécute comme la synchronisation par défaut.

De même, cette conséquence s'applique également à tous les L2, c'est-à-dire qu'un nouveau nœud de L2 ne peut pas rejouer entièrement le dernier état depuis le début de L2 à partir d'Ethereum en rejouant les blocs de L2 depuis le début de L2. De plus, étant donné que les nœuds L1 ne maintiennent pas l'état L2, l'approche de synchronisation instantanée pour L2 ne peut pas dériver le dernier état de L2 à partir de L1 - brisant une hypothèse importante de L2 d'hériter des garanties de sécurité d'Ethereum. La solution projetée reposera sur des services tiers tels qu'Infura / Etherscan / les projets L2 eux-mêmes pour stocker une copie des données ou de l'état historiques de L2, qui est centralisée avec des incitations indirectes hors protocole.

Les questions fondamentales que nous posons sont

• Pouvons-nous avoir une meilleure solution décentralisée, à la fois en termes de stockage et d'accès, au problème ?
• Est-il possible de construire une solution alignée sur Ethereum et minimisant la confiance (par exemple, sur un contrat L1) avec une solution d'incitation directe ?
• Avec tout cela, pouvons-nous ouvrir la voie à une solution d'incitation directe en protocole pour le stockage sur Ethereum et y accéder de manière entièrement décentralisée dans la feuille de route d'Ethereum ?

Solutions

Solution 1: Réseau de Portail Ethereum

Le réseau de portail Ethereum sert de réseau d'accès léger et décentralisé au protocole Ethereum. Offrant une interface JSON-RPC Ethereum telle que eth_call, eth_getBlockByNumber, il traduit les demandes JSON-RPC en demandes P2P à une table de hachage distribuée, similaire au réseau IPFS. Contrairement à IPFS, qui permet le stockage de tout type de données et est susceptible de spam, le réseau P2P du Portail héberge exclusivement des données Ethereum, telles que des en-têtes et des corps historiques. Ceci est réalisé grâce à une technique de vérification de client léger intégrée dans le réseau de portails.

Une caractéristique significative du réseau Portal est sa conception pour un fonctionnement léger et sa compatibilité avec des appareils aux ressources limitées. Il peut fonctionner sur un nœud avec quelques mégaoctets de stockage et une faible mémoire, favorisant la décentralisation. Même un téléphone portable ou un appareil Raspberry Pi peut potentiellement rejoindre le réseau et contribuer à la disponibilité des données Ethereum.

Le développement du réseau Portal est conforme à la philosophie de diversité des clients Ethereum, avec des clients écrits en Rust, JavaScript, Nim et Go. Le réseau de balises et le réseau d'historique sont prêts à être utilisés, tandis que le réseau d'état est activement en cours de développement. Notamment, le réseau Portal ne fournit pas d'incitations directes pour le stockage de données - tous les nœuds du réseau fonctionnent de manière altruiste.

Illustration : Exécution d’un réseau de portail (Trin) avec une limite de stockage de 100 Mo.

Solution 2: Réseau EthStorage

Le réseau de stockage EthStorage est un réseau de stockage incitatif décentralisé spécialement conçu pour stocker des BLOB EIP-4844, soutenu par une subvention du programme ESP.

• Confiance minimale : Contrairement aux solutions existantes qui nécessitent un pont de données centralisé, EthStorage repose sur le consensus d'Ethereum et le modèle de confiance de 1/m$ des fournisseurs de stockage EthStorage sans permission. La procédure de stockage d'un BLOB est la suivante : un utilisateur signe une transaction portant un BLOB qui appelle la méthode _put(key, blob_idx)_ du contrat de stockage. Le contrat de stockage enregistrera ensuite le hachage du BLOB et informera les fournisseurs de stockage avec un événement. Les fournisseurs de stockage, après avoir reçu l'événement, téléchargeront et stockeront ensuite le BLOB directement depuis le réseau DA Ethereum, contournant ainsi le problème du pont de données.
• Aligner le coût de stockage avec l'incitation: Lors de l'appel mettre()méthode, des frais de stockage doivent être envoyés (via msg.value) et déposé dans le contrat. Ce frais de stockage est progressivement distribué aux fournisseurs de stockage au fil du temps après la soumission réussie et la vérification d'une preuve de stockage. Par rapport au modèle actuel de frais de stockage Ethereum qui paie des frais de stockage ponctuels au proposeur, les frais de stockage payés au fil du temps suivent un modèle de flux de trésorerie actualisé - en supposant que le coût de stockage diminue par rapport à l'ETH au fil du temps. Cette innovation significative introduite par EthStorage aligne les frais payés par les utilisateurs et les contributions des fournisseurs de stockage au fil du temps.
• Preuve de stockage : La preuve de stockage est inspirée par l'échantillonnage des données disponibles, tandis que l'échantillonnage dans EthStorage est effectué contre des BLOBs au fil du temps au lieu de ceux d'un bloc proposé. Pour vérifier efficacement l'échantillonnage sur la chaîne, EthStorage s'appuie fortement sur les contrats intelligents et les derniers développements en matière de technologies SNARK.
• Réseau sans autorisation : Tout nœud dans EthStorage peut être rémunéré en tant que fournisseur de stockage tant qu'il stocke des données et soumet périodiquement une preuve de stockage on-chain.

D'un point de vue de la modularité de la blockchain, EthStorage fonctionne comme une couche 2 d'Ethereum, mais collecte des frais de stockage au lieu de frais de transaction. En indexant les hachages de BLOB on-chain, EthStorage est une couche de stockage modulaire Ethereum avec une évolutivité de stockage importante et des économies de coûts significatives - ciblant environ 1000x.

En termes de développement, EthStorage est déjà intégré à l'EIP-4844 sur le testnet Ethereum Sepolia. Un test de stress sur EthStorage et le testnet Ethereum Sepolia a été réalisé, impliquant l'écriture d'environ des centaines de gigaoctets de BLOB sur EthStorage. Plus de 50 participants de la communauté ont rejoint le réseau et ont réussi à prouver leurs stockages locaux.

L'avantage principal du réseau EthStorage réside dans la fourniture d'une incitation directe et décentralisée sur Ethereum, une fonctionnalité pionnière, pour autant que nos connaissances actuelles s'étendent. Cependant, une limitation du réseau est qu'il est spécifiquement conçu pour des BLOB de taille fixe.

Le tableau de bord d'EthStorage sur Ethereum Devnet

Projetant l'avenir

Le stockage d'Ethereum, bien que moins mis en avant, revêt une importance significative au sein de l'écosystème Ethereum. Alors que le réseau Ethereum connaît une croissance rapide, le stockage et l'accessibilité des données Ethereum émergent comme des défis critiques. Bien que le réseau Portal et le réseau EthStorage en soient à leurs débuts, nous envisageons plusieurs directions intrigantes pour le long terme :

• Accès décentralisé à faible latence à l'état d'Éthereum. Accéder à l'état d'Éthereum de manière décentralisée et vérifiable est une tâche critique mais difficile. Dans le cadre d'une configuration DHT traditionnelle, interroger un compte nécessite généralement de multiples requêtes des nœuds de trie internes stockés dans différents nœuds P2P. Cela entraîne souvent une latence considérablement longue. La clé est de savoir comment utiliser la structure de l'arbre d'état pour accélérer l'accès, comme le prévoit le futur réseau d'état du réseau Portal d'Éthereum.
• Intégration entre le réseau Portal et le réseau EthStorage : Le réseau Portal peut étendre facilement son support pour inclure des BLOBs dans le réseau, une étape déjà partiellement franchie par l'équipe EthStorage. Une progression naturelle consisterait à unir ces réseaux pour offrir un réseau JSON-RPC décentralisé capable d'appeler des contrats avec accès aux BLOBs. En combinant la logique d'application dans les contrats et le stockage BLOB mis à l'échelle par EthStorage, nous permettons de nouveaux dApps sur Ethereum tels que des sites Web décentralisés dynamiques (par exemple, twitter/youtube/wikipedia décentralisés, etc.).
• Accès décentralisé depuis les navigateurs : Similaire au protocole ipfs:// utilisé pour accéder aux données du réseau IPFS, il y a un besoin croissant d'un protocole d'accès natif à Ethereum depuis les navigateurs pour libérer le vaste potentiel des données riches d'Ethereum. Ces données englobent un large spectre, allant de la propriété des jetons et des soldes aux images de NFT et aux sites web décentralisés dynamiques, rendus possibles par les capacités des contrats intelligents et du stockage Ethereum futur. Dans ce domaine, le protocole web3://, tel que défini dans ERC-4804/6860, est actuellement en développement actif pour remplir cette fonction.
• Preuve avancée de stockage pour des données de taille dynamique : Au-delà des BLOBs fixes, explorer une preuve avancée de stockage devient impératif pour traiter des données de taille dynamique, telles que des blocs historiques ou même des objets d'état. Le développement d'algorithmes sophistiqués peut améliorer l'adaptabilité des solutions de stockage.

Dans notre poursuite, nous aspirons à ce que ces efforts contribuent collectivement à la feuille de route d'Ethereum, posant les bases pour les futures solutions de stockage décentralisé au sein de l'écosystème Ethereum.

déclaration:

1. Cet article est reproduit à partir de [ flux technologique profond marée] , le titre original est “Ethereum Storage Roadmap: Challenges and Opportunities”, les droits d'auteur appartiennent à l'auteur original [EthStorage], si vous avez des objections à la reproduction, veuillez contacter Équipe d'apprentissage de Gate, l'équipe s'en occupera dès que possible selon les procédures pertinentes.

2. Avertissement : Les points de vue et opinions exprimés dans cet article ne représentent que les points de vue personnels de l'auteur et ne constituent aucun conseil en investissement.

3. D'autres versions linguistiques de l'article sont traduites par l'équipe Gate Learn, non mentionnées dansGate.io , l'article traduit ne peut être reproduit, distribué ou plagié.