Pourquoi Ethereum a-t-il besoin du ZK-VM : la voie ultime de la scalabilité

Auteur : Ebunker

Parmi les nombreuses approches pour le scaling d’Ethereum, la ZK est la plus complexe mais aussi la plus cruciale.

À l’échelle du réseau, Vitalik et la Ethereum Foundation misent le plus sur la ZK. La ZK ressemble un peu au plus jeune enfant de la famille Ethereum : on lui consacre le plus d’efforts, mais son avenir reste le plus incertain.

Il y a quelques jours, la Ethereum Foundation a publié la feuille de route Kohaku, qui est une planification des composants de base pour un portefeuille privé. Cette feuille de route souligne à nouveau que de nombreuses fonctionnalités clés dépendront toujours de la mise en œuvre de ZK-EVM ou ZK-VM.

Alors, pourquoi Ethereum a-t-il un besoin si urgent de ZK-VM ?

La réponse est simple : pour améliorer les performances, sans sacrifier la sécurité.

Le goulot d’étranglement de la performance : validation universelle et limite de GAS

Nous avons déjà mentionné que la méthode la plus directe pour améliorer les performances d’Ethereum est d’augmenter la limite de GAS, c’est-à-dire de rendre les blocs plus grands.

Mais le problème, c’est qu’augmenter la limite de GAS a un coût : des blocs trop volumineux représentent un lourd fardeau pour les nœuds.

Actuellement, Ethereum utilise un modèle de validation appelé “validation universelle”, où chaque nœud doit valider intégralement chaque bloc. Ce mécanisme est certes simple et sûr, mais il est extrêmement redondant.

Si la limite de GAS augmente significativement, la charge de calcul de chaque nœud explosera en conséquence.

Étant donné que l’intervalle entre les blocs sur Ethereum n’est que de 12 secondes, et qu’il faut réserver du temps pour la propagation des blocs et l’ordonnancement MEV, le temps réel dont disposent les validateurs pour valider n’est que de 4 à 8 secondes, ce qui laisse très peu de marge pour gérer une charge plus importante.

Ethereum après la ZK : de la “validation universelle” à la “validation unique universelle”

Si Ethereum L1 devient entièrement ZK, le modèle de validation passera de la “validation universelle” à la “validation unique universelle”. Dans ce modèle, lorsqu’un bloc est assemblé, une preuve ZK est d’abord générée.

La caractéristique de la ZK est que la génération de la preuve est lente, mais la validation est extrêmement rapide. Ainsi, les nœuds n’ont qu’à vérifier une seule fois si la preuve est correcte, sans avoir à exécuter toutes les transactions du bloc à chaque fois.

Cela signifie qu’Ethereum peut augmenter considérablement la limite de GAS sans accroître significativement la charge des nœuds.

Une métaphore parlante : auparavant, lorsque vous soumettiez une demande de congé sur DingTalk (envoi de transaction), chaque supérieur (nœud) devait vérifier un à un si vous aviez encore des jours de congé (validation universelle), et le processus n’était validé qu’après l’approbation de tous.

Après la ZK, le système vérifie d’abord que vous avez bien des jours de congé, puis délivre une preuve à tous les supérieurs (ZK), qui n’ont alors qu’à faire confiance et approuver rapidement (validation unique universelle).

Après la ZK, vous soumettez toujours une demande de congé (envoi de transaction), le système constate que vous avez encore des jours, informe directement tous les supérieurs “cette personne a des congés”, et les supérieurs font entièrement confiance au système (ZK), ce qui rend l’approbation bien plus rapide (validation unique universelle).

C’est la raison pour laquelle Ethereum veut adopter la ZK.

Défis cryptographiques et cas d’usage

Bien sûr, la mise en œuvre de tout cela représente un énorme travail d’ingénierie et une difficulté cryptographique très élevée, c’est pourquoi Ethereum doit collaborer avec des équipes spécialisées.

Le protocole Brevis, mentionné par le chercheur de la Ethereum Foundation Justin, est l’un des cas de pointe dans ce domaine.

Brevis se concentre sur la ZK-VM, et sa dernière technologie Pico Prism est l’une des solutions les plus rapides pour générer des preuves ZK dans des conditions données.

Selon les données de test, avec la taille actuelle des blocs Ethereum à 45 M GAS, Brevis utilise 64 cartes GPU RTX 5090 et peut générer la preuve de 99,6 % des blocs en 12 secondes, dont 96,8 % des blocs en moins de 10 secondes.

Pour maintenir la décentralisation, Ethereum exige que le coût des équipements de preuve ZK ne dépasse pas 100 000 dollars.

Bien que des GPU plus haut de gamme (comme H 200 ou B 200) puissent générer des preuves plus rapidement, cela augmenterait considérablement la barrière à l’entrée. Le design actuel de Brevis reste juste en dessous de cette limite.

Pourquoi la “couverture 10 secondes” est-elle si cruciale ? Parce que les blocs MEV sont généralement générés en 1 à 3 secondes, et avec 10 secondes pour générer la preuve, cela remplit parfaitement l’intervalle de 12 secondes entre les blocs.

Résumé : la logique de la ZK pour Ethereum

Pour accélérer l’amélioration des performances du L1 d’Ethereum, il faut augmenter la limite de GAS ;

Pour augmenter la limite de GAS en toute sécurité, il faut avancer sur la ZK ;

Et pour mettre en œuvre la ZK de manière élégante (preuve générée en moins de 10 secondes, coût matériel inférieur à 100 000 dollars), il faut l’effort conjoint de la communauté cryptographique et de l’écosystème crypto.

La ZK est la direction la plus complexe mais aussi la plus déterminée dans la feuille de route du scaling d’Ethereum.

Elle ne concerne pas seulement la performance, mais représente aussi la solution ultime pour qu’Ethereum trouve l’équilibre entre sécurité et décentralisation.