Pourquoi Ethereum a-t-il un besoin urgent de ZK-VM ?

Auteur : 0xTodd ; Source : X, @0x_Todd

Parmi les nombreuses idées d'extension d'Ethereum, le ZK est le plus difficile à discuter.

Dans l'ensemble du réseau, Vitalik Buterin et la fondation Ethereum parient le plus sur les ZK. Les ZK sont un peu comme le plus jeune fils d'Ethereum, celui qui reçoit le plus d'attention, mais dont l'avenir est le plus incertain.

Il y a quelques jours, la fondation Ethereum a de nouveau publié la feuille de route de Kohaku, qui est un ensemble de composants de base pour un portefeuille de confidentialité. La feuille de route souligne à nouveau que davantage de fonctionnalités nécessitent la mise en œuvre de ZK-EVM/ZK-VM.

Alors, pourquoi Ethereum a-t-il si désespérément besoin de ZK-VM ?

La réponse est, pour la performance, sans sacrifier la sécurité.

Nous avons déjà discuté d'un sujet, à savoir que la méthode la plus efficace pour améliorer les performances d'Ethereum est d'augmenter la limite de GAS, en d'autres termes, d'agrandir chaque bloc.

Cependant, augmenter la limite de GAS a un coût, des blocs trop grands sont un lourd fardeau pour les nœuds.

Le modèle de validation actuel d'Ethereum, appelé “validation complète par tous”, signifie que tous les nœuds doivent valider complètement chaque bloc. Cette approche est simple et directe, mais malheureusement, elle entraîne une trop grande redondance.

Parce que si le plafond de GAS est trop élevé, la charge de travail de chaque nœud devra également augmenter considérablement.

Il faut savoir que l'intervalle entre les blocs d'Ethereum est de 12 secondes, et il faut également prévoir du temps pour la propagation des blocs à l'échelle mondiale, sans oublier tous ces vieux pièges à MEV à gérer. En réalité, le temps dont dispose chaque validateur pour recevoir et valider un bloc est très court (environ 4 à 8 secondes), il est donc difficile d'effectuer de nombreuses vérifications.

Cependant, si l'ensemble de la couche 1 d'Ethereum est entièrement ZK, cela deviendra “une vérification pour tous”. Une fois qu'un bloc est assemblé, un ZK proof est d'abord effectué.

Comme tout le monde le sait, la preuve ZK est très lente, mais la vérification est extrêmement rapide. Ainsi, chaque bloc n'a besoin d'être ZK-isé qu'une seule fois, et tous les nœuds n'ont besoin que de vérifier rapidement si la preuve est correcte.

L'avantage de cela est que nous pouvons augmenter considérablement la limite de GAS, car peu importe à quel point nous l'augmentons, cela ne sera pas trop lourd pour les nœuds.

Faisons une analogie, auparavant, dans DingTalk, tu suivais un processus d'approbation pour demander un congé (envoyer une transaction), où chaque responsable (nœud) devait personnellement vérifier si tu avais encore des jours de congé restants (vérification complète par tous), et tout devait être approuvé.

Après la transformation ZK, vous devez toujours suivre le processus de demande de congé (envoyer une transaction). Le système découvre que vous avez des jours de congé restants et informe directement tous les responsables : “Cette personne a des congés”, et les responsables font entièrement confiance au système qui ne peut pas se tromper (ZK). Ensuite, l'approbation des responsables est beaucoup plus rapide (vérification pour tous).

C'est la raison pour laquelle Ethereum doit être ZKifié.

Mais ce volume de travail est considérable, car la cryptographie est très complexe, donc Ethereum doit collaborer avec d'autres équipes.

Alors quel type de travail une équipe tierce doit-elle effectuer ? Prenons l'exemple du protocole Brevis mentionné par Justin de la fondation Ethereum, qui est également le protocole ZK le plus rapide actuellement.

Brevis est une entreprise opérant dans le domaine des ZK-VM, et leur dernière technologie Pico Prism est actuellement la plus rapide pour produire des preuves ZK sous des conditions données.

Selon les informations divulguées, sur le bloc Ethereum avec une limite actuelle de 45M GAS, Brevis a utilisé 64 GPU RTX 5090. Lors des tests, 99,6 % des blocs ont été prouvés en moins de 12 secondes, et 96,8 % de la couverture de preuve a été réalisée en moins de 10 secondes.

Ces données sont impressionnantes.

Pour garantir la décentralisation, Ethereum exige que les dispositifs effectuant des preuves ZK ne dépassent pas 100 000 dollars.

Sinon, avoir plusieurs H200/B200 par personne serait certainement plus rapide, mais cela rendrait la barrière d'entrée trop élevée. Ces cartes graphiques Brevis sont juste coincées dans la tranche de 10 w millions de dollars.

De plus, pourquoi le taux de couverture de 10 secondes est-il également important ?

Parce qu'en général, les blocs MEV sont créés en 1 à 3 secondes, puis avec 10 secondes de preuve, cela remplit exactement 12 secondes, ce qui utilise parfaitement le temps. Donc, 12 secondes ne fonctionnent pas, il faut que le taux de couverture soit très élevé à 10 secondes.

Donc, Brevis équivaut à “recevoir la couronne de danseur roi lors d'un concours de danse avec des menottes”.

La technologie impressionnante de Brevis a fait des percées dans les clusters multi-GPU, mais il y a beaucoup de détails techniques là-bas. Nous en discuterons plus lentement dans un post séparé quand j'aurai le temps.

Enfin, revenons au sujet principal et faisons un résumé.

Pour que l'Ethereum puisse accélérer le L1, il faut augmenter la limite de GAS;

Pour augmenter la limite de GAS, il faut ZK.

Pour réussir une ZK élégante (preuve en moins de 10 secondes, équipement à moins de 10w dollars), il faut l'effort conjugué de la communauté cryptographique du cercle Crypto.