Les différents types de zkEVM : qu’est-ce que c’est, à quoi ça sert et pourquoi c’est important

Suite à l’essor de la DeFi, le réseau Ethereum fait face à d’importants problèmes de congestions. En attendant le déploiement d’innovations telles que Sharding, le réseau a dû trouver d’autres solutions de scalabilité. Parmi elles, les solutions de seconde couche se retrouvent au centre de l’intérêt. Néanmoins, pour pleinement remplir leurs missions, ces dernières doivent proposer des écosystèmes dits « EVM équivalents ». Ainsi, de nombreux projets ont entrepris de développer des zkEVM. Revenons ensemble sur ce que sont les zkEVM ainsi que les différents types de zkEVM qui existent.

Rollups : l’avenir d’Ethereum

Avant d’entrer dans le sujet des zkEVM, nous devons présenter le contexte dans lequel elles sont utilisées.

Comme nous l’avons vu en introduction, le réseau Ethereum mise gros sur les solutions de seconde couche de type Rollups. En effet, celles-ci permettent de déporter une partie de l’activité hors de la couche principale d’Ethereum, tout en héritant de la sécurité de celle-ci. 

En pratique, il existe deux grandes familles de Rollups : les zkRollups et les Optimistic Rollups. Alors qu’il est facile de recréer un environnement similaire à celui d’Ethereum sur les Optimistic Rollups, ce n’est pas forcément le cas pour les zkRollups.

En effet, comme la particule “zk” l’indique, les zkRollups tirent parti des zero-knowledge proofs. Ainsi, les zkRollups utilisent des preuves de validité cryptographiques pour assurer une meilleure scalabilité.

Ainsi, chaque lot de transactions publié sur Ethereum est accompagné d’une preuve cryptographique, qui est vérifiée par un smart contract. De ce fait, la validité des transactions est assurée et partagée entre l’ensemble des nœuds du réseau.

C’est cette propriété qui permet d’assurer la sécurité des zkRollups. En effet, les changements d’état entraînent le calcul d’une preuve de validité. Ainsi, si un changement d’état venait à ne pas être valide, il serait impossible de produire une preuve. 

Malheureusement, cette propriété implique également une incompatibilité avec l’Ethereum Virtual Machine (EVM), comme expliqué sur le site officiel :

« Contrairement aux Optimistic Rollups, les zkRollups ne sont pas facilement compatibles avec la machine virtuelle Ethereum (EVM). Il est plus difficile et coûteux en ressources de prouver l’exécution de calculs généraux sur la machine virtuelle Ethereum (EVM) dans des circuits zero-knowledge, par rapport à la preuve d’exécution de calculs simples. »

Par conséquent, les développeurs ont dû trouver des solutions pour créer des environnements compatibles avec l’EVM dans le contexte des zero-knowledges.

>> Mettez vos cryptomonnaies au vert. Choisissez un portefeuille Ledger (lien commercial) <<

zkEVM : qu’est-ce que c’est ?

Comme nous venons de le voir, les zkRollups ne peuvent pas implémenter une simple copie de l’EVM d’Ethereum. 

Sur Ethereum, le code Solidity des smart contracts est compilé vers un langage compréhensible par l’EVM, appelé bytecode. Ce langage est lui-même composé d’instructions appelées opcode. 

Cependant, ces opcodes ne peuvent être utilisés en l’état par les circuits de génération de preuves indispensables dans le cadre des zero-knowledges.

Par conséquent, les protocoles de zkRollups doivent développer des versions alternatives à l’EVM, compatible avec le traitement des preuves zero-knowledge.

Ces versions de l’EVM compatible avec les zero-knowledge proofs sont appelées zero-knowledge EVM ou zkEVM. 

De ce fait, les zkEVM sont en mesure de vérifier l’exactitude de l’exécution d’un programme. Pour ce faire, ils définissent leur propre opcode, compatible avec les circuits zero-knowledges.

« Tout comme l’EVM, un zkEVM passe d’un état à un autre après avoir effectué un calcul sur des entrées. La différence réside dans le fait que le zkEVM crée également des preuves sans connaissance (zero-knowledge proofs) pour vérifier l’exactitude de chaque étape de l’exécution du programme. »

