Vitalik : Discutez des différents types de versions « ZK-EVM intégrées » et des défis de conception

Texte : Vitalik Buterin

Compilation : 1912212.eth, Foresight News

Les protocoles EVM de couche 2 en plus de ETH, y compris les cumuls optimistes et les cumuls ZK, reposent sur la validation EVM. Cependant, cela les oblige à faire confiance à une énorme base de code, et s’il y a des bogues dans cette base de code, ces machines virtuelles risquent d’être piratées. De plus, cela signifie que même les ZK-EVM, qui veulent être entièrement équivalents à l’EVM L1, ont besoin d’une certaine forme de gouvernance pour reproduire les modifications apportées à l’EVM L1 dans leurs propres pratiques EVM.

Cette situation n’est pas idéale, car ces projets reproduisent des fonctionnalités qui existent déjà dans le protocole ETH Workshop, et ETH Governance est déjà responsable de la mise à niveau et de la correction des bogues : ZK-EVM est essentiellement le même travail que la validation des blocs de la couche 1 ETH de l’atelier !De plus, dans les années à venir, nous nous attendons à ce que les clients légers deviennent de plus en plus puissants, et atteignent bientôt le point où les ZK-SNARK sont utilisés pour valider pleinement l’exécution de l’EVM de couche 1. À ce moment-là, le réseau ETH construira efficacement le ZK-EVM intégré. La question se pose donc : pourquoi ne pas faire en sorte que le ZK-EVM lui-même soit également adapté aux rollups ?

Dans cet article, nous examinerons quelques-unes des versions « ZK-EVM intégrées » qui peuvent être mises en œuvre, et discuterons des compromis et des défis de conception, ainsi que des raisons pour lesquelles nous n’allons pas dans une direction particulière. Les avantages de la mise en œuvre des fonctionnalités du protocole doivent être mis en balance avec les avantages de laisser les choses à l’écosystème et de garder le protocole sous-jacent simple.

Quelles sont les principales caractéristiques que nous attendons du ZK-EVM intégré ?

• Fonction de base : Valider ETH blocs. La fonction de protocole (qui n’est pas encore claire s’il s’agit d’un opcode, d’une précompilation ou d’un autre mécanisme) doit accepter au moins une racine pré-étatique, un bloc et une racine post-état en entrée, et vérifier que la racine post-état est bien le résultat de l’exécution du bloc.
• Compatible avec plusieurs clients de ETH Square. Cela signifie que nous voulons éviter un seul système d’attestation et permettre à différents clients d’utiliser différents systèmes d’attestation. Cela conduit aux points suivants :
• Exigences en matière de disponibilité des données : pour toute exécution d’EVM qui utilise le ZK-EVM intégré pour les épreuves, nous voulons garantir la disponibilité des données sous-jacentes afin que les prouveurs utilisant un système d’attestation différent puissent ré-attester l’exécution et permettre aux clients qui s’appuient sur ce système d’attestation de valider les preuves nouvellement générées.
• Des preuves existent en dehors de l’EVM et des structures de données de bloc : la fonctionnalité ZK-EVM intégrée ne prend pas les SNARK en entrée dans l’EVM, car différents clients s’attendront à 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 attestées, dont le contenu peut être consulté par un opcode ou un précompilateur, et les règles de consensus côté client vérifieront la disponibilité des données et la preuve d’existence pour chaque revendication séparément. *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 examiner. En fait, cela ajoute une autre raison pour laquelle les exigences en matière de disponibilité des données sont si importantes.
• Évolutivité. S’il s’avère qu’une solution ZK-EVM présente un bogue, nous voulons être en mesure de le corriger rapidement. Cela signifie qu’il n’y a pas besoin d’un hard fork à réparer. Cela explique pourquoi les preuves existent en dehors de l’EVM et des structures de données de blocs.
• Prend en charge presque tous les EVM. L’un des attraits de la L2 est d’innover au niveau de la couche d’exécution et de faire évoluer l’EVM. Si la machine virtuelle d’un L2 donné n’est qu’un peu différente de l’EVM, alors ce serait bien si L2 pouvait toujours utiliser le ZK-EVM dans le protocole natif dans les mêmes parties que l’EVM, et ne s’appuyer que sur son propre code dans différentes parties. Cela peut être réalisé en concevant une fonction ZK-EVM qui permet à l’appelant de spécifier des champs de bits ou des listes d’opcodes ou des adresses qui sont gérées par des tables fournies en externe plutôt que par l’EVM lui-même. Nous pouvons également faire en sorte que le coût de l’essence soit ouvert à l’édition dans une certaine mesure.

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

