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

Parmi les nombreuses approches d’extension d’Ethereum, la ZK est la direction la plus complexe mais aussi la plus cruciale.

À l’échelle du réseau, V God et la Ethereum Foundation misent le plus sur la ZK. La ZK ressemble un peu au plus jeune fils de la famille Ethereum : on y 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 constitue une planification des composants de base pour un portefeuille privé. Cette feuille de route réaffirme 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 aussi 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 l’avons déjà mentionné, le moyen le plus direct d’améliorer les performances d’Ethereum est d’augmenter la limite de GAS, c’est-à-dire de rendre les blocs plus gros.

Mais le problème est que l’augmentation de la limite de GAS a un coût : des blocs trop volumineux représentent une lourde charge pour les nœuds.

Actuellement, Ethereum adopte un mode de validation appelé “validation universelle”, c’est-à-dire que tous les nœuds doivent 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.

Compte tenu du fait que l’intervalle entre les blocs d’Ethereum n’est que de 12 secondes, dont une partie doit être réservée à la propagation des blocs et à l’ordonnancement MEV, le temps réellement disponible pour la validation par les validateurs n’est que de 4 à 8 secondes, ce qui laisse très peu de marge pour traiter une charge plus importante.

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

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

La particularité de la ZK est que la génération de la preuve est lente, mais sa vérification 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 par un si vous aviez encore des jours de congé (validation universelle), et le processus n’était approuvé qu’après validation par tous.

Après la ZK-isation, 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) ; à ce moment-là, les supérieurs n’ont plus qu’à faire confiance et approuver rapidement (validation unique universelle).

Après la ZK-isation, vous continuez à demander un congé (envoi de transaction), le système constate que vous avez des jours restants et 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 accélère grandement l’approbation (validation unique universelle).

C’est la raison pour laquelle Ethereum veut passer à la ZK.

Défis cryptographiques et cas d’usage

Bien entendu, la réalisation de tout cela nécessite un énorme travail d’ingénierie et un niveau de difficulté cryptographique très élevé, c’est pourquoi Ethereum doit collaborer avec des équipes spécialisées.

Le protocole Brevis, mentionné par Justin, chercheur à la Ethereum Foundation, est l’un des exemples les plus avancés 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 à 45M GAS, Brevis utilise 64 cartes graphiques RTX 5090 et peut générer 99,6 % des preuves de 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 génération de preuves ZK ne dépasse pas 100 000 dollars.

Bien que des GPU plus haut de gamme (comme les H200 ou B200) puissent générer des preuves plus rapidement, cela augmenterait considérablement la barrière à l’entrée. La conception actuelle de Brevis respecte tout juste cette limite.

Pourquoi la “couverture en 10 secondes” est-elle également cruciale ? Parce que les blocs MEV sont généralement générés en 1 à 3 secondes, et les 10 secondes nécessaires à la génération de la preuve remplissent parfaitement l’intervalle de 12 secondes entre les blocs.

Résumé : la logique de la ZK-isation d’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 vers la ZK-isation ;

Et pour réaliser élégamment la ZK-isation (génération de preuve en moins de 10 secondes, coût matériel inférieur à 100 000 dollars), il faut la collaboration de la communauté cryptographique et du secteur de la cryptographie.

La ZK est la direction la plus complexe mais aussi la plus déterminante dans la feuille de route d’extension d’Ethereum.

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