Auteur : Vitalik

Traduction : Block unicorn, Foresight News

Récemment, de nombreux projets « ZK-EVM » ont fait des annonces médiatisées. Polygon a ouvert son projet ZK-EVM, ZKSync a publié son plan ZKSync 2.0, et le projet relativement nouveau Scroll a récemment lancé sa propre version de ZK-EVM. Il existe également des efforts continus d'équipes comme Privacy and Scaling Explorations, ainsi que celle de Nicolas Liochon, pour développer un compilateur alpha allant du langage EVM à Cairo, un langage zk-amical développé par Starkware. Bien sûr, il y a certains projets que j'oublierai.

L’objectif central de tous ces projets est identique : utiliser la technologie ZK-SNARK pour produire des preuves cryptographiques de l’exécution de transactions semblables à celles d’Ethereum, soit afin de faciliter la vérification de la chaîne Ethereum elle-même, soit afin de construire des rollups zk qui offrent une fonctionnalité proche de celle d’Ethereum mais avec une meilleure extensibilité. Toutefois, il existe des différences subtiles entre ces projets, ainsi que des compromis entre praticité et rapidité. Cet article tentera de décrire une classification des différents « types » d’équivalence EVM, ainsi que les avantages et coûts associés à chaque tentative de mise en œuvre.

Aperçu (sous forme de tableau)

Type 1 (équivalence complète avec Ethereum)

Les ZK-EVM de type 1 visent une équivalence totale et sans concession avec Ethereum. Ils ne modifient aucune partie du système Ethereum afin de faciliter la génération de preuves. Ils ne remplacent ni les hachages, ni les arbres d'état, ni les arbres de transactions, ni les précompilations, ni aucune autre logique de consensus, même si elle semble périphérique.

Avantage : compatibilité parfaite

L'objectif est de pouvoir vérifier les blocs Ethereum exactement comme aujourd'hui, ou du moins la couche d'exécution (ainsi, la logique de consensus de la Beacon Chain n'est pas incluse, mais toutes les exécutions de transactions, la logique des contrats intelligents et des comptes le sont).

Le ZK-EVM de type 1 est ce dont nous avons besoin à long terme pour rendre la couche 1 d'Ethereum elle-même plus évolutive. À long terme, les modifications testées dans des ZK-EVM de type 2 ou de type 3 pourraient être intégrées à Ethereum lui-même, mais une telle refonte s'accompagne de sa propre complexité.

Le ZK-EVM de type 1 est aussi idéal pour les rollups car il permet de réutiliser une grande quantité d'infrastructures existantes. Par exemple, les clients d'exécution Ethereum peuvent être utilisés tels quels pour générer et traiter les blocs de rollup (ou du moins, une fois que les retraits seront implémentés, ils pourront être réutilisés, et cette fonctionnalité peut servir à prendre en charge les dépôts vers le rollup). Ainsi, les outils comme les explorateurs de blocs ou les outils de production de blocs peuvent facilement être réutilisés.

Inconvénient : temps de vérification élevé

Ethereum n’a pas été initialement conçu pour être compatible avec les zk, donc de nombreuses parties du protocole Ethereum nécessitent des calculs intensifs pour être vérifiées via zk. Le but du type 1 étant de copier fidèlement Ethereum, il ne peut atténuer ces inefficacités. Actuellement, la génération d'une preuve pour un bloc Ethereum prend plusieurs heures. Ce problème pourrait être atténué grâce à une ingénierie habile permettant une parallélisation massive du vérificateur, ou à long terme, grâce à des circuits intégrés spécialisés (ASIC) pour les ZK-SNARK.

Qui les construit ?

L’équipe Privacy and Scaling Explorations travaille sur un ZK-EVM de type 1.

Type 2 (équivalence complète avec la machine virtuelle EVM)

Les ZK-EVM de type 2 cherchent à être entièrement équivalents à l'EVM, mais pas totalement à Ethereum. Cela signifie qu'ils ressemblent parfaitement à Ethereum « de l'intérieur », mais présentent quelques différences externes, notamment au niveau des structures de données comme la structure des blocs ou des arbres d’état.

