Dans l'évolution récente de la technologie blockchain, un terme qui était à l'origine populaire uniquement dans le cercle des ingénieurs en puces est devenu le nouveau chouchou des développeurs blockchain : RISC-V.
Le 20 avril 2025, le fondateur d'Ethereum, Vitalik Buterin, a publié un message 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.
Et pendant ce temps, Polkadot a discrètement lancé sur le réseau de test AseetHub Westend un environnement d'exécution de contrats intelligents prenant en charge RISC-V. 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 ? Pourquoi un jeu d’instructions open-source, qui a été créé à l’origine pour la conception de puces, a-t-il « brisé la boucle » dans le monde de la blockchain ?
Ethereum et Polkadot parient sur RISC-V, mais que cherchent-ils derrière ?
Pourquoi RISC-V émerge-t-il de nulle part, des puces à la blockchain ?
L'« âme » de chaque dispositif de calcul est son architecture d'ensemble d'instructions (ISA), c'est-à-dire la langue par laquelle le logiciel dit au matériel « ce que je veux que tu fasses ». Les CPU Intel que nous connaissons utilisent 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 CPU sans avoir à payer de redevances à 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 adhèrent à cette norme d'architecture : structure simple, flexible et modulable, utilisable en open source, tout en évitant les risques liés à la géopolitique.
Mais quelle est la relation entre RISC-V et la blockchain ?
Une 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 dominants actuels, tels que l'EVM d'Ethereum, le WASM de Polkadot et le BPF de Solana, présentent certains problèmes évidents :
Architecture obsolète, comme l'EVM qui est un modèle en pile conçu en 2015, difficile à aligner avec les CPU modernes.
Sécurité médiocre, l’architecture existante est difficile à vérifier formellement, et il est impossible d’obtenir 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 l'architecture "très moderne" RISC-V se présente devant les ingénieurs blockchain, leur intuition est : pouvons-nous aussi "RISC-Viser" la machine virtuelle de la blockchain ?
Comparaison des modèles de calcul à pile et à registre
Choix d'Ethereum : Concevoir la prochaine génération de machine virtuelle native ZK à partir du concept
Les idées de Vitalik sont très dans le style de la communauté Ethereum : pas une simple optimisation, mais une re-conception au niveau philosophique.
Selon sa description sur le forum Ethereum Magicians, son idée est la suivante : la couche d'exécution d'Ethereum à l'avenir devrait être extrêmement simplifiée, sécurisée et mathématiquement prouvable. Or, l'EVM est déjà trop complexe et ne peut plus être modifiée. Il vaudrait mieux utiliser RISC-V pour construire une nouvelle VM vérifiable.
RISC-V a une structure claire et un comportement d’exécution prévisible, ce qui le rend idéal pour la traduction en circuits de preuve à divulgation nulle de connaissance ; À l’avenir, il pourrait également fonctionner avec le compilateur LLVM (bien que j’aie vu beaucoup de commentaires sur les bogues) pour développer des contrats dans des langages plus riches tels que Rust et C ; Plus important encore, il peut être la base de la couche d’exécution pour la construction de la « chaîne native ZK ».
Bien sûr, tout cela en 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 à une blockchain évolutive, sécurisée et digne de confiance pour l'avenir.
Le chemin de Polkadot : un réalisme axé sur les ingénieurs, commençant par le remplacement des couches sous-jacentes
Contrairement à la "conception conceptuelle" d'Ethereum, Polkadot a choisi une autre voie pragmatique.
Dès 2023, l'ingénieur principal de Parity, Jan Bujak, a commencé à explorer des alternatives à WASM et a finalement choisi RISC-V, lançant ensuite le projet PolkaVM.
L’approche de Polkadot est simple :
Langue inchangée, continuez à utiliser Solidity
Les outils restent les mêmes, Remix, Ethers.js et MetaMask sont tous compatibles.
Ajustement du chemin de compilation, compilation de Solidity en bytecode RISC-V via l’outil de relance
Exécuté sur la nouvelle machine virtuelle PolkaVM, offrant des capacités d'exécution plus efficaces, plus sécurisées et plus vérifiables.
Cela signifie que l'expérience des développeurs reste essentiellement inchangée, mais que l'exécution sous-jacente a été complètement renouvelée. De WebAssembly à RISC-V, de l'architecture à pile à l'architecture à registre, de l'exécution traditionnelle à une exécution favorable aux 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 des développeurs : votre code reste inchangé, mais le sous-jacent se restructure silencieusement
Alors qu’Ethereum et Polkadot ont emprunté des chemins différents vers RISC-V, l’un en avance sur la vision et l’autre déjà sur le terrain, leur message aux développeurs est étonnamment cohérent : il ne s’agit pas d’un changement de « couche d’écriture », mais d’une refonte de l’infrastructure sous-jacente.
Pour les développeurs, peu importe sur quelle chaîne vous vous trouvez, il est presque impossible de ressentir une rupture à 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 reste fondamentalement le même, tout est comme avant.
Mais dans les couches invisibles, le moteur d'exécution a déjà changé de cœur !
Sur Polkadot, les contrats Solidity peuvent être compilés en code byte RISC-V à l'aide de l'outil revive et exécutés sur la nouvelle machine virtuelle PolkaVM. Comparé à WASM et à l'EVM traditionnel, PolkaVM offre de meilleures performances en matière 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 native 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, constitue une solution idéale.
Plus important encore, ce changement de l'architecture ne se limite pas à une simple amélioration des performances - un changement fondamental des paradigmes de développement sur la chaîne est en train de se produire discrètement.
La sécurité passera d'un « contrôle humain » à une « vérification mathématique ». Chaque comportement d'instruction de RISC-V peut être modélisé formellement, ce qui est hors de portée de l'EVM. Cela signifie que la sécurité des contrats à l'avenir ne dépendra plus des audits répétés chaque année, mais pourra obtenir une validation mathématique de « je ne ferai pas d'erreurs » dès la phase de compilation. Vous pouvez écrire du code qui ne nécessite pas de confiance, simplement parce qu'« il peut être prouvé ».
Le zero-knowledge est passé d’une niche à une valeur par défaut. Dans le passé, la rédaction de contrats ZK était une compétence que seuls les ingénieurs seniors pouvaient maîtriser. La structure de RISC-V est intrinsèquement compatible avec zk, avec un processus d’exécution bien organisé et des circuits faciles à tourner, ce qui en fait un backend idéal pour des systèmes tels que zkEVM. Une fois le basculement sous-jacent terminé, le contrat ZK peut ne plus être une option, mais deviendra le « mode de sécurité par défaut » du contrat intelligent.
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 tels que Rust et C peuvent naturellement être compilés dans des formats d’exécution on-chain. Vous n’êtes plus limité par Solidity, et l’écriture de contrats intelligents à l’avenir sera aussi contrôlable et flexible que l’écriture de modules système. Polkadot pousse déjà l’encre ! La migration des langues vers RISC-V montre que le monde contractuel où différentes langues coexistent est une réalité, pas un fantasme.
Écrit en dernier
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 des machines virtuelles n'est pas destinée à changer votre manière d'écrire du code, mais à faire en sorte que chaque ligne de code que vous écrivez - s'exécute plus rapidement, fonctionne de manière plus stable, soit plus claire sur le plan logique et plus fiable en matière de sécurité.
Ces changements peuvent ne pas se manifester immédiatement, tout comme la reconstruction des fondations n'est jamais la première chose que l'on voit. Mais cela aura 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 Ethereum ont-ils choisi RISC-V ?
Source : PolkaWorld
Dans l'évolution récente de la technologie blockchain, un terme qui était à l'origine populaire uniquement dans le cercle des ingénieurs en puces est devenu le nouveau chouchou des développeurs blockchain : RISC-V.
Le 20 avril 2025, le fondateur d'Ethereum, Vitalik Buterin, a publié un message 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.
Et pendant ce temps, Polkadot a discrètement lancé sur le réseau de test AseetHub Westend un environnement d'exécution de contrats intelligents prenant en charge RISC-V. 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 ? Pourquoi un jeu d’instructions open-source, qui a été créé à l’origine pour la conception de puces, a-t-il « brisé la boucle » dans le monde de la blockchain ?
Ethereum et Polkadot parient sur RISC-V, mais que cherchent-ils derrière ?
Pourquoi RISC-V émerge-t-il de nulle part, des puces à la blockchain ?
L'« âme » de chaque dispositif de calcul est son architecture d'ensemble d'instructions (ISA), c'est-à-dire la langue par laquelle le logiciel dit au matériel « ce que je veux que tu fasses ». Les CPU Intel que nous connaissons utilisent 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 CPU sans avoir à payer de redevances à 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 adhèrent à cette norme d'architecture : structure simple, flexible et modulable, utilisable en open source, tout en évitant les risques liés à la géopolitique.
Mais quelle est la relation entre RISC-V et la blockchain ?
Une 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 dominants actuels, tels que l'EVM d'Ethereum, le WASM de Polkadot et le BPF de Solana, présentent certains problèmes évidents :
Donc, lorsque l'architecture "très moderne" RISC-V se présente devant les ingénieurs blockchain, leur intuition est : pouvons-nous aussi "RISC-Viser" la machine virtuelle de la blockchain ?
Comparaison des modèles de calcul à pile et à registre
Choix d'Ethereum : Concevoir la prochaine génération de machine virtuelle native ZK à partir du concept
Les idées de Vitalik sont très dans le style de la communauté Ethereum : pas une simple optimisation, mais une re-conception au niveau philosophique.
Selon sa description sur le forum Ethereum Magicians, son idée est la suivante : la couche d'exécution d'Ethereum à l'avenir devrait être extrêmement simplifiée, sécurisée et mathématiquement prouvable. Or, l'EVM est déjà trop complexe et ne peut plus être modifiée. Il vaudrait mieux utiliser RISC-V pour construire une nouvelle VM vérifiable.
RISC-V a une structure claire et un comportement d’exécution prévisible, ce qui le rend idéal pour la traduction en circuits de preuve à divulgation nulle de connaissance ; À l’avenir, il pourrait également fonctionner avec le compilateur LLVM (bien que j’aie vu beaucoup de commentaires sur les bogues) pour développer des contrats dans des langages plus riches tels que Rust et C ; Plus important encore, il peut être la base de la couche d’exécution pour la construction de la « chaîne native ZK ».
Bien sûr, tout cela en 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 à une blockchain évolutive, sécurisée et digne de confiance pour l'avenir.
Le chemin de Polkadot : un réalisme axé sur les ingénieurs, commençant par le remplacement des couches sous-jacentes
Contrairement à la "conception conceptuelle" d'Ethereum, Polkadot a choisi une autre voie pragmatique.
Dès 2023, l'ingénieur principal de Parity, Jan Bujak, a commencé à explorer des alternatives à WASM et a finalement choisi RISC-V, lançant ensuite le projet PolkaVM.
L’approche de Polkadot est simple :
Cela signifie que l'expérience des développeurs reste essentiellement inchangée, mais que l'exécution sous-jacente a été complètement renouvelée. De WebAssembly à RISC-V, de l'architecture à pile à l'architecture à registre, de l'exécution traditionnelle à une exécution favorable aux 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 des développeurs : votre code reste inchangé, mais le sous-jacent se restructure silencieusement
Alors qu’Ethereum et Polkadot ont emprunté des chemins différents vers RISC-V, l’un en avance sur la vision et l’autre déjà sur le terrain, leur message aux développeurs est étonnamment cohérent : il ne s’agit pas d’un changement de « couche d’écriture », mais d’une refonte de l’infrastructure sous-jacente.
Pour les développeurs, peu importe sur quelle chaîne vous vous trouvez, il est presque impossible de ressentir une rupture à 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 reste fondamentalement le même, tout est comme avant.
Mais dans les couches invisibles, le moteur d'exécution a déjà changé de cœur !
Sur Polkadot, les contrats Solidity peuvent être compilés en code byte RISC-V à l'aide de l'outil revive et exécutés sur la nouvelle machine virtuelle PolkaVM. Comparé à WASM et à l'EVM traditionnel, PolkaVM offre de meilleures performances en matière 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 native 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, constitue une solution idéale.
Plus important encore, ce changement de l'architecture ne se limite pas à une simple amélioration des performances - un changement fondamental des paradigmes de développement sur la chaîne est en train de se produire discrètement.
La sécurité passera d'un « contrôle humain » à une « vérification mathématique ». Chaque comportement d'instruction de RISC-V peut être modélisé formellement, ce qui est hors de portée de l'EVM. Cela signifie que la sécurité des contrats à l'avenir ne dépendra plus des audits répétés chaque année, mais pourra obtenir une validation mathématique de « je ne ferai pas d'erreurs » dès la phase de compilation. Vous pouvez écrire du code qui ne nécessite pas de confiance, simplement parce qu'« il peut être prouvé ».
Le zero-knowledge est passé d’une niche à une valeur par défaut. Dans le passé, la rédaction de contrats ZK était une compétence que seuls les ingénieurs seniors pouvaient maîtriser. La structure de RISC-V est intrinsèquement compatible avec zk, avec un processus d’exécution bien organisé et des circuits faciles à tourner, ce qui en fait un backend idéal pour des systèmes tels que zkEVM. Une fois le basculement sous-jacent terminé, le contrat ZK peut ne plus être une option, mais deviendra le « mode de sécurité par défaut » du contrat intelligent.
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 tels que Rust et C peuvent naturellement être compilés dans des formats d’exécution on-chain. Vous n’êtes plus limité par Solidity, et l’écriture de contrats intelligents à l’avenir sera aussi contrôlable et flexible que l’écriture de modules système. Polkadot pousse déjà l’encre ! La migration des langues vers RISC-V montre que le monde contractuel où différentes langues coexistent est une réalité, pas un fantasme.
Écrit en dernier
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 des machines virtuelles n'est pas destinée à changer votre manière d'écrire du code, mais à faire en sorte que chaque ligne de code que vous écrivez - s'exécute plus rapidement, fonctionne de manière plus stable, soit plus claire sur le plan logique et plus fiable en matière de sécurité.
Ces changements peuvent ne pas se manifester immédiatement, tout comme la reconstruction des fondations n'est jamais la première chose que l'on voit. Mais cela aura un impact : les futurs contrats intelligents deviendront plus puissants, plus libres et plus dignes de confiance, sans que vous ne vous en rendiez compte.