EVM compatible vs équivalent : où déployer votre dApp en 2026

Vous déployez un contrat Solidity sur Optimism, il fonctionne de manière identique à Ethereum. Vous le déployez sur zkSync, la compilation échoue. Vous le déployez sur Moonbeam, il fonctionne — mais l'adresse de votre compte change dans un autre pallet Substrate. Vous le déployez sur Scroll, il fonctionne — mais l'opcode COINBASE renvoie l'adresse d'un contrat, pas celle du mineur. Ces différences semblent mineures jusqu'à ce qu'un appel cross-chain échoue en production avec 10 millions de dollars de TVL. Ce guide technique explique pourquoi chaque EVM moderne rompt le standard de manière différente — et comment choisir un réseau sans surprises.

Quelle est la différence entre EVM compatible et EVM équivalent ?

L'EVM (Ethereum Virtual Machine) est le moteur d'exécution d'Ethereum : une machine basée sur une pile, des mots de 256 bits, des opcodes spécifiques. Depuis le succès d'Ethereum, des dizaines de réseaux ont copié ou adapté ce modèle. Mais "compatible" et "équivalent" ne sont pas la même chose :

• EVM équivalent : respecte à la lettre l'Ethereum Yellow Paper. Votre contrat Solidity s'exécute de manière identique, octet par octet, opcode par opcode. Des outils comme Hardhat, Foundry ou Tenderly fonctionnent sans modification. Exemples : Optimism, Base, Arbitrum One, Scroll (Type 2).
• EVM compatible : exécute des contrats Solidity, mais l'architecture sous-jacente, le modèle de stockage ou le consensus sont différents. Certains opcodes ont une sémantique différente ; les adresses de compte peuvent être générées différemment. Exemples : Polygon PoS, Moonbeam, Avalanche subnets, BSC, zkSync Era, Tron.

La différence semble académique jusqu'au déploiement. Un contrat qui appelle SELFDESTRUCT fonctionne sur Ethereum et Optimism. Il échoue sur Scroll. Il ne compile pas sur zkSync. Et c'est là que le problème commence.

Pourquoi Ethereum L1 est-il le standard canonique ?

Ethereum L1 exécute l'EVM de manière monolithique et unifiée avec un consensus et une disponibilité des données. Le modèle est le suivant :

• Exécution basée sur une pile (stack-based) : instructions PUSH, POP, ADD, MUL, etc. Chaque opcode occupe 1 octet. Il y a environ 140 opcodes définis.
• Mots de 256 bits : tout est manipulé comme des entiers U256. Même taille qu'un hash Keccak-256.
• Mémoire volatile adressable par octets, avec un coût de gas quadratique lors de l'expansion. Cela rend les opérations de grande mémoire plus coûteuses pour prévenir les attaques DoS.
• Stockage clé-valeur 256/256 persisté dans l'arbre Merkle-Patricia.
• Adresses H160 (20 octets), dérivées avec Keccak-256 sur la clé publique secp256k1.
• Évolution par EIPs coordonnées lors des hard forks (Cancun, Pectra, etc.). Client Geth, Nethermind, Besu, Reth.

Toute divergence par rapport à ce modèle est une décision architecturale avec des conséquences. Passons réseau par réseau.

Comment les rollups optimistes atteignent-ils l'équivalence EVM ?

Les rollups optimistes (Optimism, Arbitrum, Base) exécutent les transactions en dehors de la chaîne Ethereum L1, mais publient les données sur L1. Ils héritent de la sécurité en supposant que les transactions sont valides, avec une période de contestation (7 jours) pendant laquelle n'importe qui peut contester.

OP Stack — équivalence stricte + transactions de dépôt

Le framework OP Stack (Optimism Mainnet, Base, Zora, Mode, World Chain) vise une équivalence EVM absolue. Mais il introduit un concept étranger : les transactions de dépôt pour communiquer L1 ↔ L2.

Lorsqu'un contrat L1 appelle son homologue L2, OP Stack applique l'address aliasing : l'adresse de l'émetteur est transformée par un décalage fixe pour empêcher qu'un contrat malveillant sur L1 n'agisse avec les privilèges de son adresse homologue sur L2 :

