La mise à niveau de Cancun arrive. Quelles adaptations les L2 traditionnels ont-ils fait ?

TL;DR：

• La mise à niveau de Cancun sera lancée le 13 mars 2024 et EIP4844 sera bientôt en ligne. Danksharding est au cœur de la feuille de route Ethereum, et cette mise à niveau est la première étape pour implémenter Danksharding.
• Après l'adaptation d'Ethereum L2 à EIP4844, les frais de transaction ont considérablement diminué et le TPS de L2 a doublé. **Les utilisateurs auront l'impression que les transactions sont plus rapides, moins chères, plus fluides et plus réactives. Il y aura des applications Dapp plus complexes et plus volumineuses sur ces L2. **
• Les cumuls optimistes sont plus faciles à adapter à EIP4844, tandis que les cumuls ZK sont plus complexes à adapter**. Ethereum n'a pas de contrat précompilé pour prendre en charge les courbes elliptiques BLS12-381, ce qui rend difficile la vérification de certains ZKP et entrave la progression des cumuls ZK s'adaptant à EIP4844. **
• Le problème des courbes elliptiques peut être résolu de deux manières : 1. Attendez qu'Ethereum précompile les courbes elliptiques BLS12-381 ; 2. Utilisez une autre méthode de preuve pour atteindre le même objectif, utilisez BN254 pris en charge par la précompilation Ethereum.
• Actuellement, Arbitrum, Optimistic, Starknet, zkSync, Scroll, Polygon zkEVM et le nouveau L2 Morph s'adaptent tous à EIP4844. Parmi eux, Arbitrum, Optimistic et Starknet ont déclaré qu'ils mettraient en œuvre l'adaptation EIP4844 après la mise à niveau de Cancun. Morph a pris les devants en lançant la solution innovante d'adaptation zkSNARK zkEVM, qui sera le premier zkSNARK zkEVM à s'adapter à EIP4844

1. Origines

En 2020, Ethereum a publié la "Feuille de route Ethereum centrée sur le rollup", et l'image finale d'Ethereum décrite dans "Endgame" publiée par Vitalik l'année suivante, ** a déterminé la grande image d'Ethereum. de la couche de base d'Ethereum pour servir Rollup. **

Ethereum a conçu la technologie de partitionnement de Danksharding pour améliorer la convivialité d'Ethereum en tant que couche de disponibilité des données. Cela réduira considérablement les frais de transaction de L2, augmentera le TPS de Rollup et permettra une expansion substantielle d’Ethereum.

Jusqu'à cette année, la mise à niveau Ethereum Cancun-Dencun a finalement été lancée le 13 mars 2024 et EIP4844 est sur le point d'être mis en ligne. Ce hard fork peut être considéré comme la première étape dans la mise en œuvre de Danksharding par Ethereum.Le cœur de la feuille de route. **

Concernant ce qu'est la couche DA, les principes techniques de Danksharding et le contenu de l'EIP4844, veuillez vous référer à un article technique que j'ai écrit l'année dernière : DA (Data Availability) L'été arrive ?

**2. Comment la mise à niveau de Cancún profitera-t-elle à la L2 ? **

EIP4844 introduit un nouveau type de transaction appelé transactions portant des objets blob**. **Chaque transaction transportant des blobs peut « transporter » une liste de blobs. Un blob est un paquet de données d’environ 125 Ko. Les blobs sont stockés pendant une courte période, seulement 4 096 époques, soit un peu plus de 18 jours.

