Compass Investments

En bref, des deux concepts, celui qui est le plus proche dans le temps est EIP-7864, sur lequel @gballet et ses collègues travaillent. Il s’agit de remplacer l’arbre hexadécimal Merkle Patricia actuel d’Ethereum par un arbre binaire doté d’une fonction de hachage plus performante.

Le schéma actuel de l’arbre hexadécimal a été développé pour répondre à d’autres priorités, et non pour la future preuve d’enjeu d’Ethereum. Le passage à un arbre binaire nous donnerait des branches de Merkle quatre fois plus courtes, car la structure binaire a une dépendance logarithmique à la taille de 32

fois

log(n)$, tandis que l’arbre hexadécimal a une dépendance de 512

fois

log(n) / 4$. La réduction de la longueur des branches rendra la vérification des clients beaucoup moins coûteuse et réduira les besoins en bande passante pour des outils comme Helios et PIR.

Passons maintenant aux changements au niveau de l’exécution. J’ai déjà mentionné l’abstraction de compte, le gaz multidimensionnel, BAL et ZK-EVM.

C’est là que commencent les véritables gains en termes d’efficacité de la preuve. L’amélioration de 3 à 4 fois due au raccourcissement des branches ne dépend pas du changement de la fonction de hachage, qui peut donner un gain supplémentaire de 3 fois avec blake3 au lieu de keccak, ou même de 100 fois avec la variante Poseidon, bien que Buterin mette en garde contre la nécessité de procéder à des ajustements de sécurité avant que Poseidon ne puisse être mis en œuvre.

La structure arborescente binaire introduit également le concept d’organisation du stockage en pages, combinant des cellules contiguës en pages de 64 à 256 emplacements, ce qui représente environ 2 à 8 Ko. L’en-tête du bloc et les 1 à 4 premiers Ko de code et de mémoire partagent la même page. Cela permet une efficacité par lot pour les contrats accédant aux emplacements initiaux de la mémoire, au lieu de payer pour chaque accès individuellement. Buterin estime que cela pourrait permettre d’économiser plus de 10 000 gaz par transaction pour les dApps qui chargent déjà des données à partir des premiers magasins, ce qui est le cas de la majorité des contrats actifs.

Les arbres binaires sont également plus faciles à coder et à valider.

La profondeur d’accès plus prévisible pour les grands et les petits contrats réduit la variation des coûts d’exécution, et la structure elle-même laisse logiquement de la place pour mettre en œuvre les métadonnées nécessaires pour gérer les changements d’état différés.

{Le deuxième concept est à plus long terme et, de l’aveu même de Buterin, doit encore faire l’objet d’un consensus. L’idée est que l’architecture EVM n’est pas la meilleure fondation pour une blockchain centrée sur les preuves. La remplacer par une VM plus appropriée, telle que RISC-V, résoudrait fondamentalement le problème, plutôt que de le masquer par une accumulation de précompilations et de solutions de contournement.

Les arguments de M. Buterin reposent sur quatre avantages du RISC-V par rapport à l’EVM.

Le premier est la performance d’exécution : RISC-V surpasse l’EVM au point que de nombreuses précompilations seront inutiles, car les calculs de base qui les nécessitent peuvent être effectués efficacement par la machine virtuelle elle-même. Le deuxième point concerne l’efficacité des preuves : Aujourd’hui, les preuves ZK sont créées sur RISC-V, ce qui signifie que les VM RISC-V sont nativement compatibles avec l’infrastructure de preuve existante.

Troisièmement, la vérification côté client : les VM RISC-V permettent aux utilisateurs de créer localement des preuves ZK de ce qui se passe lorsqu’on accède à leur compte avec un ensemble spécifique de données. Cela ouvre la voie à des scénarios de confidentialité et de vérification impossibles à réaliser pour les MVE sans ajouts externes. Et quatrièmement, la simplicité : l’interpréteur RISC-V ne représente que quelques centaines de lignes de code, ce qui est exactement ce qu’il faut pour une blockchain-VM.