La « philosophie multi-clients » est probablement l’exigence la plus subjective de cette liste. Il est possible de l’abandonner et de se concentrer sur le schéma ZK-SNARK, qui simplifiera la conception, mais au prix d’un « tournant philosophique » plus important pour ETH’atelier (puisqu’il abandonne effectivement la philosophie multiclient de longue date de ETH atelier) et introduit de plus grands risques. À l’avenir, lorsque la technologie de vérification formelle s’améliorera, il sera peut-être préférable de choisir cette voie, mais il semble maintenant que le risque soit trop grand.

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 blocage nécessite une preuve fournie par 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 parce que les utilisateurs doivent maintenir des validateurs pour chaque système de preuve existant, et il y aura inévitablement des processus de gouvernance politique pour incorporer de nouveaux systèmes de preuve, etc.

Cela me motive à préférer un système multiclient ouvert, où les preuves sont placées « à l’extérieur du bloc » et vérifiées par le client individuellement. Les utilisateurs individuels peuvent utiliser n’importe quel client qu’ils souhaitent pour valider les blocs, à condition qu’au moins un prouveur crée 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 de complexité plus élevé, comme nous le verrons.

Quelles sont les principales propriétés que nous voulons tirer de l’implémentation 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 que nous puissions concevoir la fonctionnalité ZK-EVM dans le protocole, qui est asynchrone et ne renvoie chaque réponse déclarée qu’après un délai de 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, peu importe ce qui se passe dans chaque bloc est autonome.

Bien qu’il faille aujourd’hui de nombreuses minutes ou heures pour générer des preuves pour 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 parties individuelles de l’exécution d’un bloc, puis assembler les preuves à l’aide de SNARK récursifs. 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 énorme défi d’ingénierie qui ne doit pas être sous-estimé.

À quoi pourrait ressembler la fonctionnalité ZK-EVM dans le protocole ?

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

Il est important de noter qu’en pratique, nous pouvons fractionner le chargement indépendant en deux chargements indépendants 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).

Au niveau de la couche de consensus, nous avons ajouté une règle de validation qui n’accepte un bloc que si le client voit une preuve valide de chaque revendication dans le bloc. La preuve doit être un ZK-SNARK, prouver que la concaténation de transaction_and_witness_blobs est la sérialisation de la paire (Bloc, Témoin) et que le bloc est exécuté avec pre_state_root sur le Témoin

(i) est valide,

(ii) Affichez le bon post_state_root. Éventuellement, le client peut choisir d’attendre plusieurs types de preuves de M-of-N.

Il est important de noter ici que l’exécution du bloc elle-même peut simplement être considérée comme l’un des triplets qui doivent être vérifiés avec les triplets fournis dans l’objet ZKEVMClaimTransaction (σpre, σpost, Proof). Par conséquent, l’implémentation ZK-EVM de l’utilisateur peut remplacer son client d’exécution ; le client d’exécution sera toujours exécuté

(i) les prouveurs et les constructeurs de blocs et :

et (ii) les nœuds qui s’occupent de l’indexation et du stockage des données pour une utilisation locale.

De plus, étant donné que cette architecture sépare l’exécution de la validation, elle peut offrir plus de flexibilité et d’efficacité pour différents rôles dans l’écosystème ETH. Par exemple, un prouveur peut se concentrer sur la génération de preuves sans se soucier des spécificités de l’exécution, tandis que les clients d’exécution peuvent être optimisés pour répondre aux besoins d’utilisateurs spécifiques, tels que la synchronisation rapide ou les capacités d’indexation avancées.

Vérification et ré-attestation

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