Ce manque de compatibilité engendre la création de nouveaux langages, créés pour supporter les preuves de validités. Selon les solutions, les développeurs devront soit écrire des contrats directement dans un nouveau langage de programmation, soit compiler le code source Solidity en opcodes zkEVM, via ce que l’on appelle un transpiler.

Pourquoi les zkEVM sont importants ?

En attendant le déploiement de solutions telles que Sharding, la roadmap d’Ethereum a pris une direction dite « rollup-centric ». Ainsi, l’écosystème Ethereum fait le pari des Rollups pour améliorer sa scalabilité à court et moyen terme.

Comme nous l’avons vu précédemment, il existe deux types de rollups : 

• Optimistic Rollups ; 
• zkRollups.

Le principal avantage des Optimistic Rollups repose dans sa compatibilité avec l’EVM. Néanmoins, cette solution dispose de plusieurs limitations.

Dans un premier temps, ces derniers ne reposent pas sur la fiabilité des zero-knowledges pour valider les changements d’état. 

Ces derniers optent pour une méthode dite « optimiste ». Cette méthode peut être perçue comme étant opposée à celle des zkRollups. Ainsi, là où les zkRollups utilisent des preuves de validité, les Optimistic Rollups reposent quant à eux sur des preuves de fraudes.

Lorsque le Sequencer publie un nouvel état, celui-ci est en attente et peut être mis à l’épreuve pendant une période de sept jours. Pendant ce laps de temps, des acteurs appelés vérificateurs peuvent recalculer l’ensemble de l’état et vérifier sa validité. Si celui-ci venait à ne pas être valide, le nouvel état frauduleux serait abandonné et le producteur de cet état sanctionné.

Ce mécanisme comporte bien plus d’acteurs différents, et n’est pas aussi sécurisé que peut l’être l’utilisation des preuves zero-knowledges.

De surcroît, la période de validation des Optimistic Rollups implique que l’ensemble des retraits d’un Optimistic Rollup vers le L1 disposent d’une période de blocage de sept jours. Cette période a un impact négatif notable sur l’expérience utilisateur.

En conclusion, les Optimistic Rollups sont des solutions plus faciles à mettre en œuvre. Cependant, les zkRollups s’avèrent bien plus sécurisés et performants.

Comme nous l’avons vu, les zkRollups ne peuvent exister de manière pertinente sans disposer d’une EVM sur mesure. Néanmoins, ils seront une pierre angulaire de l’évolution d’Ethereum dans les prochaines années. Par conséquent, cela fait des zkEVM un sujet central pour l’amélioration de la scalabilité.

 >> Not your keys not your coins ! Optez pour un wallet hardware à toute épreuve, choisissez Ledger (lien commercial) <<

Les différents types de zkEVM

Vous l’aurez compris, l’incompatibilité entre l’EVM et les zkRollups a engendré une multitude de solutions diverses et variées.

En août dernier, Vitalik Buterin publiait un article sur son blog dans lequel il faisait le point sur les différentes approches qui existent en matière de zkEVM. Évidemment, chacune de ces approches dispose de ses avantages et inconvénients.

Dans son article, Vitalik Buterin a identifié 4 grandes familles de zkEVM. Explorons ensemble ces différentes solutions afin de comprendre leurs spécificités, leurs avantages et inconvénients.

Les zkEVM entièrement équivalents à Ethereum (Type 1)

Les zkEVM de type 1 sont la quintessence même de ce que l’on attend des zkEVM. En effet, ces derniers sont entièrement équivalents à Ethereum, et ce, sans faire de compromis.

Ce type de zkEVM ne fait état d’aucune modification de l’EVM, ni d’aucun mécanisme propre à Ethereum.

« Ils ne remplacent pas les hachages, les arbres d’états, les arbres de transactions, les précompilations ou toute autre logique de consensus. »

Nous pouvons notamment citer l’initiative combinée des équipes de Scroll, Taiko et Privacy & Scaling Explorations, pour la création de ce type de zkEVM.

Avantages

Du fait de leur pureté, ces zkEVM ont l’avantage de ne nécessiter aucune modification sur le réseau Ethereum pour être fonctionnels. Cela permet de conserver le processus de vérification des blocs sur Ethereum tel qu’il est actuellement.