• Les frais de transaction L2 ont considérablement diminué. Étant donné que les Blobs ne nécessitent pas de stockage permanent, les Blobs sont plus grands et moins chers que l’espace des blocs. Blob peut stocker 10 fois plus de données que Calldata pour la même consommation de gaz. Le rollup adapté à EIP4844 peut stocker les données de transaction dans des Blobs, réduisant ainsi les frais de transaction d'un ordre de grandeur.
• Le TPS de la L2 est doublé. L’objectif actuel est de 3 blobs par bloc, avec un maximum de 6 blobs autorisés. Les blocs ne font que 90 Ko et chaque blob fait environ 125 Ko. L'introduction de Blob équivaut à étendre plusieurs fois l'espace du bloc pour stocker les données du Rollup, de sorte que le TPS du Rollup peut également être doublé. Et "Sur l'augmentation de la limite de gaz de bloc" écrit par Toni et Vitalic a déclaré qu'en augmentant la limite de gaz de bloc et le prix des octets de données d'appel non nuls, une taille de bloc plus petite avec moins de variables sera obtenue, de sorte que davantage puisse être ajouté dans le futur. Plus il y a de blobs, plus l’espace de stockage est grand.

Pour les utilisateurs finaux, une fois **EthereumL2 adapté à EIP4844, la vitesse de transaction sera plus rapide, le coût sera inférieur, l'expérience sera plus fluide et la réponse sera plus réactive. Il y aura des applications Dapp plus complexes et plus volumineuses sur ces L2. **

3. Comment L2 s'adapte-t-il à EIP4844 ?

Comment L2 s’adapte-t-il à EIP4844 ? Nous devons discuter séparément du cumul optimiste et du cumul ZK.

Les cumuls optimistes s'adaptent à EIP4844

Le cumul optimiste utilise la preuve de fraude pour garantir l'exactitude de l'exécution du cumul. Autrement dit, le nœud choisit d'abord de croire que la transition d'état est correcte. À moins que quelqu'un ne lance un certificat de fraude dans un délai spécifié pour prouver que la transition d'état précédemment soumise est illégale, la transition d'état sera révoquée.

Le cumul optimiste est plus simple à adapter à EIP4844 que le cumul ZK. Soumettez toutes les transactions L2 à L1 via des transactions transportant des objets Blob pour terminer l'adaptation. De plus, la preuve de fraude doit être ajustée pour s'adapter à EIP4844. Cette partie peut être réalisée lentement. Après tout, de nombreux rollups optimistes n’ont pas encore lancé de preuves de fraude. J'ai mis en ligne une attestation de fraude, mais j'ai constaté qu'aucune attestation de fraude n'avait été déposée depuis plus de deux ans.

Soumission de transaction L2 : lorsque le Rollup est soumis, la transaction transportant le Blob est utilisée pour stocker les données du Rollup dans le Blob. La charge utile de la transaction transportant un Blob est rlp([tx_payload_body, blobs, engagements, proofs]), où

• tx_payload_body- est le TransactionPayloadBody de la transaction blob EIP-2718 standard.
• blobs - Liste des blobs. Une transaction peut contenir jusqu'à deux blobs.
• engagements - Liste des engagements KZG pour le blob.
• preuves- Blob et liste des preuves correspondant à l'engagement KZG. Cette preuve sera vérifiée par le nœud ETH.

Ajustement pour preuve de fraude :

• Premièrement, le prouveur et le challenger ont besoin de plusieurs cycles d'interaction pour trouver le point litigieux.
• Soumettez ensuite le point litigieux à L1 pour jugement. Pour s'adapter à EIP4844, il peut être nécessaire de prouver que les données en question sont stockées sur un certain Blob.
• Étant donné que les données Blob seront supprimées après environ 18 jours, la période de défi doit être antérieure à leur suppression, ce qui est satisfait par les cumuls optimistes actuels. Généralement, la période de challenge n'excède pas 7 jours.

ZK Rollups s'adapte à EIP4844

Le cumul ZK utilise ZKP pour prouver que la transition d'état L2 est correcte. L'adaptation du cumul ZK à EIP4844 est plus compliquée que le cumul optimiste.

