La version Dencun, mise à niveau du réseau Ethereum, a été lancée sur le réseau de test Goerli le 17 janvier 2024, et le réseau de test Sepolia a été lancé avec succès le 30 janvier. La mise à niveau de Dencun se rapproche de plus en plus.

Après la mise à niveau du réseau de test Holesky le 7 février, ce sera la mise à niveau du réseau principal. Le lancement de la mise à niveau de Cancún sur le réseau principal a été officiellement annoncé le 13 mars 2024.

Presque chaque mise à niveau d'Ethereum s'accompagne de tendances de marché importantes. Si l'on considère la dernière mise à niveau du 12 avril 2023, connue sous le nom de mise à niveau de Shanghai, les projets liés au Proof-of-Stake (PoS) ont connu une demande accrue du marché.

Si nous suivons les expériences précédentes, il y aura probablement des opportunités de positionnement stratégique avant la prochaine mise à niveau de Dencun.

Cependant, en raison de la complexité technique de la mise à niveau de Dencun, celle-ci ne peut pas être résumée aussi succinctement que celle de Shanghai par une seule phrase, telle que « Ethereum passe du PoW au PoS ». Cette complexité rend difficile la saisie des points focaux pour un positionnement stratégique.

Cet article vise donc à expliquer les détails techniques de la mise à niveau de Dencun dans un langage simple et compréhensible. Il expliquera aux lecteurs les subtilités de cette mise à niveau, en mettant en évidence ses liens avec la disponibilité des données (DA), les solutions de couche 2 et d'autres aspects pertinents.

01. AVRIL 4484

L'EIP-4844 s'impose comme la proposition la plus cruciale de la mise à niveau de Dencun, marquant ainsi une avancée significative pour Ethereum dans sa démarche de mise à l'échelle décentralisée.

En termes simples, les solutions actuelles de couche 2 d'Ethereum nécessitent de soumettre les transactions effectuées sur la couche 2 aux données d'appel du réseau principal d'Ethereum. Ces données d'appel sont ensuite utilisées par les nœuds pour vérifier la validité des blocs sur le réseau de couche 2.

Cette approche présente toutefois des défis, car malgré les efforts visant à compresser les données de transaction, l'important volume de transactions sur la couche 2, multiplié par les coûts de stockage élevés sur le réseau principal Ethereum, impose toujours des dépenses importantes aux nœuds et aux utilisateurs de couche 2. Ce coût élevé peut à lui seul entraîner la migration des utilisateurs vers les sidechains.

L'EIP-4844 propose une solution rentable en créant un nouveau type de zone de stockage appelée Binary Large Object (BLOB). Il introduit un nouveau type de transaction appelé « transaction porteuse de blobs » pour remplacer les données de transaction précédemment stockées dans Calldata avant la mise à niveau. Cette approche innovante permet à l'écosystème Ethereum Layer 2 de réaliser des économies de gaz.

Pourquoi le stockage BLOB est rentable ?

Comme nous le savons tous, la rentabilité s'accompagne souvent d'un compromis. La raison pour laquelle les données BLOB sont moins coûteuses que les données d'appel Ethereum classiques de taille similaire est que la couche d'exécution d'Ethereum (EL) ne peut pas accéder directement aux données BLOB elle-même.

Au lieu de cela, l'EL ne peut accéder qu'aux références aux données BLOB, et les données réelles du BLOB ne peuvent être téléchargées et stockées que par la couche de consensus Ethereum (CL, également connue sous le nom de nœuds balises). Les besoins en mémoire et en calcul pour stocker les données BLOB sont nettement inférieurs à ceux des données d'appel Ethereum classiques.

De plus, BLOB a une particularité : il ne peut être stocké que pendant une période limitée (généralement environ 18 jours) et ne s'étend pas à l'infini comme la taille du grand livre Ethereum.

Période de validité du stockage BLOB

Contrairement au registre permanent de la blockchain, les BLOB sont des espaces de stockage temporaires disponibles pendant 4 096 époques, soit environ 18 jours.