De surcroît, du fait de leur parfaite compatibilité, les zkEVM de type 1 permettent un déploiement facilité de l’ensemble des infrastructures déjà existantes sur Ethereum. 

« Par exemple, les clients d’exécution Ethereum peuvent être utilisés tels quels pour générer et traiter les blocs de rollup, de sorte que les outils tels que les explorateurs de blocs, la production de blocs, etc. sont très faciles à réutiliser. »

Inconvénients

Évidemment, ce type de zkEVM ne présente pas que des avantages. En effet, le protocole Ethereum n’a pas été imaginé pour supporter nativement la génération de preuves zero-knowledge.

Par conséquent, de nombreuses parties du protocole nécessitent une importante puissance de calcul pour générer les preuves zero-knowledges. Si bien, que Vitalik envisage même l’utilisation de matériel dédié, sous la forme d’ASICs : 

« Actuellement, la production des preuves pour les blocs Ethereum prend plusieurs heures. Ce problème peut être atténué soit par une ingénierie intelligente permettant de paralléliser massivement le prouveur, soit, à plus long terme, par des ASIC ZK-SNARK. »

Les zkEVM équivalents à l’EVM (Type 2)

Ce second type de zkEVM est quant à lui entièrement équivalent à l’EVM d’Ethereum. Néanmoins, dans ce cas, les développeurs ont pris plus de libertés vis-à-vis des différentes mécaniques propres à Ethereum.

Comme l’explique Vitalik, ces dernières ressemblent exactement à Ethereum de l’intérieur, mais présentent quelques différences à l’extérieur. Cela peut se traduire par des modifications dans des structures de données ou dans l’arbre d’état.

« L’objectif est d’être entièrement compatible avec les applications existantes, tout en apportant quelques modifications mineures à Ethereum pour faciliter le développement et accélérer la génération de preuves. »

Le projet de zkEVM développé par le protocole Scroll entre dans cette catégorie. Il en va de même pour Polygon Hermez. Néanmoins, du fait de leur complexité d’implémentation, ce type de zkEVM n’est pas encore arrivé à maturité.

Avantages

Les zkEVM de type 2 ont l’avantage de présenter une équivalence parfaite avec l’EVM d’Ethereum. Par conséquent, la majorité des applications décentralisées pourraient y être déployées sans avoir à subir de modifications.

Il en va de même pour les différents outils et autres fournisseurs d’infrastructures indispensables aux développeurs.

Comme expliqué par Vitalik, cette compatibilité dispose tout de même de certaines exceptions. C’est notamment le cas pour les applications qui utilisent les preuves de Merkle sur l’historique des blocs Ethereum.

De plus, les zkEVM de type 2 permettent de générer plus rapidement les preuves que leurs cousins de type 1.

Inconvénients

Comme nous venons de le voir, les zkEVM type 2 accélèrent le temps de génération des preuves. Cela est majoritairement dû au retrait de plusieurs mécanismes propres à Ethereum, peu favorable aux zero-knowledges.

« En particulier, ils pourraient changer l’algorithme de hachage Keccak d’Ethereum et l’arbre Merkle Patricia basé sur RLP, ainsi que les structures de bloc. »

Bien que ces modifications améliorent le temps de génération des preuves, elles ne sont pas sans impacts.

« La lenteur liée à la nécessité de prouver l’EVM tel qu’il est, avec toutes les inefficacités et l’incompatibilité avec ZK inhérentes à l’EVM, reste toujours présente. »

Les zkEVM presque équivalents à l’EVM (Type 3)

Ce troisième type de zkEVM est proche de l’équivalence à l’EVM, mais effectue certains compromis afin d’améliorer le temps de génération des preuves.

Les zkEVM de Scroll et Polygon sont, en l’état, tous deux des zkEVM de type 3, bien qu’ils ambitionnent de devenir des zkEVM de type 2 à terme. En effet, comme l’explique Vitalik, les zkEVM de type 3 ne sont qu’une transition : 

« Aujourd’hui, aucune équipe ZK-EVM ne souhaite devenir une ZK-EVM de type 3 ; le type 3 est simplement une étape transitoire jusqu’à ce que le travail compliqué d’ajout de précompilation soit terminé et que le projet puisse passer au type 2.5 (une étape entre le type 2 et le type 3). »

