---
id: 16
title: "Ce que signifie réellement la compatibilité EVM : bytecode, précompilations, JSON-RPC et outillage"
slug: evm-compatibility-explained
date: 2026/09/03
summary: "« Compatible EVM » est souvent réduit à un argument marketing. Ce qui détermine réellement le coût de migration, ce sont la sémantique du bytecode, l'ensemble des précompilations, le comportement de JSON-RPC et la question de savoir si Foundry/Hardhat fonctionnent encore sans modification. Cet article sépare ces quatre couches et explique pourquoi le parallélisme rend la compatibilité plus difficile à maintenir."
keywords: compatibilité EVM,bytecode,précompilations,JSON-RPC,Foundry,Hardhat
heroImage: /images/community-bg.png
---

Presque toutes les pages d'accueil des nouvelles chaînes affichent « entièrement compatible EVM ». Cette formule sonne comme une garantie technique et se comporte plutôt comme une affirmation qui appelle des questions de suivi : les contrats peuvent-ils se déployer sans modifier le bytecode ? Les portefeuilles et les explorateurs peuvent-ils ne changer que le point de terminaison RPC ? Ou « compatible » signifie-t-il seulement « vous pouvez écrire du Solidity » ? Ce sont trois promesses d'ingénierie très différentes, que le marketing compresse régulièrement en une seule phrase.

Pour une chaîne qui conserve la compatibilité EVM tout en repensant l'exécution autour du parallélisme, il s'agit d'une contrainte quotidienne, et non de rhétorique. Après avoir réordonné les ordonnancements et ajouté la détection de conflits et l'exécution multi-moteur, ce qui compte est de savoir si le comportement visible pour les auteurs de contrats correspond toujours à Ethereum. [Positionnement de Bitroot](/fr/blog/bitroot-positioning) a expliqué pourquoi Bitroot insiste sur une pleine compatibilité EVM ; cet article décompose « pleine » en quatre couches vérifiables.

## Bytecode : la plus petite unité de compatibilité est l'opcode, pas la syntaxe

L'EVM n'exécute jamais le code source Solidity. Il exécute des opcodes compilés — un jeu d'instructions bâti autour de la pile, de la mémoire et du stockage — ainsi qu'un modèle de compte où chaque adresse possède un nonce, un solde, un hachage de code et son propre arbre de stockage. Une compatibilité stricte signifie que la sémantique des opcodes, la comptabilisation du gaz, les limites de profondeur de pile et les règles de lecture/écriture des comptes s'alignent sur un hard fork Ethereum cible. À ce niveau d'exigence, un bytecode non recompilé devrait, en principe, produire la même transition d'état sur une autre chaîne.

Ce standard fixe le plancher du coût de migration. Une compatibilité au niveau du bytecode signifie que des contrats audités n'ont pas besoin d'être entièrement réaudités pour une dérive silencieuse de la couche syntaxique ; les contrats qui dépendent de la dérivation d'adresse CREATE2 ou du coût en gaz d'un opcode précis pour leurs défenses contre la réentrance ne devraient pas mal se comporter parce que la tarification a changé sous le capot. Si une chaîne « prend seulement en charge l'écriture de contrats en Solidity », les développeurs gagnent une familiarité de syntaxe — et une dérive dès qu'ils touchent des opcodes peu courants ou des hypothèses de gaz.

Vérifiez aussi l'alignement sur les hard forks : l'ensemble des opcodes autorisés n'est pas identique entre Shanghai, Cancun et les mises à niveau ultérieures. Une affirmation de compatibilité devrait nommer la mise à niveau Ethereum qu'elle suit, plutôt que d'agiter un vague « EVM ». Les équipes de migration peuvent redéployer le bytecode d'exécution du mainnet et comparer les hachages de code ainsi que les valeurs de retour sur les chemins d'appel critiques.

