Quel zkEVM a les meilleures performances ? Test de déploiement du contrat Ethereum L2

Auteur : Jarrod Watts; Compilation : Block Beats

Dans la guerre d'expansion d'Ethereum, les cumuls Optimistic sont hautement compatibles ou même complètement équivalents à l'EVM, ce qui conduit aux avantages inhérents de l'Arbitrum et de l'Optimisme sur la voie à adopter par les développeurs. Son portage transparent de code L1 à L2 et ses outils de développement riches peuvent rapidement inciter les développeurs à s'installer, à déployer et à créer des applications sur la plate-forme.

En revanche, la série ZK est plus difficile. Ses caractéristiques techniques inhérentes amènent les rollups ZK à personnaliser leurs propres machines virtuelles, ce qui signifie que la partie projet doit faire plus de travail pour "interpréter" le code de l'EVM ou même développer et écrire un nouveau code à partir de zéro. Cependant, plusieurs projets de suivi de cumuls ZK, notamment Taiko, Polygon, Linea, Scroll et ZkSync Era, ont lancé leurs propres implémentations de zkEVM.

En tant que Saint Graal de l'expansion, zkEVM a un impact crucial sur l'expérience de déploiement du contrat du développeur. Face à une variété de projets de déploiement ZK, comment les développeurs doivent-ils choisir ?

Cet article compile un résumé des tweets de Jarrod Watts, ingénieur des relations avec les développeurs chez Polygon. En déployant des contrats intelligents (1 contrat intelligent Solidity et un contrat NFT) sur le projet actuel populaire de déploiements ZK, il a mesuré les performances zkEVM de projets tels que Taiko, Polygon, Linea, Scroll et ZkSync Era, et a comparé leurs avantages et inconvénients respectifs et les crédits L2 à L1. .

Ce qui suit est une compilation du texte original de BlockBeats :

**Qu'est-ce que ZK-EVM et pourquoi en avons-nous besoin ? ****Avant d'interpréter ce qu'est ZK-EVM, voyons pourquoi ZK-EVM est nécessaire ? **

ZK Rollups apporte évolutivité et hautes performances à Ethereum.D'un autre côté de la médaille, la solution ZK Rollups n'est pas compatible avec EVM (Ethereum Virtual Machine), ce qui signifie que la solution ZK Rollups ne peut prendre en charge que des opérations limitées, y compris le transfert, la frappe ou la gravure, et des outils tels que des portefeuilles doivent être développés pour les utilisateurs.

Par conséquent, nous avons besoin de ZK Rollups compatibles avec l'EVM, et pour cela, diverses entreprises ont développé leurs propres ZK-EVM.

ZK-EVM, ou Zero-Knowledge EVM, est une implémentation de machine virtuelle Ethereum compatible avec Zero-Knowledge Proofs.

La fonction principale de ZK-EVM est de traiter par lots les transactions sur Ethereum L2 (couche 2) et de renvoyer la "preuve de validité" des transactions par lots à Ethereum L1. En général, zkEVM peut tout faire pour le réseau principal Ethereum. Il compile le code lisible par l'homme dans Solidity ou Vyper en bytecode, exécute des contrats intelligents et met à jour l'état de la blockchain.

La difficulté de créer des cumuls ZK compatibles EVM est qu'Ethereum n'a pas été conçu à l'origine avec la convivialité ZK à l'esprit. Cela signifie que les preuves à connaissance nulle nécessitent beaucoup de ressources pour être calculées.

Parmi eux, certains opcodes de code d'opération EVM sont particulièrement "incompatibles avec ZK", ce qui conduit aux produits ZK-EVM finalement conçus par diverses sociétés avec une compatibilité EVM différente.

** Que sont les opcodes, bytecode et EVM ? **

C'est l'heure de la vulgarisation scientifique, que sont les opcodes, bytecodes et EVM ?

Tout d'abord, EVM est l'environnement d'exploitation des contrats intelligents sur Ethereum. Ethereum stocke le soi-disant "état de la machine" dans une structure de données arborescente, qui change après l'exécution de chaque transaction dans un bloc.

