Vitalik Nouvel article : L’avenir et les défis du ZK-EVM

Titre original : « À quoi pourrait ressembler un « ZK-EVM enchâssé » ? »

Auteur original : Vitalik

Compilation originale : Luccy, BlockBeats

*Note de l’éditeur : Le 13 décembre, Vitalik Buterin, co-fondateur de ETH Place, a publié un article qui s’est penché sur la mise en œuvre possible de la « ZK-EVM » (Zero-Knowledge Ethereum Virtual Machine) et a discuté de la conception de différentes versions de la ZK-EVM. *

*Le concept ZK-EVM de Vitalik vise à réduire la duplication des fonctionnalités du protocole Ethereum par les projets de couche 2 et à améliorer leur efficacité dans la validation des blocs Ethereum de couche 1. L’article souligne que les protocoles EVM de couche 2 actuels (tels que les Optimistic Rollups et les ZK Rollups) s’appuient sur des mécanismes de vérification EVM, mais cela signifie également qu’ils doivent faire confiance à une grande base de code. Une fois qu’il y a une vulnérabilité dans la base de code, ces machines virtuelles risquent d’être attaquées. *

*En outre, il a mentionné la prise en charge de « presque-EVM », qui permet aux machines virtuelles L2 d’utiliser ZK-EVM dans le protocole avec seulement des différences mineures par rapport à l’EVM, tout en offrant une certaine flexibilité pour une certaine personnalisation de l’EVM. *

Les protocoles EVM de couche 2 sur ETH, y compris les cumuls op et ZK, reposent sur la validation EVM. Cependant, cela les oblige à faire confiance à une grande base de code, et si ce stock de code est dans la faille, ces machines virtuelles risquent d’être piratées. De plus, même les ZK-EVM, qui veulent être entièrement équivalents à l’EVM L1, ont besoin d’une certaine forme de gouvernance pour répliquer les modifications de l’EVM L1 dans leurs propres implémentations EVM.

Cette situation n’est pas idéale, car ces projets reproduisent les fonctionnalités qui existent déjà dans le protocole ETH Fang, et ETH gouvernance Fang est déjà responsable de la mise à jour et de la correction des bogues : ZK-EVM fait essentiellement le même travail que la validation des blocs ETH L1 ! De plus, dans les prochaines années, nous nous attendons à ce que les clients légers deviennent de plus en plus puissants, et bientôt qu’ils valident entièrement l’exécution L1 ETH Fang à l’aide de ZK-SNARKs. À ce stade, le réseau ETH disposera effectivement d’un ZK-EVM intégré. La question se pose donc : pourquoi ne pas mettre cette localisation ZK-EVM à la disposition du projet de rollup ?

Cet article décrira plusieurs versions possibles du « ZK-EVM enchâssé » et explorera les compromis et les défis de conception, ainsi que les raisons de ne pas choisir une direction particulière. Les avantages de la mise en œuvre des fonctionnalités du protocole doivent être mis en balance avec les avantages laissés à l’écosystème et les avantages de garder le protocole sous-jacent simple.

Quels sont les attributs clés que l’on peut attendre de la ZK-EVM qui est inscrite en standard ?

Fonction de base : Valider ETH blocs. La fonctionnalité de protocole (qui n’est toujours pas certaine s’il s’agit d’un opcode, d’une précompilation ou d’un autre mécanisme) devrait au moins accepter la racine pré-étatique, le bloc et la racine post-état en entrée, et vérifier que la racine post-état est bien le résultat de l’exécution d’un bloc au-dessus de la racine pré-étatique.

Compatibilité avec ETH concept multi-clients. Cela signifie que nous voulons éviter d’utiliser un seul système d’attestation et permettre à différents clients d’utiliser différents systèmes d’attestation. Ceci, à son tour, signifie quelques points :

· Exigences en matière de disponibilité des données : pour toute exécution EVM qui utilise les preuves ZK-EVM intégrées, nous voulons être en mesure de 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.

· La preuve existe en dehors de l’EVM et de la structure de données de bloc : la fonctionnalité ZK-EVM n’utilise pas directement les SNARK comme entrée dans 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 : les transactions peuvent contenir des instructions qui doivent être prouvées (pré-état, corps de bloc, post-état), dont le contenu peut être accessible par des opcodes ou des précompilations, et les règles de consensus côté client vérifieront la disponibilité des données et l’existence de preuves pour chaque revendication faite dans le bloc, respectivement.

Vérifiabilité. 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. Dans la pratique, cela ajoute une autre raison à l’importance des exigences en matière de disponibilité des données.

