Le réseau principal de zkSync 2.0 bientôt en ligne, analyse des différents types de zkEVM
TechFlow SélectionTechFlow Sélection
Le réseau principal de zkSync 2.0 bientôt en ligne, analyse des différents types de zkEVM
En ce qui concerne le choix de la voie technologique pour les Rollups, le ZK Rollup est considéré comme l'objectif final du scaling d'Ethereum.
Dédié à des analyses Web3 approfondiesL'évolution d'Ethereum s'oriente de plus en plus vers la blockchain modulaire (Modular Blockchain), combinant le partage des données (data sharding) au niveau de la couche 1 (Layer 1) et l'extension via les Rollups au niveau de la couche 2 (Layer 2), formant ainsi une architecture modulaire qui permettrait à Ethereum de réaliser son objectif initial d’« ordinateur mondial ».
En ce qui concerne les choix technologiques pour les Rollups, le ZK Rollup est considéré comme l'objectif final de l'extension d'Ethereum.
ZK Rollup
Le mécanisme central du ZK Rollup consiste à compresser et stocker sur la chaîne l'état des utilisateurs dans un arbre de Merkle, tout en transférant hors chaîne les modifications de cet état, garantissant par ailleurs la validité de ces opérations hors chaîne grâce à des preuves zksnark ou zkstark. De manière simplifiée, on peut comprendre le ZK Rollup comme une méthode permettant de vérifier un nombre linéaire d'instructions avec un traitement sous-linéaire, grâce aux technologies zksnark ou zkstark. Par exemple, 1 000 instructions nécessitent 10 vérifications, tandis que 10 000 instructions n'en nécessitent que 11. Ce résultat se traduit par une capacité d'extension effective d'Ethereum offerte par le ZK Rollup.
Le processus général de traitement des transactions par un ZK Rollup est le suivant :
-
Les utilisateurs verrouillent leurs actifs dans un contrat intelligent ZK Rollup déployé sur la L1 ;
-
Les utilisateurs soumettent leurs transactions relatives à ces actifs à la L2. Un rôle spécifique sur la L2 (le Séquenceur, souvent centralisé dans les premiers projets, bien que certains optent désormais pour une approche décentralisée) regroupe ces transactions selon certaines règles en lots ordonnés, puis génère pour chaque lot une preuve de validité (zksnark/zkstark) ainsi qu'une mise à jour agrégée de l'état ;
-
Cette mise à jour d'état et sa preuve sont envoyées au contrat intelligent ZK Rollup sur la L1 et y sont vérifiées, entraînant alors la mise à jour correspondante sur la blockchain L1 ;
-
Les utilisateurs peuvent utiliser cet état L1 (selon divers mécanismes de disponibilité des données) pour récupérer leurs actifs, assurant ainsi une gestion complète en autonomie (self-custody). C’est pourquoi le ZK Rollup est considéré comme héritant de la sécurité d’Ethereum.
La nécessité du zkEVM
Comme on le sait, les premières générations de ZK Rollups ne supportaient pas l'EVM, offrant une programmabilité et une composable faibles, limitées à certains cas d'usage spécifiques : Loopring était restreint aux paiements et swaps ; Immutable, à la création, échange et jeux autour des NFT ; zksync 1.0 ne supportait pas non plus le zkEVM. Elles manquaient donc de caractère universel.
Par la suite, les principaux projets ZK Rollup ont commencé à explorer la possibilité d’exécuter des codes compatibles avec les octets (bytecode) de l’EVM au sein du ZK Rollup, permettant ainsi aux contrats intelligents existants sur Ethereum d’être migrés vers le ZK Rollup sans avoir besoin d’être réécrits depuis zéro.
L’EVM, première machine virtuelle blockchain Turing-complète, a été lancée en 2015. Elle reste à ce jour la machine virtuelle blockchain la plus éprouvée et constitue une infrastructure fondamentale pour les contrats intelligents sur Ethereum. Même lorsqu’on évoque d'autres blockchains, la compatibilité avec l’EVM est souvent utilisée comme critère d’évaluation, car elle implique non seulement un environnement d’exécution de contrats, mais aussi l’accès à l’écosystème et aux outils existants d’Ethereum, ainsi qu’un effet réseau considérable. Ainsi, les projets ZK Rollup n’ont pas pu ignorer cet aspect.
Le zkEVM peut être compris comme l’exécution du moteur EVM comme moteur de contrats intelligents au sein d’un ZK Rollup. Son objectif est d’apporter intégralement l’expérience Ethereum à la couche 2 sans sacrifier les avantages de performance offerts par les Rollups.
À ce jour, les principaux projets ZK Rollup universels tels que zkSync 2.0, Polygon Hermez 2.0 et Scroll ont tous lancé leurs réseaux de test zkEVM, tandis que StarkNet est déjà entré dans sa phase Alpha Mainnet.
Classification de la compatibilité du zkEVM
Actuellement, les zkEVM des ZK Rollups ne sont pas entièrement compatibles avec Ethereum lui-même, encore moins avec la vision ultime d’« équivalence Ethereum ». Ainsi, non seulement la feuille de route d’Ethereum intègre désormais des améliorations favorables aux Rollups, mais les différents projets ZK Rollup s’efforcent également continuellement de résoudre les problèmes de compatibilité avec Ethereum.
Vitalik a classé les zkEVM universels selon leur degré de compatibilité avec les infrastructures existantes de l’EVM en quatre catégories :
Type-1 : Équivalent complet à Ethereum
Le zkEVM de type 1 vise une équivalence totale et inconditionnelle à Ethereum. Il ne modifie aucune partie du système Ethereum : ni les hachages, ni les arbres d’état, ni les arbres de transactions, ni les précompilations, ni aucune logique de consensus. En résumé, un zkEVM de type 1 est entièrement équivalent à Ethereum.
Un zkEVM de type 1 est capable de valider les blocs Ethereum, ou du moins la couche d’exécution (incluant toutes les transactions, contrats intelligents et logiques de comptes), à l’exclusion de la logique de consensus liée à la Beacon Chain.
Le zkEVM de type 1 est ce dont Ethereum a finalement besoin, et représente le choix idéal pour les Rollups. D’une part, il permet de réutiliser massivement les infrastructures existantes (clients d’exécution Ethereum, explorateurs de blocs, outils de production de blocs, etc.). D’autre part, il rend la couche 1 d’Ethereum elle-même plus évolutible, car certaines améliorations expérimentées sur le zkEVM de type 1 pourraient à terme être intégrées directement dans Ethereum.
Bien sûr, le zkEVM de type 1 présente aussi des défauts. Ethereum n’a pas été initialement conçu pour être compatible avec les preuves ZK, et de nombreuses parties du protocole exigent des calculs intensifs pour générer ces preuves. Le type 1, étant identique à Ethereum, ne peut pas contourner cette inefficacité — notamment en termes de temps de génération des preuves, qui reste long. Pour résoudre cela, les solutions proposées consistent principalement à paralléliser massivement la génération des preuves grâce à une ingénierie fine, ou à recourir à des accélérateurs matériels (ASIC) dédiés aux ZK-SNARK.
Actuellement, deux équipes travaillent sur le zkEVM de type 1 : l’équipe Privacy and Scaling Explorations et Taiko.
Type-2 : Équivalent complet à l’EVM
Le zkEVM de type 2 vise une équivalence totale à l’EVM, mais pas à Ethereum dans son ensemble. Il est pleinement compatible avec les applications existantes, mais nécessite de légères modifications d’Ethereum afin de faciliter le développement et accélérer la génération des preuves.
Le type 2 apporte quelques modifications aux structures de données telles que la structure des blocs ou les arbres d’état. Comme ces éléments ne sont pas directement accessibles par l’EVM, les applications fonctionnant sur Ethereum peuvent presque toutes fonctionner directement sur un Rollup zkEVM de type 2. Bien que les clients d’exécution d’Ethereum ne puissent pas être utilisés tels quels, ils peuvent l’être après modification, tout comme les outils de débogage EVM et la plupart des autres outils de développement.
En supprimant certaines parties inutiles ou peu adaptées aux ZK dans la pile Ethereum, le type 2 obtient des temps de preuve plus rapides que le type 1. Ces modifications améliorent significativement l’efficacité du prouveur, mais ne résolvent pas fondamentalement le problème de la lenteur. En somme, le temps de preuve du type 2 reste lent.
Type-3 : Quasi-équivalent à l’EVM
Le zkEVM de type 3 est presque équivalent à l’EVM, faisant quelques concessions sur la compatibilité, mais facilitant le développement.
Le type 3 supprime certaines fonctionnalités difficiles à implémenter dans un zkEVM (comme certaines précompilations) et apporte des ajustements dans le traitement du code, de la mémoire ou de la pile, sacrifiant ainsi un peu d’équivalence pour gagner en rapidité de vérification et en facilité de développement.
Ces sacrifices en matière de compatibilité signifient que certaines applications utilisant les précompilations supprimées devront être partiellement réécrites pour fonctionner.
À l’heure actuelle, Scroll et Polygon relèvent du type 3. Toutefois, à long terme, aucun projet zkEVM n’a publiquement indiqué vouloir rester durablement au stade du type 3. Scroll et Polygon Hermez évoluent tous deux vers un zkEVM de type 2, même s’il reste de nombreuses précompilations complexes à implémenter.
Type-4 : Équivalent au niveau du langage haut niveau
Le type 4 relève en réalité des zkVM. Les systèmes de type 4 fonctionnent en prenant le code source des contrats intelligents écrits dans un langage de haut niveau (Solidity, Vyper) et en le compilant vers un langage spécifiquement conçu pour être compatible avec les ZK-SNARK.
Les avantages et inconvénients sont clairs. Ils offrent des temps de vérification très rapides, car contrairement au type 1, ils ne génèrent pas de preuve ZK pour chaque étape d’exécution de l’EVM, mais commencent à un niveau supérieur du code, réduisant ainsi les coûts et accélérant la vérification. En revanche, la compatibilité est moindre : les adresses des contrats dans un système de type 4 diffèrent de celles sur l’EVM ; l’utilisation de bytecode EVM écrit à la main devient difficile ; une grande partie de l’infrastructure de débogage n’est pas réutilisable, car celle-ci repose sur le bytecode EVM.
En résumé, le type 4 est équivalent au niveau du langage, mais présente un écart important en compatibilité comparé à l’équivalence au niveau du bytecode. Selon Vitalik, les principaux projets actuels relevant du type 4 sont Zksync, bien qu’il puisse à terme ajouter une compatibilité avec le bytecode EVM ; le projet Warp de Nethermind, qui construit un compilateur de Solidity vers Cairo pour Starkware, transformera également StarkNet en un système de type 4.
Comparaison des différents zkEVM
Il n
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
