Les développeurs réfutent Vitalik : les hypothèses sont fausses, et RISC-V n’est pas le meilleur choix

Cet article provient de : Compilation du développeur Ethereum levochka.eth

|Odaily Planet Daily (@OdailyChina) ; @azuma_eth Note de l’éditeur

:

Hier, le co-fondateur d’Ethereum, Vitalik, a publié un article radical sur la mise à niveau de la couche d’exécution d’Ethereum (voir « Vitalik’s Radical New Article : Execution Layer Scaling « Doesn’t Break, Doesn’t Stand », EVM Must Be Iterated in the Future), mentionnant qu’il espère le remplacer par RISC-V EVM en tant que langage de machine virtuelle pour les contrats intelligents.

Dès que cet article est sorti, il a immédiatement provoqué un tollé dans la communauté des développeurs d’Ethereum, et de nombreux gros bonnets techniques ont exprimé des points de vue différents sur le plan. Peu de temps après la publication de l’article, le développeur Ethereum de niveau 1, levochka.eth, a écrit un long article sous l’article original pour réfuter l’argument de Vitalik selon lequel Vitalik avait fait de mauvaises hypothèses sur le système de preuve et ses performances, et que RISC-V pourrait ne pas être le meilleur choix car il ne pouvait pas équilibrer « évolutivité » et « maintenabilité ».

Ce qui suit est l’article original publié sur levochka.eth, compilé par le quotidien Odaily.

S’il vous plaît, ne faites pas ça.

Ce plan n’a pas de sens, car vous faites de mauvaises hypothèses sur la preuve du système et de ses performances.

Hypothèse de validation

D’après ce que je comprends, les principaux arguments en faveur de ce schéma sont la « scalabilité » et la « maintenabilité ».

Tout d’abord, je veux parler de la maintenabilité.

En fait, toutes les zk-VM RISC-V nécessitent des « précompilations » pour gérer les opérations de calcul intensif. La liste précompilée de SP 1 se trouve dans la documentation de Succinct, et vous constaterez qu’elle couvre presque tous les opcodes « computationnels » importants de l’EVM.

Par conséquent, toutes les modifications apportées aux primitives cryptographiques de la couche de base nécessitent l’écriture et l’audit de nouveaux « circuits » pour ces précompilations, ce qui constitue une limitation sérieuse.

En effet, si les performances sont suffisamment bonnes, il peut être relativement facile d’assurer la maintenance de la partie « non-EVM » du client. Je ne suis pas sûr que ce soit assez bon, mais je suis moins confiant dans cette partie pour les raisons suivantes :

• le « calcul de l’arbre d’état » peut en effet être considérablement accéléré avec une pré-compilation amicale comme Poséidon.

• Cependant, il n’est pas clair si la « désérialisation » peut être gérée de manière élégante et maintenable.
  

• De plus, certains détails délicats (tels que le comptage du gaz et diverses vérifications) peuvent relever du « temps d’évaluation du bloc », mais devraient en fait être classés comme des pièces « non EVM », qui ont tendance à être plus vulnérables à la pression de maintenance.

Deuxièmement, la partie sur l’évolutivité.

Je dois répéter qu’il est impossible pour RISC-V de gérer les charges EVM sans utiliser la précompilation, absolument pas.

Ainsi, l’affirmation dans le texte original selon laquelle « le temps de preuve final sera dominé par l’opération de précompilation actuelle » est techniquement correcte, mais elle est trop optimiste - elle suppose qu’il n’y aura pas de précompilation à l’avenir, alors qu’en fait (dans ce scénario futur) la précompilation existera toujours, et est exactement la même que les opcodes à calcul intensif dans l’EVM (tels que les signatures, les hachages et éventuellement les analogues de grande taille).

Il est difficile de juger l’exemple de Fibonacci sans entrer dans les détails les plus subtils, mais les avantages viennent au moins en partie :

• la différence entre l’interprétation et la surcharge d’exécution ;

• Déroulement cyclique (réduisant le « flux de contrôle » de RISC-V, il n’est pas certain que Solidity puisse être mis en œuvre, mais même un seul opcode peut toujours générer un grand nombre d’accès au flux de contrôle/mémoire en raison de la surcharge d’interprétation) ;

