Comment Vitalik Buterin envisage l’évolution de la technologie ZK (zero knowledge) pour l’écosystème Ethereum (ETH) ?
La technologie Zero-knowledge est considérée comme un élément essentiel pour la résolution des problèmes de scalabilité de la blockchain Ethereum. Le début de 2023 a été marqué par le lancement public de nombreuses solutions de couche 2 basées sur cette technologie : Arbitrum, Polygon, zkSync Era… Dans un billet de blog, le co-fondateur d’Ethereum, Vitalik Buterin, a expliqué qu’il souhaitait voir évoluer l’utilisation de technologie Zero-knowledge au niveau des machines virtuelles Ethereum (EVM, Ethereum Virtual Machines) et non pas uniquement sur les rollups. Selon Buterin, la création de zk-EVM sur la première couche d’Ethereum pourrait accélérer le processus de vérification sur la blockchain de base.
Buterin a expliqué qu’Ethereum avait été développé avec une “philosophie multi-clients” pour assurer la décentralisation du protocole. Deux types de clients fonctionnent actuellement sur la blockchain Ethereum : les clients dits de « consensus » et « exécution ». Le client de consensus implémente la preuve de participation pour s’assurer que les nœuds du réseau parviennent à un accord, tandis que le client d’exécution identifie les nouvelles transactions diffusées sur le réseau, les exécute en EVM standard et détient une copie du dernier état de la blockchain. Les zk-EVM serait le troisième type de client du réseau.
L’idée de Buterin est née d’un constat simple : le réseau Ethereum fait aujourd’hui face à un problème différent, qu’aucune mise à l’échelle de la couche 2 ne peut résoudre à elle seule. En effet, la couche 1 est difficile à vérifier, au point que peu d’utilisateurs exécutent leur propre nœud. Au lieu de cela, la plupart des utilisateurs font simplement confiance à des fournisseurs tiers.
Une mise en oeuvre qui se heurte à des difficultés
Grâce aux zk-EVM, la fonction de la couche 1 serait d’être une chambre de compensation pour les protocoles de la couche 2 qui facilite occasionnellement les transferts de fonds importants entre eux. Cette approche présente toutefois des faiblesses importantes : de nombreuses applications basées sur la couche 1 deviendraient alors “économiquement non viables” et les transferts de fonds – d’une valeur de quelques centaines de dollars ou moins – pourraient rester “bloqués” si les frais de gaz devenaient trop importants.
La seconde option serait d’utiliser un ZK-EVM de type 1 (entièrement équivalent à Ethereum) pour vérifier l’exécution EVM d’un bloc Ethereum (couche 1). La création de ce ZK-EVM serait difficile : aujourd’hui, les ZK-EVM mettent entre quelques minutes à plusieurs heures pour vérifier les blocs Ethereum, et la génération de preuves en temps réel nécessiterait une ou plusieurs (i) améliorations d’Ethereum lui-même pour supprimer les incompatibilités, (ii ) des gains d’efficacité importants avec du matériel spécialisé, et (iii) des améliorations architecturales.
Selon Buterin, une structure ouverte multi ZK-EVM serait la plus appropriée pour cette seconde option : différents clients disposeraient de différentes implémentations de ZK-EVM, et chaque client devra attendre une preuve compatible avec sa propre implémentation avant d’accepter un bloc comme valide. Buterin privilégie cette approche car elle n’abandonnerait pas le paradigme “multi-clients”, et une infrastructure zk-EVM ouverte garantirait également que de nouveaux clients pourraient être développés, ce qui décentraliserait davantage Ethereum au niveau de la couche de base.