Après expiration, la plupart des clients consensuels ne seront pas en mesure de récupérer des données spécifiques dans le BLOB. Cependant, la preuve de son existence antérieure restera sur le réseau principal sous la forme d'engagements KZG et sera stockée en permanence sur le réseau principal Ethereum.

Pourquoi 18 jours ? Il s'agit d'un compromis entre le coût du stockage et l'efficacité.

Tout d'abord, nous devons prendre en compte les bénéficiaires les plus intuitifs de cette mise à niveau, à savoir les cumuls optimistes (tels que Arbitrum et Optimism), car Optimistic Rollups comporte une fenêtre de 7 jours anti-fraude. Les données de transaction stockées dans le Blob correspondent exactement à ce dont Optimistic Rollups a besoin pour lancer un défi.

Par conséquent, la période de validité du Blob doit garantir l'accessibilité de l'Optimistic Rollups Fraud Proof. Par souci de simplicité, la communauté Ethereum en a choisi 2 à la puissance 12 (4 096 époques sont dérivées de 2^12, et une époque dure environ 6,4 minutes).

Transaction porteuse de BLOB et BLOB

Il est important de comprendre la relation entre les deux pour comprendre le rôle des BLOB dans la disponibilité des données (DA).

La première est la proposition globale de l'EIP-4484 et constitue un nouveau type de transaction, tandis que la seconde peut être considérée comme un lieu de stockage temporaire pour les transactions de couche 2.

La relation entre les deux peut être comprise comme suit : la plupart des données du premier (données de transaction de couche 2) sont stockées dans le second. Les données restantes, c'est-à-dire l'engagement en matière de données BLOB, seront stockées dans les données d'appel du réseau principal. En d'autres termes, les promesses peuvent être lues par l'EVM.

L'engagement peut être imaginé comme le fait de regrouper toutes les transactions du BLOB dans un arbre Merkle, puis seule la racine de Merkle, qui est le Commitment, est accessible par le contrat.

Cela peut être fait intelligemment : bien que l'EVM ne puisse pas connaître le contenu spécifique du BLOB, le contrat EVM peut vérifier l'authenticité des données de transaction en connaissant l'Engagement.

02. La relation entre BLOB et Layer 2

La technologie Rollup assure la disponibilité des données (DA) en téléchargeant des données sur le réseau principal Ethereum, mais elle n'est pas destinée à permettre aux contrats intelligents de L1 de lire ou de vérifier directement ces données téléchargées.

Le but du téléchargement des données des transactions sur L1 est simplement de permettre à tous les participants de les consulter.

Avant la mise à niveau de Dencun, comme indiqué plus haut, Optimistic Rollups publiera les données de transaction sur Ethereum sous forme de données d'appel. Par conséquent, n'importe qui peut utiliser ces informations de transaction pour reproduire l'état et vérifier l'exactitude du réseau de couche 2.

Il n'est pas difficile de comprendre que les données relatives aux transactions cumulées doivent être peu coûteuses, ouvertes et transparentes. Calldata n'est pas l'endroit idéal pour stocker des données de transaction spécifiques à la couche 2, et Blob-carrying Transaction est conçu sur mesure pour le Rollup.

À ce stade, vous vous demandez peut-être quelle est l'importance des données de transaction.

En réalité, les données de transaction ne sont utilisées que dans des scénarios spécifiques :

• Pour Optimistic Rollup, sur la base d'une hypothèse de confiance, il existe un risque de malhonnêteté. Dans de tels cas, les enregistrements de transactions téléchargés par cumul deviennent utiles, car ils permettent aux utilisateurs de lancer des preuves de fraude.
• Pour ZK Rollup, aucune preuve de connaissance prouve que la mise à jour d'état est correcte. Le téléchargement de données est uniquement destiné à permettre aux utilisateurs de calculer eux-mêmes l'état complet. Lorsque le nœud de couche 2 ne peut pas fonctionner correctement, le mécanisme de trappe d'évacuation, qui nécessite un arbre d'états L2 complet, est activé. Cela sera abordé dans la dernière section de cet article.