L'exécution parallèle ajoute de la pression. Le parallélisme optimiste peut spéculer en parallèle puis revenir en arrière, mais pour les auteurs de contrats, la transition d'état validée doit rester équivalente à un ordre sériel défini (généralement l'ordre des transactions dans le bloc). Si l'ordonnancement modifie l'état final visible, ce n'est pas de la compatibilité — c'est une autre machine virtuelle. Pour les frontières de correction et la sérialisabilité, voir [Introduction au contrôle de concurrence optimiste (OCC)](/fr/blog/optimistic-concurrency-control-intro). Pour situer le parallélisme sur une carte de scalabilité plus large, comparez [Cartographier la scalabilité des chaînes de blocs](/fr/blog/blockchain-scaling-map) et [Le goulot d'étranglement du monothread de l'EVM](/fr/blog/evm-single-thread-bottleneck) : la compatibilité doit préserver la sémantique déterministe sur laquelle s'appuient les auteurs de contrats, et non l'interpréteur monothread lui-même.

## Précompilations : même adresse, implémentation différente, c'est de l'incompatibilité

Ethereum implémente les opérations coûteuses sous forme de contrats précompilés à des adresses fixes telles que `0x01`–`0x0a` — appariement de courbes elliptiques, exponentiation modulaire, hachage, etc. Les applications et les bibliothèques codent en dur ces adresses et ces coûts en gaz. Si une chaîne modifie l'ensemble des précompilations, la correspondance des adresses ou la sémantique des valeurs de retour, Solidity peut encore compiler alors que la compatibilité est déjà rompue : des bibliothèques auditées peuvent échouer on-chain ou renvoyer des résultats erronés.

Les schémas courants de « fausse compatibilité » consistent à n'implémenter que les précompilations populaires, à ajouter des précompilations personnalisées sur des adresses Ethereum réservées ou à modifier le gaz sans le documenter. Les équipes de migration ne devraient pas se fier à la ligne « compatible EVM » du livre blanc ; elles devraient comparer avec la table de précompilations du fork cible : mêmes entrées et mêmes calldata, même valeur de retour et même gaz sur le mainnet et sur la chaîne cible. Les chemins d'appariement et de modexp méritent une attention particulière, car ils sont coûteux et souvent utilisés par les ponts, la vérification de preuves et les bibliothèques cryptographiques.

L'EVM parallèle n'exige pas de modifier la sémantique des précompilations. Le vrai risque est la tentation de spécialiser « pour la vitesse ». Toute modification de précompilation visant le débit devrait être une différence de protocole explicite, et non glissée dans un récit de compatibilité. Si une équipe ajoute des précompilations personnalisées pour un calcul spécialisé, elle devrait utiliser un espace d'adresses clairement non réservé et documenter l'écart, afin que les adresses réservées à Ethereum restent intactes.

## JSON-RPC : l'outillage survit ou meurt par l'interface, pas par le slogan

Des contrats déployables ne font pas un écosystème utilisable. Les portefeuilles, les explorateurs, les indexeurs et les outils de surveillance dépendent de JSON-RPC : `eth_call`, `eth_getLogs`, `eth_estimateGas`, `eth_getTransactionReceipt`, etc. Si la signification des champs, les codes d'erreur, l'indexation des journaux ou la sémantique pending versus latest s'écartent des habitudes des clients Ethereum, les interfaces et l'infrastructure ont besoin d'adaptateurs — et le coût de migration passe de « changer le RPC » à « reconstruire la chaîne d'exploitation ».

`eth_estimateGas` et les API de type trace méritent une attention particulière. Sous exécution parallèle, des estimations de gaz qui ne simulent pas la sémantique sérielle finale peuvent être systématiquement trop basses ou trop hautes ; sans traces isomorphes au mainnet, les tests de fork Foundry et l'analyse d'incidents deviennent plus difficiles. La compatibilité JSON-RPC n'est donc pas « MetaMask se connecte », mais la question de savoir si les parcours quotidiens de développement et d'exploitation restent réutilisables. Les abonnements à des filtres, `eth_feeHistory` et les champs liés à l'EIP-1559 décident souvent si les SDK existants peuvent être mis en production avec guère plus qu'un changement de configuration.

Les indexeurs et les explorateurs ont aussi besoin d'un ordre des journaux et de champs de reçu stables. Si l'exécution parallèle change le moment où l'état intermédiaire devient visible mais que les reçus finaux restent isomorphes au mainnet, les applications s'en accommodent généralement ; si des champs de reçu manquent ou que les codes d'erreur sont propriétaires, les outils de l'écosystème nécessitent une maintenance dérivée. La recette de compatibilité devrait traiter « lire un appel + envoyer une transaction + récupérer les journaux + estimer le gaz » comme une boucle fermée, et non seulement un déploiement réussi.

## Outillage : Foundry et Hardhat sont la cour d'appel en dernier ressort

Pour la plupart des équipes, la compatibilité se juge localement : `forge test`, les scripts Hardhat, les contrats OpenZeppelin et les plugins de vérification courants s'exécutent-ils contre le RPC cible avec peu ou pas de modification ? Foundry (Forge / Cast / Anvil) est la pile de test par défaut de nombreux nouveaux projets ; Hardhat couvre encore une large base installée. Les deux supposent que la sortie du compilateur, les précompilations on-chain et le comportement du RPC sont suffisamment proches d'Ethereum.

Une liste de recette courte et reproductible :

1. Compilez avec la même version de Solidity et les mêmes réglages d'optimiseur ; vérifiez si les hachages de bytecode déployé correspondent aux déploiements du mainnet (ou ne diffèrent que par des immutables explicables).
2. Comparez les précompilations critiques.
3. Forkez l'état de la chaîne cible avec Anvil / Hardhat Network et exécutez les tests d'intégration existants.
4. Ne changez que le chainId et le RPC dans un portefeuille et effectuez signature → envoi → reçu.
5. Exécutez des tests d'invariants sur les contrats centraux : conservation des soldes, contrôle d'accès et défenses contre la réentrance tiennent toujours sur la chaîne cible.

Tout échec signifie que « compatible » comporte encore des lacunes. Bitroot place la complexité dans l'ordonnancement parallèle à l'exécution plutôt que de demander aux développeurs de réécrire leur Solidity ou de changer de chaîne d'outils, de sorte que les parcours ci-dessus peuvent rester intacts ; voir aussi [La parallélisation optimiste de l'EVM de Bitroot expliquée](/fr/blog/bitrootevm-) et [Exécution parallèle multi-moteur](/fr/blog/bitroot-evm). Comparé à [Trois voies vers l'exécution parallèle](/fr/blog/parallel-execution-approaches), insister sur la compatibilité du bytecode revient à renoncer à une partie du plafond de parallélisme offert par de nouveaux modèles de comptes, en échange d'un rayon de migration plus large pour l'écosystème des développeurs.

## Comment lire une affirmation de « compatibilité EVM »

Transformez la phrase marketing en quatre questions fermées : la sémantique du bytecode correspond-elle au hard fork cible ? La table des précompilations est-elle identique ? JSON-RPC couvre-t-il les méthodes courantes du mainnet avec une sémantique isomorphe ? Les projets Foundry / Hardhat existants peuvent-ils s'exécuter avec peu ou pas de modification ? Quatre oui approchent une compatibilité stricte ; tout non devrait faire l'objet d'un document d'écart explicite, et non être dissimulé derrière un slogan.

Le parallélisme peut modifier le débit et la latence en cas de conflit, mais il ne devrait pas réécrire la sémantique déterministe sur laquelle s'appuient les auteurs de contrats. Les réessais visibles par l'utilisateur et les variations de latence sous charges chaudes relèvent de la performance et de la charge de travail, et sont distincts de la question « la sémantique est-elle compatible » — voir plus loin [Points chauds de conflit et charges de travail](/fr/blog/parallel-evm-workload-hotspots) et [Glossaire des métriques de performance](/fr/blog/performance-metrics-glossary). Une chaîne qui achète un benchmark plus rapide tout en rendant le comportement de l'outillage et du bytecode imprévisible dépense un capital écosystémique de long terme pour une affiche de court terme — et les effets de réseau de la voie EVM sont exactement ce que cette affiche cherche à s'offrir.

L'article suivant propose des parcours de lecture par rôle, qui ne renvoient qu'à des articles déjà publiés, afin que des profils différents ne soient pas écrasés en un seul texte que personne ne termine.

## Pour aller plus loin

- Précédent : [Positionner Bitroot : un Layer 1 hautes performances bâti sur un EVM parallèle optimiste](/fr/blog/bitroot-positioning)
- Suivant : [Qui devrait lire sur l'EVM parallèle : trois parcours pour les développeurs de contrats, les ingénieurs clients et les chercheurs](/fr/blog/who-should-read-parallel-evm)
- Associés : [Le goulot d'étranglement du monothread de l'EVM](/fr/blog/evm-single-thread-bottleneck), [Introduction au contrôle de concurrence optimiste (OCC)](/fr/blog/optimistic-concurrency-control-intro)