Pourquoi Ethereum a besoin de ZK-VM : le chemin ultime pour l'extensibilité

Titre original : « Pourquoi Ethereum a besoin de ZK-VM : le chemin ultime de l'évolutivité »

Auteur original : Ebunker 中文

Parmi les nombreuses approches pour l'extension d'Ethereum, ZK est la direction la plus complexe et la plus cruciale.

Dans l'ensemble du réseau, Vitalik Buterin et la fondation Ethereum parient le plus sur ZK. ZK est un peu comme le plus jeune fils d'Ethereum, celui sur lequel on investit le plus d'efforts, mais dont l'avenir est également le plus incertain.

Il y a quelques jours, la fondation Ethereum a publié la feuille de route Kohaku, qui est un ensemble de composants de base pour un portefeuille de confidentialité. La feuille de route souligne à nouveau que de nombreuses fonctionnalités clés dépendront toujours de la mise en œuvre de ZK-EVM ou de 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 compromettre la sécurité.

Goulots d'étranglement des performances : validation par tous et limite de GAS

Nous avons précédemment mentionné que le moyen le plus efficace d'améliorer les performances d'Ethereum est d'augmenter la limite de GAS, c'est-à-dire d'agrandir les blocs.

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

Actuellement, Ethereum adopte un mode de validation appelé « validation complète par tous », c'est-à-dire que tous les nœuds doivent valider complètement chaque bloc. Ce mécanisme, bien que simple et sécurisé, présente une redondance très élevée.

Si la limite de GAS augmente de manière significative, la charge de calcul de chaque nœud augmentera également de manière exponentielle.

Considérant que l'intervalle entre les blocs d'Ethereum n'est que de 12 secondes, dont une partie doit être réservée pour la propagation des blocs et le tri MEV, le temps disponible pour les validateurs pour effectuer la validation est d'environ 4 à 8 secondes, laissant presque aucune marge pour gérer une charge plus importante.

Ethereum après ZK : de « tous vérifiés » à « tous vérifiés une fois »

Si Ethereum L1 est entièrement ZK, le mode de vérification passera de « tous vérifient tout » à « tous vérifient un ». Dans ce mode, lorsqu'un bloc est assemblé, un ZK proof sera d'abord généré.

Les caractéristiques de ZK sont que la génération de preuves est lente, mais la vérification est très rapide. Ainsi, les nœuds n'ont besoin de vérifier qu'une seule fois si la preuve est correcte, sans avoir à exécuter à nouveau toutes les transactions dans le bloc.

Cela signifie qu'Ethereum peut augmenter considérablement la limite de GAS sans augmenter de manière significative la charge des nœuds.

Une métaphore illustrative est la suivante : autrefois, lorsque vous soumettiez une demande de congé sur DingTalk (effectuer une transaction), chaque dirigeant (nœud) devait vérifier individuellement si vous aviez encore des jours de congé disponibles (vérification complète), et le processus ne passait qu'après approbation de tous.

Et après la transformation en ZK, le système vérifie d'abord que vous avez effectivement des congés, puis délivre un certificat (ZK) à tous les dirigeants. À ce moment-là, les dirigeants n'ont qu'à faire confiance et à approuver rapidement (vérification unique pour tous).

Après la transformation ZK, tu peux toujours demander un congé (effectuer une transaction). Le système détecte que tu as des jours de congé restants et informe directement les dirigeants : « Cette personne a du congé », et les dirigeants font entièrement confiance au système pour ne pas se tromper (ZK). Ainsi, l'approbation des dirigeants est beaucoup plus rapide (vérification par tous).

C'est la raison pour laquelle Ethereum doit passer à la ZK.

Défis et cas de la cryptographie

Bien sûr, la quantité de travail nécessaire pour réaliser tout cela est énorme, et la difficulté de la cryptographie est également très élevée, c'est pourquoi Ethereum doit collaborer avec des équipes professionnelles.

Le protocole Brevis mentionné par Justin, chercheur à la Fondation Ethereum, est l'un des cas les plus avancés dans ce domaine.

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

Selon les données de test, avec une taille de bloc de 45M GAS sur Ethereum, Brevis utilise 64 GPU RTX 5090 et peut compléter 99,6 % de la preuve de bloc en 12 secondes, dont 96,8 % des blocs peuvent être prouvés en 10 secondes.

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

Bien que des GPU plus avancés (comme le H200 ou le B200) puissent générer des preuves plus rapidement, cela augmenterait considérablement le seuil d'accès. La conception actuelle de Brevis se situe exactement à cette limite.

Pourquoi le « taux de couverture de 10 secondes » est-il également crucial ? Parce que les blocs MEV sont généralement générés en 1 à 3 secondes, et que 10 secondes de temps de preuve comblent parfaitement l'intervalle de bloc de 12 secondes.

Résumé : La logique du chemin de la ZK-ification d'Ethereum

Pour améliorer les performances de L1 d'Ethereum, il est nécessaire d'augmenter la limite de GAS.

Pour augmenter en toute sécurité la limite de GAS, il est nécessaire de promouvoir la ZK.

Et pour réaliser élégamment la ZK (génération de preuves en moins de 10 secondes, coût matériel inférieur à 100 000 dollars), il est nécessaire d'avoir un effort commun de la cryptographie et de l'écosystème cryptographique.

ZK est la direction la plus complexe mais aussi la plus certaine dans la voie d'extension d'Ethereum.

Il ne s'agit pas seulement de performance, mais aussi de la solution ultime d'Ethereum pour rechercher un équilibre entre sécurité et décentralisation.