Fondateur d'EthStorage : comment la disponibilité des données garantit-elle la sécurité des Rollup ?
TechFlow SélectionTechFlow Sélection
Fondateur d'EthStorage : comment la disponibilité des données garantit-elle la sécurité des Rollup ?
Cet épisode explore la décentralisation des rollups sous l'angle de la disponibilité des données et du stockage décentralisé.
Dédié à des analyses Web3 approfondiesAnimatrice : Franci
Invité : Qi Zhou, fondateur d’EthStorage
Introduction
Il s'agit du dernier épisode de la série d'entretiens consacrée aux rollups décentralisés. Dans cet épisode, nous abordons la décentralisation des rollups sous l'angle de la « disponibilité des données (DA) et du stockage décentralisé ». Nous avons invité Qi Zhou, fondateur d’EthStorage, pour discuter de la manière dont la DA réutilise les propriétés de sécurité du réseau principal Ethereum, de EIP-4844 et de danksharding, ainsi que comparer la sécurité de différents modèles de DA. M. Zhou présente également comment EthStorage s'intégrera à la prochaine mise à jour d'Ethereum via EIP-4844.
Présentation de l'invité
Je suis ravi de pouvoir partager avec vous nos réflexions sur la technologie DA d’Ethereum et sur notre travail relatif au stockage décentralisé. J’ai rejoint à plein temps l’industrie Web3 en 2018, après avoir travaillé comme ingénieur dans de grandes entreprises telles que Google et Facebook. Je détends un doctorat de Georgia Institute of Technology. Depuis 2018, je me concentre sur les infrastructures Web3, une orientation naturelle étant donné mon expérience antérieure dans les systèmes distribués et le stockage distribué. J’estime également qu’il existe encore beaucoup d’espaces d’amélioration dans ce domaine au sein de la blockchain. Que ce soit les technologies initiales que nous avons explorées, comme le sharding d’exécution – ce qu’on appelait le sharding 1.0 d’Ethereum – ou aujourd’hui le sharding de données (sharding 2.0), ainsi que la disponibilité des données (data availability), tous ces efforts visent à innover autour des infrastructures fondamentales de Web3.
Nous suivons donc étroitement la feuille de route d’Ethereum, en menant des recherches actives et en participant à la communauté pour contribuer à son amélioration. À la fin de l’année dernière, nous avons eu l’honneur de recevoir le soutien de la Fondation Ethereum pour nos travaux de recherche sur l’échantillonnage de disponibilité des données (data availability sampling). Nous aidons la Fondation à mener des recherches théoriques sur danksharding, notamment sur la manière de restaurer efficacement les données. Parallèlement, nous développons EthStorage, une couche de données pour Ethereum basée sur sa technologie DA. Grâce à des contrats intelligents Ethereum, nous pouvons valider massivement le stockage hors chaîne des données. Cela revêt une grande importance pour Ethereum. Aujourd'hui, je suis donc particulièrement heureux de partager avec vous comment EthStorage construit un réseau de stockage de données plus performant grâce aux technologies DA.
Partie entretien
Première partie : Discussion sur la définition de la DA
Comment la disponibilité des données (DA) garantit-elle la sécurité des rollups ?
Durant mes recherches sur la DA, j'ai constaté que beaucoup de personnes ont des difficultés à comprendre cette notion. C'est donc un plaisir d'en discuter aujourd'hui. J'ai déjà échangé à ce sujet avec plusieurs membres de la Fondation Ethereum, comme Dankrad Feist, sur le rôle crucial de la DA dans l'écosystème Ethereum L2.
Comme mentionné précédemment, le fonctionnement de base d’un rollup Ethereum consiste à déplacer les transactions en ligne vers un niveau hors chaîne, puis à utiliser diverses méthodes de preuve (preuves de fraude et preuves de validité) pour informer les contrats intelligents de la couche L1 que les résultats d’exécution peuvent être vérifiés comme corrects.
Un point central est la volonté de réutiliser la sécurité intrinsèque du réseau Ethereum tout en augmentant considérablement sa capacité de calcul. Le fait de déporter le calcul hors chaîne permet d’augmenter cette capacité. Mais comment conserver par ailleurs la sécurité d’Ethereum ?
Par exemple, dans le cas d’un Optimistic Rollup, comment garantir qu’un utilisateur peut contester un séquenceur qui agirait de manière malveillante ? Un élément clé ici est la possibilité d’accéder aux transactions brutes effectuées hors chaîne. Sans accès à ces données brutes, il serait impossible de récupérer les enregistrements nécessaires pour contester le séquenceur sur la chaîne. La DA assure donc la sécurité en exigeant que les métadonnées de chaque transaction hors chaîne soient accessibles sur la chaîne.
Extension de l’espace des blocs
Toutes nos transactions doivent être inscrites sur la chaîne, générant ainsi d’importantes quantités de données même sans calculs associés. Le problème fondamental que résout la DA peut être vu comme une technique très efficace pour agrandir l’espace des blocs. Si vous êtes familiers avec l’architecture blockchain, chaque bloc contient de nombreuses transactions — cet espace est précisément ce que l’on appelle l’espace des blocs.
Actuellement, chaque bloc Ethereum mesure environ 200 à 300 Ko. Ce volume est manifestement insuffisant pour répondre aux besoins futurs de scalabilité d’Ethereum. Faisons un rapide calcul : 200 Ko divisé par environ 100 octets par transaction donne environ 2000 transactions par bloc. En divisant cela par le temps de bloc d’Ethereum (12 secondes), on obtient une limite théorique de TPS d’environ 166, souvent arrondie à 100 en pratique. Ce chiffre reste très faible au regard des ambitions de scalabilité d’Ethereum.
Ainsi, les solutions L2 d’Ethereum cherchent à assurer la sécurité tout en permettant de stocker d’importantes quantités de données dans l’espace des blocs. Cela permet aux preuves de fraude ou de validité de réutiliser les données présentes dans les blocs d’Ethereum pour leurs vérifications, garantissant ainsi que la sécurité des résultats de calcul hors chaîne repose sur celle d’Ethereum. Voilà en substance le lien entre la DA et la sécurité d’Ethereum.
Comprendre la DA sous l’angle du coût de bande passante et du coût de stockage
Les principaux coûts liés à la DA sont de deux ordres : le coût de bande passante réseau et le coût de stockage.
En ce qui concerne le coût de bande passante, dans les réseaux P2P tels que Bitcoin ou Ethereum, la diffusion des blocs se fait actuellement par méthode « gossip » (diffusion en cascade) vers tous les nœuds du réseau. Cette méthode présente l’avantage d’être très sécurisée, car tous les nœuds finissent par recevoir une copie complète du bloc.
Son inconvénient réside dans la forte charge imposée à la bande passante et la latence du réseau. Sachant qu’Ethereum produit un bloc toutes les 12 secondes depuis la mise à jour POS, si les blocs deviennent trop volumineux, ils risquent de ne pas être diffusés à temps, ce qui pourrait entraîner des pertes de blocs et une baisse générale de performance du réseau, jusqu’à un niveau inacceptable. On peut donc dire que la DA vise à résoudre le problème de bande passante lié à l’inscription massive de données sur la chaîne.
Le deuxième aspect est le coût de stockage. Ce sujet fait l’objet de nombreux débats au sein de la Fondation Ethereum. La solution retenue prévoit que les données de DA téléchargées ne soient pas conservées indéfiniment.
Cela soulève une autre question : une fois que tant de données sont inscrites sur la chaîne, mais qu’elles seront supprimées par le protocole Ethereum après une semaine ou deux, existe-t-il de meilleures solutions décentralisées pour conserver durablement ces données DA ?
C’est précisément l’une des motivations derrière la conception d’EthStorage. D’une part, de nombreux rollups ont besoin de conserver leurs données sur le long terme. D’autre part, une fois ces données disponibles, on peut mieux développer des applications entièrement sur chaîne — par exemple, des NFTs complets, les interfaces front-end de nombreuses dApps, voire même les articles et commentaires publiés dans des réseaux sociaux. Tous ces contenus peuvent être envoyés sur la blockchain via le réseau DA, à moindre coût, tout en bénéficiant de la même sécurité que la couche L1 d’Ethereum.
Après avoir étudié la technologie DA d’Ethereum et discuté avec de nombreux experts du projet, nous avons conclu qu’Ethereum avait besoin d’une couche de stockage — décentralisée, modulaire, et ne nécessitant aucune modification du protocole lui-même — afin de résoudre le problème de conservation à long terme des données.
Deuxième partie : Discussion sur les différentes solutions DA
Relation entre EIP-4844 et danksharding, et pourquoi déployer EIP-4844 ?
Proto-danksharding, aussi connu sous le nom d’EIP-4844, constitue selon moi l’une des prochaines mises à jour majeures d’Ethereum. La raison principale de son déploiement remonte à une estimation faite par la Fondation Ethereum concernant le calendrier de mise à jour du sharding d’Ethereum (danksharding), qu’elle jugeait alors extrêmement long — potentiellement trois à cinq ans — vers 2020-2021.
Dans ce contexte, on anticipait une croissance rapide du nombre de rollups sur Ethereum. Or, l’interface de données fournie par danksharding est totalement différente de l’interface Calldata actuellement utilisée par les rollups. Cela aurait pu empêcher de nombreuses applications de migrer rapidement et sans heurt vers danksharding, les privant ainsi de ses avantages.
Lors de ma participation à Devcon l’année dernière, Vitalik a souligné l’importance de mieux servir les couches 2 d’Ethereum, en leur permettant de développer leurs contrats avec une interface compatible dès maintenant avec celle de danksharding. Ainsi, une fois danksharding activé, ces applications bénéficieraient automatiquement de ses nouveautés sans avoir à mettre à jour leurs contrats déjà testés et déployés.
Ainsi, EIP-4844 est une version fortement simplifiée de danksharding. Il introduit une interface d’application identique, incluant un nouvel opcode appelé Data Hash et un nouvel objet de données appelé Binary Large Objects (Blob).
Ces objets sont conçus pour permettre aux rollups de se préparer à l’arrivée de danksharding en adoptant dès maintenant sa structure de données — notamment le Data Hash et les Blobs. Grâce à EIP-4844, ces concepts sont implémentés progressivement dans les mises à jour futures d’Ethereum. En examinant les interfaces, les fonctions pré-compilées et les nouvelles instructions d’EIP-4844, on peut déjà entrevoir comment danksharding interagira avec la couche applicative à l’avenir.
La Fondation Ethereum adopte donc une approche centrée sur les applications, visant à faciliter leur accès aux technologies de scalabilité sans coût supplémentaire de mise à niveau.
Toutefois, EIP-4844 ne résout pas le problème de l’extension de l’espace des blocs — seul danksharding y parviendra. Actuellement, chaque bloc Ethereum mesure environ 200 Ko. Avec danksharding, la taille prévue dans la spécification atteint 32 mégaoctets, soit une augmentation d’environ 100 fois. EIP-4844, en revanche, ne règle pas le goulot d’étranglement lié à la bande passante d’inscription des blocs.
Comment danksharding résout-il le problème d’extension de l’espace des blocs ?
Dans la conception d’EIP-4844, la diffusion des données sur la chaîne suit toujours la méthode classique du Calldata, via le réseau P2P. Cette méthode reste donc limitée par les contraintes physiques de bande passante du réseau P2P. En revanche, danksharding modifie radicalement cette diffusion en utilisant une technique d’échantillonnage des données, permettant aux participants de s’assurer que les données sont disponibles sans avoir à télécharger l’intégralité du bloc.
D’une certaine manière, cela rappelle les mécanismes ZK : grâce à l’échantillonnage, je peux savoir que le réseau contient des blocs de 32 mégaoctets générés par danksharding, sans avoir à télécharger l’intégralité des 32 Mo ni à les stocker localement. Bien sûr, ceux disposant de suffisamment de bande passante et d’espace disque peuvent choisir de le faire, mais pour un validateur ordinaire, ce n’est pas nécessaire.
Développements et retours d’expérience sur le testnet EIP-4844
Nous avons récemment lancé notre propre testnet interne pour EIP-4844 et déployé les contrats correspondants afin de tester le chargement des données Blob, l’appel de contrats et la validation des données. Tout fonctionne désormais parfaitement. Dès que EIP-4844 sera activé, nous serons prêts à déployer immédiatement nos contrats.
Nous espérons également, grâce à notre collaboration avec les développeurs Ethereum et nos contrats déjà opérationnels, aider les futurs projets rollup dans leur développement, apprentissage et création d’outils.
Nous avons récemment soumis de nombreux codes à la communauté Ethereum, notamment un ensemble d’outils pour EIP-4844, incluant de nouveaux contrats intelligents supportant l’opcode data hash — Solidity ne le supportant pas encore actuellement. Tous ces travaux sont synchronisés avec les développeurs de la Fondation Ethereum.
Applications et limites du Comité de Disponibilité des Données (DAC)
Actuellement, les frais payés par les utilisateurs L2 comprennent plus de 90 % de coûts liés à la disponibilité des données. Pour réduire ces coûts, certains projets L2, comme ZKSync avec ZKPorter ou Arbitrum avec Arbitrum Nova, ont mis en place leurs propres DAC (Data Availability Committee), créant ainsi leur propre couche de données.
Ce comité introduit une confiance supplémentaire, indispensable pour atteindre un niveau de sécurité équivalent à celui d’Ethereum. Les membres du DAC sont donc généralement choisis parmi de grands fournisseurs de données ou entreprises renommées. Cependant, ce modèle fait face à de nombreuses critiques, car il va à l’encontre du principe fondamental de décentralisation et d’absence de permission. En réalité, la majorité des DAC sont composés de quelques organisations étroitement liées aux projets L2 eux-mêmes.
Par exemple, Arbitrum Nova compte actuellement six ou sept nœuds, hébergés sur des clouds comme Google Cloud ou Amazon AWS, chargés de conserver les données et de garantir l’exécution des transactions. L’avantage ? Un coût d’exécution environ mille fois inférieur à celui d’Ethereum, car toutes les données ne sont pas écrites sur la L1. Toutefois, ce système reste relativement centralisé, ce qui suscite des inquiétudes pour les applications à haute valeur, notamment celles manipulant des montants importants — millions ou milliards — où la disponibilité des données du DAC devient un point de confiance critique.
Dans la conception d’EthStorage, nous n’utilisons aucun concept de comité de données. Notre objectif est que n’importe qui puisse participer comme fournisseur de données. Ils doivent prouver cryptographiquement qu’ils stockent effectivement les données. Théoriquement, même si un DAC affirme avoir sept ou huit nœuds, il pourrait très bien ne sauvegarder physiquement qu’une seule copie tout en simulant plusieurs adresses.
Comment prouver alors que les données sont suffisamment redondantes pour garantir leur sécurité ? C’est là une innovation clé d’EthStorage, que nous mettons fortement en avant lors de nos présentations auprès de la Fondation Ethereum (programme ESP). Grâce à la technologie ZK utilisée par EthStorage, les nœuds fournissant les données L2 peuvent rejoindre sans permission et prouver qu’ils maintiennent plusieurs copies, assurant ainsi une meilleure sécurité des données.
Le DAC est donc une solution temporaire efficace pour réduire le coût du transfert de données vers la L1. Nous croyons que, grâce aux techniques cryptographiques d’EthStorage combinées à des mécanismes de vérification sur contrats intelligents Ethereum, nous pouvons offrir une solution de stockage supérieure. À l’approche du lancement d’EIP-4844, nous partagerons activement nos innovations et les résultats obtenus sur le réseau.
Différences entre EthStorage et le DAC
EthStorage est en réalité un « storage rollup » pour Ethereum. Imaginons un Layer 2 qui ne serait pas un EVM exécutant des contrats, mais plutôt une immense base de données, un système key-value pouvant atteindre des tailles de dizaines, centaines de téraoctets, voire du pétaoctet.
Comment garantir que les données de cette base bénéficient de la même sécurité qu’Ethereum ? Premièrement, il faut publier toutes ces données massives via la DA sur la couche L1 d’Ethereum, afin que chacun puisse vérifier leur disponibilité. Cependant, nous ne pouvons pas garantir leur conservation permanente, car Ethereum supprime ces données après deux à quatre semaines.
Deuxièmement, après avoir publié les données, nous les conservons sur les nœuds de notre Layer 2. Contrairement au DAC, nos nœuds de stockage sont sans permission : n’importe qui peut participer, prouver son stockage et recevoir une récompense. Ce mécanisme repose sur un système de preuve de stockage que nous avons conçu, inspiré des modèles de Filecoin et Arweave. Toutefois, il est adapté spécifiquement au cadre DA d’Ethereum et aux contrats intelligents. Nous pensons ainsi apporter une contribution unique à l’écosystème Ethereum et au stockage décentralisé en général.
Mécanisme de preuve de stockage
Tous les mécanismes de preuve de stockage, comme ceux de Filecoin ou Arweave, commencent par encoder les métadonnées utilisateur. Cet encodage dépend de l’adresse du fournisseur de données : chaque fournisseur possédant une adresse unique, les données encodées deviennent des « replicas uniques ». Par exemple, la donnée « hello world » serait simplement copiée plusieurs fois dans un système centralisé. Mais dans EthStorage, chaque copie est encodée différemment selon l’adresse du fournisseur, produisant ainsi des données distinctes physiquement stockées à différents endroits.
L’avantage ? Grâce à la cryptographie, nous pouvons prouver qu’un grand nombre d’adresses distinctes — donc de fournisseurs — ont encodé et stocké les données. Filecoin et Arweave utilisent des principes similaires, mais uniquement pour des données statiques. Nous, nous nous concentrons sur les données « chaudes » de la DA Ethereum, et permettons à un contrat intelligent Ethereum de vérifier qu’il existe bien plusieurs copies physiques. Chaque donnée encodée est unique, car générée à partir de l’adresse du fournisseur.
Nous optimisons ainsi les idées existantes de stockage décentralisé, tout en adaptant la solution DA d’Ethereum à des données dynamiques, et en trouvant des moyens efficaces de valider ces preuves via des contrats intelligents tout en minimisant les coûts en gaz. De nombreuses recherches et innovations technologiques restent à réaliser dans ce domaine.
Comment EthStorage maintient-il une preuve de stockage sans permission ?
Ethereum dispose de nœuds dits « archive », qui conservent l’intégralité de l’historique des transactions et de l’état global. Cependant, danksharding posera un défi majeur : il générera environ 80 To de données par an. Après trois à quatre ans, cela représentera 200 à 300 To, voire plus. Cela constitue un obstacle sérieux pour les nœuds archive, car il n’existe actuellement aucun modèle économique ou incitation tokenisée pour motiver leur maintenance.
EthStorage doit donc d’abord résoudre le problème de l’incitation économique pour la conservation permanente des données. Pour cela, nous adoptons le modèle de flux de trésorerie actualisé (discounted cash flow) d’Arweave, en l’intégrant efficacement dans nos contrats intelligents.
Deuxièmement, notre modèle est sans permission. Notre mécanisme incitatif encourage la participation de 10, 50, voire 100 nœuds pour stocker les données. Ainsi, n’importe quel nouveau nœud peut contacter l’un d’eux, synchroniser les données, et devenir à son tour fournisseur de stockage. D’autres optimisations incitatives sont également envisagées.
Troisièmement, un nœud doit initialement stocker l’intégralité des données — plusieurs centaines de téraoctets, voire un pétaoctet à long terme — ce qui représente un coût prohibitif. Pour pallier cela, nous introduisons un « data sharding ». Ainsi, un nœud ordinaire n’a besoin que de 4 To (actuellement conçu pour 4 To, évoluable vers 8 To) pour stocker une partie des données archivées. Grâce à des mécanismes incitatifs, nous garantissons que l’ensemble du réseau conserve collectivement la totalité des données.
De nombreux défis persistent : volume excessif des données pour les nœuds archive, incitations tokenisées, accès décentralisé… Tous ces problèmes peuvent être résolus automatiquement via des contrats intelligents déployés sur la couche L1. Notre rôle est de fournir le réseau de données, permettant à toute personne disposant des ressources nécessaires de télécharger les données, générer des preuves de stockage et les soumettre à Ethereum pour obtenir une récompense. Nos contrats sont pratiquement finalisés et déjà en phase de test sur le Devnet 4844 d’Ethereum.
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
ECN | Ethereum.cn