L'EVM est déterministe, ce qui signifie que l'exécution d'un ensemble d'instructions sur un état particulier entraînera le même nouvel état.

Selon la documentation du développeur Ethereum, un ancien état valide (S) + un nouvel ensemble de transactions valides (T), Ethereum générera un nouvel état de sortie valide S'

Vous pouvez le considérer comme un jeu comme les échecs. Ethereum est comme un échiquier, où il y a différents états de jeu, et dans Ethereum, les possibilités de cet état sont infinies. Les jeux de société ont leurs propres règles de mouvement spécifiques (comparez les transactions sur Ethereum) et ont des restrictions spécifiques sur les actions qui peuvent être effectuées sur quelles pièces. Les joueurs prennent des mesures (par rapport aux utilisateurs soumettant des transactions sur Ethereum), et le jeu (Ethereum) formule et applique les règles, ce qui entraîne un nouvel état du tableau (Ethereum global) après chaque tour (correspondant au temps de blocage).

Pour Ethereum ou tout développement de blockchain compatible EVM, les contrats intelligents doivent être écrits dans Solidity. Solidity est un langage de haut niveau conçu pour être lisible par l'homme afin que les développeurs puissent se concentrer sur l'écriture de code plutôt que sur les registres, les adresses mémoire, les piles d'appels et d'autres abstractions.

Cependant, l'EVM ne peut pas lire Solidity. Au lieu de cela, il ne comprend que le "bytecode", qui est un code binaire de bas niveau lisible par machine.

Dans EVM, "bytecode" (bytecode) représente une série de "opcodes" EVM (opcodes), les opcodes sont des instructions lisibles de bas niveau du programme, représentant des opérations spécifiques qui peuvent être effectuées dans l'EVM.

Puisqu'un langage de haut niveau comme Solidity ne peut pas être exécuté directement dans l'EVM, nous avons besoin d'un moyen de convertir le code de contrat intelligent à partir du bytecode de l'opcode du langage Solidity lisible par l'homme à exécuter par l'EVM, qui est le travail du compilateur.

Après avoir compilé le code Solidity avec le compilateur Remix IDE, vous pouvez voir l'opcode spécifique dans lequel le contrat intelligent est converti et afficher le bytecode généré à partir de l'opcode.

Voici les opcodes :

Voici le bytecode correspondant à l'opcode ci-dessus.

En traduisant les bytecodes en opcodes, il est possible de savoir quelles instructions d'exécution sont contenues dans les bytecodes.

En raison de la difficulté de preuve ZK pour certains opcodes spécifiques dans EVM, des ZK-EVM avec différents degrés de compatibilité sont apparus sur le marché.Parmi eux, certains jeux d'opcodes ZK-EVM et EVM sont complètement équivalents, certains ont partiellement modifié certains opcodes EVM, et un a des bytecodes complètement différents.

Différents types de ZK-EVM

Étant donné que la conception Ethereum n'a pas pris en compte la convivialité ZK au début, en théorie, plus la conception Ethereum est proche, plus il est difficile et long de générer des preuves ZK. En août 2022, Vitalik, le fondateur d'Ethereum, a publié un article de blog "Écoutez l'interprétation de Vitalik de l'avenir de différents types de ZK-EVM", classant différents ZK-EVM.

Dans cet article, Vitalik a classé divers ZK-EVM en fonction des deux dimensions de la compatibilité EVM et du temps de génération de la preuve ZK (performances). Vitalik a répertorié quatre (semi) types dans ce tableau, et tous les produits ZK-EVM actuellement sur le marché peuvent être inclus.

1, le premier type de ZK-EVM est complètement équivalent à Ethereum, ils ne changent aucune partie du système Ethereum et sont plus faciles à générer des preuves. Dans de tels systèmes, les preuves ZK prennent beaucoup de temps (plusieurs heures) à générer. Taiko appartient à ce type de ZK-EVM.

2. Le deuxième type est complètement équivalent à l'EVM, mais modifie certaines représentations internes différentes, telles que la méthode de stockage de l'état de la chaîne, pour accélérer le temps de génération des preuves ZK. Actuellement, il n'existe pas de ZK-EVM de ce type sur le marché ; cependant, Polygon, Linea et Scroll travaillent dans ce sens.

