V Shen Xinwen : Après ETH Fang intégré à ZK, où va Layer2 ?

Produit | Otous les jours

Compiler | Loopy Lu

Aujourd’hui, Vitalik Buterin a publié un nouvel article dans la communauté ETH intitulé « À quoi pourrait ressembler un ZK-EVM intégré ? ». Cet article explore comment ETH atelier aura son propre ZK-EVM intégré dans les futures mises à niveau du réseau.

Comme nous le savons tous, dans le contexte de la lenteur du développement du ETH, presque tous les principaux réseaux de couche 2 sont déjà équipés de ZK-EVM, mais lorsque le réseau principal de l’atelier ETH encapsulera son propre ZK-EVM, y aura-t-il un conflit entre le positionnement des rôles du réseau principal et celui de la couche 2 ?

Dans cet article, Vitalik Buterin souligne l’importance de la compatibilité, de la disponibilité des données et de l’auditabilité, et explore les possibilités d’implémenter des attesteurs efficaces et avec état. En outre, l’article explore la possibilité de mettre en œuvre des preuves d’efficacité avec état et discute du rôle des projets de couche 2 dans la fourniture de stratégies rapides de pré-confirmation et d’atténuation des MEV. Cet article reflète l’équilibre entre l’avancement du développement du réseau ETH par le biais des ZK-EVM tout en conservant sa flexibilité.

Odaily Planet Daily a compilé l’article original, et le texte complet de l’article est le suivant :

les rollups optimistes et les rollups ZK, en tant que protocoles EVM de couche 2 en plus de ETH, reposent tous deux sur la vérification EVM. Cependant, cela les oblige à faire confiance à une base de code volumineuse, et s’il y a des bogues dans cette base de code, ces machines virtuelles risquent d’être piratées. Cela signifie également que les ZK-EVM, même s’ils veulent être entièrement équivalents à l’EVM L1, auront besoin d’une certaine forme de gouvernance pour répliquer les modifications de l’EVM L1 dans leurs propres implémentations EVM.

Ce n’est pas une situation idéale. Étant donné que ces projets reproduisent les fonctionnalités qui existent déjà dans le protocole ETH Workshop pour eux-mêmes, ETH Governance est déjà responsable de la mise à niveau et de la correction des bogues, et ce que ZK-EVM fait essentiellement est de valider les blocs de ETH de couche 1. Au cours des prochaines années, nous nous attendons à ce que les clients légers deviennent de plus en plus puissants et qu’ils soient bientôt en mesure d’utiliser les ZK-SNARK pour valider pleinement les exécutions EVM L1. À ce moment-là, le réseau ETH disposera en fait d’un ZK-EVM dans un package. La question se pose donc : pourquoi ne pas rendre ce ZK-EVM nativement disponible pour les rollups ?

Cet article décrira plusieurs versions du « ZK-EVM encapsulé », en analysant leurs compromis, leurs défis de conception et les raisons pour lesquelles ils ne vont pas dans certaines directions. Les avantages de la mise en œuvre de la fonctionnalité d’un protocole doivent être comparés aux avantages de laisser l’écosystème gérer les transactions et de garder le protocole sous-jacent simple.

Quelles sont les caractéristiques clés que nous voulons obtenir du ZK-EVM encapsulé ?

Quels sont les attributs clés que nous pouvons attendre du ZK-EVM emballé ?

Fonction de base : Valider ETH blocs. La fonction de protocole (qui n’a pas encore été déterminée s’il s’agit d’un opcode, d’une précompilation ou d’un autre mécanisme) devrait être capable d’accepter au moins une racine pré-étatique, un bloc et une racine post-état en entrée, et de vérifier que la racine post-état est bien le résultat de l’exécution de ce bloc au-dessus de la racine pré-étatique. Compatible avec le multi-client de ETH Workshop. Cela signifie que nous voulons éviter l’intégration d’un système d’attestation unique et permettre à différents clients d’utiliser différents systèmes d’attestation.

Cela signifie également plusieurs choses :

Exigences en matière de disponibilité des données : pour toute exécution EVM qui utilise des preuves ZK-EVM encapsulées, nous voulons garantir que les données sous-jacentes sont utilisables afin que les prouveurs utilisant un système d’attestation différent puissent attester à nouveau l’exécution, et que les clients qui s’appuient sur ce système d’attestation puissent valider ces preuves nouvellement générées.

