Dans l'évolution récente de la technologie Blockchain, un terme qui était à l'origine populaire uniquement dans le cercle des ingénieurs en chipsets est devenu le nouveau chouchou des développeurs Blockchain : RISC-V.
Le 20 avril 2025, le fondateur d'Ethereum, Vitalik Buterin, a publié un article sur le forum communautaire Ethereum Magicians, proposant une suggestion exploratoire pour remplacer la machine virtuelle EVM utilisée depuis longtemps par Ethereum par RISC-V.
Pendant ce temps, Polkadot a discrètement mis en ligne un environnement d'exécution de contrats intelligents prenant en charge RISC-V sur le réseau de test AseetHub Westend, et les développeurs peuvent même continuer à utiliser Solidity pour essayer de développer sur Polkadot, mais les contrats s'exécuteront finalement sur un tout nouveau moteur d'exécution appelé PolkaVM.
Est-ce une coïncidence ? Un jeu d'instructions open source initialement conçu pour les puces, pourquoi a-t-il réussi à "percer" dans le monde de la Blockchain ?
Ethereum et Polkadot misent tous deux sur RISC-V, qu'est-ce qui les attire vraiment ?
De la puce au Blockchain, pourquoi RISC-V est-il apparu ?
L'« âme » de chaque appareil de calcul est son architecture d'ensemble d'instructions (ISA), c'est-à-dire le langage par lequel le logiciel dit au matériel « ce que je veux que tu fasses ». Le CPU Intel que nous connaissons utilise l'architecture x86, tandis que les puces M des ordinateurs Apple utilisent l'architecture ARM.
RISC-V est une norme d'architecture open source et gratuite, que tout le monde peut utiliser pour concevoir des processeurs, sans avoir à payer de frais de licence à Intel ou ARM.
Il s'agissait à l'origine d'un projet académique de l'Université de Californie à Berkeley, et de plus en plus d'entreprises de puces reconnaissent aujourd'hui cette norme d'architecture : structure simple, flexible et modulable, utilisable en open source, et capable d'éviter les risques liés à la géopolitique.
Mais quelle est la relation entre RISC-V et Blockchain ?
La machine virtuelle (VM) est le "cerveau d'exécution" de chaque blockchain, tous les contrats doivent y être exécutés. Cependant, les systèmes de machine virtuelle les plus courants, comme l'EVM d'Ethereum, le WASM de Polkadot et le BPF de Solana, présentent tous des problèmes évidents :
· Architecture obsolète, comme EVM qui est un modèle en pile conçu en 2015, difficile à aligner avec les CPU modernes
· Sécurité faible, l'architecture actuelle est difficile à vérifier formellement, ne peut pas réaliser une véritable sécurité du code au niveau mathématique.
· Le support multilingue est limité, les développeurs ne peuvent pas choisir librement la langue, ils doivent uniquement dépendre passivement de la pile Solidity.
Donc, lorsque cette architecture "très moderne" qu'est RISC-V se présente devant les ingénieurs en Blockchain, leur instinct est : pouvons-nous aussi "RISC-Viser" la machine virtuelle de la Blockchain ?
Comparaison entre le modèle de calcul à pile et le modèle de calcul basé sur les registres
Choix d'Ethereum : concevoir la prochaine génération de machines virtuelles ZK natives à partir du concept.
Les idées de Vitalik sont très dans le style de la communauté Ethereum : il ne s'agit pas d'une simple optimisation, mais d'une redéfinition à un niveau philosophique.
Selon sa description sur le forum Ethereum Magicians, son idée est la suivante : à l'avenir, la couche d'exécution d'Ethereum devrait être extrêmement simple, sécurisée et mathématiquement prouvable. L'EVM est déjà trop complexe et ne peut pas être modifié. Il vaudrait mieux utiliser RISC-V pour construire une nouvelle VM vérifiable.
La structure RISC-V est claire et le comportement d'exécution est prévisible, ce qui le rend particulièrement adapté à la conversion en circuits de preuve à zéro connaissance ; à l'avenir, il pourrait également être associé au compilateur LLVM (bien que de nombreux commentaires sur des bugs aient été observés), pour développer des contrats dans des langages plus riches, tels que Rust et C ; plus important encore, il peut devenir la base de la couche d'exécution pour construire une "chaîne ZK native".
Bien sûr, tout cela est encore au stade de l'idée. La communauté Ethereum n'a pas encore de plan concret, mais la direction est claire : il ne s'agit pas seulement de changer de machine virtuelle, mais de se préparer pour un Blockchain évolutif, sécurisé et fiable à l'avenir.
Le chemin de Polkadot : un réalisme piloté par des ingénieurs, commençant par le remplacement de la couche sous-jacente.
Contrairement à la "conception conceptuelle" d'Ethereum, Polkadot a choisi une autre voie pragmatique.
Dès 2023, Jan Bujak, ingénieur principal chez Parity, a commencé à explorer des alternatives à WASM et a finalement choisi RISC-V, lançant ensuite le projet PolkaVM.
La démarche de Polkadot est très claire :
· La langue reste inchangée, continuer à utiliser Solidity
· Outils inchangés, Remix, Ethers.js, MetaMask sont tous compatibles
· Ajustement du chemin de compilation, compilation de Solidity en code binaire RISC-V à l'aide de l'outil revive
· Fonctionnant finalement sur la nouvelle machine virtuelle PolkaVM, offrant une capacité d'exécution plus efficace, plus sûre et plus vérifiable.
Cela signifie que l'expérience des développeurs reste essentiellement la même, mais que l'exécution sous-jacente a été complètement renouvelée. De WebAssembly à RISC-V, de la pile à l'architecture registre, de l'exécution traditionnelle à une exécution compatible avec ZK, c'est une "révolution silencieuse".
Actuellement, PolkaVM peut fonctionner sur le réseau de test Westend d'Asset Hub, avec pour objectif de lancer Polkadot au troisième trimestre 2025.
Perspective du développeur : votre code reste inchangé, mais le sous-jacent se reconstruit discrètement.
Bien que Ethereum et Polkadot aient des approches différentes envers RISC-V, l'un étant en avance sur la vision et l'autre ayant déjà été mis en œuvre, les signaux qu'ils envoient aux développeurs sont étonnamment cohérents : ce n'est pas une révolution du "niveau d'écriture", mais une reconstruction des infrastructures de base.
Pour les développeurs, peu importe sur quelle chaîne vous vous trouvez, vous ne ressentirez presque pas de déconnexion à court terme : vous pouvez toujours écrire des contrats en Solidity, continuer à utiliser des outils familiers comme Remix, Ethers.js, MetaMask, et le processus de déploiement est essentiellement le même, tout reste comme avant.
Mais au niveau sous-jacent invisible, le moteur d'exécution a déjà changé de cœur !
Sur Polkadot, les contrats Solidity peuvent désormais être compilés en bytecode RISC-V via l'outil revive et exécutés sur la nouvelle machine virtuelle PolkaVM. Par rapport à WASM et à l'EVM traditionnel, PolkaVM offre de meilleures performances en termes d'efficacité d'exécution et de facturation des ressources, en particulier pour le contrôle des coûts d'exécution des contrats complexes.
Dans la conception technique d'Ethereum, RISC-V est également considéré comme la base la plus appropriée pour une "chaîne natale ZK". Vitalik a clairement indiqué que si l'on veut réaliser une exécution logique sur chaîne véritablement prouvable mathématiquement à l'avenir, l'EVM est un obstacle incontournable, tandis que RISC-V, avec sa structure claire et son comportement prévisible, est un chemin de solution idéal.
Plus important encore, ce changement d'architecture va bien au-delà d'une simple amélioration des performances - un changement fondamental dans le paradigme de développement sur la Blockchain est en train de se produire discrètement.
La sécurité passera du « regard humain » au « mathématiquement vérifiable ». Chaque comportement d’instruction de RISC-V peut être formellement modélisé, ce qui est hors de portée de l’EVM. Cela signifie que l’avenir de la sécurité des contrats ne reposera plus sur des audits année après année, mais sur l’approbation mathématique de « Je ne peux pas me tromper » à l’étape de la compilation. Vous pouvez écrire du code qui ne nécessite pas de confiance, simplement parce que « c’est prouvable ».
La connaissance zéro passe de la niche à la norme. Auparavant, écrire des contrats ZK était une compétence réservée aux ingénieurs avancés. La structure de RISC-V est intrinsèquement adaptée au zk, avec un processus d'exécution régulier et une possibilité de conversion facile en circuits, ce qui en fait un backend idéal pour des systèmes tels que zkEVM. Une fois que le changement de niveau inférieur est effectué, les contrats ZK pourraient ne plus être une option, mais devenir le "mode de sécurité par défaut" des contrats intelligents.
L'ère des contrats intelligents multilingues est également sur le point de commencer. RISC-V est connecté à l'écosystème d'outils LLVM, ce qui signifie que des langages comme Rust, C, etc. peuvent être naturellement compilés en formats d'exécution sur la chaîne. Vous n'êtes plus limité par Solidity, à l'avenir, écrire des contrats intelligents sera aussi contrôlable et libre que d'écrire des modules système. Polkadot est déjà en train de promouvoir la migration du langage ink! vers RISC-V, ce qui montre qu'un monde de contrats coexistant dans différents langages est une réalité, pas une illusion.
Écrit à la fin
Peu importe sur quelle chaîne vous êtes maintenant, que ce soit avec Solidity ou Rust, que vous écriviez des contrats sur Remix ou que vous utilisiez Ethers.js pour le front-end, vous finirez par réaliser que l'évolution de la machine virtuelle n'est pas destinée à changer votre façon d'écrire du code, mais à faire en sorte que chaque ligne de code que vous écrivez - s'exécute plus rapidement, soit plus stable, ait une logique plus claire et soit plus sûre et fiable.
Ces changements pourraient ne pas être immédiatement visibles, tout comme la reconstruction des fondations n'est jamais ce qui est vu en premier. Mais cela finira par avoir un impact : les futurs contrats intelligents deviendront plus puissants, plus libres et plus dignes de confiance, sans que vous ne vous en rendiez compte.
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Pourquoi Polkadot et Vitalik ont-ils tous deux choisi RISC-V ?
Dans l'évolution récente de la technologie Blockchain, un terme qui était à l'origine populaire uniquement dans le cercle des ingénieurs en chipsets est devenu le nouveau chouchou des développeurs Blockchain : RISC-V.
Le 20 avril 2025, le fondateur d'Ethereum, Vitalik Buterin, a publié un article sur le forum communautaire Ethereum Magicians, proposant une suggestion exploratoire pour remplacer la machine virtuelle EVM utilisée depuis longtemps par Ethereum par RISC-V.
Pendant ce temps, Polkadot a discrètement mis en ligne un environnement d'exécution de contrats intelligents prenant en charge RISC-V sur le réseau de test AseetHub Westend, et les développeurs peuvent même continuer à utiliser Solidity pour essayer de développer sur Polkadot, mais les contrats s'exécuteront finalement sur un tout nouveau moteur d'exécution appelé PolkaVM.
Est-ce une coïncidence ? Un jeu d'instructions open source initialement conçu pour les puces, pourquoi a-t-il réussi à "percer" dans le monde de la Blockchain ?
Ethereum et Polkadot misent tous deux sur RISC-V, qu'est-ce qui les attire vraiment ?
De la puce au Blockchain, pourquoi RISC-V est-il apparu ?
L'« âme » de chaque appareil de calcul est son architecture d'ensemble d'instructions (ISA), c'est-à-dire le langage par lequel le logiciel dit au matériel « ce que je veux que tu fasses ». Le CPU Intel que nous connaissons utilise l'architecture x86, tandis que les puces M des ordinateurs Apple utilisent l'architecture ARM.
RISC-V est une norme d'architecture open source et gratuite, que tout le monde peut utiliser pour concevoir des processeurs, sans avoir à payer de frais de licence à Intel ou ARM.
Il s'agissait à l'origine d'un projet académique de l'Université de Californie à Berkeley, et de plus en plus d'entreprises de puces reconnaissent aujourd'hui cette norme d'architecture : structure simple, flexible et modulable, utilisable en open source, et capable d'éviter les risques liés à la géopolitique.
Mais quelle est la relation entre RISC-V et Blockchain ?
La machine virtuelle (VM) est le "cerveau d'exécution" de chaque blockchain, tous les contrats doivent y être exécutés. Cependant, les systèmes de machine virtuelle les plus courants, comme l'EVM d'Ethereum, le WASM de Polkadot et le BPF de Solana, présentent tous des problèmes évidents :
· Architecture obsolète, comme EVM qui est un modèle en pile conçu en 2015, difficile à aligner avec les CPU modernes · Sécurité faible, l'architecture actuelle est difficile à vérifier formellement, ne peut pas réaliser une véritable sécurité du code au niveau mathématique. · Le support multilingue est limité, les développeurs ne peuvent pas choisir librement la langue, ils doivent uniquement dépendre passivement de la pile Solidity.
Donc, lorsque cette architecture "très moderne" qu'est RISC-V se présente devant les ingénieurs en Blockchain, leur instinct est : pouvons-nous aussi "RISC-Viser" la machine virtuelle de la Blockchain ?
Comparaison entre le modèle de calcul à pile et le modèle de calcul basé sur les registres Choix d'Ethereum : concevoir la prochaine génération de machines virtuelles ZK natives à partir du concept.
Les idées de Vitalik sont très dans le style de la communauté Ethereum : il ne s'agit pas d'une simple optimisation, mais d'une redéfinition à un niveau philosophique.
Selon sa description sur le forum Ethereum Magicians, son idée est la suivante : à l'avenir, la couche d'exécution d'Ethereum devrait être extrêmement simple, sécurisée et mathématiquement prouvable. L'EVM est déjà trop complexe et ne peut pas être modifié. Il vaudrait mieux utiliser RISC-V pour construire une nouvelle VM vérifiable.
La structure RISC-V est claire et le comportement d'exécution est prévisible, ce qui le rend particulièrement adapté à la conversion en circuits de preuve à zéro connaissance ; à l'avenir, il pourrait également être associé au compilateur LLVM (bien que de nombreux commentaires sur des bugs aient été observés), pour développer des contrats dans des langages plus riches, tels que Rust et C ; plus important encore, il peut devenir la base de la couche d'exécution pour construire une "chaîne ZK native".
Bien sûr, tout cela est encore au stade de l'idée. La communauté Ethereum n'a pas encore de plan concret, mais la direction est claire : il ne s'agit pas seulement de changer de machine virtuelle, mais de se préparer pour un Blockchain évolutif, sécurisé et fiable à l'avenir.
Le chemin de Polkadot : un réalisme piloté par des ingénieurs, commençant par le remplacement de la couche sous-jacente.
Contrairement à la "conception conceptuelle" d'Ethereum, Polkadot a choisi une autre voie pragmatique.
Dès 2023, Jan Bujak, ingénieur principal chez Parity, a commencé à explorer des alternatives à WASM et a finalement choisi RISC-V, lançant ensuite le projet PolkaVM. La démarche de Polkadot est très claire :
· La langue reste inchangée, continuer à utiliser Solidity · Outils inchangés, Remix, Ethers.js, MetaMask sont tous compatibles · Ajustement du chemin de compilation, compilation de Solidity en code binaire RISC-V à l'aide de l'outil revive · Fonctionnant finalement sur la nouvelle machine virtuelle PolkaVM, offrant une capacité d'exécution plus efficace, plus sûre et plus vérifiable.
Cela signifie que l'expérience des développeurs reste essentiellement la même, mais que l'exécution sous-jacente a été complètement renouvelée. De WebAssembly à RISC-V, de la pile à l'architecture registre, de l'exécution traditionnelle à une exécution compatible avec ZK, c'est une "révolution silencieuse".
Actuellement, PolkaVM peut fonctionner sur le réseau de test Westend d'Asset Hub, avec pour objectif de lancer Polkadot au troisième trimestre 2025. Perspective du développeur : votre code reste inchangé, mais le sous-jacent se reconstruit discrètement.
Bien que Ethereum et Polkadot aient des approches différentes envers RISC-V, l'un étant en avance sur la vision et l'autre ayant déjà été mis en œuvre, les signaux qu'ils envoient aux développeurs sont étonnamment cohérents : ce n'est pas une révolution du "niveau d'écriture", mais une reconstruction des infrastructures de base.
Pour les développeurs, peu importe sur quelle chaîne vous vous trouvez, vous ne ressentirez presque pas de déconnexion à court terme : vous pouvez toujours écrire des contrats en Solidity, continuer à utiliser des outils familiers comme Remix, Ethers.js, MetaMask, et le processus de déploiement est essentiellement le même, tout reste comme avant.
Mais au niveau sous-jacent invisible, le moteur d'exécution a déjà changé de cœur !
Sur Polkadot, les contrats Solidity peuvent désormais être compilés en bytecode RISC-V via l'outil revive et exécutés sur la nouvelle machine virtuelle PolkaVM. Par rapport à WASM et à l'EVM traditionnel, PolkaVM offre de meilleures performances en termes d'efficacité d'exécution et de facturation des ressources, en particulier pour le contrôle des coûts d'exécution des contrats complexes.
Dans la conception technique d'Ethereum, RISC-V est également considéré comme la base la plus appropriée pour une "chaîne natale ZK". Vitalik a clairement indiqué que si l'on veut réaliser une exécution logique sur chaîne véritablement prouvable mathématiquement à l'avenir, l'EVM est un obstacle incontournable, tandis que RISC-V, avec sa structure claire et son comportement prévisible, est un chemin de solution idéal.
Plus important encore, ce changement d'architecture va bien au-delà d'une simple amélioration des performances - un changement fondamental dans le paradigme de développement sur la Blockchain est en train de se produire discrètement.
La sécurité passera du « regard humain » au « mathématiquement vérifiable ». Chaque comportement d’instruction de RISC-V peut être formellement modélisé, ce qui est hors de portée de l’EVM. Cela signifie que l’avenir de la sécurité des contrats ne reposera plus sur des audits année après année, mais sur l’approbation mathématique de « Je ne peux pas me tromper » à l’étape de la compilation. Vous pouvez écrire du code qui ne nécessite pas de confiance, simplement parce que « c’est prouvable ».
La connaissance zéro passe de la niche à la norme. Auparavant, écrire des contrats ZK était une compétence réservée aux ingénieurs avancés. La structure de RISC-V est intrinsèquement adaptée au zk, avec un processus d'exécution régulier et une possibilité de conversion facile en circuits, ce qui en fait un backend idéal pour des systèmes tels que zkEVM. Une fois que le changement de niveau inférieur est effectué, les contrats ZK pourraient ne plus être une option, mais devenir le "mode de sécurité par défaut" des contrats intelligents.
L'ère des contrats intelligents multilingues est également sur le point de commencer. RISC-V est connecté à l'écosystème d'outils LLVM, ce qui signifie que des langages comme Rust, C, etc. peuvent être naturellement compilés en formats d'exécution sur la chaîne. Vous n'êtes plus limité par Solidity, à l'avenir, écrire des contrats intelligents sera aussi contrôlable et libre que d'écrire des modules système. Polkadot est déjà en train de promouvoir la migration du langage ink! vers RISC-V, ce qui montre qu'un monde de contrats coexistant dans différents langages est une réalité, pas une illusion.
Écrit à la fin
Peu importe sur quelle chaîne vous êtes maintenant, que ce soit avec Solidity ou Rust, que vous écriviez des contrats sur Remix ou que vous utilisiez Ethers.js pour le front-end, vous finirez par réaliser que l'évolution de la machine virtuelle n'est pas destinée à changer votre façon d'écrire du code, mais à faire en sorte que chaque ligne de code que vous écrivez - s'exécute plus rapidement, soit plus stable, ait une logique plus claire et soit plus sûre et fiable.
Ces changements pourraient ne pas être immédiatement visibles, tout comme la reconstruction des fondations n'est jamais ce qui est vu en premier. Mais cela finira par avoir un impact : les futurs contrats intelligents deviendront plus puissants, plus libres et plus dignes de confiance, sans que vous ne vous en rendiez compte.
Lien de référence de cet article :