2.5, entre le type 2 et le type 3, il existe aussi un type 2.5. Ce type est exactement équivalent à l'EVM, sauf que le coût du gaz de certains types d'opérations est augmenté pour "réduire considérablement le temps de preuve dans le pire des cas". Actuellement, il n'y a pas de ZK-EVM de ce type sur le marché ; cependant, un nouveau projet ZK-EVM appelé Kakarot y travaille.

3. Le type 3 est presque équivalent à EVM, mais avec quelques compromis sur une précision équivalente pour réduire davantage le temps de preuve et simplifier le développement EVM. Actuellement, Polygon, Linea et Scroll sont de ce type.

4. Le type 4 est équivalent au langage de haut niveau de ZK-EVM.Ce type de ZK-EVM compile le code source du contrat intelligent dans un langage compatible avec ZK-SNARK, ce qui apportera un temps de preuve plus rapide et les inconvénients correspondants tels que l'incompatibilité et les limitations. Actuellement, zkSync Era entre dans cette catégorie.

Il convient de noter que le temps nécessaire pour renvoyer la preuve de validité à Ethereum L1 est le temps nécessaire à l'utilisateur pour transférer les fonds vers L1. Si la génération de preuves prend des heures, cet utilisateur ne peut pas transférer les fonds vers L1 pendant ces heures.

Combat pratique : évaluation du développement de Taiko, Polygon, Linea, Scroll et ZkSync Era

Après avoir passé en revue les connaissances théoriques, voici la partie combat proprement dite.

En déployant les contrats intelligents Solidity et les contrats NFT sur Taiko, Polygon, Linea, Scroll et ZkSync Era respectivement, les performances et les défauts correspondants de chaque ZK-EVM sont testés.L'auteur donne également les ressources disponibles pour les développeurs, et l'évaluation est principalement effectuée à partir des deux dimensions de l'expérience développeur et du temps de transition de L2 à L1.

Taiko ZK-EVM

Taiko est un ZK-EVM de type 1 et est actuellement au stade testnet. Taiko gère exactement ce que fait Ethereum ; en utilisant les mêmes fonctions de hachage, les prix du gaz, les algorithmes de cryptage, etc.

Processus de fonctionnement : déploiement d'un contrat intelligent Solidity simple et déploiement d'une collection NFT simple à l'aide du proxy ThirdWeb.

L'inconvénient de Type 1 ZK-EVM est qu'il faut beaucoup de temps pour générer des preuves alors que tout est exactement comme dans Ethereum (même en interne). Cela signifie qu'il faut plusieurs heures à un utilisateur pour relier ETH de Taiko L2 à Ethereum L1 (comme indiqué ci-dessous).

Ligne ZK-EVM

Linea appartient au type 3 ZK-EVM, et Linea ne peut pas encore prouver tous les opcodes ou la précompilation ; il représente un état interne de chaîne différent d'Ethereum, comme l'utilisation d'une fonction de hachage différente.

Le bytecode déployé est le même qu'Ethereum.

Le processus de déploiement a été presque transparent, ce qui a facilité le déploiement et l'interaction avec les deux contrats intelligents. C'est le même comportement qu'Ethereum ; les outils et portefeuilles existants peuvent être utilisés pour déployer des contrats intelligents, interagir avec eux, créer des NFT, etc.

Au moment de la rédaction de cet article, Linea n'a pas encore lancé l'interface frontale du pont. Par conséquent, seules les fonctions de contrat intelligent pontées peuvent être appelées directement.

Selon la documentation Linea, le pont L2 à L1 de l'ETH prend généralement environ 15 minutes, mais dans ce cas, il a fallu environ quelques heures.

Polygone ZK-EVM

Polygon ZK-EVM appartient au type 3 ZK-EVM et a lancé le réseau principal depuis la fin mars de cette année.

La documentation officielle de Polygon zkEVM répertorie toutes les différences actuelles entre l'EVM et zkEVM.

