Compass Investments

Quatre spécialistes du développement Arbitrum d’Offchain Labs ne sont pas d’accord avec la position de Vitalik Buterin sur la mise en œuvre de l’architecture d’instructions RISC-V (ISA) pour le niveau d’exécution d’Ethereum.

Selon eux, WASM semble être une meilleure solution à long terme que RISC-V pour le format de contrat intelligent L1 d’Ethereum, ou “ISA de livraison”.

Offchain Labs, un développeur clé de solutions de la couche 2 d’Ethereum Arbitrum, s’est prononcé contre la proposition de Vitalik Buterin de déplacer la couche d’exécution d’Ethereum vers RISC-V, en publiant une analyse technique détaillée qui plaide en faveur de la supériorité de WebAssembly (WASM) sur le long terme.

Dans un article publié le 20 novembre sur Ethereum Research, quatre experts d’Offchain Labs affirment que si RISC-V est actuellement performant pour générer des confirmations ZK, cela n’en fait pas le choix optimal pour déposer et stocker des contrats intelligents sur le réseau Ethereum.

Le cofondateur d’Ethereum, M. Buterin, a suggéré dans un post d’avril sur Ethereum Magicians que le bytecode de la machine virtuelle Ethereum soit remplacé par l’architecture ouverte RISC-V (prononcée “risk-five”), arguant qu’elle pourrait potentiellement réduire le coût des preuves ZK dans la chaîne jusqu’à cent fois dans certains cas.

ous partageons ces objectifs, mais nous remettons en question la conclusion infondée de Vitalik selon laquelle la même ISA peut être idéale à la fois pour les preuves ZK et la livraison des contrats intelligents.

Mario Alvarez, Matteo Campanelli, Tzahi Siedenberg et Daniel Lumi notent.

Séparation de la livraison et de la preuve ?

La thèse principale de l’équipe est qu’il devrait y avoir une séparation entre dISA (dISA) – le format de téléchargement des contrats sur le réseau – et pISA (pISA), le format utilisé par les machines virtuelles ZK. Ils estiment que ces fonctions ne devraient pas être combinées.

Les blocs Arbitrum, y compris les contrats intelligents Stylus basés sur le WASM, subissent une vérification ZK par le biais de la compilation du WASM en RISC-V et d’une preuve d’exécution ultérieure sur le RISC-V.

ous sommes aujourd’hui en mesure de réaliser des preuves de blockchain réelles ZK proof-of-stake sur une blockchain qui utilise WASM comme dISA, en appliquant ZK-VM basé sur RISC-V comme côté serveur.

L’équipe est sceptique quant à la perspective de RISC-V comme point final du développement de ZK-VM, soulignant les changements rapides dans le domaine des preuves. Le récent passage de la version 32 bits à la version 64 bits de RISC-V souligne cette incertitude.

La fixation de RISC-V sur L1 pourrait lier Ethereum à une technologie de preuve de concept particulière, alors que de meilleures alternatives émergent, avertissent-ils, tandis que les ZK-VM basés sur WASM, tels que Ligetron de Ligero, démontrent déjà des avantages que les ISA basés sur le matériel pourraient ne pas être en mesure d’égaler.

Entre-temps, le coût de la preuve de concept ZK est tombé à environ 0,025 $ par bloc Ethereum et continue de baisser, ce qui rend l’optimisation ciblée de l’efficacité de la preuve de concept moins prioritaire, affirment les chercheurs.

Même si L1 exigeait plusieurs preuves ZK par bloc, ces coûts seraient négligeables par rapport aux frais de gaz et de MEV qu’un constructeur de blocs pourrait recevoir.

–

–

-, écrivent-ils.

L’équipe souligne la conception structurée de WASM, qui facilite les modifications et l’optimisation du code sans compromettre la compatibilité avec les contrats existants. En outre, WASM fonctionne bien sur du matériel standard, alors que la plupart des nœuds Ethereum ne disposent pas de processeurs RISC-V, ce qui nécessite une émulation.

Les capacités de validation de WASM garantissent la sécurité des types et préviennent les vulnérabilités, et sa boîte à outils mature a été testée dans des milliards de scénarios d’exécution.

ous pensons que WASM peut devenir une sorte de protocole Internet pour les contrats intelligents, agissant comme un intermédiaire idéal entre les différents langages de code source utilisés pour créer des contrats intelligents et les différentes solutions de serveur utilisées pour les exécuter et les valider.