|
Getting your Trinity Audio player ready...
|
Dernière modification effectuée le 07.08.2022 20:11
Vitalik Buterin, le plus jeune crypto milliardaire au monde à l’origine de la blockchain Ethereum (ETH), publie un article dans lequel il fournit des explications sur les différents types de ZK-EVM. Dans le même temps, il présente leurs avantages et inconvénients et revient sur les (nombreux) projets ZK-EVM actuels.
Il est vrai que de plus en plus de sociétés dévoilent leur solution ZK-EVM (de l’abréviation Zero-knowledge Ethereum Virtual Machin). L’on pense par exemple à Polygon (MATIC) mi-juillet, ZKSync avec ZKSync 2.0 prochainement disponible sur le mainnet ETH ou encore Scroll. Selon lui, toutes ces entreprises ont un objectif commun. Lequel peut être de trois ordres (1) faciliter la vérification de la chaîne Ethereum (2) créer des ZK-rollups plus évolutifs (3) utiliser la technologie ZK-SNARK pour créer des preuves crypto graphiques de transaction exécutées sur Ethereum.
Ainsi, le fondateur de la blockchain Ethereum analyse quatre types de ZK-EVM.
Les ZK-EVM de type 1
Les ZK-EVM de type 1 sont entièrement Ethereum compatibles. Ici, aucune logique de consensus ne se trouve modifiée. Ce qui signifie qu’ils n’ont aucune incidence sur la structure même du système Ethereum ou sur sa sécurité.
Vitalik identifie plusieurs avantages comme la possibilité de vérifier les blocs actuels en raison de sa compatibilité « parfaite » et la capacité de rendre la L1 d’Ethereum plus évolutive. Surtout, il explique qu’ils sont « idéals pour les rollups car ils leur permettent de réutiliser une grande partie de l’infrastructure. »
Le seul inconvénient est qu’ils requièrent une grande quantité de calcul. Corrélativement, le temps de vérification sur Ethereum peut prendre plusieurs heures.
Les ZK-EVM de type 2
Les ZK-EVM de type 2 sont entièrement compatibles EVM, mais pas Ethereum. Leur objectif est d’être entièrement compatibles avec des applications existantes tout en apportant des modifications mineures dans le but de développer et d’accélérer la génération des preuves.
« Elles ressemblent exactement à Ethereum « de l’intérieur », mais elles présentent quelques différences à l’extérieur, en particulier dans les structures de données comme la structure de blocs et le state tree. »
Le premier avantage souffre d’une exception. En principe, les type 2 ont une compatibilité EVM parfaite. Ainsi, ils permettent de modifier les structures de données contenant des éléments comme l’état d’Ethereum. Vitalik indique que c’est en cela qu’il est quasiment toujours possible de faire fonctionner des applications issues d’Ethereum sur un rollup ZK-EVM de type 2. Par exception, il y aura incompatibilité en cas d’utilisation des preuves Merkle ou si un ZK-EVM remplace Keccak par une fonction de hachage.
En revanche, bien qu’il y ait une légère amélioration, le temps de vérification est encore lent.
Si Scroll et Polygon développent des types 2, Vitalik estime qu’ils ne sont pas encore au point car les mécanismes de précompilations ne sont pas encore bons.
Les EVM-ZK de type 3
Les EVM-ZK de type 3 sont presque compatibles EVM. S’ils ne le sont pas totalement, c’est contrebalancé par le fait qu’ils améliorent le temps de vérification et rendent les EVM plus simples à développer. Ils peuvent notamment supprimer des fonctionnalités qui sont exceptionnellement difficiles à mettre en œuvre dans une implémentation ZK-EVM. « En outre, les ZK-EVM de type 3 ont parfois aussi des différences mineures dans la façon dont ils traitent le code du contrat, la mémoire ou la pile. » écrit Vitalik.
L’inconvénient se porte ici sur les problèmes d’incompatibilités pouvant être rencontrées pour certaines applications, nécessitant de fait une réécriture.
Toutefois, il indique que le type 3 est souvent une phase de transition pour l’entreprise (c’est le cas de Polygon et de Scroll), en attendant de finir le travail de précompilations.
Les EVM-ZK de type 4
Les EVM-ZK de type 4, comme ZKSync, utilisent le code source d’un smart contract écrit dans un langage comme Solidity ou Vyper et sont conçus pour être compatibles avec ZK-SNARK. Contrairement aux autres, le temps de vérification est nettement plus rapide et de nombreux frais peuvent être évités sous certaines conditions.
Toutefois, ce dernier système implique des cas d’incompatibilités. En effet, certains contrats peuvent contenir des adresses différentes que celles dans l’EVM. Cela car les adresses des contrats CREATE2 dépendent du bytecode. Or, ce dernier est difficile à utiliser et n’est pas toujours pris en charge bien que son efficacité soit renforcée.
Quelle conséquence ? Cela interrompt les applications qui reposent sur des « contrats contrefactuels » non encore déployés, les portefeuilles ERC-4337, les singletons EIP-2470 et d’autres applications.
Enfin, il conclue sa publication sur l’avenir de ces technologies. Il espère qu’ils deviendront tous des types 1 au fil du temps grâce aux améliorations des ZK-EVM et d’Ethereum.
« Dans un tel avenir, nous aurions plusieurs implémentations de ZK-EVM qui pourraient être utilisées à la fois pour les rollups ZK et pour vérifier la chaîne Ethereum elle-même ».
Nous vous invitons à consulter l’article pour davantage de détails.
