Ethereum (ETH) : Vitalik explique les ZK-EVM

Les ZK-EVM sont des protocoles utilisés par les réseaux de niveau 2 pour augmenter la scalabilité sur Ethereum (ETH). En pratique, ils permettent la création de rollups Zero-Knowledge pour agréger la validation des transactions sur le réseau sans divulguer d’informations sensibles. Ce faisant, ils assurent une exploitation plus rapide et moins coûteuse des dApps Ethereum tout en préservant la décentralisation et la sécurité.

Polygon Hermez, zkSync et Scroll s’affrontent pour obtenir le monopole sur ce marché. Actuellement, la question est de savoir qui proposera l’offre la plus attractive entre performance et compatibilité avec l’Ethereum Virtual Machine (EVM). Dans ce contexte de frénésie, Vitalik Buterin, le fondateur d’Ethereum, a publié un article qui établit une typologie des solutions existantes et leurs spécificités. Il en a identifié cinq.

An explainer of the different types of ZK-EVMs and ZK-EVM-like projects out there, and the tradeoffs between them.https://t.co/HAYpNfCHRH

— vitalik.eth (@VitalikButerin) August 4, 2022

Type 1 – entièrement équivalent à Ethereum

Les ZK-EVM de type 1 ont la particularité d’offrir une équivalence absolue avec l’EVM. Cela dit, ils épousent Ethereum dans son intégralité. Leur fonctionnement repose sur la volonté de faciliter la génération de preuves sur le réseau, sans modifier les propriétés de sa couche d’exécution.

Manifestement, les ZK-EVM de type 1 sont susceptibles de stimuler la montée en charge sur Ethereum. En effet, ils offrent de nombreux avantages, notamment la possibilité pour les rollups d’exploiter la majorité de l’infrastructure et des outils du réseau (clients d’exécution, explorateurs de blocs, etc.).

Cependant, à la base, Ethereum n’a pas été pensé pour intégrer les protocoles Zero-Knowledge (ZK). Cela explique pourquoi, actuellement, la production des preuves ZK nécessite beaucoup de temps et de calculs de la part du réseau. Par ailleurs, dans la mesure où le ZK-EVM a été développé en fonction d’Ethereum, il sera difficile de combler ces lacunes, du moins à court terme.

Un défi que la Privacy and Scaling Explorations, une organisation issue de la communauté Ethereum, a décidé de relever. En effet, les membres de cette association travaillent actuellement à la création d’un ZK-EVM de type 1.

Type 2 – entièrement équivalent à un EVM

Les ZK-EVM type 2 sont partiellement compatible avec Ethereum mais en équivalence parfaite avec l’EVM. Plus précisément, il présente les mêmes caractéristiques intrinsèques qu’Ethereum, avec des différences principales au niveau des structures de données. Il s’agit ici d’assurer une cohérence maximale avec les applications en service, tout en adaptant légèrement le système pour réduire le temps de vérification des blocs.

Par ailleurs, contrairement aux protocoles de type 1, les ZK-EVM de type 2 limitent le recours à certaines ressources d’exécution propres à Ethereum. En revanche, les autres aspects de l’architecture du réseau restent accessibles. De plus, ce modèle offre des temps de génération de preuves réduits par rapport au précédent. Cela dit, il subsiste une certaine lourdeur dans l’exécution.

Les ZK-EVM de Scroll et Polygon Hermez tendent à devenir des ZK-EVM de type 2. Toutefois, cette orientation ne s’est pas encore pleinement matérialisée.

Type 2.5 – équivalent EVM, sauf pour les frais de gaz

Inspirée de la ZK-EVM type 2, cette typologie est destinée à résoudre le problème de la lenteur. Elle consiste à définir certaines restrictions pour optimiser le processus de génération de preuves.

Une solution consiste à majorer les frais de gaz pour les transactions de haute complexité. Cela peut éventuellement compromettre le fonctionnement de certaines applications. Cependant, cette approche présente des risques limités. Néanmoins, pour assurer une certaine cohérence, certaines règles doivent être respectées. Il s’agit entre autres du fait que les développeurs ne doivent jamais réclamer des frais plus élevés pour une transaction que ce qu’il y a dans un bloc.

La deuxième méthode est d’imposer un plafond au nombre de requêtes autorisées pour chaque transaction. Bien que simple à implémenter, l’efficacité de cette technique est fortement réduite par les exigences de sécurité de l’EVM.

Type 3 – presque équivalent à l’EVM

Les protocoles ZK-EVM de type 3 correspondent à un modèle en équivalence partielle avec l’EVM. Par contre, ils apportent des changements relativement mineurs (fonction de hachage, gestion de la mémoire, suppression de la pré-compilation, etc.) qui ont des répercussions sur la couche applicative.

Ils offrent tout de même de nombreux avantages. Notamment la facilité à développer des DApps Ethereum, la compatibilité avec la majorité des applications et des délais plus courts.

Le problème est que les modifications apportées peuvent entraîner le dysfonctionnement de certaines applications. Ce phénomène peut s’expliquer par la suppression des pré-compilations ainsi que par des dépendances subtiles concernant des cas extrêmes de différence de traitement des machines virtuelles.

Scroll et Polygon Hermez proposent actuellement des ZK-EVM de type 3. Un modèle qu’ils envisagent d’abandonner au profit du type 2.

Type 4 – équivalent aux langages de haut niveau

Les protocoles ZK-EVM de type 4 ont la capacité de compiler directement le code source des applications écrites avec des langages de haut niveau (Solidity, Vyper, etc.) afin d’obtenir un script intelligible pour l’EVM. Cela dit, ils ne sont pas compatibles avec une bonne partie des applications Ethereum et ne permettent pas d’utiliser l’infrastructure réseau. Toutefois, ils réduisent considérablement les temps et les coûts de génération des preuves. De plus, cette approche contribue à la décentralisation en allégeant le travail du validateur. A ce jour, ZKSync est un système de type 4, ce qui devrait bientôt être le cas pour StarkNet aussi.

À ce stade, il est difficile de se prononcer sur la pertinence de l’une ou l’autre de ces approches. Il convient avant tout de déterminer dans quelle mesure on est prêt à concilier vitesse et compatibilité avec l’infrastructure Ethereum. « Personnellement, j’espère que tout deviendra Type 1 au fil du temps. […] Cependant, il faudra un certain temps avant que nous arrivions à un tel avenir », conclut Vitalik Buterin. Fait intéressant, les protocoles peuvent être amenés à évoluer d’un type à l’autre en fonction des besoins auxquels ils souhaitent répondre.