Mise à niveau de Cancun : quelles L2 l'ont adoptée ?
TechFlow SélectionTechFlow Sélection
Mise à niveau de Cancun : quelles L2 l'ont adoptée ?
L'adaptation des Optimistic Rollups à l'EIP-4844 est plus simple, tandis que celle des ZK Rollups est plus complexe.
Dédié à des analyses Web3 approfondiesRédaction : Maggie@Foresight Ventures
TL;DR
-
La mise à jour Cancun sera lancée le 13 mars 2024, et l'EIP-4844 arrivera bientôt. Danksharding est au cœur de la feuille de route d'Ethereum, et cette mise à jour en constitue la première étape.
-
Une fois les L2 Ethereum adaptés à l’EIP-4844, les frais de transaction chuteront fortement et le TPS des L2 doublera voire plus. Les utilisateurs percevront des transactions plus rapides, moins coûteuses, avec une expérience plus fluide et réactive. Des applications Dapp plus complexes et volumineuses émergeront sur ces L2.
-
L'adaptation des rollups optimistes à l'EIP-4844 est simple, tandis que celle des rollups ZK est plus complexe. Le fait qu'Ethereum ne dispose pas de contrats précompilés supportant la courbe elliptique BLS12-381 rend difficile la vérification de certaines preuves ZKP, ce qui ralentit l'adoption de l'EIP-4844 par les rollups ZK.
-
Ce problème de courbe elliptique peut être résolu de deux manières : 1. Attendre que la prise en charge précompilée de BLS12-381 soit intégrée dans Ethereum ; 2. Utiliser un autre type de preuve atteignant le même objectif, en employant la courbe BN254 déjà prise en charge par les contrats précompilés d'Ethereum.
-
Actuellement, Arbitrum, Optimism, Starknet, zkSync, Scroll, Polygon zkEVM ainsi que le nouveau L2 Morph s'adaptent tous à l'EIP-4844. Parmi eux, Arbitrum, Optimism et Starknet ont annoncé mettre en œuvre leur adaptation après la mise à jour Cancun. Morph a quant à lui publié en premier une solution innovante d'adaptation du zkSNARK zkEVM à l'EIP-4844, devenant ainsi le premier zkSNARK zkEVM compatible avec EIP-4844.
I. Contexte
En 2020, Ethereum a publié sa « Feuille de route centrée sur les Rollups », puis l’année suivante Vitalik a décrit dans son article « Endgame » la vision finale du réseau. Ces documents ont fixé la direction principale d’Ethereum : optimiser la couche fondamentale pour mieux servir les rollups.
Ethereum a conçu la technologie de sharding Danksharding afin d’améliorer la disponibilité des données sur sa couche de base. Cela réduira fortement les frais de transaction sur les L2, augmentera le TPS des rollups et permettra une extension massive d’Ethereum.
Cette année enfin, la mise à jour Cancun-Deneb d’Ethereum a été lancée le 13 mars 2024, marquant l’arrivée imminente de l’EIP-4844. Ce hard fork constitue véritablement la première étape vers la réalisation de Danksharding, au cœur absolu de la feuille de route d’Ethereum.
II. En quoi la mise à jour Cancun bénéficie-t-elle aux L2 ?
L’EIP-4844 introduit un nouveau type de transaction appelé « transaction portant des blobs ». Chaque transaction de ce type peut « transporter » une liste de blobs. Un blob est un paquet de données d’environ 125 Ko. Les blobs sont stockés temporairement pendant 4096 epochs, soit légèrement plus de 18 jours.
-
Diminution drastique des frais de transaction sur les L2. Comme les blobs n’ont pas besoin d’être stockés indéfiniment, ils offrent un espace bien plus vaste et économique que celui du bloc standard. À consommation de gaz équivalente, un blob peut stocker jusqu’à 10 fois plus de données que les calldata. Les rollups compatibles avec l’EIP-4844 peuvent donc placer leurs données transactionnelles dans les blobs, réduisant ainsi les frais d’un ordre de grandeur.
-
Le TPS des L2 augmente exponentiellement. Actuellement, chaque bloc cible 3 blobs, pouvant en accueillir jusqu’à 6 maximum. Le bloc principal fait seulement 90 Ko, alors qu’un seul blob représente environ 125 Ko. L’introduction des blobs revient à étendre plusieurs fois l’espace disponible dans chaque bloc pour y stocker les données des rollups, ce qui multiplie d’autant le TPS des rollups. De plus, comme mentionné par Toni et Vitalik dans leur article « On Increasing the Block Gas Limit », une augmentation future de la limite de gaz par bloc combinée à une hausse tarifaire des octets non nuls de calldata permettra d’avoir des blocs plus petits et plus stables, ouvrant la voie à davantage de blobs. Plus il y aura de blobs, plus l’espace de stockage sera grand.
Pour l’utilisateur final, une fois les L2 Ethereum adaptés à l’EIP-4844, les transactions seront plus rapides, moins coûteuses, l’expérience plus fluide et réactive. Des applications Dapp plus complexes et ambitieuses pourront prospérer sur ces L2.
III. Comment les L2 s’adaptent-ils à l’EIP-4844 ?
Comment les L2 s’adaptent-ils à l’EIP-4844 ? Il convient de distinguer selon qu’il s’agisse d’un Optimistic Rollup ou d’un ZK Rollup.
Adaptation des Optimistic Rollups à l’EIP-4844
Les rollups optimistes garantissent la validité des exécutions via des preuves de fraude (fraud proofs). Autrement dit, les nœuds supposent initialement qu’une transition d’état est correcte, sauf si, durant une période définie, quelqu’un soumet une preuve de fraude démontrant que la transition proposée était invalide — auquel cas celle-ci est annulée.
L’adaptation des Optimistic Rollups à l’EIP-4844 est relativement plus simple que pour les ZK rollups. Il suffit de soumettre toutes les transactions L2 via des transactions portant des blobs pour achever l’adaptation. Par ailleurs, il faudra ajuster les mécanismes de preuve de fraude pour les rendre compatibles avec l’EIP-4844, mais cela peut se faire progressivement. D’ailleurs, beaucoup d’Optimistic Rollups n’ont toujours pas déployé de preuves de fraude. Et ceux qui l’ont fait constatent qu’après plus de deux ans, aucune preuve de fraude n’a encore été soumise.
Soumission des transactions L2 : lors de la soumission, le rollup utilise une transaction portant des blobs pour stocker ses données dans un blob. La charge utile (payload) de cette transaction est rlp([tx_payload_body, blobs, commitments, proofs]), où :
-
tx_payload_body - correspond au corps standard de la transaction selon EIP-2718.
-
blobs - une liste de blobs. Une transaction peut contenir jusqu’à deux blobs.
-
commitments - une liste des engagements KZG associés aux blobs.
-
proofs - une liste des preuves liant chaque blob à son engagement KZG. Ces preuves sont vérifiées par les nœuds Ethereum.
Ajustement des preuves de fraude :
-
Tout d’abord, le prouveur et le challenger doivent interagir en plusieurs tours pour identifier le point litigieux.
-
Ensuite, le point contesté est soumis à L1 pour validation. Avec l’EIP-4844, il pourrait être nécessaire de prouver que les données litigieuses étaient bien présentes dans un blob spécifique.
-
Étant donné que les données des blobs sont supprimées après environ 18 jours, la période de contestation doit nécessairement se terminer avant cette suppression. Heureusement, tous les Optimistic Rollups actuels respectent cette contrainte, car leurs périodes de défi ne dépassent généralement pas 7 jours.
Adaptation des ZK Rollups à l’EIP-4844
Les ZK rollups utilisent des preuves ZK (ZKP) pour démontrer que la transition d’état L2 est correcte. Cette adaptation est donc plus complexe que pour les rollups optimistes.
-
Soumission des transactions L2 : cette étape est similaire à celle des Optimistic Rollups.
-
Soumission de la preuve ZK : outre la preuve ZKP standard de la transition d’état, il faut désormais ajouter une preuve supplémentaire : démontrer que l’engagement du blob correspond bien au lot de transactions, garantissant ainsi que les entrées de la preuve d’état sont correctes.
-
Par analogie : un circuit ZK peut produire une preuve du calcul a + a = b. Cette preuve est valide aussi bien pour (a=1, b=2) que pour (a=2, b=4). Il faut donc fournir une preuve additionnelle que les entrées utilisées étaient bien (a=1, b=2) et non (a=2, b=4).
-
Avant l’EIP-4844, cette étape était inutile car les données étaient directement accessibles dans les calldata, assurant ainsi l’intégrité des entrées. Avec l’EIP-4844, les données des blobs ne sont plus lisibles directement, ce qui nécessite un nouveau circuit dédié à cette preuve.
-
Les ZK rollups utilisant STARK (comme Starknet) trouvent plus facilement à implémenter ce mécanisme. En revanche, pour les rollups basés sur SNARK, cela pose un défi majeur : l’engagement blob de l’EIP-4844 utilise la courbe elliptique BLS12-381, alors que les contrats précompilés d’Ethereum ne supportent que BN254. Cette différence de courbe empêche de valider efficacement l’engagement blob directement dans un contrat intelligent.
-
Les zkEVM/zkVM basés sur SNARK doivent résoudre le problème d’impossibilité de générer une preuve ZK causé par cette incompatibilité de courbes mentionnée au point 2.
-
Attendre que la prise en charge précompilée de BLS12-381 soit ajoutée à Ethereum. Cependant, cela risque de prendre beaucoup de temps.
-
Adopter une autre méthode de preuve. Cela implique de concevoir un nouveau circuit utilisant la courbe elliptique BN254, prise en charge par les contrats précompilés. Aujourd’hui, nous observons que Morph a adopté cette approche, ce qui fait de Morph le premier zkEVM pleinement compatible avec l’EIP-4844.
Pour consulter la solution d'intégration EIP-4844 zkEVM de Morph : lien de l'article
IV. Quels L2 ont adapté l’EIP-4844 ?
Parmi les rollups optimistes, Optimism et Arbitrum ont exprimé leur engagement à adopter l’EIP-4844, collaborant étroitement avec leurs communautés pour tester et déployer les mises à jour nécessaires. Arbitrum appartient à la catégorie des rollups de niveau 1 (Stage 1), offrant une sécurité relativement bonne, bien qu’il doive adapter ses preuves de fraude à l’EIP-4844. Optimism, quant à lui, est un rollup de niveau 0 (Stage 0), sans preuve de fraude à ce jour, ce qui facilite son adaptation, mais au détriment de la sécurité.
Dans le domaine des ZK rollups, la difficulté d’adaptation varie selon l’algorithme utilisé. Les rollups basés sur STARK s’adaptent plus facilement à l’EIP-4844, avec Starknet comme principal représentant. Celui-ci a publié un article annonçant son intention de mettre en œuvre cette adaptation après la mise à jour Cancun. Quant aux rollups basés sur SNARK, zkSync explore comment exploiter les transactions portant des blobs pour réduire encore les coûts et améliorer les performances. Scroll a, quant à lui, publié l’année dernière un article détaillant sa stratégie d’adaptation à l’EIP-4844.
Ce qui marque particulièrement, c’est Morph, un Optimistic ZK Rollup, qui a été le premier à publier une solution complète d’adaptation du zkEVM à l’EIP-4844, devenant ainsi le premier zkEVM Rollup compatible avec l’EIP-4844.
L’Optimistic ZK Rollup combine les avantages des deux types de rollups. Il suppose par défaut la validité des résultats fournis par le Séquenceur, tout en autorisant toute personne doutant du résultat à lancer un défi. Seulement en cas de défi, un prouveur génère une preuve ZK pour attester de la justesse du résultat. Il allie ainsi l’efficacité des Optimistic Rollups à la fiabilité des preuves ZK des rollups ZK.
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
Foresight Ventures