• utiliser des types de données plus petits ;

Ici, je voudrais souligner que pour réaliser les avantages du point 1 et du point 2, il faut éliminer la « surcharge d’interprétation ». C’est conforme à la philosophie de RISC-V, mais ce n’est pas du RISC-V dont nous discutons actuellement, mais plutôt d’un « ( ?)RISC-V » similaire - il nécessite certaines capacités supplémentaires, telles que la prise en charge des concepts de contrat.

Voici le problème

, donc, il y a quelques problèmes ici.

• Pour améliorer la maintenabilité, vous avez besoin d’un RISC-V (avec précompilation) qui compile l’EVM - c’est à peu près tout.

• Pour améliorer l’évolutivité, quelque chose de complètement différent est nécessaire : une nouvelle architecture qui pourrait être similaire à RISC-V et qui comprend le concept de « contrats », qui est compatible avec les limitations d’exécution d’Ethereum et qui peut exécuter le code du contrat directement (sans la « surcharge d’interprétation »).

Je suppose maintenant que vous faites référence au deuxième cas (puisque le reste de l’article semble l’impliquer). Je dois attirer votre attention sur le fait que tout le code en dehors de cet environnement sera toujours écrit dans le langage RISC-V zkVM actuel, ce qui a un impact significatif sur la maintenance.

Comme alternative,

nous pouvons compiler le bytecode à partir de l’opcode EVM de haut niveau. Le compilateur est chargé de s’assurer que le constructeur reste invariant, par exemple en ne subissant pas de « dépassement de pile ». J’aimerais que cela soit montré dans un EVM normal. Des SNARK correctement compilés peuvent être fournis avec des instructions de déploiement de contrat.

Nous pouvons également construire une « preuve formelle » qui prouve que certains invariants sont conservés. Pour autant que je sache, cette approche (et non la « virtualisation ») a été utilisée dans certains contextes de navigateur. En générant des SNARK de cette preuve formelle, vous pouvez obtenir des résultats similaires. 

Bien sûr, l’option la plus simple est de mordre la balle et de faire ......

Construire une MMU minimale « chaînée »,

que vous pouvez exprimer implicitement dans l’article, mais permettez-moi de vous avertir que si vous voulez éliminer la surcharge de virtualisation, vous devez exécuter le code compilé directement - ce qui signifie que vous devez d’une manière ou d’une autre empêcher le contrat (maintenant exécutable) d’écrire dans la mémoire du noyau (et non une implémentation EVM).

Par conséquent, nous avons besoin d’une sorte d'"unité de gestion de la mémoire » (MMU). Le mécanisme de pagination des ordinateurs traditionnels n’est peut-être pas nécessaire car l’espace mémoire « physique » est presque infini. Cette MMU doit être aussi légère que possible (car elle est au même niveau d’abstraction que l’architecture elle-même), mais certaines caractéristiques telles que l’atomicité des transactions peuvent être déplacées vers cette couche.

À ce stade, l’EVM prouvable devient le programme du noyau s’exécutant sur cette architecture.

Il

est intéressant de noter que, dans toutes ces conditions, la meilleure « architecture de jeu d’instructions » (ISA) pour cette tâche n’est peut-être pas RISC-V, mais quelque chose de similaire à EOF-EVM pour les raisons suivantes :

• Les « petits » opcodes entraînent en fait beaucoup d’accès à la mémoire, ce qui est difficile à gérer efficacement pour les méthodes d’attestation existantes.

• Pour réduire la surcharge de branchement, nous avons montré comment prouver du code de « sauts statiques » (EOF) avec des performances de niveau précompilation dans notre récent article, Morgana.

Ma suggestion est de construire une nouvelle architecture conviviale avec une MMU minimale qui permet au contrat de s’exécuter en tant qu’exécutable distinct. Je ne pense pas que ce soit censé être RISC-V, mais plutôt un nouvel ISA optimisé pour les limitations du protocole SNARK, et même un ISA qui hérite partiellement d’un sous-ensemble d’opcodes EVM pourrait être meilleur - comme nous le savons, la précompilation est là pour rester, que nous le voulions ou non, donc RISC-V n’apporte aucune simplification ici.