Les preuves résident à l’extérieur de l’EVM et des structures de données de blocs :* La fonctionnalité ZK-EVM ne prend pas vraiment les SNARK en entrée à l’intérieur de l’EVM, car différents clients s’attendent à différents types de SNARK. Au lieu de cela, cela pourrait être similaire à la validation d’objets blob : une transaction peut inclure des revendications (pré-état, corps de bloc, post-état) qui doivent être prouvées, dont le contenu peut être accessible par des opcodes ou des précompilations, et les règles de consensus côté client vérifient la disponibilité des données et la preuve des revendications faites dans le bloc, respectivement.

Auditabilité : si une exécution est prouvée, nous voulons que les données sous-jacentes soient utilisables afin qu’en cas de problème, les utilisateurs et les développeurs puissent les inspecter. En fait, cela ajoute une raison supplémentaire pour laquelle les exigences en matière de disponibilité des données sont importantes.

Évolutivité : Si nous trouvons un bogue dans une solution ZK-EVM particulière, nous voulons être en mesure de le corriger rapidement. Cela signifie qu’il n’y a pas besoin d’un hard fork pour résoudre le problème. Cela ajoute une autre raison pour laquelle les preuves en dehors de l’EVM et des structures de données par blocs sont importantes.

L’un des attraits de la prise en charge des « EVM approximatifs » :**L2 est la possibilité d’innover au niveau de la couche d’exécution et de faire évoluer l’EVM. Si une machine virtuelle L2 n’est que légèrement différente de l’EVM, il serait bien que L2 puisse utiliser le ZK-EVM natif dans le protocole pour les mêmes parties que l’EVM, et ne s’appuyer que sur son propre code pour gérer les différentes parties. Cela peut être réalisé en concevant une fonction ZK-EVM qui permet à l’appelant de spécifier un champ de bits, un opcode ou une liste d’adresses, qui sera gérée par un formulaire fourni de l’extérieur plutôt que par l’EVM lui-même. Nous pouvons également rendre le coût du gaz personnalisable dans une certaine mesure.

Systèmes multiclients « ouverts » vs. « fermés »

La « mentalité multi-clients » est probablement l’exigence la plus controversée de cette liste. Une option serait d’abandonner le multiclient et de se concentrer sur un schéma ZK-SNARK, ce qui simplifierait la conception. Mais au prix d’un « changement philosophique » plus important au sein de ETH Workshop (car cela revient à abandonner la mentalité multi-clients de longue date de ETH Workshop) et à introduire un plus grand risque. À long terme, par exemple, lorsque les techniques de vérification formelle s’amélioreront, il sera peut-être préférable d’emprunter cette voie, mais pour l’instant, cela semble trop risqué.

Une autre option est un système multiclient fermé avec un ensemble fixe de systèmes d’attestation connus dans le protocole. Par exemple, nous pouvons décider d’utiliser trois ZK-EVM : PSE ZK-EVM, Polygon ZK-EVM et Kakarot. Un bloc a besoin de preuves d’au moins deux de ces trois éléments pour être valide. C’est mieux qu’un système de preuve unique, mais cela rend le système moins adaptable en raison du fait que les utilisateurs doivent maintenir des validateurs pour chaque système de preuve existant, il y aura un processus de gouvernance inévitable pour incorporer de nouveaux systèmes de preuve, etc.

Cela me pousse à préférer un système multiclient ouvert où les preuves sont placées « à l’extérieur du bloc » et vérifiées séparément par les clients. Les utilisateurs individuels utiliseront n’importe quel client qu’ils souhaitent pour valider un bloc, et ils pourront le faire tant qu’au moins un prouveur créera une preuve pour ce système d’attestation. Le système d’attestation gagnera en influence en convainquant les utilisateurs de les exécuter, et non en convainquant le processus de gouvernance du protocole. Cependant, cette approche a un coût plus complexe, comme nous le verrons.

Quelles sont les fonctionnalités clés que nous voulons dans la mise en œuvre de ZK-EVM ?

Outre les garanties de base en matière d’exactitude fonctionnelle et de sécurité, l’attribut le plus important est la rapidité. Bien qu’il soit possible de concevoir un protocole asynchrone avec une fonctionnalité ZK-EVM intégrée où chaque revendication ne renvoie des résultats qu’après N emplacements, le problème devient beaucoup plus facile si nous pouvons garantir de manière fiable qu’une preuve sera générée en quelques secondes, de sorte que ce qui se passe dans chaque bloc soit autosuffisant.

Bien qu’il faille aujourd’hui des minutes ou des heures pour générer une preuve d’un bloc ETH, nous savons qu’il n’y a aucune raison théorique d’empêcher la parallélisation de masse : nous pouvons toujours assembler suffisamment de GPU pour prouver séparément les différentes parties de l’exécution du bloc, puis utiliser des SNARK récursifs pour assembler ces preuves. De plus, le processus de preuve peut être optimisé grâce à l’accélération matérielle des FPGA et des ASIC. Cependant, y parvenir est un défi d’ingénierie qu’il ne faut pas sous-estimer.

