Skip to main content

Qu'est-ce qu'une blockchain non-EVM

Remarque : Ce document est une traduction automatique de la version originale anglaise.

Qu'est-ce qu'une blockchain non-EVM

Une blockchain non-EVM est toute blockchain qui n'utilise pas la machine virtuelle Ethereum comme moteur d'exécution. Au lieu d'exécuter du bytecode Solidity, les chaînes non-EVM utilisent des machines virtuelles différentes, des langages de programmation différents et des modèles d'exécution différents. Parmi les exemples : Solana (SVM/Sealevel), les chaînes basées sur Cosmos (CosmWasm, modules spécifiques à l'application), NEAR (environnement d'exécution basé sur WebAssembly), Sui et Aptos (MoveVM), et Bittensor (environnement d'exécution personnalisé basé sur Substrate).

Cette distinction est importante parce que le choix de la machine virtuelle détermine quels langages de programmation les développeurs utilisent, comment les contrats intelligents se comportent, quel outillage est disponible et avec quelle facilité un projet peut interagir avec d'autres chaînes. Un projet construit sur une chaîne non-EVM ne peut pas simplement copier-coller des contrats Solidity depuis Ethereum — il lui faut une base de code différente, des compétences de développeurs différentes et un ensemble d'outils d'infrastructure différent.

En bref : les blockchains non-EVM utilisent des environnements d'exécution autres que la machine virtuelle Ethereum. Cela signifie des langages de programmation différents, un outillage différent et des compromis architecturaux différents — mais aussi le potentiel de caractéristiques de performance que l'EVM ne peut pas atteindre.

En quoi l'exécution non-EVM diffère de l'EVM

L'EVM est une machine virtuelle à pile qui exécute le bytecode Solidity séquentiellement, utilise des entiers de 256 bits et mesure le calcul via le gas. Les chaînes non-EVM s'écartent de ce modèle de diverses manières :

Des machines virtuelles différentes

Chaîne / écosystème Machine virtuelle Langage principal Différence architecturale clé
Solana SVM (Sealevel) Rust Exécution parallèle des transactions via la déclaration des accès à l'état
Chaînes Cosmos CosmWasm / modules natifs Rust (CosmWasm), Go (modules) Blockchain spécifique à l'application avec communication inter-chaînes intégrée (IBC)
NEAR WebAssembly (Wasm) Rust, AssemblyScript Exécution shardée avec appels asynchrones entre shards
Sui MoveVM Move Modèle d'état centré sur les objets permettant l'exécution parallèle
Aptos MoveVM Move Moteur d'exécution parallèle Block-STM
Bittensor Environnement d'exécution Substrate Rust Coordination spécifique à l'IA ; subnets comme unités d'exécution

Chaque machine virtuelle fait des compromis différents. La SVM de Solana exige que les transactions déclarent à l'avance à quel état elles vont accéder, permettant à l'environnement d'exécution de traiter en parallèle les transactions sans conflit — chose que l'EVM ne peut pas faire nativement. Les chaînes Cosmos abandonnent entièrement le modèle d'exécution partagée : chaque application obtient sa propre chaîne avec une logique personnalisée, connectée aux autres chaînes via le protocole IBC. Les chaînes basées sur Move (Sui, Aptos) utilisent un modèle de programmation orienté ressources qui prévient certaines classes de bugs (comme la réentrance) au niveau du langage.

Des langages de programmation différents

L'écosystème EVM est dominé par Solidity — un langage conçu spécifiquement pour les contrats intelligents Ethereum. Les chaînes non-EVM utilisent des langages généralistes ou des alternatives conçues sur mesure :

  • Rust — utilisé par Solana (via le framework Anchor), Cosmos (via CosmWasm), NEAR et les chaînes basées sur Substrate, dont Bittensor. Les garanties de sûreté mémoire et la performance de Rust le rendent adapté aux programmes on-chain.
  • Move — développé à l'origine chez Facebook/Diem, désormais utilisé par Sui et Aptos. Move traite les actifs on-chain comme des ressources de première classe qui ne peuvent être dupliquées ni détruites accidentellement, réduisant une catégorie de vulnérabilités courantes des contrats intelligents.
  • Go — utilisé pour le développement de modules natifs dans les chaînes Cosmos SDK. Les validateurs exécutent directement des binaires compilés en Go.
  • AssemblyScript — un langage proche de TypeScript qui compile vers WebAssembly, utilisé comme langage alternatif pour le développement sur NEAR.

Cette diversité de langages signifie que les développeurs ne peuvent pas transférer directement leurs compétences Solidity vers des chaînes non-EVM. Un projet qui construit sur Solana a besoin d'ingénieurs Rust ; un projet qui construit sur Sui a besoin d'ingénieurs Move. Le vivier de talents pour chaque langage affecte la vitesse à laquelle un projet peut construire et itérer.

Des caractéristiques de performance différentes

Les chaînes non-EVM atteignent souvent des profils de performance différents :

  • Exécution parallèle — Solana, Sui et Aptos exécutent en parallèle les transactions sans conflit, ce qui peut offrir un débit supérieur au modèle d'exécution séquentielle de l'EVM.
  • Frais plus bas et plus prévisibles — certaines chaînes non-EVM ont des structures de frais conçues dès le départ pour un débit élevé, évitant les marchés de frais volatils que les chaînes EVM peuvent connaître pendant la congestion.
  • Modèles d'état personnalisés — les chaînes non-EVM peuvent utiliser des modèles d'état optimisés pour des schémas d'accès spécifiques. Le modèle centré sur les objets de Sui, par exemple, permet une propriété par objet et un traitement parallèle qui seraient complexes à implémenter sur l'EVM.

Ces avantages de performance s'accompagnent de compromis : des écosystèmes de développeurs plus petits, un outillage moins mature, moins de cabinets d'audit avec l'expertise pertinente, et moins de composabilité avec le vaste écosystème DeFi et de tokens basé sur l'EVM.

Pourquoi c'est important pour les projets crypto IA

Le choix de la machine virtuelle a des implications pratiques pour les projets blockchain liés à l'IA :

  • Flexibilité d'exécution — les chaînes non-EVM peuvent prendre en charge des modèles d'exécution mieux adaptés aux charges de travail de coordination IA. L'exécution parallèle, les machines à états personnalisées et les jeux d'instructions à moindre surcoût peuvent mieux servir les transactions liées à l'IA à haute fréquence (attributions de tâches de calcul, soumissions de résultats, mises à jour de registres de modèles).
  • Adéquation du langage — les chaînes basées sur Rust s'alignent bien avec l'infrastructure IA/ML, puisqu'une grande partie de l'outillage IA (composants critiques en performance, coordination GPU, programmation système) est écrite en Rust ou s'interface bien avec du code Rust.
  • Conception spécifique à l'application — les appchains Cosmos et les subnets Bittensor permettent aux projets IA de construire une logique d'exécution personnalisée au niveau de la chaîne, sans les contraintes du jeu d'opcodes et du modèle de gas de l'EVM.
  • Compromis d'écosystème — les projets non-EVM ne peuvent pas facilement puiser dans le vaste écosystème EVM de protocoles DeFi, de ponts de tokens et d'infrastructure de portefeuilles. Les projets IA sur des chaînes non-EVM doivent soit construire cette infrastructure eux-mêmes, soit s'appuyer sur des ponts inter-chaînes, soit accepter un écosystème initial plus restreint.

Dans les fiches projet DecAIHub, Type: non-EVM indique au lecteur que le projet n'utilise pas Solidity, ne peut pas se déployer sur des chaînes compatibles EVM sans réécriture, et opère dans un écosystème technique différent.

Où cela apparaît dans les fiches projet DecAIHub

Dans les fiches projet DecAIHub, la désignation non-EVM apparaît dans :

  • Type — non-EVM indique que les contrats intelligents ou la logique on-chain du projet utilisent une machine virtuelle autre que l'EVM. Cela affecte l'outillage, les langages et les standards applicables.
  • Main chain — la chaîne non-EVM spécifique est indiquée (Solana, Bittensor, une chaîne Cosmos, Sui, etc.). Chaque chaîne a sa propre VM, son propre langage et son propre écosystème.
  • Token standard — les chaînes non-EVM ont leurs propres standards de tokens. Solana utilise les tokens SPL ; les chaînes Cosmos utilisent des dénominations natives ou CW-20 (CosmWasm) ; les chaînes basées sur Move utilisent des ressources coin/fungible-asset. Ils ne sont pas interchangeables avec ERC-20.
  • Contrats intelligents / logique on-chain — le langage de programmation et le framework diffèrent des projets EVM. Les programmes Solana sont écrits en Rust (Anchor), les contrats Cosmos en Rust (CosmWasm) ou Go, et ainsi de suite.

Ce qu'une classification non-EVM seule ne prouve pas

  • Non-EVM ne signifie pas de meilleures performances. Bien que certaines chaînes non-EVM offrent l'exécution parallèle ou des frais plus bas, la performance dépend de la chaîne spécifique, de son infrastructure de validateurs et de la charge courante — pas seulement du choix de la VM.
  • Non-EVM ne prouve pas la sophistication technique. Choisir une chaîne non-EVM est une décision d'infrastructure. Cela n'indique pas la qualité du composant IA du projet, de son code ou de son produit.
  • Non-EVM ne signifie pas que le projet ne peut pas interagir avec les chaînes EVM. De nombreux projets non-EVM utilisent des ponts, des oracles ou des tokens enveloppés (wrapped) pour se connecter à Ethereum et à d'autres écosystèmes EVM. L'interaction inter-chaînes est possible ; elle requiert simplement une infrastructure supplémentaire.
  • Une VM différente ne signifie pas des garanties de sécurité différentes. Les bugs de contrats intelligents, les erreurs de logique et les risques de centralisation existent sur toutes les chaînes, quelle que soit la machine virtuelle. Les langages non-EVM comme Rust et Move éliminent certaines classes de bugs mais en introduisent d'autres.
  • Une étiquette non-EVM n'explique pas pourquoi le projet a choisi cette chaîne. Le choix peut être motivé par des besoins de performance, l'expertise de l'équipe de développement, des incitations d'écosystème, ou simplement l'endroit où l'équipe fondatrice a commencé. Sans contexte supplémentaire, l'étiquette seule est informative, pas évaluative.

Ne pas confondre avec

  • EVM — l'EVM est la machine virtuelle Ethereum. Non-EVM se définit par contraste avec elle : toute chaîne qui n'utilise pas l'EVM entre dans la catégorie non-EVM.
  • Ethereum — Ethereum est la chaîne EVM d'origine. Être non-EVM signifie que la chaîne n'est pas Ethereum et n'utilise pas le moteur d'exécution d'Ethereum — mais elle peut néanmoins interagir avec Ethereum via des ponts ou des protocoles inter-chaînes.
  • Solana — Solana est une blockchain non-EVM spécifique avec sa propre machine virtuelle (SVM). « Non-EVM » est une catégorie large qui inclut Solana, Cosmos, Sui, Aptos, NEAR, Bittensor et bien d'autres.
  • « Anti-Ethereum » — être non-EVM n'est pas une prise de position contre Ethereum. De nombreuses chaînes non-EVM coexistent avec Ethereum et bénéficient de liquidité transférée par ponts. Le choix de la VM reflète des priorités de conception différentes, pas une opposition idéologique.
  • Incompatible — les chaînes non-EVM ne peuvent pas exécuter nativement du bytecode EVM, mais cela ne signifie pas qu'elles sont isolées. Les ponts inter-chaînes, les protocoles de messagerie (comme IBC, LayerZero, Wormhole) et les tokens enveloppés permettent l'interopérabilité entre les écosystèmes EVM et non-EVM.

Questions fréquentes

Quelles sont les chaînes non-EVM les plus courantes utilisées par les projets crypto IA ?

Solana et Bittensor comptent parmi les chaînes non-EVM les plus fréquemment rencontrées dans l'espace crypto IA suivi par DecAIHub. Le débit élevé de Solana et son écosystème basé sur Rust attirent les projets IA qui ont besoin d'une coordination on-chain rapide et à faible coût. Bittensor est conçu spécifiquement pour l'IA décentralisée, avec des subnets dédiés à des tâches IA spécifiques. Les appchains basées sur Cosmos constituent un autre schéma, en particulier pour les projets qui veulent un environnement d'exécution entièrement personnalisé avec une communication inter-chaînes intégrée via IBC.

Un projet non-EVM peut-il aussi se déployer sur des chaînes EVM ?

Oui, mais cela nécessite une base de code distincte. Un projet écrit en Rust pour Solana ne peut pas être déployé tel quel sur Ethereum — il devrait être réécrit en Solidity (ou disposer d'une implémentation Solidity distincte). Certains projets maintiennent des contrats à la fois sur des chaînes EVM et non-EVM, mais chaque déploiement nécessite un développement, un audit et une maintenance indépendants. Les ponts inter-chaînes peuvent aussi permettre aux projets non-EVM d'avoir une représentation de leur token sur des chaînes EVM (par exemple des tokens SPL enveloppés en ERC-20 sur Ethereum).

Le non-EVM est-il meilleur pour les applications IA ?

Il n'y a pas de réponse universelle. Les chaînes non-EVM peuvent offrir des avantages pour des cas d'usage IA spécifiques — l'exécution parallèle de Solana convient à la coordination à haut débit, l'architecture en subnets de Bittensor est conçue spécifiquement pour les incitations IA, et les appchains Cosmos permettent une logique d'exécution entièrement personnalisée. Cependant, les chaînes EVM offrent un écosystème de développeurs plus vaste, un outillage plus mature, une liquidité DeFi plus profonde et une prise en charge plus large des portefeuilles. Le meilleur choix dépend des exigences spécifiques du projet : quelles charges de travail s'exécutent on-chain, quelle performance est nécessaire, quel écosystème l'équipe préfère, et où se trouvent les utilisateurs cibles.

Les chaînes non-EVM ont-elles des standards de tokens comme ERC-20 ?

Oui, mais différents. Solana utilise les tokens SPL. Les chaînes Cosmos utilisent des dénominations natives ou des tokens CW-20 (via CosmWasm). Sui et Aptos utilisent les ressources coin et fungible asset de Move. NEAR utilise NEP-141. Chaque standard définit comment les tokens sont créés, transférés et gérés sur cette chaîne. Ces standards ne sont pas interchangeables avec ERC-20 — un token créé en SPL sur Solana ne peut pas être utilisé directement sur une chaîne EVM sans enveloppement (wrapping) ou pont.

Références externes

Voir aussi

No comments to display

Back to top