1. Soumission de transaction L2 : cette étape du cumul optimiste est similaire.
2. ** Soumission de la preuve ZK : par rapport au ZK Rollup avant adaptation, en plus de la preuve de transition d'état ZKP, un processus de preuve supplémentaire est requis. C'est-à-dire qu'il est prouvé que l'engagement du blob et le lot de transactions correspondent, garantissant ainsi que la saisie de la preuve de transition d'état est correcte. **
3. Par exemple : le circuit ZK de transition d'état peut générer une preuve du processus de calcul a + a = b. Le ZKP généré lorsque (a=1,b=2) et (a=2,b=4) est légal. Par conséquent, je dois également fournir une preuve que l'entrée que j'ai fournie à ce moment-là était (a=1,b=2) au lieu de (a=2,b=4).
4. Cela n'a pas besoin d'être fait avant l'adaptation à EIP4844, car les données sont directement stockées dans Calldata et peuvent être lues directement, garantissant que l'entrée ne sera pas ajustée. Après avoir utilisé EIP4844, les données Blob ne peuvent pas être lues directement, et cela ne peut être prouvé que via un nouveau circuit.
5. Il est plus facile de mettre en œuvre ce mécanisme de preuve en utilisant le rollup ZK de STARK (comme Starknet). Il s'agit d'un défi pour le cumul ZK utilisant SNARK. La raison est la suivante : ** La courbe elliptique utilisée par l'engagement blob d'EIP4844 est BLS12-381, alors que le contrat précompilé ETH ne prend en charge que BN254. En raison des différentes courbes, il nous est difficile de Vérifiez directement la preuve d’achèvement de l’engagement blob dans le contrat intelligent. **
6. **ZkEVM/zkVM utilisant SNARK doit résoudre le problème mentionné au point 2 selon lequel la preuve ZK ne peut pas être générée en raison d'une inadéquation de courbe. **

• En attente qu'Ethereum prenne en charge les contrats précompilés BLS12-381. Ce sera long.
• Utilisez une autre méthode de preuve pour prouver. Pour concevoir de nouveaux circuits, vous devez utiliser la courbe elliptique BN254 supportée par le contrat précompilé. Actuellement, nous voyons Morph adopter cette approche. Cela fait également de Morph le premier zkEVM à terminer l'adaptation EIP4844.

Solution intégrée EIP-4844 zkEVM de Morph, veuillez consulter :

**4. Quels L2 sont adaptés à EIP4844 ? **

Dans le rollup Optimistic, Optimism et Arbitrum ont exprimé leur engagement à adopter l'EIP-4844 et travaillent en étroite collaboration avec leurs communautés pour tester et déployer les mises à jour nécessaires. Arbitrum est un rollup de niveau 1 et offre une sécurité relativement bonne. Cela implique la nécessité d’adapter la preuve de fraude à EIP4844. Le rollup optimiste est un rollup de niveau 0. Il n'existe actuellement aucune preuve de fraude. Il est plus facile à adapter, mais la sécurité n'est pas assez élevée.

Dans le rollup ZK, la difficulté de l'adaptation du rollup à l'aide de STRAK et SNARK est différente. Il est plus facile d'adapter EIP4844 avec le rollup de STARK, et Starknet est l'un des représentants. Starknet a publié un article indiquant que Cancun mettra en œuvre l'adaptation EIP4844 après la mise à niveau (lien de l'article). À l'aide du rollup de SNARK, zkSync explore également comment tirer parti des transactions transportant des objets blob pour réduire davantage les coûts et améliorer les performances. Scroll a publié l'année dernière un article présentant l'idée d'adapter EIP4844 (lien de l'article)

Le plus impressionnant est Morph, qui est un rollup ZK optimiste et a été le premier à publier une solution pour adapter zkEVM à EIP4844. **On peut dire que c'est le premier rollup zkEVM à compléter EIP4844. **

Optimistic ZK Rollup combine les avantages des deux types de Rollup. Il croit avec optimisme aux résultats d'exécution soumis par Sequencer et permet à ceux qui doutent des résultats de lancer des défis. Ce n'est que lorsqu'un défi est émis que le prouveur générera du ZKP pour prouver l'exactitude des résultats d'exécution. **Il présente l'efficacité du cumul optimiste et la fiabilité éprouvée du cumul ZK. **