À quoi ressemble exactement la fonction ZK-EVM dans le protocole ?

À l’instar des transactions d’objets blob EIP-4844, nous introduisons un nouveau type de transaction qui inclut les revendications ZK-EVM :

classe ZKEVMClaimTransaction(Container) :
pré_state_root : octets 32
post_state_root : octets 32
transaction_and_witness_blob_pointers : Liste[VersionedHash]
…

Comme pour EIP-4844, l’objet passé dans le mempool est une version modifiée de la transaction :

classe ZKEvmClaimNetworkTransaction(Container) :
pré_state_root : octets 32
post_state_root : octets 32
preuve : octets
transaction_and_witness_blobs : Liste[Octets[CHAMP_ELEMENTS_PER_BLOB * 31 ]]

Ce dernier peut être converti en premier, mais pas l’inverse. Nous avons également étendu l’objet sidecar de bloc (introduit dans EIP-4844) pour inclure une liste de preuves déclarées dans un bloc.

Notez qu’en pratique, nous pouvons diviser le compartiment latéral en deux compartiments latéraux distincts, l’un pour les objets blob et l’autre pour l’attestation, et configurer un sous-réseau distinct pour chaque type de preuve (et un sous-réseau supplémentaire pour les objets blob).

Au niveau de la couche de consensus, nous avons ajouté une règle de validation qui n’acceptera un bloc que si le client voit une preuve valide de chaque revendication dans le bloc. La preuve doit être une concaténation de la preuve ZK-SNARK, sérialisée sous la forme d’une paire de transaction_and_witness_blobs, et pré_state_root valide avec (i) et le témoin (ii) affiche le bon post_state_root. (Bloquer, Témoin) Potentiellement, les clients peuvent choisir d’attendre M-of-N pour plusieurs types de preuves.

Une note ici est que l’exécution du bloc elle-même peut simplement être considérée comme un triplet qui doit être vérifié avec les triplets fournis dans l’objet ZKEVMClaimTransaction (σpre, σpost, Proof).

Par conséquent, l’implémentation ZK-EVM d’un utilisateur peut remplacer son client d’exécution, qui sera toujours utilisé par (i) les prouveurs et les constructeurs de blocs, et (ii) les nœuds qui s’occupent de l’indexation et du stockage des données pour une utilisation locale.

Validation et revalidation

Supposons que vous ayez deux clients ETH, dont l’un utilise PSE ZK-EVM et l’autre utilise Polygon ZK-EVM. Supposons qu’à ce stade, les deux implémentations aient évolué au point où elles peuvent prouver l’exécution d’un bloc ETH en moins de 5 secondes, et que pour chaque système de preuve, il y a suffisamment de volontaires indépendants exécutant du matériel pour générer des preuves.

Malheureusement, étant donné que les systèmes d’attestation indépendants ne sont pas intégrés, ils ne peuvent pas être encouragés dans le protocole, cependant, nous prévoyons que le coût de fonctionnement d’un prouveur est inférieur au coût de la R&D, de sorte que nous pouvons simplement utiliser un organisme générique pour financer les biens publics pour les prouveurs.

Supposons que quelqu’un publie une ZKEvmClaimNetworkTransaction, mais qu’il ne publie qu’une version de la preuve PSE ZK-EVM. Le nœud de preuve de Polygon ZK-EVM le voit et utilise la preuve de Polygon ZK-EVM pour calculer et republier l’objet.

Cela augmente le délai maximum total entre le nœud honnête le plus ancien acceptant un bloc et le nœud honnête le plus récent acceptant le même bloc δ : 2 δ+Tprove (en supposant Tprove<5 s).

La bonne nouvelle, cependant, c’est que si nous prenons la finalité de l’emplacement, nous pouvons presque certainement « pipeliner » cette latence supplémentaire ainsi que la latence de consensus multi-tours inhérente à SSF. Par exemple, dans une proposition à 4 emplacements, l’étape de « vote principal » peut n’avoir besoin que de vérifier la validité du bloc de base, mais l’étape « geler et confirmer » nécessitera alors une preuve d’existence.

Extension : Prise en charge de « l’EVM approximatif »

L’un des objectifs idéaux de la fonction ZK-EVM est de prendre en charge « l’EVM approximatif », c’est-à-dire un EVM avec quelques fonctionnalités supplémentaires intégrées. Il peut s’agir d’une nouvelle précompilation, de nouveaux opcodes, ou même d’options où le contrat peut être écrit dans un EVM ou une machine virtuelle complètement différente (par exemple, comme dans Arbitrum Stylus), ou même plusieurs EVM parallèles avec une communication croisée synchrone.