Évolutivité. Si nous trouvons une vulnérabilité dans une solution ZK-EVM particulière, nous voulons être en mesure de la corriger rapidement. Cela signifie qu’il n’y a pas besoin d’un hard fork pour le réparer. Cela ajoute une raison supplémentaire de prouver l’importance d’exister en dehors de l’EVM et des structures de données de blocs.

Réseaux qui prennent en charge la quasi-EVM. L’un des attraits de L2 est la possibilité d’innover dans la couche d’exécution et de faire évoluer l’EVM. Si la machine virtuelle (VM) d’un L2 donné n’est que légèrement différente de l’EVM, il serait bien que L2 puisse toujours utiliser le même ZK-EVM natif dans le protocole que l’EVM, en s’appuyant uniquement sur son propre code pour les mêmes parties de l’EVM et son propre code pour les différentes parties. Cela peut être réalisé en concevant une fonctionnalité ZK-EVM qui permet à l’appelant de spécifier des opcodes, des adresses ou des champs de bits qui sont gérés par une table fournie en externe, plutôt que par l’EVM lui-même. Nous pouvons également rendre les coûts de gaz ouverts à la personnalisation dans une mesure limitée.

Systèmes multi-clients « ouverts » et « fermés »

Le « concept multi-clients » est probablement l’exigence la plus affirmée de cette liste. Il y a la possibilité d’abandonner cette idée et de se concentrer sur une solution ZK-SNARK, ce qui simplifiera la conception, mais au prix d’un « changement philosophique » plus important sur ETH’atelier (car cela constituerait en fait un écart par rapport à la philosophie multiclient à long terme de ETH atelier) et à l’introduction de risques plus importants. À long terme, par exemple, si les techniques de vérification formelle s’améliorent, il serait peut-être préférable de choisir cette voie, mais pour l’instant, les risques semblent trop importants.

Une autre option est un système multiclient fermé où un ensemble fixe de systèmes d’attestation est connu dans le protocole. Par exemple, nous pouvons décider d’utiliser trois ZK-EVM : PSE ZK-EVM, Polygon ZK-EVM et Kakarot. Un bloc doit porter la preuve de deux de ces trois éléments pour être considéré comme valide. C’est mieux qu’un système de preuve unique, mais cela rend le système moins adaptable parce que les utilisateurs doivent maintenir des validateurs pour chaque système de preuve connu, il y a forcément un processus de gouvernance politique pour incorporer de nouveaux systèmes de preuve, et ainsi de suite.

Cela m’a amené à préférer un système ouvert, multi-clients, où les preuves sont placées « à l’extérieur des blocs » et vérifiées séparément par les clients. Les utilisateurs individuels peuvent valider les blocs avec le client qu’ils souhaitent, à condition qu’il y ait au moins un prouveur qui génère la preuve du système. 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 des coûts de complexité plus élevés que nous ne le verrons.

Quelles sont les principales caractéristiques que nous voulons que l’implémentation ZK-EVM ait ?

En plus de la fonctionnalité correcte de base et des garanties de sécurité, la caractéristique la plus importante est la vitesse. Bien qu’il soit possible de concevoir une fonctionnalité ZK-EVM au sein d’un protocole asynchrone qui ne renvoie qu’une seule réponse pour chaque revendication après un délai de N créneaux horaires, le problème que tout ce qui se passe dans chaque bloc est autonome serait plus facile si nous pouvions garantir de manière fiable que les preuves seraient générées en quelques secondes.

Bien qu’il faille aujourd’hui de nombreuses minutes ou heures pour générer des preuves de ETH blocs, nous savons qu’il n’y a aucune raison théorique d’empêcher la parallélisation de masse : nous pouvons toujours combiner suffisamment de GPU pour prouver séparément les différentes parties de l’exécution des blocs, puis utiliser des SNARK récursifs pour assembler ces preuves. De plus, l’accélération matérielle par le biais de FPGA et d’ASIC peut aider à optimiser davantage les preuves. Cependant, en arriver là est un défi d’ingénierie important qui ne doit pas être sous-estimé.

À quoi pourraient ressembler les fonctionnalités ZK-EVM du protocole ?

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

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

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 faites 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 les preuves, et configurer un sous-réseau distinct pour chaque type de preuve (et un sous-réseau supplémentaire pour les objets blob).

En plus de la couche de consensus, nous avons ajouté une règle de validation selon laquelle un bloc ne sera accepté que si le client voit une preuve valide de chaque revendication dans le bloc. La preuve doit être une instruction d’attestation ZK-SNARK, c’est-à-dire que la concaténation de transaction_and_witness_blobs est la sérialisation de la paire (Bloc,Témoin), le bloc d’exécution est valide sur pre_state_root en utilisant Témoin (i), et (ii) affiche le post_state_root correct. Potentiellement, les clients peuvent choisir d’attendre M-of-N pour plusieurs types d’attestation.

