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

TL;DR :

• La mise à niveau de Cancun sera lancée le 13 mars 2024 et l'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 vers la réalisation de 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 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, en utilisant 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 une solution innovante d'adaptation zkSNARK zkEVM, qui sera le premier zkSNARK zkEVM adapté à EIP4844

1. Contexte

En 2020, Ethereum a publié une feuille de route avec Rollup comme principale initiative ouvrant la voie à l'avenir. développement. Par la suite, Vitalik a décrit la vision finale d'Ethereum dans "Endgame" de la deuxième année, en mettant l'accent sur l'optimisation de la construction de la couche de base et en fournissant un support pour le Rollup. Ces mesures ont clarifié l'orientation principale du développement futur d'Ethereum et jeté les bases de la croissance continue de l'écosystème blockchain.

Ethereum a introduit la technologie de partitionnement Danksharding pour améliorer sa stabilité en tant que couche de disponibilité des données. Cette technologie devrait réduire les frais de transaction L2, augmenter le nombre de transactions Rollup par seconde et étendre encore l'échelle du réseau Ethereum.

À partir de cette année, la mise à niveau Ethereum Cancun-Dencun a finalement été publiée le 13 mars 2024, avec le lancement prochain d'EIP4844. Ce hard fork est considéré comme la première étape pour Ethereum vers la mise en œuvre de Danksharding et constitue un maillon crucial de la feuille de route d’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 a la capacité de « transporter » une liste de blobs. Un blob est un paquet de données d’une taille d’environ 125 Ko. La durée de stockage de Blob est relativement courte, seulement 4096 époques, soit environ 18 jours.

• 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 des blocs. 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.
• Le TPS de la L2 a été 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.

Après s'être adapté à EIP4844, Ethereum L2 offrira aux utilisateurs finaux des transactions plus rapides, des coûts réduits, une expérience plus fluide et des réponses plus réactives. Cela apportera des applications Dapp plus complexes et à grande échelle à la plate-forme 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 est une technologie qui garantit l'exactitude de l'exécution du rollup grâce à la preuve de la fraude. Dans le cadre de ce mécanisme, le nœud supposera que la transition d'état est correcte à moins que quelqu'un ne propose une preuve de fraude dans le délai spécifié pour prouver que la transition d'état est illégale. Une fois la preuve de fraude obtenue, les transitions d'état précédemment soumises seront révoquées.

Le rollup optimiste est plus simple à adapter à EIP4844 que le rollup 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 effectué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 de blobs. Une transaction peut contenir jusqu'à deux blobs.
• engagements - Liste des engagements KZG de Blob.
• preuves- Blob et liste 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.
• Ensuite, soumettez 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 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, et le contrat précompilé ETH ne prend en charge que BN254. En raison des différentes courbes, il nous est difficile de l'utiliser directement. Vérifiez le certificat d’achèvement de l’engagement blob dans le contrat.
6. 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

4. Quelles sont les adaptations L2 ? Vous avez 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 suffisamment élevée.

Dans le rollup ZK, la difficulté d'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). Avec le cumul SNARK, zkSync explore également comment exploiter les transactions transportant des objets blob pour réduire davantage les coûts et améliorer les performances. Scroll a publié un article l'année dernière présentant l'idée d'adapter EIP4844 (lien de l'article)

La chose la plus impressionnante est Morph, qui est un Optimistic ZK Rollup et a été le premier à publier une solution pour que zkEVM s'adapte à EIP4844. serait 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 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 présente l'efficacité du cumul optimiste et la fiabilité éprouvée 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!