Cela implique que l'utilisation réelle des données de transaction dans le cadre des contrats est très limitée. Même pour les preuves de fraude d'Optimistic Rollup, seule la preuve que les données des transactions « existaient » à un moment donné est requise, et il n'est pas nécessaire de stocker les détails de chaque transaction sur le réseau principal à l'avance.

En plaçant les données des transactions dans le BLOB, bien que cela soit inaccessible aux contrats, le contrat du réseau principal peut stocker l'engagement du BLOB.

Si le mécanisme antifraude a besoin d'une transaction spécifique à l'avenir, le fait de fournir les données pour cette transaction, à condition qu'elles correspondent, peut convaincre le contrat et fournir les données de transaction pour le mécanisme antifraude.

Cela permet non seulement de tirer parti de l'ouverture et de la transparence des données des transactions, mais aussi d'éviter les énormes frais d'essence liés à la saisie préalable de toutes les données dans le contrat.

En enregistrant uniquement les engagements, les données des transactions sont vérifiables tout en optimisant considérablement les coûts. Il s'agit d'une solution intelligente et efficace pour télécharger les données des transactions à l'aide de la technologie Rollup.

Il convient de noter que dans le fonctionnement réel de Dencun, l'arbre de Merkle, similaire à Celestia, n'est pas utilisé pour générer de l'engagement, mais l'algorithme KZG (Kate-Zaverucha-Goldberg, Polynomial Commitment) est utilisé.