Malheureusement, étant donné que les systèmes individuels de preuve de la boîte ne sont pas formalisés, ils ne peuvent pas être encouragés dans le protocole, cependant, nous prévoyons que le coût d’exécution des preuves sera inférieur à celui de la recherche et du développement, de sorte que nous pouvons facilement financer les prouveurs par le biais d’institutions financées pour les biens publics.

Supposons que quelqu’un publie une ZKEvmClaimNetworkTransaction, mais qu’il ne publie qu’une preuve de la version PSE ZK-EVM. Le noeud de preuve du polygone ZK-EVM le voit, calcule et republie l’objet, ainsi que la preuve du polygone ZK-EVM.

Cela augmentera le délai maximum total 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<5s ici).

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

Extension : Prise en charge des « presque-EVM »

L’objectif souhaitable de la fonctionnalité ZK-EVM est de prendre en charge les « presque-EVM », c’est-à-dire les EVM avec des fonctionnalités supplémentaires. Il peut s’agir d’une nouvelle précompilation, de nouveaux opcodes, de contrats qui peuvent être EVM ou des VM complètement différentes (par exemple dans Arbitrum Stylus), ou même de 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 être utilisé dans les situations suivantes :

1. Tableau personnalisé des coûts du gaz (les utilisateurs ne sont pas autorisés à réduire les coûts du gaz, mais ils peuvent les augmenter)
2. Désactiver certains opcodes
3. Définissez le numéro de bloc (cela signifie qu’il existe des règles différentes en fonction du hard fork)
4. Définissez l’indicateur pour activer l’ensemble complet des modifications EVM qui sont déjà normalisées pour L2 mais pas pour l’utilisation L1, ou d’autres modifications plus simples

Afin de permettre aux utilisateurs d’ajouter de nouvelles fonctionnalités d’une manière plus ouverte, par exemple en introduisant un nouveau précompilé (ou opcode), nous pouvons ajouter un moyen d’inclure les enregistrements d’entrée/sortie précompilés dans la section blob de ZKEVMClaimNetworkTransaction :

class PrecompileInputOutputTran(Container) :used_precompile_addresses : Liste[Address][VersionedHash]inputs_commitments : Liste[Bytes]outputs : Liste

L’exécution de l’EVM sera modifiée comme suit. Un tableau appelé inputs sera initialisé comme 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 l’objet RETURNDATA 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 de l’engagement de l’objet blob résultant dans la sérialisation SSZ des entrées. Le but de l’exposition des entrées_commitments est de permettre au SNARK externe de prouver la relation entre les entrées et les sorties.

Notez l’asymétrie entre les entrées et les sorties, où les entrées sont stockées dans des hachages et les sorties sont stockées dans des 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 l’entrée générée correspond à l’entrée déclarée, ce qui ne nécessite qu’une vérification de hachage. Cependant, la sortie doit leur être entièrement fournie, de sorte que la disponibilité des données doit être disponible.

Une autre fonctionnalité utile pourrait être d’autoriser l’appel de « transactions privilégiées » à partir de n’importe quel compte d’expéditeur. Ces transactions peuvent être exécutées entre deux autres transactions, ou au sein d’une autre transaction (et éventuellement privilégiée), lors de l’appel de la précompilation. Cela peut être utilisé pour permettre à des mécanismes non-EVM de rappeler l’EVM.

La 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, le design est très puissant. Par exemple :

Des fonctionnalités telles qu’Arbitrum Stylus peuvent être prises en charge en définissant used_precompile_addresses pour inclure une liste d’adresses de compte standard avec un certain indicateur défini dans leur objet de compte dans l’état, et en générant des SNARK qui prouvent qu’ils sont construits correctement, où un contrat peut écrire son code dans un EVM ou un WASM (ou une autre machine virtuelle). Les transactions privilégiées peuvent être utilisées pour permettre aux comptes WASM de rappeler 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 la bonne manière, il est possible de démontrer qu’un système parallèle de plusieurs EVM communiquant entre eux via un canal de synchronisation peut être démontré.