L'objectif est d'être entièrement compatible avec les applications existantes, tout en apportant de légères modifications à Ethereum afin de faciliter le développement et d'accélérer la génération des preuves.

Avantage : équivalence complète au niveau de la machine virtuelle

Les ZK-EVM de type 2 modifient les structures de données qui stockent l'état Ethereum. Heureusement, ces structures ne sont pas directement accessibles par l'EVM elle-même, donc les applications fonctionnant sur Ethereum fonctionnent presque toujours sur un rollup ZK-EVM de type 2. Vous ne pouvez pas utiliser tels quels les clients d'exécution Ethereum, mais vous pouvez les utiliser avec quelques modifications, et vous pouvez encore utiliser les outils de débogage EVM et la plupart des autres infrastructures de développement.

Il existe toutefois quelques exceptions. Une incompatibilité apparaît pour les applications qui valident des preuves de Merkle sur des anciens blocs Ethereum afin de confirmer des affirmations concernant des transactions passées, des justificatifs ou l’état (par exemple, certaines passerelles font cela). Un ZK-EVM remplaçant Keccak par une autre fonction de hachage invaliderait ces preuves. Toutefois, je recommande généralement de ne pas construire des applications de cette manière, car des modifications futures d’Ethereum (comme les arbres de Verkle) casseraient déjà ce genre d’applications même sur Ethereum lui-même. Une meilleure alternative serait d’ajouter à Ethereum même une précompilation fiable pour l’accès à l’historique.

Inconvénient : amélioration du temps de vérification, mais toujours lent

Les ZK-EVM de type 2 offrent un temps de vérification plus rapide que ceux de type 1, principalement en supprimant des composants de la pile Ethereum qui reposent sur des éléments cryptographiques complexes et peu adaptés aux zk. En particulier, ils pourraient modifier Keccak d’Ethereum et ses arbres de Merkle-Patricia basés sur RLP, voire aussi les structures des blocs et des justificatifs. Les ZK-EVM de type 2 pourraient utiliser une fonction de hachage différente, comme Poseidon. Une autre modification naturelle serait de modifier l’arbre d’état pour stocker les hachages de code et de keccak, évitant ainsi de devoir vérifier les hachages lors de l’utilisation des opcodes EXTCODEHASH et EXTCODECOPY.

Ces modifications améliorent significativement le temps de vérification, mais ne résolvent pas tous les problèmes. En raison des inefficacités inhérentes à l’EVM et de son manque d’amitié avec les zk, prouver l’exécution fidèle de l’EVM reste lent. Un exemple simple est la mémoire : puisque MLOAD peut lire n’importe quel bloc de 32 octets, y compris des blocs « non alignés » (dont le début et la fin ne sont pas des multiples de 32), MLOAD ne peut pas simplement être interprété comme la lecture d’un seul bloc ; au contraire, il peut devoir lire deux blocs consécutifs et effectuer des opérations bit à bit pour fusionner les résultats.

Qui les construit ?

Le projet ZK-EVM de Scroll avance vers un ZK-EVM de type 2, tout comme Polygon Hermez. Cependant, aucun des deux projets n’est encore terminé (aucun n’a achevé le travail sur ZK-EVM) ; en particulier, de nombreuses précompilations complexes ne sont pas encore implémentées. Pour l’instant, les deux projets doivent plutôt être considérés comme de type 3.

Type 2.5 (équivalent à l’EVM, sauf les frais de gaz)

Une façon d’améliorer significativement le temps de vérification dans le pire cas consiste à augmenter fortement le coût en gaz des opérations spécifiques difficiles à prouver dans l’EVM. Cela pourrait concerner les précompilations, les opcodes KECCAK, ou encore les conventions d’appel ou certains schémas d’accès à la mémoire, au stockage ou aux retours.