Il y a une note philosophique ici que l’exécution du bloc elle-même peut être traitée comme quelque chose qui n’a besoin d’être vérifié qu’avec l’un des triplets (σpre, σpost, Proof) fournis dans l’objet ZKEVMClaimTransaction. 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.

Vérification et ré-attestation

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 ETH l’exécution de blocs en moins de 5 secondes, et 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 individuels ne sont pas formalisés, ils ne peuvent pas être encouragés dans le protocole, cependant, nous prévoyons que le coût de fonctionnement d’un nœud de preuve sera inférieur au coût de recherche et développement, de sorte que nous pouvons simplement financer les nœuds de preuve par le biais d’un organisme commun finançant les biens publics.

Supposons que quelqu’un publie une ZKEvmClaimNetworkTransaction, à moins qu’il ne publie qu’une preuve de la version PSE ZK-EVM. Voyant cela, le nœud Preuve du polygone ZK-EVM calcule et republie l’objet avec la preuve du polygone ZK-EVM.

Cela augmente la latence maximale totale entre le premier nœud honnête acceptant un bloc et le dernier nœud honnête acceptant le même bloc de δ à 2 δ+Tprove (en supposant que Tprove < 5 secondes ici).

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

Extension : Prise en charge de « presque-EVM »

L’un des objectifs souhaitables de la fonctionnalité ZK-EVM est de prendre en charge le « presque-EVM » : les EVM avec quelques fonctionnalités supplémentaires. Cela pourrait inclure une nouvelle précompilation, de nouveaux opcodes, permettant d’écrire des contrats dans des EVM ou des VM complètement différentes (par exemple, 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 des règles EVM modifiées. Cela peut être utilisé pour :

· Tableau personnalisé des coûts de l’essence (les utilisateurs ne sont pas autorisés à réduire les coûts de l’essence, mais peuvent les augmenter)

· Désactiver certains opcodes

· Définissez le numéro de bloc (cela signifie qu’il y aura des règles différentes en fonction du hard fork)

· Définissez un indicateur qui active l’ensemble complet des modifications EVM qui ont été normalisées pour une utilisation L2 au lieu d’une utilisation L1, ou d’autres modifications plus simples

Afin de permettre aux utilisateurs d’ajouter de nouvelles fonctionnalités en introduisant de nouveaux pré-compilés (ou opcodes) d’une manière plus ouverte, nous pouvons ajouter un contenu contenant des transcriptions d’entrées/sorties précompilées à une partie du blob de ZKEVMClaimNetworkTransaction :

L’exécution de l’EVM sera modifiée comme suit. Les entrées du tableau seront initialisées comme vides. Chaque fois que l’adresse de used_precompile_addresses est appelée, nous ajoutons l’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 nombre total de fois et que inputs_commitments correspond au résultat de la sérialisation SSZ des engagements d’objets blob générés vers les entrées. Le but de l’exposition des entrées_commitments est de faciliter les SNARK externes pour prouver 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. Les exécutions EVM ont déjà généré des entrées pour elles, elles n’ont donc qu’à vérifier si les entrées générées correspondent aux entrées déclarées, ce qui ne nécessite qu’une vérification de hachage. Cependant, le résultat doit leur être fourni sous forme complète, il doit donc s’agir de données disponibles.

Une autre fonctionnalité utile pourrait être d’autoriser les « transactions privilégiées », c’est-à-dire les transactions qui lancent des appels à partir de n’importe quel compte d’expéditeur. Ces transactions peuvent s’exécuter entre deux autres transactions, ou lors de l’appel de precompile dans une autre transaction (et éventuellement privilégiée). Cela peut être utilisé pour permettre à des mécanismes non-EVM de rappeler l’EVM.

Cette conception peut être modifiée pour prendre en charge des opcodes nouveaux ou modifiés, en plus de la précompilation nouvelle ou modifiée. Même avec seulement une précompilation, cette conception est très puissante. Par exemple :

· En définissant used_precompile_addresses, en incluant une liste d’adresses de compte normales avec certains indicateurs définis dans leurs objets de compte dans l’état, et en créant un SNARK pour prouver qu’il a été construit correctement, vous pouvez prendre en charge les fonctionnalités de style Arbitrum Stylus où le code du contrat peut être écrit dans EVM ou WASM (ou d’autres machines virtuelles). Les transactions privilégiées peuvent être utilisées pour permettre aux comptes WASM d’être rappelés à l’EVM.

· En ajoutant une vérification externe pour s’assurer que les transcriptions d’entrée/sortie et les transactions privilégiées effectuées par plusieurs EVM sont mises 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.

· Le quatrième type de ZK-EVM peut fonctionner en ayant plusieurs implémentations : une qui convertit Solidity ou d’autres langages de haut niveau directement en machines virtuelles compatibles SNARK, et une autre qui le compile en code EVM et l’exécute dans le ZK-EVM consacré. La deuxième implémentation (inévitablement plus lente) ne s’exécute que si le prouveur d’erreurs envoie une transaction indiquant qu’il y a une erreur, et s’il est en mesure de fournir une transaction qui est gérée différemment par les deux, il peut être récompensé.

· Une machine virtuelle purement asynchrone peut être obtenue en faisant en sorte que tous les appels retournent zéro et en mappant les appels aux transactions privilégiées qui sont ajoutées à la fin du bloc.

Extension : prise en charge des attesteurs avec état

L’un des défis de la conception ci-dessus est qu’elle est complètement sans état, ce qui la rend moins efficace en termes d’utilisation des données. En prenant en charge la compression avec état, les envois ERC 20 peuvent économiser jusqu’à 3 fois plus d’espace que lors de l’utilisation de la compression sans état seule, en utilisant une compression de données idéale.

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 : c’est du gâchis de demander à ce que des données soient disponibles, car on sait déjà que les données sont exploitables parce qu’elles ont été saisies ou produites par une exécution antérieure de l’EVM.

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

1. Exiger que σpre soit vide, ou une liste de données disponibles pour une paire clé-valeur pré-déclarée, ou un σpost précédemment exécuté.

2. Ajoutez l’engagement d’objet blob d’un reçu généré par bloc R au tuple (σpre,σpost, Proof). Toutes les promesses d’objets blob précédemment générées ou utilisées, y compris celles représentant des blocs, des témoins, des reçus ou même des transactions d’objets blob EIP-4844 régulières, qui peuvent avoir une limite de temps, peuvent être référencées dans ZKEVMClaimTransaction et accessibles pendant son exécution (éventuellement via une série d’instructions : « Insérer l’octet N de l’engagement i à la position j du bloc + données témoins… N+k− 1 」)。

(1) En gros, au lieu de solidifier la vérification EVM sans état, nous allons solidifier les chaînes enfants EVM. (2) Essentiellement la création d’un algorithme de compression avec état minimal intégré qui utilise un objet blob précédemment utilisé ou généré comme dictionnaire. Ces deux éléments ajoutent la charge de stocker plus d’informations au nœud de preuve, qui n’est que le nœud de preuve, et dans le cas (2), il est plus facile de limiter cette charge à un certain temps que dans le cas (1).

Le débat entre les systèmes multi-preuves fermés et les données off-chain

Un système multi-étalon fermé permet d’éviter bon nombre des complexités ci-dessus en fixant un certain nombre de preuves dans une structure M-of-N. En particulier, les systèmes multi-étalons fermés n’ont 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 plasma EVM.

Cependant, les systèmes multi-étalons fermés augmentent la complexité de la gouvernance et réduisent l’auditabilité, ce qui constitue un compromis entre le coût élevé et ces avantages.

Si nous établissons ZK-EVM en tant que fonctionnalité de protocole, quel sera le rôle continu du « projet L2 » ?

Le protocole gérera les fonctionnalités de vérification EVM que les équipes L2 implémentent actuellement elles-mêmes, mais le projet L2 sera toujours responsable d’un certain nombre de fonctionnalités importantes :

Pré-confirmation rapide : la finalité d’un seul emplacement peut ralentir les emplacements L1, et les projets L2 fournissent déjà à leurs utilisateurs une « pré-confirmation » soutenue par la propre sécurité de L2, avec une latence beaucoup plus faible qu’un seul emplacement. Ce service continuera d’être un passif L2 pur.

Stratégies d’atténuation des MEV : il peut s’agir de mempools chiffrés, d’une sélection séquentielle basée sur la réputation et d’autres fonctionnalités que les L1 sont réticents à mettre en œuvre.

Extensions de l’EVM : Les projets L2 peuvent intégrer des extensions substantielles de l’EVM afin d’apporter une valeur significative à leurs utilisateurs. Cela inclut à la fois des « presque-EVM » et des approches fondamentalement différentes comme la prise en charge WASM d’Arbitrum Stylus et le langage convivial Cairo de SNARK.

Commodité pour les utilisateurs et les développeurs : les équipes L2 font beaucoup de travail pour attirer les utilisateurs et les projets dans leur écosystème et les faire se sentir les bienvenus, et elles sont rémunérées par l’acquisition de MEV et de frais de congestion au sein de leur réseau. Cette relation est là pour rester.

Lien vers l’article original