Le déploiement de bytecode sur Polygon zkEVM est identique à Ethereum, ce qui rend le déploiement et l'interaction avec les contrats intelligents très simples. Vitalik a dit un jour : "Polygon zkEVM a une conception unique, et ils utilisent ZK pour vérifier leur propre langage interne appelé zkASM".

L'équipe d'ingénierie de Polygon a déclaré qu'en plus d'améliorer la génération de preuve et le temps de retrait, la précompilation restante sera achevée dès que possible dans le futur, dans le but de devenir le type 2 dans le diagramme Vitalik.

Dans ce cas de déploiement, le pontage du réseau principal zkEVM s'est déroulé sans problème ; le processus de pontage L2 -> L1 prend environ 1 heure.

Faire défiler

Scroll appartient au type 3 ZK-EVM et est actuellement au stade testnet. Scroll répertorie également les différences entre ZK-EVM et Ethereum EVM dans la documentation officielle.

Comme les autres ZK-EVM de type 3, le processus de déploiement est presque transparent, et les contrats intelligents Solidity et les collections NFT sont facilement déployés et interagissent avec. Le transfert des fonds de L2 à L1 devrait prendre "10 minutes à quelques heures".

** L'ère ZkSync **

ZkSync Era appartient au type 4 ZK-EVM. Complètement différent des autres ZK-EVM, le bytecode de contrat intelligent déployé sur le zkEVM de ZkSync Era est différent d'Ethereum.

Cela permet à ZkSync Era de fournir une fonctionnalité unique, la prise en charge native de l'abstraction de compte, qui apportera une expérience de développeur différente. En règle générale, la plupart des portefeuilles cryptographiques ne sont que des adresses standard qui peuvent envoyer et recevoir des fonds et interagir avec des contrats intelligents. Avec l'abstraction de compte, les portefeuilles cryptographiques sont personnalisables et peuvent être conçus de manière plus complexe pour fournir un plus large éventail de fonctionnalités. De plus, le zkEVM permet toujours aux développeurs d'utiliser les mêmes langages de haut niveau tels que Solidity.

Bien que le ZK-EVM de ZkSync Era soit assez différent de l'EVM, ZkSync Era fournit un ensemble de meilleures pratiques et considérations pour les développeurs. De plus, les développeurs devront apporter quelques ajustements mineurs au processus de développement pour créer spécifiquement pour ZkSync Era.

Par exemple, dans l'exemple ci-dessous, l'environnement Hardhat doit être installé et configuré avec une extension zkSync personnalisée pour générer un bytecode pouvant être déployé sur l'Era ZK-EVM.

La compilation génère un tout nouveau bytecode qui est complètement différent d'Ethereum, qui est complètement différent du bytecode généré par le ZK-EVM ci-dessus.

Il convient de noter que ThirdWeb a lancé zkSync Era pour offrir aux développeurs une expérience de déploiement plus pratique.

Au total, deux contrats intelligents sont déployés au cours de cette opération, interagissent avec eux et renvoient les actifs de L2 vers L1. Actuellement, il y a un délai de 24 heures pour les retraits du réseau principal ZkSync Era vers Ethereum L1 pour des raisons de sécurité.

Kakarot ZkEvm

Un autre projet dédié à la réalisation de Type 2.5 ZK-EVM est Kakarot ZkEvm, qui a reçu un financement de plusieurs institutions dont Vitalik Buterin et StarkWare en juin de cette année. Kakarot prévoit de publier le testnet plus tard en 2023.

Conclusion

Pour les utilisateurs finaux, peu importe qui remporte la course, car les progrès d'une solution ZK compatible EVM sont une grande victoire pour l'industrie dans son ensemble. Pour les différentes parties du projet, il ne s'agit pas tant d'une compétition que d'explorer différentes méthodes pour promouvoir le progrès de l'ensemble de l'industrie. Vitalik a même une "théorie des multi-certificateurs". La prémisse de base est que différents Rollups peuvent travailler ensemble pour améliorer la sécurité globale d'Ethereum.

En fin de compte, tout le monde veut qu'Ethereum réussisse. La transformation d'expansion L2 est l'une des trois transformations techniques que Vitalik estime qu'Ethereum doit subir. Nous attendrons de voir comment cela se développera à l'avenir.