La modification des coûts en gaz peut réduire la compatibilité avec les outils de développement et casser certaines applications, mais on considère généralement que c’est moins risqué que des changements « plus profonds » dans l’EVM. Les développeurs devraient veiller à ne pas dépasser la capacité du bloc en gaz requis par une transaction, ni utiliser des montants de gaz codés en dur dans les appels (ce qui est déjà un conseil standard depuis longtemps).

Type 3 (presque équivalent à l’EVM)

Les ZK-EVM de type 3 sont presque équivalents à l’EVM, mais acceptent quelques sacrifices pour accélérer davantage le temps de vérification et simplifier la conception de l’EVM.

Avantages : plus facile à construire, temps de vérification plus rapide

Les ZK-EVM de type 3 pourraient supprimer certaines fonctionnalités particulièrement difficiles à implémenter dans un ZK-EVM. Ici, les précompilations sont souvent en tête de liste ; de plus, les ZK-EVM de type 3 peuvent avoir de légères différences dans la gestion du code du contrat, de la mémoire ou de la pile.

Inconvénients : plus d’incompatibilités

L’objectif des ZK-EVM de type 3 est d’être compatibles avec la majorité des applications, les autres nécessitant seulement des réécritures minimales. Toutefois, certaines applications devront être réécrites, soit parce qu’elles utilisent des précompilations supprimées par le ZK-EVM de type 3, soit parce qu’elles dépendent subtilement de cas limites traités différemment par l’EVM.

Qui les construit ?

Scroll et Polygon sont actuellement des ZK-EVM de type 3, bien qu’ils espèrent améliorer leur compatibilité avec le temps. Polygon a un design unique où il valide via zk son propre langage interne zkASM, et utilise zkASM pour interpréter le code ZK-EVM. Malgré ce détail d’implémentation, je continue de le considérer comme un véritable ZK-EVM de type 3 ; il valide toujours du code EVM, simplement en utilisant une logique interne différente.

Aujourd’hui, aucune équipe ZK-EVM ne souhaite rester en type 3 ; le type 3 n’est qu’une étape transitoire jusqu’à ce que le travail complexe d’ajout des précompilations soit terminé, permettant aux projets de passer au type 2.5. Cependant, à l’avenir, un ZK-EVM de type 1 ou de type 2 pourrait volontairement devenir un ZK-EVM de type 3 en ajoutant de nouvelles précompilations amies des ZK-SNARK, offrant aux développeurs des fonctionnalités à faible coût de vérification et de gaz.

Type 4 (équivalent à un langage de haut niveau)

Les systèmes de type 4 fonctionnent en prenant le code source des contrats intelligents écrits dans un langage de haut niveau (par exemple Solidity, Vyper ou un langage intermédiaire compilé par les deux), puis en le compilant vers un langage explicitement conçu pour être compatible avec les ZK-SNARK.

Avantage : temps de vérification très rapide

En évitant de devoir prouver via zk chaque étape d’exécution de l’EVM, et en démarrant directement à partir d’un code de plus haut niveau, on évite beaucoup de surcoût.

Je ne décris cet avantage qu’en une phrase dans cet article (face à la longue liste de points négatifs liés à la compatibilité ci-dessous), mais cela ne doit pas être interprété comme un jugement de valeur ! Compiler directement depuis un langage de haut niveau permet vraiment de réduire fortement les coûts, et aide à la décentralisation en rendant plus facile d’être un fournisseur de preuves.

Inconvénient : plus d’incompatibilités

Une application « normale » écrite en Vyper ou Solidity peut être compilée et « fonctionner normalement », mais il existe plusieurs aspects importants où beaucoup d'applications ne fonctionnent pas correctement :