Comparé à Merkle Tree Proof, le processus de génération de KZG Proof est relativement complexe, mais son volume de vérification est moindre et les étapes de vérification plus simples. Cependant, l'inconvénient est que cela nécessite des paramètres fiables (ceremony.ethereum.org, qui est maintenant terminée) et n'est pas en mesure de prévenir les attaques informatiques quantiques (Dencun utilise la méthode Version Hash, et d'autres méthodes de vérification peuvent être remplacées si nécessaire).

Pour Celestia, le désormais populaire projet DA, utilise une variante de l'arbre Merkle. Contrairement à KZG, il repose dans une certaine mesure sur l'intégrité des nœuds mais contribue à abaisser le seuil de ressources de calcul entre les nœuds, préservant ainsi la nature décentralisée du réseau.

03. Opportunités à Dencun

Bien que l'EIP-4844 réduise les coûts et augmente l'efficacité de la couche 2, il augmente également les risques de sécurité, ce qui ouvre également de nouvelles opportunités.

Pour comprendre pourquoi, nous devons revenir au mécanisme de trappe d'évacuation ou au mécanisme de retrait forcé mentionné plus haut.

Lorsque le nœud de couche 2 est désactivé, ce mécanisme peut garantir que les fonds des utilisateurs sont renvoyés en toute sécurité sur le réseau principal. Pour activer ce mécanisme, l'utilisateur doit obtenir l'arbre d'état complet de la couche 2.

Dans des circonstances normales, les utilisateurs n'ont qu'à trouver un nœud complet de couche 2 pour demander des données, générer des preuves Merkle, puis les soumettre au contrat du réseau principal pour prouver la légitimité de leur retrait.

Mais n'oubliez pas que l'utilisateur souhaite activer le mécanisme de trappe d'évacuation pour quitter la L2 précisément parce que les nœuds L2 ont agi de manière malveillante. Si cela se produit, il est fort probable qu'ils n'obtiennent pas les données souhaitées sur les nœuds.

C'est ce que Vitalik appelle souvent une attaque de rétention de données.

Avant l'EIP-4844, les enregistrements permanents de couche 2 étaient enregistrés sur le réseau principal. Lorsqu'aucun nœud de couche 2 ne pouvait fournir un statut hors chaîne complet, les utilisateurs pouvaient déployer eux-mêmes un nœud complet.

Ce nœud complet peut obtenir toutes les données historiques publiées par le séquenceur de couche 2 sur le réseau principal via le réseau principal Ethereum. Les utilisateurs peuvent créer la preuve Merkle requise et la soumettre au contrat sur le réseau principal afin d'effectuer le retrait d'actifs L2 en toute sécurité.

Après l'EIP-4844, les données de couche 2 n'existent que dans le BLOB des nœuds complets d'Ethereum, et les données historiques antérieures à 18 jours seront automatiquement supprimées.

Par conséquent, la méthode décrite au paragraphe précédent pour obtenir l'arborescence des états complète en synchronisant le réseau principal n'est plus possible. Si vous voulez obtenir l'arbre d'état complet de la couche 2, vous ne pouvez vous fier qu'à des nœuds tiers du réseau principal qui ont stocké toutes les données BLOB d'Ethereum (qui auraient dû être automatiquement supprimées au bout de 18 jours), ou à des nœuds natifs de couche 2 (ce qui est rare).

Après la mise en ligne de l'EIP-4844, il sera très difficile pour les utilisateurs d'obtenir l'arbre de statut complet de la couche 2 de manière totalement fiable.

Si les utilisateurs ne disposent pas d'un moyen stable d'obtenir l'arbre d'état de la couche 2, ils ne peuvent pas effectuer d'opérations de retrait forcé dans des conditions extrêmes. L'EIP-4844 constitue donc dans une certaine mesure une faille de sécurité pour la couche 2.

Pour pallier ce manque de sécurité, nous avons besoin d'une solution de stockage fiable présentant un cycle économique positif. Ici, le stockage fait principalement référence à la conservation des données sur Ethereum de manière fiable, ce qui est différent de l'espace de stockage par le passé car il y a un mot clé « trustless » dans ce cas.

Ethstorage peut résoudre le problème de l'absence de confiance et a reçu deux cycles de financement de la part de la Fondation Ethereum.

En fait, ce concept peut réellement exploiter le potentiel apporté par la mise à niveau de Dencun, et il mérite toute notre attention.

L'intérêt le plus intuitif d'Ethstorage est qu'il peut prolonger la durée de disponibilité de DA BLOB de manière totalement décentralisée, comblant ainsi les lacunes de la sécurité de couche 2 après EIP-4844.

De plus, la plupart des solutions L2 existantes se concentrent principalement sur l'augmentation de la puissance de calcul d'Ethereum, c'est-à-dire sur l'augmentation du TPS. Cependant, la demande de stockage sécurisé de grandes quantités de données sur le réseau principal Ethereum a augmenté, notamment en raison de la popularité de dApps telles que les NFT et DeFi.

Par exemple, la demande de stockage de NFT en chaîne est énorme, car les utilisateurs possèdent non seulement les jetons des contrats NFT, mais aussi l'image de la chaîne. Ethstorage peut résoudre les problèmes de confiance supplémentaires liés au stockage de ces images chez un tiers.

Enfin, Ethstorage peut également répondre aux besoins frontaux des DApps décentralisées. Les solutions existantes sont principalement hébergées par des serveurs centralisés (avec DNS). Cette configuration rend les sites Web vulnérables à la censure et à d'autres problèmes tels que le piratage du DNS, le piratage de sites Web ou les pannes de serveurs, comme en témoignent des incidents tels que Tornado Cash.

Ethstorage n'en est qu'à ses premiers tests, et les utilisateurs optimistes quant aux perspectives de ce titre peuvent l'essayer.

Avertissement：

1. Cet article est repris de [Biteye]. Tous les droits d'auteur appartiennent à l'auteur original [Biteye]. En cas d'objection à cette réimpression, contactez l'équipe de Gate Learn, elle s'en occupera rapidement.
2. Avertissement en matière de responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent en aucun cas un conseil d'investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, de distribuer ou de plagier les articles traduits.