Vitalik contre développeurs de premier plan : une table ronde virtuelle sur la guerre des machines virtuelles Web3
TechFlow SélectionTechFlow Sélection
Vitalik contre développeurs de premier plan : une table ronde virtuelle sur la guerre des machines virtuelles Web3
EVM cherche la compatibilité écosystémique, RISC-V se concentre sur l'efficacité matérielle, WASM adopte le développement multi-langage, MoveVM met l'accent sur la sécurité des actifs, tandis que FuelVM franchit les limites de performance.
Dédié à des analyses Web3 approfondiesChaque blockchain a ses propres points forts et récits uniques. Sur le plan technique, les modules de code des blockchains sont à peu près similaires : tous disposent de communication entre nœuds, de consensus et d'exécution. Toutefois, chacune choisit les technologies et algorithmes les mieux adaptés à ses besoins, notamment en matière d’algorithmes de consensus et de machines virtuelles au niveau d’exécution. Récemment, la volonté d'Ethereum de passer du bytecode EVM à l'ensemble d'instructions RISC-V a mis en lumière ce domaine technologique relativement discret qu’est la machine virtuelle.
Il y a quelques jours, j’ai compilé un article pédagogique sur RISC-V afin que chacun puisse comprendre son passé et son avenir.
EVM vers RISC-V ? Retour sur l’histoire de RISC-V et ses applications dans le domaine Web3
Aujourd’hui, je souhaite partager avec vous une vision plus complète et globale de la question des machines virtuelles. Je reconnais humblement que mes connaissances restent limitées sur le sujet. Pour contourner cette limite, j’ai compilé diverses réflexions et analyses provenant de grands spécialistes des machines virtuelles disponibles en ligne, afin que vous puissiez comparer leurs similitudes et différences.
En rassemblant ces matériaux, j’ai eu l’impression que ces échanges ressemblaient particulièrement à la période des « Cent Écoles » durant l’époque des Royaumes combattants en Chine. Inspiré, j’ai décidé de reformuler leurs propos sous la forme d’une table ronde virtuelle / Space, populaire aujourd’hui, afin de présenter une « table ronde virtuelle » mettant en avant cette dynamique de « débat pluraliste ». Après tout, les hommes nobles s’accordent sans se conformer.
Pour faciliter la compréhension rapide des arguments clés, voici un tableau comparatif structuré des caractéristiques essentielles des principales machines virtuelles Web3, synthétisé à partir des discussions approfondies de plus de 10 leaders techniques mentionnés dans le texte.
Couvre 9 types de solutions incluant RISC-V, WASM, EVM, etc., en matière d’architecture, performance et défis pratiques : (faites défiler horizontalement pour voir l’intégralité du tableau)
En 2024, la proposition de la communauté Ethereum visant à remplacer l’EVM par RISC-V a suscité un vif débat. Nous invitons donc virtuellement les concepteurs de VM issus de différentes écoles afin d’échanger sur les aspects fondamentaux de la technologie, l’adaptabilité aux écosystèmes, la compatibilité ZK, etc.
Modérateur : Bienvenue d’abord à @VitalikButerin[1], cofondateur d’Ethereum. L’EVM, machine virtuelle pionnière, est désormais bien connue. On sait que vous cherchez à innover davantage. Pouvez-vous nous en dire plus ?
@VitalikButerin : Bonjour à tous ! Je suis Vitalik, et certains internautes chinois m’appellent « petit V » (sourire). Comme vous le savez, j’ai récemment publié une proposition concernant le remplacement de l’EVM par RISC-V. Vous pouvez consulter le texte original sur le forum [2] (version chinoise [3]), donc je ne vais pas le répéter ici. Voici simplement quelques points clés :
• Remplacer l’EVM par RISC-V comme langage de machine virtuelle pour les contrats intelligents est une idée radicale – mais pourrait bien être la seule voie possible.
• Parmi les facteurs limitant l’extension d’Ethereum L1, l’efficacité d’exécution est l’un des principaux goulets d’étranglement. Nous devons améliorer l’efficacité et simplifier fortement la couche d’exécution.
• Les anciens contrats EVM continueront de fonctionner, avec une compatibilité bidirectionnelle complète avec les nouveaux contrats RISC-V. Plusieurs méthodes d’implémentation sont envisageables :
• La solution la moins disruptive consiste à supporter simultanément les deux machines virtuelles.
• Une méthode plus radicale serait de convertir les contrats EVM existants en appelant un interpréteur EVM écrit en RISC-V, exécutant ainsi leur code EVM actuel.
• Le protocole pourrait explicitement intégrer le concept d’« interpréteur de machine virtuelle », dont la logique serait écrite en RISC-V. L’EVM serait la première instance.
• À l’avenir, d’autres langages pourraient aussi être supportés (Move pourrait être une option).
• L’expérience de développement pourrait rester presque inchangée, voire imperceptible pour les développeurs.
• Nervos CKB VM a déjà ouvert la voie, étant fondamentalement une implémentation basée sur RISC-V [4].
Modérateur : Merci à @VitalikButerin pour avoir partagé les derniers plans d’Ethereum. Dans votre publication initiale, beaucoup ont exprimé leur soutien, tandis que d’autres ont estimé que la faisabilité méritait plus d’études. Puisque notre sujet porte sur la comparaison des forces et faiblesses des machines virtuelles, nous n’entrerons pas dans les détails de faisabilité liés à RISC-V. Nous avons toutefois invité plusieurs intervenants pertinents à participer à cette discussion.
Modérateur : Accueillons maintenant notre deuxième invité : @IAmNickDodson[5], fondateur et PDG de Fuel Network [6], ancien membre de ConsenSys ayant contribué au développement des infrastructures et outils d’Ethereum, profondément impliqué dans l’optimisation des clients Ethereum (comme Geth ou Parity), une personne expérimentée et influente en conception et implémentation de VM.
@IAmNickDodson : Tout d’abord, le message de Vitalik est enthousiasmant. Je travaille sur l’EVM depuis avant le lancement du réseau principal d’Ethereum, et je peux affirmer clairement – nous savions dès le départ qu’elle présentait des défauts, et ces problèmes persistent encore aujourd’hui. Mais on ne peut nier qu’elle est devenue la pierre angulaire pour construire des applications véritablement décentralisées, et nous lui sommes reconnaissants. [src[7]]
Modérateur : Pourquoi avoir choisi de développer FuelVM plutôt que d’adopter une solution existante ?
@IAmNickDodson : En concevant FuelVM, nous avons étudié diverses architectures : jeux d’instructions (ISA) comme MIPS, RISC-V, x86, ARM ; machines virtuelles comme WASM ; et VM dédiées aux blockchains : EVM, BitcoinScript, MoveVM, SVM, etc. Chacune présente des atouts, mais aucune ne répondait pleinement à nos besoins. Je reviendrai plus tard sur mes conclusions. Avant cela, je vous invite, chers spectateurs, à réfléchir à trois questions fondamentales : L’architecture est-elle conçue spécifiquement pour les scénarios blockchain ? Peut-elle maintenir des performances dans un environnement de mesure hostile ? Représente-t-elle une réelle amélioration par rapport à l’EVM ? [src[8]]
Modérateur : Merci à nos invités pour leurs présentations. Passons maintenant à l’analyse de certains projets/technologies représentatifs, selon l’ordre d’étude de @IAmNickDodson. N’hésitez pas à donner votre avis ou à intervenir si vous avez une opinion différente.
MIPS/RISC-V
@IAmNickDodson : Ces jeux d’instructions CPU ont été initialement conçus pour les premiers microprocesseurs et dispositifs embarqués.
Avantages : Architecture simple, documentation complète, écosystème open source, possibilité de compilation en code machine natif (parfois avec traitement supplémentaire) et support multilingue (Rust/Go, etc.).
Inconvénients : Sont essentiellement des jeux d’instructions CPU (non des architectures de calcul virtuel), MIPS est trop basique, nécessitant plus d’opcodes pour accomplir des tâches réalisables en une seule instruction sur x86 ou une VM spécialisée (voir section CISC ci-dessous), ne tiennent pas compte de la comptabilisation dans un environnement hostile, ne sont pas optimisés pour les blockchains, et offrent une efficacité médiocre pour les preuves à divulgation nulle (cf. recherches de Starkware/Valida).
Même si la technologie ZK réduit la nécessité de mesure par les nœuds, dans les cas de haut débit, des preuves précalculées/partagées restent nécessaires, rendant toujours utile un mécanisme anti-DoS (la comptabilisation garde donc sa valeur). [src[9]]
Georgios Konstantopoulos[10] (associé et CTO chez Paradigm[11]) : Si vous aimez la proposition de @VitalikButerin, vous allez adorer R55, que nous développons progressivement depuis quelques mois... [src[13]]
0xpedro.eth/acc[14] : R55 permet d’écrire des contrats intelligents en Rust pur, exécutés via RISC-V dans les clients Ethereum. Habituellement, Solidity est compilé en bytecode EVM, mais R55 compile Rust en instructions RISC-V, un framework open source qui libère le potentiel d’optimisation matérielle. Utiliser Rust sur Ethereum ? Intéressant, mais délicat. RISC-V ne connaît pas nativement l’état Ethereum (stockage, appels, etc.), donc R55 ajoute des appels système. Via l’instruction ecall de RISC-V, les contrats Rust peuvent lire le stockage (ex. SLOAD), appeler d’autres contrats ou envoyer des logs – connectant ainsi Rust à Ethereum de façon transparente.
R55 est encore en développement, nécessitant des ajustements sur le gaz et la sécurité, mais l’avenir est prometteur : rollups ou chaînes applicatives pourraient exécuter des contrats Rust natifs, ou zkEVM pourrait tirer parti de RISC-V pour les opérations cryptographiques. À mon sens, la sécurité et la rapidité de Rust en font un atout pour Ethereum. R55 déclenchera-t-il une vague de développeurs Rust sur Ethereum ? Peut-être trop tôt pour le dire, mais cela mérite attention. [src[15]]
Dave Rauchwerk[16] : @VitalikButerin c’est une excellente idée. Un avantage clé de RISC-V est son extensibilité explicite. Nous devrions étudier la définition d’un ensemble d’instructions RISC-V personnalisées, dédiées à accélérer les opcodes EVM critiques. La nature ouverte de RISC-V permet des implémentations matérielles spécialisées (ASIC, FPGA) au-delà des processeurs génériques. Cela ouvre la voie à une augmentation significative du TPS L1 en accélérant directement dans le silicium la logique centrale EVM, potentiellement des ordres de grandeur plus rapide que les méthodes logicielles actuelles (interprétation ou JIT).
Sur la vérifiabilité et la sécurité : comparé aux ISA traditionnels complexes, la conception modulaire et sobre de RISC-V la rend plus facile à vérifier formellement. Un cœur RISC-V vérifié formellement exécutant la logique EVM offre des garanties renforcées sur le comportement à l’exécution, crucial pour la sécurité des contrats intelligents à haute valeur. RISC-V pourrait être enrichi par des instructions personnalisées centrées sur l’EVM, offrant une voie attrayante vers un L1 plus performant, sécurisé et évolutif.
Par ailleurs, il convient de comparer les implémentations EVM existantes avec des modèles logiciels potentiels RISC-V. revive/PolkaVM semble très bon – il cible actuellement seulement RV32EM, sujet à discussion. [src[17]]
Koute[18] (responsable de PolkaVM chez Parity Technologies[19]) : Puisque PolkaVM est mentionné, permettez-moi d’expliquer en détail ce qu’est PolkaVM et comment il fonctionne.
PolkaVM prend actuellement en charge riscv64emac avec l’extension Zbb, mais contrairement à la plupart (toutes ?) autres VM RISC-V, il ne peut pas exécuter tels quels les binaires RISC-V (ce n’est en réalité pas une VM RISC-V !). Hors ligne, nous extrayons le binaire ELF RISC-V classique, construit avec un compilateur standard, puis le convertissons en un bytecode personnalisé plus contraint et plus efficace, conçu spécifiquement pour une VM (plutôt que pour du matériel natif comme RISC-V). Notre objectif est de minimiser autant que possible la complexité de la VM elle-même (qui doit tourner en chaîne), en transférant la complexité vers des outils hors chaîne, et en améliorant la sécurité en supprimant des fonctionnalités inutiles (par exemple, dans RISC-V d’origine, vous pouvez sauter à n’importe quelle adresse ; dans le bytecode PolkaVM, l’espace d’adresses code est entièrement virtualisé, vous ne pouvez sauter n’importe où, et le bytecode n’est même pas chargé en mémoire accessible au programme).
Sur le plan des performances, nous sommes très proches des performances brutes [1] ; aussi rapides que les meilleures VM WASM *wasmtime*, mais avec un temps de recompilation O(n) garanti, et une vitesse de recompilation en code natif accrue de plusieurs centaines de fois. Plus précisément, recompiler un programme à partir du bytecode PolkaVM brut en code natif est beaucoup plus rapide que de récupérer un artefact recompilé mis en cache via son hachage (autrement dit, recompiler un programme est plus rapide que de calculer son hachage), et cela *sans* sacrifier les performances d’exécution.
Nous utilisons principalement RISC-V non pas parce que c’est un excellent bytecode pour une VM (en fait, ce n’est pas si bon), mais parce que c’est simple, bien supporté et relativement facile à convertir en autre chose, ce qui nous permet d’avoir le meilleur des deux mondes : compatibilité logicielle exceptionnelle (vous pouvez utiliser des compilateurs et langages existants, par exemple j’ai récemment porté Quake sur PolkaVM), tout en bénéficiant d’un bytecode personnalisé et optimisé (vitesse de compilation extrême, performances proches du natif, simplicité et personnalisation). [src[20]]
dilrong[21] : @VitalikButerin affirme que remplacer la machine virtuelle Ethereum (EVM) par RISC-V pourrait améliorer l’efficacité des preuves à divulgation nulle (ZK) de 50 à 100 fois. Pourtant, RISC-V est-il vraiment supérieur ? L’EVM fonctionne stably depuis environ neuf ans, une plateforme éprouvée, alors que RISC-V manque d’expérience pratique dans les environnements d’exécution blockchain. Bien que PolkaVM utilise RISC-V, je pense qu’il n’est pas suffisamment validé, car il n’a pas encore été rigoureusement testé sur mainnet.
L’EVM est spécifiquement optimisée pour l’exécution de contrats intelligents, tandis que RISC-V est une architecture générale, potentiellement dépourvue d’optimisations sur mesure pour les cas d’usage blockchain. Bien que la polyvalence de RISC-V permette d’utiliser des langages d’autres blockchains, Vitalik lui-même indique qu’il est préférable d’améliorer Solidity existant. Transitionner tout l’écosystème vers une nouvelle architecture représente un défi colossal.
Implémenter RISC-V en logiciel entraîne inévitablement une baisse de performance. L’exécution logicielle via émulateur soulève des doutes sur sa capacité à traiter efficacement les tâches. D’un autre côté, adopter du matériel RISC-V impliquerait un coût de transition énorme. Je pense que le ZK-EVM satisfait déjà aux besoins actuels. Compte tenu des coûts de développement, de l’ampleur du travail nécessaire et des erreurs imprévues possibles, remplacer l’EVM par RISC-V ne semble pas une solution viable.
Bien que la transition vers RISC-V puisse apporter des bénéfices potentiels, je pense qu’améliorer le ZK-EVM et optimiser l’EVM existant sont des alternatives plus pratiques et stables. [src[22]]
Eduardo Bart[23] (développeur principal du VM Cartesi[24]) : En tant que développeur activement impliqué dans Cartesi Machine[25], une machine virtuelle RISC-V pour applications blockchain, je souhaite partager quelques arguments en faveur de l’exploration de RISC-V pour la couche d’exécution d’Ethereum.
Je pense qu’un des principaux avantages de RISC-V est l’accès immédiat à des outils matures et à un écosystème développé. Contrairement à un environnement entièrement personnalisé, RISC-V permet aux développeurs (et aux protocoles) de tirer parti de décennies d’avancées accumulées autour de compilateurs comme GCC et LLVM, de débogueurs, de bibliothèques, voire d’OS complets comme Linux. Comparé à des toolchains nouvelles et non éprouvées, cela abaisse considérablement la barrière d’entrée pour les développeurs et réduit potentiellement les risques de bugs dans les compilateurs. Cela correspond bien à l’objectif de permettre à des contrats écrits en Rust, voire en C++, d’être compilés via des backends standards ciblant Ethereum. Pour ceux qui craignent des bugs dans LLVM ou GCC, il est possible de renforcer la sécurité avec des compilateurs vérifiés formellement comme CompCert[26], désormais capable de cibler RISC-V. À plus grande échelle, on pourrait même exécuter des applications sur un noyau OS RISC-V vérifié formellement (comme seL4[27]) au sein d’une machine virtuelle couvrant la spécification ISA privilégiée de RISC-V (comme celle que je développe), ce qui ouvre la voie à des applications complexes nécessitant un environnement OS.
Les inquiétudes sur les performances ne sont pas infondées, mais elles peuvent être résolues. Selon mon expérience, RISC-V, correctement implémenté, ne sacrifie pas les performances d’exécution. Bien que les opérations u256 se décomposent naturellement en plusieurs instructions, en pratique, dans une VM RISC-V bien optimisée, ce coût devrait avoir un impact mineur dans la plupart des cas. De plus, des techniques d’optimisation au niveau de la VM peuvent réduire fortement ces coûts, car l’ISA RISC-V est suffisamment extensible pour ajouter des extensions personnalisées dédiées à la blockchain, optimisant ainsi les opérations cryptographiques courantes (ex. Keccak256).
Je crois qu’établir la future couche d’exécution sur une ISA standardisée, ouverte et bien supportée comme RISC-V fournira une base solide. Cela ouvre une voie pour exploiter l’écosystème logiciel existant, simplifiant potentiellement l’expérience développeur et profitant des progrès futurs du matériel RISC-V.
Bien que le chemin soit complexe, je suis convaincu que les avantages potentiels de RISC-V en termes d’évolutivité, de maturité des outils et de maintenabilité à long terme en font une direction très valable pour les environnements d’exécution blockchain futurs. Actuellement, de nombreuses VM RISC-V existantes dans le domaine blockchain démontrent qu’il est possible de réaliser des implémentations RISC-V robustes et prêtes à la production. Notamment, je pense que Cartesi Machine illustre la puissance d’une ISA standard et ouverte. Il s’agit d’un simulateur RISC-V stable et haute performance, implémentant l’ISA standard RV64GC, capable d’exécuter toute la pile logicielle Linux et des binaires ELF RV64GC non modifiés. Crucialement, il est entièrement déterministe, y compris pour les opérations à virgule flottante. Pour ceux qui souhaitent expérimenter ses capacités, je recommande WebCM[28], un terminal serverless exécutant directement dans le navigateur un Linux virtuel via une machine RISC-V simulée par un simulateur Cartesi compilé en WebAssembly.
Actuellement, les propositions L1 se concentrent sur les preuves à divulgation nulle, tandis que Cartesi utilise actuellement des preuves de fraude interactives, exploitant l’exécution déterministe et les preuves Merkle d’état pour la validation on-chain. Bien que les mécanismes de vérification diffèrent, Cartesi confirme qu’il est faisable et pertinent de construire un environnement d’exécution vérifiable et déterministe sur RISC-V.
Bien sûr, intégrer directement RISC-V dans L1 et le prouver en ZK pose des défis uniques et importants, notamment en matière de comptabilisation du gaz, de définition précise des appels système pour les interactions d’état, et d’optimisation des circuits ZK pour les instructions RISC-V. Les performances dans le contexte spécifique de la preuve ZK doivent également être étudiées en profondeur. Heureusement, de nombreux projets de VM RISC-V à divulgation nulle travaillent déjà sur ces aspects.
Concernant la stratégie d’implémentation, je pense qu’une « méthode radicale » mérite d’être sérieusement envisagée : définir un protocole intégrant le concept d’interpréteur de machine virtuelle compilé en RISC-V. Cette approche permettrait de garder la VM RISC-V centrale d’Ethereum minimaliste et simple, tout en restant assez flexible pour accueillir différents interpréteurs de VM au-delà de l’EVM, offrant ainsi plus de liberté aux développeurs dans le développement de VM.
En résumé, je crois que l’utilisation d’une norme comme RISC-V offre d’importants avantages en termes d’outils, de familiarité des développeurs, de flexibilité et même de potentiel d’accélération matérielle à long terme. Mon expérience avec Cartesi Machine renforce l’idée que RISC-V constitue une base puissante et viable pour le calcul blockchain vérifiable de nouvelle génération. Voir cette technologie sérieusement envisagée pour la couche d’exécution centrale d’Ethereum me remplit d’enthousiasme. [src[29]]
Xuejie Xiao[30] : Bonjour à tous, je suis le concepteur initial et mainteneur actuel de CKB-VM chez Nervos. Pour Nervos, le choix de CKB-VM découle d’un raisonnement premier principe : nous voulions un bac à sable simple, sécurisé, rapide, pouvant fonctionner légèrement sur des CPU commerciaux. Il s’est avéré que les jeux d’instructions CPU étaient le meilleur choix, et parmi eux, RISC-V s’est distingué. Bien qu’il existe d’autres cœurs RISC CPU open source, RISC-V attire le plus d’attention, ce qui signifie plus de développeurs impliqués dans les toolchains. Pour nous, c’est un avantage énorme.
Lorsqu’on compare EVM et RISC-V, je propose d’aller plus loin : comparons-les soit avec précompilés inclus, soit sans. Ne comparons pas EVM avec précompilés à RISC-V sans, ou vice versa. À mon sens, cette comparaison serait inappropriée. En supposant une implémentation RISC-V JIT ou AOT, ou l’introduction d’instructions AVX, nous pourrions atteindre des performances comparables à celles d’EVM sans précompilés utilisant une VM RISC-V sans précompilés.
À notre connaissance, RISC-V était la meilleure solution il y a 7 ans, et le restera dans l’avenir prévisible. Si quelqu’un dit que RISC-V est une solution matérielle, très bien, nous l’avons implémenté en logiciel pur, et il répond parfaitement à nos besoins. En ce sens, nous sommes satisfaits de la situation actuelle et poursuivrons cette voie. [src[31]]
Modérateur : La CKB-Virtual Machine (CKB-VM) est une machine virtuelle basée sur le jeu d’instructions RISC-V, utilisée pour exécuter des contrats intelligents sur Nervos CKB, écrite en Rust. Ceux intéressés peuvent lire l’article de @Xuejie Xiao datant de 2018 : An Introduction to Nervos CKB-VM[32], pour découvrir leur réflexion de l’époque, un excellent partage !
ZKM[33] : Le plan RISC-V proposé par @VitalikButerin pour Ethereum est très audacieux, mais la maturité et les traditions de MIPS en font un outsider séduisant – un jeu d’instructions fixe particulièrement adapté aux preuves ZK à faible latence. MIPS a piloté des systèmes critiques pendant 40 ans – Ethereum pourrait exploiter cette stabilité pour obtenir une efficacité similaire (voire supérieure), tout en réduisant les risques liés à l’adoption d’une ISA encore immature et trop vantée comme RISC-V. Puisque MIPS est déjà validé, pourquoi miser sur les douleurs de croissance de RISC-V ? [src[34]]
WebAssembly (WASM)
@IAmNickDodson : Conçu initialement pour exécuter du code arbitraire dans les navigateurs/environnements isolés : Avantages : Support multilingue/environnemental, compilable en code natif, spécification open source claire, ajout ultérieur de la comptabilisation (mais avec surcoût), Inconvénients : Architecture basée sur pile (les recherches académiques indiquent des performances inférieures, mais à nuancer), pas conçu spécifiquement pour blockchain, la comptabilisation est un correctif tardif nuisant aux performances, expérience de débogage très mauvaise.
Théoriquement, WASM est un bon choix, mais en pratique, le débogage est extrêmement pénible. Plusieurs équipes entièrement axées sur WASM avec lesquelles nous avons parlé regrettent leur choix. En comparaison, RISC-V/MIPS sont plus faciles à comprendre, ce qui explique peut-être pourquoi des équipes comme Succinct/RISC0 les ont choisies. [src[35]]
Peter Kieltyka[36] (cofondateur de Sequence[37]) : @VitalikButerin Je sais que c’est un peu tiré par les cheveux, mais envisagez EVM+/Stylus développé par Offchain Labs comme couche d’exécution L1 future. Il est totalement compatible avec le bytecode EVM, s’exécute dans une VM WASM, supporte tout langage compatible WASM (ex. Rust), offre une performance nettement supérieure, tout en conservant une interopérabilité complète au runtime avec les contrats bytecode EVM. Cela semble être la voie de mise à niveau la plus simple tout en maintenant la compatibilité. [src[38]]
Xuejie Xiao[39] : Beaucoup pensent que WASM est le choix idéal pour les VM blockchain, principalement parce que WASM est conçu pour l’implémentation logicielle (si cela a un sens, passons-y). Savez-vous qu’avant WASM, un sous-ensemble de JavaScript, asm.js, a connu une certaine popularité ? asm.js a ensuite évolué vers WASM, devenant mystérieusement bien plus volumineux que la vision initiale d’asm.js (je dirais franchement que WASM ressemble aujourd’hui plus à une JVM proprement conçue qu’à asm.js). Mais n’oublions pas l’objectif initial d’asm.js : les gens désiraient un IR logiciel pouvant mapper de façon déterministe les instructions CPU natives, plutôt que le JIT qui y parvient 90 % du temps. Si RISC-V peut atteindre cet objectif, je pense qu’il convient parfaitement comme machine virtuelle logicielle. [src[40]]
Hazel Hu[41] (Delphinus Lab[42]) : Bien que @VitalikButerin soutienne fermement RISC-V, les machines virtuelles ZK n’ont pas qu’une seule voie technologique. Les VM ZK ne sont pas exclusives à ETH, c’est un domaine indépendant, potentiellement plus vaste que l’écosystème ETH. ETH a besoin de ZKVM, mais ZKVM ne se limite pas à l’écosystème Ethereum. [src[43]]
Les systèmes ZK utilisent des RISC, jeux d’instructions réduits, avec deux options : premièrement, créer un jeu d’instructions personnalisé comme Cairo (courbe d’apprentissage trop abrupte), ou utiliser un jeu d’instructions existant. RISC-V en fait partie. Des projets comme @RiscZero[44], @SuccinctLabs[45], @NexusLabs[46] et Jolt soutenu par @a16z[47] sont des VM ZK basées sur RISC-V.
Dès 2018, l’écosystème Ethereum a lancé le projet eWASM. L’inventeur de l’EVM, @gavofyork[48], a affirmé la faisabilité du remplacement de l’EVM par WASM. Le fondateur de Polygon, @sandeepnailwal[49], est également un fervent partisan de WASM. Pourtant, eWASM n’a pas été largement adopté, en raison de la complexité technique, des changements de priorité et de l’émergence des solutions L2, conduisant à son report dans les feuilles de route subséquentes.
Après la publication de la proposition par @VitalikButerin, le fondateur de Zebra @shumochu[50], le chercheur associé de 1kx @_weidai[51], etc., ont souligné que WASM pourrait être plus adapté que RISC-V à la couche d’exécution Ethereum, pour les raisons suivantes :
Processus plus simple : RISC-V est conçu pour l’implémentation matérielle, pas comme représentation intermédiaire. S’il est utilisé comme couche d’exécution pour contrats Ethereum, une couche VM supplémentaire devra gérer la consommation de gaz et contrôler le flux d’exécution, augmentant la complexité.
Convivialité pour l’analyse statique : WASM n’a pas d’instruction de saut, sa structure de code est simple, facilitant la vérification des propriétés du contrat.
Large support linguistique : Les développeurs peuvent compiler en WASM à partir de presque tous les langages de programmation principaux, réduisant considérablement la courbe d’apprentissage. Le fondateur de Miden, @bobbinth[52], suggère en outre que pour une meilleure compatibilité ZK, on pourrait concevoir un jeu d’instructions meilleur que RISC-V, ou utiliser le modèle de composants WASM. [src[53]]
Notre laboratoire @Delphinuslab[54] a publié la première VM ZKWASM open source. Bien que nous ayons actuellement seulement un SDK Solidity, en réalité, le règlement des contrats ZKVM peut se faire sur n’importe quelle chaîne, et à l’avenir, cela pourrait s’étendre à des chaînes hétérogènes comme Solana, Sui, etc.
À quoi peut servir une VM ZKWASM ?
1. Permettre à davantage de développeurs d’entrer dans le monde blockchain avec leur langage de programmation familier, sans obliger chacun à apprendre Solidity (ou des langages blockchain plus complexes et niche) ou Rust
2. Permettre à davantage d’applications web2.5 de migrer instantanément sur blockchain. Si cela fonctionne complètement, des milliers d’applications navigateur pourraient être rapidement déployées sur blockchain
3. Briser le triangle impossible, atteindre un équilibre entre décentralisation, efficacité et sécurité. [src[55]]
x86/ARM
@IAmNickDodson : Ces deux jeux d’instructions CPU ne sont pas open source : ARM appartient à l’architecture RISC (réduite), x86 à l’architecture CISC (complexe). Avec l’évolution du matériel CPU, les deux sont devenus extrêmement complexes. Notons que bien que CISC soit progressivement remplacé par RISC dans le domaine CPU en raison de sa complexité, en blockchain, CISC présente plutôt un avantage. [src[56]]
Xuejie Xiao[57] : x64 est trop lourd (quand nous avons essayé RISC-V pour la première fois, quelqu’un utilisait x64 pour construire une VM blockchain !), et ARM pourrait poser des problèmes de licence, ou pas. [src[58]]
Bitcoin Script
@IAmNickDodson : Première VM blockchain, conçue spécifiquement pour Bitcoin :
Avantages : Spécialement conçue pour les blockchains et le modèle de transaction Bitcoin, adaptée à un environnement hostile, supporte des opérations basiques comme la multisignature
Inconvénients : Fonctionnalités extrêmement limitées, gravement limité par la capacité de traitement du réseau Bitcoin.
Nous avons hérité de Bitcoin Script le paradigme puissant de P2SH (paiement au hash de script) – la programmation conditionnelle. Ce paradigme de programme élaguable (supprimé des nœuds complets après exécution) permet des scénarios riches comme les échanges hors chaîne, les portefeuilles multisignatures, les enchères. L’architecture Bitcoin nous enseigne : la conception de la VM doit être profondément coordonnée avec le modèle de transaction. [src[59]]
MoveVM
@IAmNickDodson : VM dédiée à la blockchain développée par l’équipe Meta, mettant l’accent sur la sécurité :
Avantages : Conception native blockchain, support de la comptabilisation dans un environnement hostile, langage dédié Move
Inconvénients : Sacrifice important de la flexibilité d’état pour la sécurité, trop orienté RISC (voir analyse précédente), fragmentation de l’écosystème (variantes incompatibles entre SUI/Aptos).
L’écosystème Move a presque stagné en 2020-21. Nous avons abandonné son adoption car nous refusions d’être prisonniers d’une architecture empêchant l’innovation, et ses caractéristiques de « sécurité » sont surtout un habillage de système RISC, incapable d’empêcher une mauvaise écriture de code. À l’époque, la vérification formelle ne convenait qu’à des méthodes simples, pas aux applications complètes, avec un rapport coût-bénéfice très faible. [src[60]]
EVM
@IAmNickDodson : L’équivalent blockchain du PHP, supportant des contrats intelligents représentant des milliers de milliards de valeur :
Avantages : Conception native blockchain, mécanisme de comptabilisation complet, compatibilité totale de l’écosystème, langage Solidity éprouvé
Inconvénients : Conception à mot de 256 bits, support uniquement des appels/contrats, absence de fonctionnalité script, absence de programmation conditionnelle (pas d’équivalent P2SH), modèle de transaction trop simplifié, inefficacité (le mot de 256 bits et la conception des opcodes entraînent de nombreux gaspillages de calcul), conception fortement étatique rendant l’accès au stockage un goulot d’étranglement.
Bien que certaines équipes affirment avoir résolu les problèmes via de nouvelles bases de données ou schémas d’accès à l’état, fondamentalement, ces calculs auraient pu être évités. L’EVM convient pour construire rapidement un écosystème, mais manque d’innovation du point de vue du modèle de transaction et de l’espace de conception. L’appel de Vitalik reflète peut-être cette prise de conscience. [src[61]]
Alex Vlasov[62] : Il n’est pas clair que RISC-V soit vraiment meilleur que l’EVM. L’EVM est basée sur pile, donc son fichier de registres est petit. L’EVM manipule des nombres de 256 bits, ce qui peut poser problème si des valeurs plus petites dominent. Toutefois, le prouveur a accès à la trajectoire d’exécution réelle, il peut donc choisir pour les petites valeurs des implémentations plus légères (par exemple, la décomposition en octets d’une valeur de 32 bits occupe moins de lignes que celle d’une valeur de 256 bits). [src[63]]
Un autre aspect est le coût de la vérification formelle des contrats intelligents. Le jeu d’instructions (ISA) de l’EVM est plus limité que celui de RISC-V, donc la F/V sera globalement plus complexe. Les contrats intelligents RISC-V contiendront généralement plus de boucles et plus d’opérations mémoire, ce qui pose problème pour la F/V.
Par exemple, une étude (/www.cs.utexas.edu/~isil/solis.pdf[64]) montre qu’environ un cinquième des contrats intelligents EVM contient une ou plusieurs boucles. Puisque l’EVM manipule des valeurs de 256 bits, davantage de boucles seront nécessaires dans le code RISC-V. Même avec déroulage de boucle, cela entraînera des requêtes SMT plus grandes.
RISC-V possède un modèle mémoire plus riche, donc davantage d’opérations mémoire (ex. EVM dispose de 1024 piles de 256 bits, contre 16-32 registres de 32/64 bits pour EVM). Ainsi, l’aliasing (deux expressions syntaxiquement différentes pointant vers la même position mémoire) sera un problème plus grave. Cela affectera à son tour l’analyse statique, comme la reconstruction de graphe d’appels, l’analyse de pointage, etc.
Je prévois que le raisonnement formel sur des contrats intelligents RISC-V avec boucles/aliasing sera plus difficile que sur des contrats EVM. [src[65]]
SVM
@IAmNickDodson : La machine virtuelle Solana a récemment gagné en notoriété :
Avantages : Conception native blockchain, support de la comptabilisation dans un environnement hostile, compilable en code natif, conception haute performance
Inconvénients : Architecture complexe et difficile à comprendre, mauvaise expérience de développement en Rust et autres langages, absence de langage dédié mature.
Nous n’avons pas choisi SVM principalement à cause de son hypothèse de modèle de transaction – une conception similaire à Ethereum, priorisant la vitesse plutôt que les règlements complexes multi-parties, ce qui ne correspond pas à notre modèle de transaction prévu. [src[66]]
CairoVM
Akash Balasubramani (responsable écosystème chez StarkWare) : @IAmNickDodson excellente analyse ! Encore mieux avec CairoVM. [src[67]]
@IAmNickDodson : Non inclus car lors de notre recherche en 2020/21, il n’était pas encore sur notre radar. Je suis un grand admirateur de Cairo et de la technologie STARK. [src[68]]
Eli Ben-Sasson (cofondateur de StarkWare) : @IAmNickDodson excellente discussion ! Ma seule suggestion : ajouter l’analyse de Cairo. Permettez-moi d’ajouter : Avantages : conçu spécifiquement pour blockchain + efficacité zkSTARK, sécurité de type linéaire, comptabilisation du gaz efficace (Sierra), Inconvénients : notoriété / maturité des outils plus faibles :) [src[69]]
Modérateur : Merci pour vos commentaires éclairants. Quelle est votre conclusion finale ? Quelles idées pouvez-vous partager avec nous ?
@IAmNickDodson : Après avoir étudié toutes les VM, nous avons réalisé que l’importance de la machine virtuelle elle-même est surestimée. Théoriquement, toutes ces VM (sauf BitcoinScript) peuvent accomplir les calculs requis avec des efficacités différentes. Ce qui est vraiment crucial, c’est la conception conjointe entre la VM et le modèle de transaction. De nombreuses chaînes se concentrent excessivement sur la VM en négligeant le modèle de transaction – qui est pourtant au cœur du comportement blockchain. [src[70]]
L’originalité de FuelVM réside précisément là, ce sont les optimisations combinées de FuelVM [src[71]] :
• Efficacité mémoire (contexte mémoire partagé réduisant les copies)
• Utilisation intelligente des registres et de la mémoire (ex. placer la transaction complète en mémoire visible pour l’autonomie à l’exécution)
• Réduction extrême des accès IO
• Renforcement des capacités au niveau transaction (la transaction fait plus, la VM fait moins)
• Modèle de transaction combinant accès à l’état et transferts multi-actifs/multi-conditions/multi-modes
• Équilibre optimal entre CISC et RISC
• Pas d’arbre d’état global (modèle UTXO empêchant naturellement les doubles dépenses par retour temporel)
• Tous les opcodes optimisés pour l’efficacité de la comptabilisation
• Support de divers types de programmes comme la programmation conditionnelle par prédicats
• Langage associé Sway alliant performance de Rust et expérience de développement de Solidity
La croyance traditionnelle veut que la VM blockchain doive viser des instructions minimalistes (pour des raisons de sécurité et de compilation en code natif). Mais le problème est que, dans un scénario de vérification optimiste, chaque opération doit être comptabilisée. Plus la VM est simple, plus elle nécessite d’opcodes pour accomplir une même fonction, augmentant ainsi la charge de calcul de comptabilisation en chaîne. FuelVM choisit donc de conce
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