• L’adresse des contrats dans un système de type 4 peut différer de celle dans l’EVM, car l’adresse des contrats via CREATE2 dépend exactement du bytecode. Cela casse les applications qui dépendent de « contrats contre-factuels » non encore déployés, de portefeuilles ERC-4337, de singletons EIP-2470 et de nombreuses autres applications.
• L'utilisation de bytecode EVM écrit à la main devient plus difficile. Pour gagner en efficacité, de nombreuses applications utilisent du bytecode EVM écrit manuellement dans certaines parties. Les systèmes de type 4 pourraient ne pas le supporter, bien qu’il existe des méthodes permettant d’offrir un support limité au bytecode EVM pour ces cas d’usage, sans pour autant devenir un ZK-EVM complet de type 3.
• Beaucoup d’infrastructures de débogage ne peuvent plus fonctionner, car elles s’appuient sur le bytecode EVM. Toutefois, cet inconvénient peut être atténué en accédant davantage aux outils de débogage depuis des langages traditionnels de haut niveau ou intermédiaires (par exemple LLVM).

Les développeurs doivent être conscients de ces problèmes.

Qui les construit ?

ZKSync est un système de type 4, bien qu’il puisse progressivement ajouter une compatibilité avec le bytecode EVM. Le projet Warp de NetherMind construit un compilateur de Solidity vers Cairo, le langage de Starkware, transformant ainsi StarkNet en un système de facto de type 4.

L’avenir des différents types de ZK-EVM

Ces types ne sont pas clairement « meilleurs » ou « pires » les uns que les autres. Au contraire, ils représentent différents points dans un espace de compromis : les types plus faciles à coder sont plus compatibles avec les infrastructures existantes, mais plus lents ; les types plus difficiles à coder sont moins compatibles, mais plus rapides. Globalement, explorer tous ces types est sain pour le domaine.

• Un ZK-EVM peut commencer en type 3, en décidant d’exclure certaines fonctionnalités particulièrement difficiles à prouver via zk. Plus tard, il peut progressivement ajouter ces fonctionnalités et passer au type 2.
• Un ZK-EVM peut commencer en type 2, puis devenir un hybride type 2/type 1 en offrant la possibilité de fonctionner en mode entièrement compatible avec Ethereum ou d’utiliser un arbre d’état modifié plus rapide à prouver. Scroll envisage précisément cette direction.
• Un système démarrant en type 4 pourrait devenir un type 3 au fil du temps, en ajoutant la capacité de traiter le code EVM (bien que les développeurs soient toujours encouragés à compiler directement depuis un langage de haut niveau pour réduire les frais et le temps de vérification).
• Si Ethereum lui-même adopte des modifications pour devenir plus compatible avec les zk, alors un ZK-EVM de type 2 ou 3 pourrait devenir un ZK-EVM de type 1.
• Un ZK-EVM de type 1 ou 2 pourrait devenir un ZK-EVM de type 3 en ajoutant des précompilations capables de valider du code écrit dans un langage ami des ZK-SNARK. Cela permettrait aux développeurs de choisir entre compatibilité Ethereum et rapidité, ce qui constituerait un type 3 (car cela brise l’équivalence parfaite avec l’EVM), mais aurait de nombreux avantages pratiques des types 1 et 2. Le principal inconvénient serait que certains outils de développement ne comprennent pas les précompilations personnalisées du ZK-EVM, bien que cela puisse être corrigé : les outils pourraient ajouter un support généralisé pour les précompilations en permettant des formats de configuration incluant des implémentations équivalentes en code EVM.

Personnellement, j’espère qu’avec le temps, tout deviendra du type 1, grâce à l’amélioration des ZK-EVM et à celle d’Ethereum lui-même pour mieux s’adapter aux ZK-SNARK. Dans un tel futur, nous aurons plusieurs implémentations de ZK-EVM, utilisées à la fois pour les rollups zk et pour vérifier Ethereum lui-même. En théorie, Ethereum n’aurait pas besoin de normaliser une seule implémentation de ZK-EVM pour la couche 1 ; différents clients pourraient utiliser différentes preuves, et nous continuerions ainsi à bénéficier de la redondance du code.

Toutefois, cela prendra encore un certain temps. D’ici là, nous assisterons à de nombreuses innovations sur les différentes voies d’extension d’Ethereum et des rollups zk basés sur Ethereum.