Les EOA (comptes externes) conservent une adresse identique ; seuls les contrats sont aliasés. De plus, OP Stack supprime le mempool public (seul le séquenceur le voit) et introduit des états de finalité différenciés : Unsafe, Safe, Finalized.

Arbitrum Nitro + Stylus — Geth au cœur + WASM parallèle

Arbitrum Nitro (sécurisant >12 000 M$ TVL) adopte une approche différente : il exécute une version modifiée du client canonique Geth pour une exécution native. En cas de litige, il compile la fonction de transition d'état en WebAssembly et résout le conflit sur L1 via des preuves de fraude interactives multi-tours (BOLD).

L'innovation la plus radicale est Stylus : une deuxième machine virtuelle basée sur WASM qui partage le stockage avec l'EVM traditionnelle, permettant de déployer des contrats en Rust, C ou C++. Sa tarification du gas utilise une unité appelée encre (ink) qui est convertie en gas EVM :

Comment les zkEVM de Type 2 et de Type 4 diffèrent-elles ?

Les ZK-Rollups utilisent des preuves cryptographiques (SNARKs/STARKs) pour certifier la légitimité des transactions. L1 vérifie mathématiquement des milliers d'exécutions en quelques secondes. La finalité des retraits est quasi-immédiate (contre 7 jours pour les optimistes). La taxonomie de Vitalik classe les zkEVM par niveau d'équivalence :

Scroll — Type 2 (équivalence de bytecode)

Scroll est de Type 2 : le bytecode compilé de Solidity s'exécute de manière identique. Mais il introduit des modifications obligées par le coût de prouver certains opcodes dans les circuits Halo2 :

• COINBASE ne renvoie pas l'adresse du validateur, mais celle du contrat de coffre de frais (0x5300...0005)
• DIFFICULTY et PREVRANDAO renvoient toujours 0
• SELFDESTRUCT est complètement désactivé : tout appel est annulé
• EIP-1559 calcule le basefee mais ne brûle pas d'ETH

Précompilations affectées : RIPEMD-160, blake2f, point evaluation (EIP-4844 blobs) et courbes BLS12 — toutes N/A. modexp a une entrée limitée à 8192 bits. 0p256Verify natif est ajouté pour les signatures secp256r1 (EIP-7951).

zkSync Era — Type 4 (équivalence de compilateur)

zkSync Era n'interprète pas le bytecode EVM. Il utilise zksolc (basé sur LLVM) pour traduire Solidity/Vyper directement en EraVM, une machine virtuelle à registres optimisée pour les circuits zk. Cela entraîne des divergences profondes :

• Déploiement : les contrats enfants doivent être déclarés dans le champ factoryDeps d'une transaction EIP-712. CREATE et CREATE2 n'acceptent pas de code d'initialisation dynamique. type(T).runtimeCode génère une erreur de compilation.
• Gas de mémoire : linéaire constant (1 erg par octet), non quadratique. msize() rapporte les octets au lieu des mots de 32.
• Opcodes interdits : SELFDESTRUCT, CALLCODE, EXTCODECOPY sont des erreurs de compilation dures.
• Ether natif : les transferts sont simulés via le contrat système MsgValueSimulator — EraVM ne prend pas en charge le passage de soldes dans les appels internes.
• Variables immuables : elles sont stockées dans ImmutableSimulator, sans modifier le bytecode du constructeur.

zkSync propose un interpréteur EVM optionnel pour exécuter le bytecode standard sans recompilation — utile pour des intégrations rapides mais perd des optimisations.

Pourquoi Moonbeam et Astar ont-ils des comptes doubles ?

Les parachains de Polkadot opèrent sur Substrate (framework modulaire Parity). L'EVM n'est pas le cœur : elle est ajoutée comme module optionnel via Frontier (pallets pallet-evm et pallet-ethereum).

Le choc des formats est structurel :

• Substrate SS58 : clés de 32 octets, signatures sr25519, format Base58Check
• Ethereum H160 : 20 octets, signatures secp256k1, hex

Frontier résout l'adressage avec un mappage unidirectionnel :

Cela génère un compte SS58 virtuel sans clé privée connue, où sont stockés les soldes accessibles depuis l'EVM. La fonction de hachage est unidirectionnelle : impossible de déduire H160 à partir d'une SS58 arbitraire.