Certaines modifications peuvent être prises en charge de manière simple : nous pouvons définir un langage qui permet à ZKEVMClaimTransaction de passer la description complète de la règle EVM modifiée. Cela peut se faire :

• Table de gaz personnalisée (les utilisateurs ne peuvent pas réduire les coûts de gaz, mais peuvent les augmenter)
• Désactiver certains opcodes
• Définir le numéro de bloc (cela impliquera des règles différentes en fonction du hard fork)
• Définir un indicateur qui active un ensemble complet de modifications EVM qui ont été normalisées pour une utilisation L2 plutôt que pour une utilisation L1, ou d’autres modifications plus simples

Afin de permettre aux utilisateurs d’ajouter de nouvelles fonctionnalités de manière plus ouverte, en introduisant une nouvelle précompilation (ou opcode), nous pouvons inclure un enregistrement d’entrée/sortie précompilé dans le blob de ZKEVMClaimNetworkTransaction :

classe PrecompileInputOutputTran(Container) :
utilisé_precompile_addresses : Liste[Address]
entrées_commitments : Liste[VersionedHash]
sorties : Liste[Bytes]

L’exécution de l’EVM sera modifiée comme suit. Initialisez un tableau d’entrée vide. Chaque fois que l’adresse de used_precompile_addresses est appelée, nous ajoutons un objet InputsRecord(callee_address, gas, input_calldata) aux entrées et définissons la valeur RETURNDATA de l’appel sur outputs[i]。 Enfin, nous vérifions que used_precompile_addresses a été appelé len(outputs) un total de fois, et que inputs_commitments correspond au résultat promis en sérialisant le SSZ sur l’entrée. Le but de l’exposition des entrées_commitments est de permettre aux SNARK externes de prouver plus facilement la relation entre les entrées et les sorties.

Notez l’asymétrie entre l’entrée et la sortie, où l’entrée est stockée dans un hachage et la sortie est stockée dans les octets qui doivent être fournis. Cela est dû au fait que l’exécution doit être effectuée par un client qui ne voit que l’entrée et comprend l’EVM. L’exécution EVM a déjà généré l’entrée pour eux, ils n’ont donc qu’à vérifier si l’entrée générée correspond à l’entrée revendiquée, ce qui ne nécessite qu’une vérification de hachage. Cependant, les résultats doivent leur être fournis dans leur intégralité et doivent donc être des données exploitables.

Une autre fonctionnalité utile pourrait être d’autoriser les « transactions privilégiées » qui peuvent être invoquées à partir de n’importe quel compte d’expéditeur. Ces transactions peuvent être exécutées entre deux autres transactions, ou dans le cadre d’une autre transaction (et éventuellement privilégiée) lorsque la précompilation est appelée. Cela peut être utilisé pour permettre aux mécanismes non-EVM d’être rappelés dans l’EVM.

Cette conception peut être modifiée pour prendre en charge des opcodes nouveaux ou modifiés, en plus des précompilations nouvelles ou modifiées. Même avec seulement une précompilation, cette conception est assez puissante. Par exemple :

• En définissant used_precompile_addresses pour inclure une liste d’adresses de compte normales avec certains drapeaux dans l’état, et en créant un SNARK pour prouver qu’il est construit correctement, vous pouvez prendre en charge les fonctionnalités de style Arbitrum Stylus où le contrat peut être écrit dans EVM ou WASM (ou une autre machine virtuelle). Les transactions privilégiées peuvent être utilisées pour permettre aux comptes WASM d’être rappelés dans l’EVM.
• En ajoutant une vérification externe pour s’assurer que les enregistrements d’entrée/sortie et les transactions privilégiées effectuées par plusieurs EVM sont mis en correspondance de manière correcte, vous pouvez démontrer un système parallèle de plusieurs EVM communiquant entre eux via un canal de synchronisation.
• Un ZK-EVM de type 4 peut être utilisé en ayant plusieurs implémentations : une qui convertit directement Solidity ou un autre langage de haut niveau en une machine virtuelle compatible SNARK, et une autre qui le compile en code EVM et l’exécute dans le ZK-EVM intégré. La deuxième implémentation (inévitablement plus lente) ne peut s’exécuter que si le prouveur d’erreurs envoie une transaction qui affirme qu’il y a un bogue et collecte une prime s’il peut proposer que les deux gèrent des transactions différentes. Une machine virtuelle asynchrone pure peut être obtenue en renvoyant zéro à tous les appels et en mappant les appels aux transactions privilégiées ajoutées à la fin du bloc.