Un ZK-EVM de type 4 peut fonctionner en ayant plusieurs implémentations : l’une qui convertit Solidity ou un autre langage de niveau supérieur directement en une machine virtuelle compatible avec SNARK, et l’autre qui le compile en code EVM et l’exécute dans le ZK-EVM prescrit. La deuxième implémentation (et inévitablement plus lente) ne peut s’exécuter que si le prouveur d’échec envoie une transaction prétendant avoir une erreur, et s’il est en mesure d’offrir que les deux gèrent des transactions différentes, la prime peut être collectée.

Vous pouvez implémenter une machine virtuelle asynchrone pure en renvoyant zéro à tous les appels et en mappant les appels aux transactions privilégiées qui sont ajoutées à la fin du bloc.

Extension : Prise en charge de la preuve d’état

Le défi avec la conception ci-dessus est qu’elle est complètement sans état, ce qui la rend médiocre en termes d’efficacité des données. Avec une compression idéale des données, la compression avec état peut rendre les envois ERC20 jusqu’à 3 fois plus économes en espace par rapport à la compression sans état seule.

De plus, les EVM avec état ne sont pas tenus de fournir des 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 alors que l’on sait déjà que les données sont disponibles parce qu’elles ont été saisies ou produites par une exécution antérieure de l’EVM. **

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

Nécessite que σpre soit null, soit une liste pré-déclarée de clés et de valeurs pour lesquelles des données sont disponibles, soit une σpost précédemment exécutée.

Ajoutez un engagement d’objet blob au tuple (σpre, σpost, proof) pour la réception R générée par le bloc. Tous les engagements d’objets blob précédemment générés ou utilisés qui peuvent être référencés dans ZKEVMClaimTransaction et accessibles pendant leur exécution, y compris les engagements représentant des blocs, des témoins, des reçus ou même des transactions d’objets blob EIP-4844 ordinaires (il peut y avoir des limites de temps, qui peuvent être référencées par 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) Le sens de base est le suivant : au lieu d’établir une vérification EVM sans état, nous établirons une chaîne enfant EVM.

et (2) 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. Dans les deux cas, il s’agit d’une charge pour le nœud de prouveur, et seul le nœud de prouveur peut stocker plus d’informations.

Dans le cas (2), il est plus facile de limiter cette charge dans le temps, tandis que dans le cas (1), c’est plus difficile.

Arguments en faveur des systèmes multi-étalons fermés et des données hors chaîne

Un système multi-étalon fermé, dans lequel il y a un nombre fixe de preuves dans la structure M-of-N, évite une grande partie de la complexité décrite ci-dessus. En particulier, un système multi-attester fermé n’a pas à se soucier de s’assurer que les données existent 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-attesteurs fermés augmentent la complexité de la gouvernance et affaiblissent l’auditabilité, ce qui représente un coût élevé qui doit être mis en balance avec ces avantages.

Si nous intégrons ZK-EVM et en faisons une fonctionnalité de protocole, quel est le rôle continu du projet L2 ?

Les fonctions de validation EVM qui sont actuellement implémentées par l’équipe L2 elle-même seront gérées par le protocole, mais le projet L2 sera toujours responsable d’un certain nombre de fonctions importantes :

• Pré-confirmation rapide : la finalité d’un seul emplacement peut ralentir les emplacements L1, alors que L2 fournit déjà aux utilisateurs un service de pré-confirmation avec sa propre sécurité, avec une latence bien inférieure à un emplacement. Ce service continuera d’être sous la seule responsabilité de L2.
• Stratégies d’atténuation MEV : Cela peut inclure des fonctionnalités telles que les mempools cryptés, la sélection séquentielle basée sur la réputation, etc., que L1 est réticent à mettre en œuvre.
• Extensions de l’EVM : Les projets de niveau 2 peuvent introduire des extensions significatives de l’EVM qui apportent une valeur significative à leurs utilisateurs. Cela inclut des « presque-EVM » et des approches complètement différentes, telles que la prise en charge WASM d’Arbitrum Stylus et la langue conviviale du Caire de SNARK.
• Commodité pour les utilisateurs et les développeurs : les équipes de niveau 2 déploient beaucoup d’efforts pour attirer les utilisateurs et les projets dans leur écosystème et leur faire sentir qu’ils sont les bienvenus ; ils sont payés en capturant les frais de MEV et de congestion au sein de leur réseau. Cette relation est là pour rester.