Moonbeam a brisé ce dualisme : il a reconfiguré l'ensemble du runtime Substrate pour utiliser uniquement H160 et secp256k1 de manière native. Cela permet d'utiliser MetaMask pour signer à la fois les transactions EVM et les extrinsèques Substrate. Astar maintient des comptes doubles mais ajoute pallet-unified-accounts pour gérer un mappage bidirectionnel explicite.

Pour que l'EVM accède à l'état natif de la parachain (staking, gouvernance), Frontier utilise des contrats précompilés comme traducteurs : lorsque la dApp invoque un précompilé, Frontier exécute en interne des fonctions de pallets Substrate. Cela permet de faire du staking natif ou de voter lors de référendums à partir de code Solidity.

Quand une sidechain est-elle préférable à un rollup ?

Les sidechains sont des chaînes souveraines parallèles à Ethereum : leurs propres validateurs, leur propre consensus, sans héritage de sécurité. La connexion avec L1 se fait par des contrats de pont avec leur propre modèle de confiance. Quatre modèles architecturaux de ponts :

Gnosis Chain — gas en xDAI stable

Gnosis Chain est une sidechain PoS sécurisée par plus de 200 000 validateurs. La différence technique la plus utile : le gas est payé en xDAI, pas en son token natif GNO. xDAI est un stablecoin 1:1 USD ponté depuis L1. Résultat : des transactions qui coûtent 0,001 $ à 0,01 $ de manière prévisible, sans volatilité. Idéal pour les applications commerciales qui nécessitent des frais stables.

Polygon PoS — migration vers Validium

Polygon PoS publie des checkpoints sur L1 toutes les 30 minutes, mais la finalité opérationnelle est locale (validateurs DPoS avec stake en POL). Il est en transition architecturale vers Validium L2 : des preuves de validité ZK envoyées à Ethereum pour certifier les transitions d'état sans perdre le faible coût. Migration motivée par la pression concurrentielle post-Kelp DAO.

Autres cas

• SKALE Network : modèle "gas gratuit" utilisant sFUEL sans valeur économique. Rompt les protocoles cross-chain comme LayerZero qui exigent le paiement du gas à destination — nécessite un ERC-20 secondaire.
• Avalanche Subnets : EVM personnalisée avec gas en token natif du subnet ou ERC-20 spécifique.
• Tron VM : Solidity oui, mais API différente (TronWeb au lieu de Web3.js/Ethers). Gas payé en TRX.

Qu'en est-il de SELFDESTRUCT, COINBASE et d'autres opcodes rares ?

Résumé de quel réseau rompt quel opcode :

Si votre contrat dépend de l'un de ces éléments, le tester sur chaque réseau avant de migrer est obligatoire. Il ne suffit pas de vérifier qu'il compile.

Comment décider où déployer ma dApp ?

Quatre questions dans l'ordre :

1. Avez-vous besoin de la sécurité maximale d'Ethereum ? → L2 rollup. Optimism, Arbitrum, Base si vous voulez une équivalence stricte. Scroll si vous avez besoin d'une finalité rapide avec zk.
2. Avez-vous une logique computationnelle lourde (vérification de preuves, AI on-chain, big data) ? → Arbitrum Stylus pour WASM. zkSync EraVM si vous acceptez de perdre les outils standard en échange de performances.
3. Avez-vous besoin d'une gouvernance complexe ou d'un staking natif ? → Parachain (Moonbeam, Astar). Vous acceptez le dualisme des comptes en échange de l'accès à l'écosystème Polkadot.
4. Votre application est-elle commerciale et a-t-elle besoin d'un gas prévisible ? → Gnosis Chain (xDAI). Vous payez avec confiance dans le pont ; vous gagnez en stabilité des frais.

La conclusion inconfortable : il n'y a pas de réseau "meilleur" universel. Il existe des réseaux optimisés pour des cas d'utilisation spécifiques. L'équivalence EVM résout les frictions de développement, pas nécessairement les frictions opérationnelles. La compatibilité EVM acceptable rompt les outils mais ouvre des capacités impossibles sur L1.

Guides associés