Extension : Prise en charge des certificateurs avec état

L’un des défis de la conception ci-dessus est qu’elle est complètement sans état, ce qui la rend inefficace en termes de données. Dans le cas d’une compression idéale des données, les envois ERC 20 utilisant la compression avec état peuvent être jusqu’à 3 fois plus économes en espace que la compression à état seul.

De plus, les EVM avec état n’ont pas besoin de fournir de données témoins. Dans les deux cas, le principe est le même : lorsque l’on sait déjà que les données sont exploitables parce qu’elles ont été saisies ou générées lors d’une précédente exécution EVM, alors c’est du gâchis de demander que les données soient disponibles.

Si nous voulons que la fonctionnalité ZK-EVM ait un état, nous avons deux options :

1. Exigences σpre Soit il est vide, soit il s’agit d’une liste de données disponibles avec les clés et les valeurs déclarées, soit il est exécuté avant un certain temps σpost 。

2. Vers ( σpre, σpost, Preuve ) Triple pour ajouter un reçu généré pour le bloc R d’engagements blob. Tous les engagements d’objets blob précédemment générés ou utilisés, y compris ceux qui représentent des blocs, des témoins, des reçus ou même des transactions d’objets blob EIP-4844 simples, peuvent avoir des contraintes de temps qui peuvent être référencées dans ZKEVMClaimTransaction et accessibles pendant leur exécution (éventuellement via une série d’instructions : « Sera validé Je Les octets de N… N+k-1 est inséré dans les données de bloc + témoin J "）。

L’option 1 signifie qu’au lieu d’avoir une vérification EVM sans état intégrée, il est préférable d’avoir une chaîne enfant EVM intégrée. La deuxième option crée essentiellement un algorithme de compression avec état intégré minimal qui utilise un objet blob précédemment utilisé ou généré comme dictionnaire. Les deux approches imposent une charge au nœud de l’étalon, qui est le seul à avoir besoin de stocker plus d’informations, et dans le deuxième cas, il est plus facile d’avoir une limite de temps sur ce fardeau que dans le premier cas.

Paramètres pour les multi-cerverseurs fermés et les données off-chain

Un système multi-étalon fermé avec un nombre fixe de preuves dans une structure M-of-N permet d’éviter une grande partie de la complexité ci-dessus. En particulier, un système multi-étalon fermé n’a pas à se soucier de s’assurer que les données sont sur la chaîne. De plus, un système multi-attester fermé permettra d’exécuter les preuves ZK-EVM hors chaîne, ce qui les rendra compatibles avec les solutions EVM Plasma.

Cependant, un système multi-étalon fermé ajoute de la complexité à la gouvernance et supprime l’auditabilité, ce qui représente des coûts élevés qui doivent être mis en balance avec ces avantages.

Si nous y intégrions ZK-EVM et en faisions une fonctionnalité de protocole, quel serait le rôle d’un « projet de couche 2 » ?

Les fonctions de vérification EVM actuellement mises en œuvre par les équipes de couche 2 elles-mêmes seront gérées par le protocole, mais le projet de couche 2 est toujours responsable d’un certain nombre de fonctionnalités importantes :

• Pré-confirmation rapide : La finalité d’un seul emplacement peut ralentir les emplacements de couche 1, tandis que les projets de couche 2 fournissent déjà à leurs utilisateurs des « pré-confirmations » qui sont soutenues par la propre sécurité de la couche 2 avec une latence beaucoup plus faible qu’un seul emplacement. Ce service continuera d’être entièrement sous la responsabilité de Layer 2.
• Stratégies d’atténuation MEV (Miner Extractable Value) : Il peut s’agir de mempools cryptés, d’une sélection de séquenceurs basée sur la réputation et d’autres fonctionnalités que les couches 1 sont réticentes à mettre en œuvre.
• Extensions de l’EVM : Les projets de couche 2 peuvent fournir des extensions significatives à l’EVM pour leurs utilisateurs. Cela inclut « l’EVM approximatif » et des approches fondamentalement différentes comme la prise en charge WASM d’Arbitrum Stylus et le langage Cairo convivial pour SNARK.
• Commodité pour les utilisateurs et les développeurs : les équipes de couche 2 ont fait beaucoup pour attirer les utilisateurs et les projets dans leur écosystème et leur faire sentir qu’ils sont les bienvenus ; ils sont rémunérés en capturant les MEV et les frais de congestion au sein de leur réseau. Cette relation est là pour rester.