La mise à jour Dencun d'Ethereum et ses opportunités potentielles
TechFlow SélectionTechFlow Sélection
La mise à jour Dencun d'Ethereum et ses opportunités potentielles
Cet article expliquera en termes simples les détails techniques de la mise à niveau Dencun.
Dédié à des analyses Web3 approfondiesAuteur : Fishery Isla, contributeur principal de Biteye
Édité par : Crush, contributeur principal de Biteye
Communauté : @BiteyeCN
*Environ 4500 caractères, lecture estimée : 5 minutes
La mise à niveau Dencun du réseau Ethereum a été déployée sur le testnet Goerli le 17 janvier 2024, puis avec succès sur Sepolia le 30 janvier. La mise à niveau Dencun est désormais imminente.
Après une dernière mise à jour prévue sur le testnet Holesky le 7 février, ce sera au tour du réseau principal. La mise à niveau de Cancun sur le réseau principal est désormais officiellement fixée au 13 mars.
Chaque mise à niveau d’Ethereum s’accompagne presque invariablement d’un mouvement spéculatif spécifique. En remontant à la dernière mise à niveau majeure, celle de Shanghai le 12 avril 2023, les projets liés à la preuve d’enjeu (PoS) avaient fortement attiré l’intérêt des marchés.
Selon les précédents, la mise à niveau Dencun offrira également des opportunités stratégiques anticipées.
Toutefois, contrairement à la mise à niveau de Shanghai, dont on pouvait résumer l’essence en une phrase simple — « passage d’Ethereum de PoW à PoS » —, les aspects techniques de Dencun sont plus complexes et difficiles à vulgariser, rendant plus ardue l’identification claire des axes d’investissement.
Cet article vise donc à expliquer de manière accessible les détails techniques de Dencun, afin de clarifier pour le lecteur les liens entre cette mise à niveau et des domaines comme la disponibilité des données (DA) ou les solutions Layer 2.
01 EIP-4844
L'EIP-4844 est la proposition la plus importante de la mise à niveau Dencun, marquant un pas concret et significatif vers l’évolutivité décentralisée d’Ethereum.
En termes simples, les réseaux Layer 2 actuels doivent publier leurs transactions dans le champ calldata de la blockchain Ethereum principale, permettant aux nœuds de vérifier la validité des blocs générés sur ces Layer 2.
Le problème est que, même si les données sont compressées, le volume énorme des transactions sur Layer 2 combiné au coût élevé du stockage sur Ethereum rend cette méthode coûteuse pour les opérateurs et utilisateurs de Layer 2. Ce seul facteur de prix risque de faire fuir les utilisateurs vers des sidechains.
L’EIP-4844 introduit une nouvelle zone de stockage moins coûteuse appelée BLOB (Binary Large Object, objet binaire volumineux), ainsi qu’un nouveau type de transaction, la « BLOB-Carrying Transaction », qui remplace le stockage des données dans le calldata. Cela permet aux Layer 2 de réduire drastiquement leurs frais de gaz.
Pourquoi le stockage BLOB est-il moins cher ?
Comme souvent, un prix bas implique des compromis. Les données BLOB coûtent moins cher que des données calldata de taille similaire parce que la couche d’exécution (EL, EVM) ne peut pas y accéder directement.
À la place, l’EVM n’a accès qu’à une référence (commitment) des données BLOB. Les données elles-mêmes sont téléchargées et stockées uniquement par la couche de consensus (CL, nœuds beacon), ce qui nécessite beaucoup moins de mémoire et de puissance de calcul que le traitement classique du calldata.
De plus, les BLOB ont une durée de vie limitée — environ 18 jours — contrairement au registre d’Ethereum qui croît indéfiniment.
Durée de validité du BLOB
Contrairement au registre permanent de la blockchain, le BLOB est un stockage temporaire, disponible pendant 4096 époques, soit environ 18 jours.
Passé ce délai, la plupart des clients de consensus ne peuvent plus récupérer les données spécifiques du BLOB. Toutefois, la preuve de leur existence reste conservée sous forme d’un engagement KZG sur la blockchain principale, où elle est stockée de façon permanente.
Pourquoi 18 jours ? C’est un compromis entre coût de stockage et efficacité fonctionnelle.
Il faut d’abord considérer les bénéficiaires directs de cette mise à niveau : les Optimistic Rollups (comme Arbitrum et Optimism). Ces systèmes prévoient une fenêtre de 7 jours pour présenter une preuve de fraude (fraud proof).
Les données de transaction contenues dans le BLOB sont justement celles nécessaires pour initier un tel défi.
Ainsi, la durée du BLOB doit couvrir cette période critique. Pour simplifier, la communauté Ethereum a choisi 2¹² (soit 4096 époques, chaque époque durant environ 6,4 minutes).
Relation entre BLOB-Carrying Transaction et BLOB
Comprendre cette relation est essentiel pour saisir le rôle du BLOB dans la disponibilité des données (DA).
La première désigne l’ensemble de la proposition EIP-4844, une nouvelle forme de transaction ; le second est un espace temporaire destiné au stockage des données des Layer 2.
On peut dire que la majorité des données (transactions L2) est stockée dans le BLOB, tandis que l’engagement (commitment) de ces données reste dans le calldata du réseau principal. Ce commitment est lui accessible par l’EVM.
On peut imaginer le commitment comme la racine d’un arbre de Merkle construit à partir de toutes les transactions du BLOB — seule cette racine est accessible aux contrats.
Ainsi, bien que l’EVM ne voie pas le contenu du BLOB, il peut valider l’authenticité des données via le commitment.
02 Relation entre BLOB et Layer 2
La technologie Rollup garantit la disponibilité des données (DA) en publiant les données sur Ethereum, mais pas pour que les contrats L1 les lisent directement.
L’objectif est simplement que tous les participants puissent consulter ces données.
Avant Dencun, les Op-Rollups publiaient leurs données dans le calldata d’Ethereum. N’importe qui pouvait alors reproduire l’état et vérifier la légitimité du réseau L2.
Il devient clair que les données des Rollups doivent être bon marché ET transparentes. Le calldata n’est pas optimisé pour cela, alors que la BLOB-Carrying Transaction l’est parfaitement.
Vous vous demandez peut-être : à quoi servent ces données, si elles semblent peu importantes ?
En réalité, elles ne sont utiles que dans quelques cas :
-
Pour les Optimistic Rollups, basés sur une hypothèse de confiance, un comportement malhonnête est possible. Dans ce cas, les données publiées permettent à un utilisateur de lancer un défi (fraud proof) ;
-
Pour les ZK Rollups, la preuve zéro-connaissance valide déjà la mise à jour d’état. Les données sont publiées pour permettre aux utilisateurs de recalculer l’état complet, activant ainsi un « sas d’évacuation » (escape hatch) si les nœuds L2 tombent en panne (ceci nécessite l’arbre d’état complet, sujet abordé plus tard).
Autrement dit, les contrats utilisent très rarement ces données directement. Même dans un fraud proof, il suffit de prouver que certaines données ont existé, sans qu’elles soient stockées à l’avance sur la chaîne principale.
Si nous plaçons ces données dans un BLOB, inaccessible aux contrats, mais que l’on conserve son commitment sur la chaîne, alors lorsqu’un défi est lancé, il suffit de fournir la donnée manquante et de montrer qu’elle correspond au commitment.
Cela exploite la transparence des données tout en évitant le coût prohibitif de les stocker intégralement dans les contrats.
Enregistrer uniquement le commitment permet de garantir la vérifiabilité tout en optimisant radicalement les coûts. C’est une solution élégante et efficace pour les Rollups.
Notons que Dencun n’utilise pas une structure d’arbre de Merkle comme Celestia, mais un algorithme subtil appelé KZG (Kate-Zaverucha-Goldberg, ou engagement polynomial).
Bien que la génération d’une preuve KZG soit plus complexe que celle d’une preuve Merkle, sa vérification est plus légère et plus rapide. Son inconvénient est la nécessité d’un paramètre de configuration confidentiel (ceremony.ethereum.org, désormais terminé) et une vulnérabilité face aux ordinateurs quantiques (bien que Dencun utilise une méthode de hachage de version permettant un remplacement futur si nécessaire).
Concernant les projets DA populaires comme Celestia, ils utilisent une variante de l’arbre de Merkle. Comparé au KZG, cela repose davantage sur la bonne foi des nœuds, mais réduit les exigences matérielles, favorisant ainsi la décentralisation.
03 Les opportunités de Dencun
L’EIP-4844 améliore les performances des Layer 2, mais introduit aussi de nouveaux risques — et donc de nouvelles opportunités.
Pour comprendre pourquoi, revenons au mécanisme d’évacuation d’urgence (ou retrait forcé).
Quand un nœud L2 tombe en panne, ce mécanisme permet aux utilisateurs de récupérer leurs fonds sur la chaîne principale. Pour cela, l’utilisateur doit disposer de l’arbre d’état complet de Layer 2.
Normalement, il suffit de demander les données à un nœud complet L2, générer une preuve Merkle, puis la soumettre au contrat L1 pour prouver la légitimité du retrait.
Mais attention : l’utilisateur active justement ce mécanisme parce que le nœud L2 est malveillant. Si le nœud est corrompu, il ne fournira probablement pas les bonnes données.
C’est ce que Vitalik appelle une « attaque par retenue de données » (data withholding attack).
Avant l’EIP-4844, les données L2 étaient enregistrées de façon permanente dans le calldata. Sans nœud L2 coopératif, l’utilisateur pouvait déployer son propre nœud complet, récupérer historiquement toutes les données publiées par le séquenceur L2 sur Ethereum, reconstruire l’arbre d’état, générer la preuve Merkle, et retirer ses actifs en toute sécurité.
Mais après l’EIP-4844, les données L2 sont stockées dans les BLOB, supprimés automatiquement après 18 jours.
Par conséquent, la méthode ci-dessus n’est plus possible. Pour obtenir l’arbre d’état complet, l’utilisateur dépend désormais de tiers ayant volontairement conservé les anciennes données BLOB (normalement supprimées), ou de rares nœuds natifs L2.
Ainsi, après l’activation de l’EIP-4844, il devient extrêmement difficile pour un utilisateur d’obtenir de manière fiable l’arbre d’état complet de Layer 2.
Sans accès stable à cet arbre, le retrait forcé devient impossible en situation d’urgence. L’EIP-4844 crée donc une faille de sécurité dans les Layer 2.
Pour combler cette lacune, nous avons besoin d’une solution de stockage fiable, sans confiance, et dotée d’un modèle économique viable. Ici, le mot-clé est « sans confiance » — différent des solutions de stockage traditionnelles.
Ethstorage peut résoudre ce problème de confiance, et a d’ailleurs reçu deux financements successifs de la Fondation Ethereum.
Ce concept est véritablement aligné avec les besoins créés par la mise à niveau Dencun — un domaine à surveiller de près.
Premièrement, Ethstorage permet de prolonger de manière totalement décentralisée la disponibilité des données BLOB, comblant ainsi la plus grande faiblesse de sécurité des Layer 2 post-4844.
Deuxièmement, la plupart des solutions L2 actuelles se concentrent sur l’évolutivité du calcul (augmentation du TPS). Or, la demande de stockage sécurisé sur Ethereum explose, notamment avec la popularité des NFT et des applications DeFi.
Par exemple, le stockage des NFT sur chaîne est crucial : les utilisateurs veulent posséder non seulement le jeton, mais aussi l’image associée. Ethstorage permet de stocker ces images sans dépendre de serveurs tiers ni introduire de nouvelles failles de confiance.
Enfin, Ethstorage répond aussi au besoin de frontends décentralisés pour les dApps. Aujourd’hui, ces interfaces sont souvent hébergées sur des serveurs centralisés (avec DNS), ce qui les expose à la censure, au détournement DNS, aux piratages ou pannes. Des cas comme Tornado Cash illustrent ces risques.
Ethstorage en est encore à ses premiers tests sur testnet, mais ceux qui croient en ce domaine peuvent déjà l’expérimenter.
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
@BiteyeCN