Dans l’écosystème de Starknet, le projet Kakarot développé en Cairo propose un zkEVM de type 3 qui tourne dans un smart contract sur Starknet.

Avantages

Les zkEVM de type 3 ont comme principal avantage d’être plus faciles à implémenter que les zkEVM de type 1 ou 2.

Du fait du retrait de plusieurs fonctionnalités trop compliquées à implémenter pour qu’elles soient compatibles avec les zero-knowledges, ces zkEVM permettent de réduire le temps de génération des preuves.

Inconvénients

Bien qu’il réduise le temps de génération des preuves, le retrait de certaines fonctionnalités engendre une incompatibilité avec certaines applications. Par exemple, le retrait du precompile.

Ainsi, certaines applications nécessitent d’être partiellement voire entièrement réécrite pour être déployées sur ces solutions.

Les zkEVM high-level-language equivalent (Type 4)

Contrairement aux autres cas de zkEVM, le type 4 se concentre sur les langages de programmation plutôt qu’à recréer une EVM compatible.

Ainsi, les zkEVM de type 4 vont compiler les smart contracts (par exemple en Solidity) pour les compiler dans un langage conçu pour être favorable aux zero-knowledges.

En pratique, des projets tels que le transpiler Warp qui vise à convertir du code Solidity en Cairo, permet de considérer Starknet comme un zkEVM de type 4. La zkEVM de zkSync est, elle aussi, de type 4.

Avantages

En s’attaquant au code de haut niveau, les zkEVM de type 4 contournent les problèmes liés à la génération de preuves zero-knowledges pour chaque partie de l’EVM.

« La compilation directe à partir de langages de haut niveau peut vraiment réduire considérablement les coûts et favoriser la décentralisation en facilitant la tâche des vérificateurs. »

Évidemment, cela impacte favorablement le temps de génération des preuves ainsi que la puissance nécessaire à leur génération.

Inconvénients

Les zkEVM de type 4 souffrent cependant de nombreux problèmes de compatibilité. En effet, bien que certaines applications écrites en Solidity pourraient être converties sans accroc dans le langage spécifique de la zkEVM, c’est loin d’être le cas de l’ensemble des applications.

Par exemple, de nombreux développeurs écrivent des pans entiers de leurs applications directement en bytecode EVM par souci d’optimisation.

« Les systèmes de type 4 peuvent ne pas le supporter, bien qu’il existe des moyens de mettre en œuvre un support limité du bytecode EVM pour satisfaire ces cas d’utilisation sans passer par l’effort de devenir un ZK-EVM de type 3 à part entière. »

De plus, ces zkEVM se coupent de certaines applications de débuggage qui reposent sur le bytecode de l’EVM.

Conclusion

Vous l’aurez compris, le monde des zkEVM est aussi riche que varié. De plus, les solutions ne sont pas figées dans une catégorie ou dans une autre. Comme l’explique Vitalik, les zkEVM peuvent évoluer au fil du temps pour passer d’un type à l’autre : 

« Un zkEVM pourrait commencer par le type 3, en décidant de ne pas inclure certaines fonctionnalités qui sont particulièrement difficiles à prouver via les zero-knowledges. Il peut cependant ajouter ces fonctionnalités au fil du temps, et passer au type 2. »

Pour son article, Vitalik Buterin a réalisé un graphique qui permet de visualiser les différents types de zkEVM en fonction de leur compatibilité et de leur performance.

De plus, nous avons réalisé un tableau qui compile les avantages et inconvénients de chacun de ces types.

Type de zkEVM	Avantages	Inconvénients
Type 1	Compatibilité parfaite	Temps de génération des preuves
Type 2	Équivalence parfaite à l’EVM	Temps de génération des preuves
Type 3	Facilité de développement Temps de génération des preuves réduit	Nombreuses incompatibilités
Type 4	Temps de génération des preuves réduit	Nombreuses incompatibilités

Pour dormir l’esprit tranquille, équipez-vous d’un wallet hardware sécurisé Ledger, il y en a pour toutes les bourses. Votre sécurité n’a pas de prix (lien commercial).