Foresight Ventures : la mise à niveau de Cancun arrive, quelle L2 a été adaptée ?

Auteur : Maggie@Foresight Ventures

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 d'Ethereum, et cette mise à niveau est la première étape pour réaliser 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 sentiront que la vitesse de transaction est plus rapide, le coût est inférieur, l'expérience est plus fluide et la réponse est plus réactive. 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 certaines vérifications ZKP difficiles 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 la précompilation Ethereum prise en charge BN254.
• 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. Contexte

En 2020, Ethereum a publié la "Rollup-centered Ethereum Roadmap", et la version finale d'Ethereum décrite dans "Endgame" publiée par Vitalik l'année suivante L'image détermine le direction générale d'Ethereum : optimiser la construction de la couche de base d'Ethereum et servir le Rollup.

Ethereum a introduit la technologie de partitionnement de Danksharding pour améliorer ses performances en tant que couche de disponibilité des données. Cette technologie devrait réduire considérablement les frais de transaction L2 et augmenter le TPS de Rollup, permettant ainsi une expansion à grande échelle 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 fois qu'Ethereum implémente Danksharding Cette étape. est au cœur de la feuille de route Ethereum. Concernant ce qu'est la couche DA, les principes techniques du 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 ? https://foresightnews.pro/article/detail/33575

2. Comment la mise à niveau de Cancun profite-t-elle à la L2 ?

EIP4844 introduit un nouveau type de transaction appelé transactions portant des objets blob. Chaque transaction transportant un blob peut "porter" 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.

1. Les frais de transaction L2 ont considérablement baissé. Étant donné que les Blobs ne nécessitent pas de stockage permanent, les Blobs sont plus grands et moins chers que l’espace de bloc. Les blobs peuvent 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.
2. Le TPS de la L2 est doublé. Actuellement, l'objectif par bloc est de 3 Blobs, 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, après l'adaptation de Ethereum L2 à 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.

Optimistic Rollups s'adapte à EIP4844

Optimistic Rollup utilise la preuve de fraude pour garantir l'exactitude lors de l'exécution du rollup. Le nœud supposera que la transition d'état est correcte, à moins que quelqu'un ne fournisse un certificat de fraude dans le délai spécifié, indiquant que la transition d'état soumise précédemment est illégale, auquel cas la transition d'état sera annulée.

Par rapport à ZK Rollup, Optimistic Rollup est plus facile à adapter à EIP4844. Il lui suffit de soumettre les transactions de couche 2 à la couche 1 via des transactions transportant des objets blob pour terminer l'adaptation. De plus, l'ajustement de la preuve de fraude pour se conformer aux exigences de l'EIP4844 est également nécessaire, bien que cette partie puisse être réalisée progressivement. En fait, de nombreux projets Optimistic Rollup n’ont pas encore lancé de fonctions anti-fraude. Même si des preuves de fraude ont été lancées, aucune preuve de fraude n'a été soumise au cours des deux dernières années.

1. 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, commitments, 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 de Blob.
• preuves- Liste de Blob et de preuves correspondant à l'engagement KZG. Cette preuve sera vérifiée par le nœud ETH.

Ajustement de la preuve de fraude :

• Tout d'abord, le prouveur et le challenger ont besoin de plusieurs cycles d'interaction pour trouver le point de litige.
• Soumettez ensuite le point litigieux à L1 pour jugement. Pour s'adapter à EIP4844, il peut être nécessaire de prouver que les données en cause 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 avant 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

ZK rollup 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 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.

   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).

   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.

   Il est plus facile de mettre en œuvre ce mécanisme de preuve en utilisant le rollup ZK de STARK (comme Starknet). C'est 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 le faire directement. Vérifiez la preuve de l’achèvement de l’engagement du blob dans le contrat intelligent.

3. L'utilisation de zkEVM/zkVM de 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 attendant qu'Ethereum prenne en charge les contrats précompilés BLS12-381. Ce sera long.
• Prenez une autre façon de le 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 d'intégration EIP-4844 zkEVM de Morph, veuillez consulter : https://medium.com/@morphlayer2/morphs-solution-to-eip-4844-zkevm-integration-7f469910478f

IV. Les L2 sont adaptés à EIP4844 ?

Le rollup optimiste est relativement facile à adapter à EIP4844.

• Arbitrum lancera la mise à niveau Arb OS20 le 14 mars pour mettre en œuvre les modifications EIP pour la mise à niveau de Cancun (lien de l'article). Arbitrum appartient à l'étape 1 Rollup. La soumission des transactions et la preuve de fraude doivent s'adapter à EIP4844, et sa sécurité est relativement bonne.
• Optimism a lancé la mise à niveau Ecotone le 14 mars pour compléter l'adaptation(lien de l'article). 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 suffisamment élevée. Une fois l'adaptation terminée, tous les réseaux de super-chaînes de l'écosystème Op bénéficieront également de l'EIP-4844.

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 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).
• zkSync a été mis à niveau via Boojum pour permettre à zkSync de terminer la transition de la preuve SNARK à la preuve STARK. Il s'agit également d'une préparation à la mise à niveau EIP4844. Boojun est un système de preuve basé sur STARK. (Lien de l'article)
• Il est relativement compliqué de s'adapter avec le rollup de SNARK

Polygon zkEVM devrait être lancé avec la mise à niveau Feijoa en mai, s'adaptant à EIP-4844. (Lien de l'article)

Scroll a publié l'année dernière un article présentant l'idée de s'adapter à EIP4844 (Lien de l'article).

La chose la plus impressionnante est Morph, qui est un rollup optimiste de ZK et a été le premier à publier le plan d'adaptation zkSNARK zkEVM pour EIP4844, on peut dire qu'il est le premier à terminer le rollup zkSNARK zkEVM d'EIP4844 (article lien) . 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 ont des doutes sur les 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 a l'efficacité du cumul optimiste et la fiabilité éprouvée par ZK du cumul ZK.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!