Une empreinte de 32 octets garde des milliers de nœuds Ethereum en phase
Dans la première semaine de novembre 2026, Base, BNB Chain et le réseau Tempo ont diffusé des mises à jour à leurs opérateurs de nœuds. Un bug de staking means depositing a proof of stake coin with a protocol that stakes it for you and issues a transferable token (such as Lido stETH or rETH) representing the deposit plus rewards, which you can use or sell while the coins stay staked.">Reth, un client d’exécution développé par Paradigm, pouvait faire calculer à un nœud une racine d’état erronée. Les correctifs sont sortis entre le 4 et le 6 novembre, et aucune perte de fonds, aucun exploit ni aucune panne n’a été signalé, comme le détaille notre article sur le bug de la racine d’état de Reth et les correctifs des couches 2. L’épisode est une bonne porte d’entrée pour comprendre comment fonctionne l’EVM d’Ethereum, car Reth est l’un des programmes qui l’implémentent. Le correctif lui-même, la pull request 28264 de Reth, a été fusionné le 3 novembre sous le titre « fix(trie): tighten iterator seek boundary ».
Une racine d’état est un nombre de 32 octets. Chaque en-tête de bloc Ethereum en porte une. Elle résume tous les soldes de comptes, tout le code des contrats et chaque emplacement de stockage tels qu’ils sont une fois les transactions du bloc exécutées. Des milliers d’ordinateurs, qui font tourner cinq grands clients écrits dans quatre langages, recalculent ce nombre chacun de leur côté. Un nœud qui obtient une autre valeur n’est plus d’accord avec la chaîne. Les règles que tous doivent reproduire au bit près sont celles de la machine virtuelle d’Ethereum (Ethereum Virtual Machine, EVM).
La suite commence par les données, l’état du monde et la façon dont un bloc s’y engage, puis ouvre la machine : du bytecode exécuté un opcode à la fois sur une pile de mots de 256 bits, les appels entre contrats, le trajet d’une transaction de la signature au reçu, les clients qui font tourner l’ensemble et les changements à venir. Elle prend la suite de notre leçon sur l’histoire d’Ethereum et son livre blanc. Aucune connaissance de Solidity n’est nécessaire : nous restons au niveau des octets.
L’état du monde : un registre de comptes et ce à quoi chacun s’engage
Quatre champs par compte, et ce que la machine en fait
Chaque compte Ethereum a quatre champs : un nonce, un solde en wei, un hash de code et une racine de stockage. Les comptes externes (EOA, pour externally owned accounts) sont contrôlés par une clé privée ; les comptes de contrat sont contrôlés par leur code et ne peuvent pas lancer de transaction par eux-mêmes. Notre guide sur les modèles UTXO et de comptes couvre déjà ces champs, le nonce et le poids du stockage des contrats ; ici, nous regardons seulement ce que l’EVM en fait.
Un compte se retrouve grâce à une adresse de 20 octets. Pour un EOA, l’adresse est formée des 20 derniers octets du hash Keccak-256 de sa clé publique, d’après la documentation d’ethereum.org sur les comptes. Pour un contrat, l’adresse est calculée à la création du contrat, comme on le verra plus bas. Le hash de code pointe vers le bytecode, et la machine n’a aucune instruction pour réécrire le code stocké à une adresse une fois déployé. La racine de stockage est elle-même la racine d’un second arbre, qui contient le stockage de ce seul contrat.
La documentation d’Ethereum écrit tout le système comme une fonction, Y(S, T) = S’ : un ancien état plus une transaction valide donnent un nouvel état. Chaque nœud applique la même fonction à la même entrée et doit aboutir à la même sortie. Tout le reste de cette leçon n’est qu’un détail de cette fonction.
Pourquoi l’état est un trie et non un tableau
Un tableau de comptes serait facile à stocker, mais impossible à vérifier sans le télécharger en entier. Ethereum garde donc l’état dans ce qu’ethereum.org appelle un Merkle Patricia Trie modifié : un arbre à 16 branches au plus par nœud, où le chemin vers une feuille est écrit par la clé et où chaque nœud est identifié par le hash de son contenu. Modifiez un solde et les hashs le long du chemin, de cette feuille jusqu’au sommet, changent, jusqu’à la racine d’état de l’en-tête de bloc.
L’intérêt, ce sont les preuves. Un nœud peut remettre à un inconnu la courte liste des nœuds de l’arbre situés entre un compte et la racine, et toute personne qui possède l’en-tête de bloc peut vérifier que le solde est bien celui annoncé. Une requête eth_getProof envoyée à un nœud Ethereum public le 10 novembre 2026 a renvoyé, pour une adresse ordinaire, une preuve de compte de neuf nœuds. Le stockage de chaque contrat forme son propre trie du même type, ce qui explique qu’un solde de jeton soit, au bout du compte, une feuille de l’arbre de stockage du contrat du jeton. Le volume de données suit : la proposition EIP-8037 indique que la base d’état de Geth pesait environ 390 Gio en janvier 2026.
Arbre binaire, arbre de Verkle ou aucun des deux : le prochain arbre d’état reste un brouillon
Le trie hexaire a un coût. Les preuves sont longues, car chaque niveau peut comporter jusqu’à 15 hashs frères, et Keccak est lent à prouver dans des circuits à divulgation nulle de connaissance. Pendant des années, le plan officiel a été un arbre de Verkle, et la page de feuille de route d’ethereum.org le décrit encore ainsi. Depuis janvier 2025, un concurrent est sur la table : l’EIP-7864, « Ethereum state using a unified binary tree » (en anglais), rédigée par Vitalik Buterin, Guillaume Ballet, Dankrad Feist et d’autres.
L’EIP-7864 ouvrirait un nouvel arbre binaire qui réunit données de comptes, code et stockage, tandis que le trie actuel serait gelé puis migré par une proposition distincte. Ses auteurs font valoir qu’un arbre purement fondé sur des hashs donne des preuves plus petites, convient mieux aux preuves à divulgation nulle de connaissance et évite la cryptographie à courbes elliptiques sur laquelle reposent les arbres de Verkle, qu’un ordinateur quantique pourrait un jour casser. La fonction de hachage n’est pas choisie : le brouillon utilise BLAKE3 pour les tests et cite Keccak et Poseidon2 comme candidates. Au 10 novembre 2026, l’EIP est toujours au statut Draft et aucune mise à niveau nommée ne prévoit de changer l’arbre d’état.
Comment fonctionne l’EVM d’Ethereum : une machine à pile de mots de 256 bits
Le bytecode : ce qu’est vraiment un contrat sur la chaîne
Sur la chaîne, un smart contract n’est rien de plus qu’une suite d’octets stockée à une adresse. L’adresse du jeton USDC sur Ethereum, 0xA0b8…eB48, contenait 2 186 octets de code le 10 novembre 2026. Depuis la mise à niveau Spurious Dragon du 22 novembre 2016 (bloc 2 675 000), l’EIP-170 plafonne le code déployé à 24 576 octets. L’EIP-7954, prévue pour la mise à niveau Glamsterdam (statut Last Call, date limite de relecture au 1er novembre 2026), porterait ce plafond à 64 Kio, soit 65 536 octets, et la limite du code d’initialisation de 48 Kio à 128 Kio.
Chaque instruction, ou opcode, tient sur un octet. 0x01 est ADD, 0x55 est SSTORE, 0x00 est STOP. Quelques opcodes portent des données : PUSH1 (0x60) est suivi d’un octet à placer sur la pile, et ainsi de suite jusqu’à PUSH32, qui en porte 32. Un contrat écrit en Solidity ou en Vyper est compilé dans ce format, comme le montre, côté développeur, notre guide pour apprendre Solidity.
Quand une transaction appelle un contrat, ses données d’entrée (calldata) commencent en général par un sélecteur de fonction de 4 octets, les quatre premiers octets du hash Keccak-256 de la signature de la fonction. 0xa9059cbb, par exemple, correspond à transfer(address,uint256), la fonction derrière la plupart des transferts de jetons. Les premières instructions du contrat lisent ces quatre octets et sautent vers le morceau de code correspondant. smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">Il n’existe pas d’autre mécanisme d’aiguillage.
La pile : 1 024 emplacements de 256 bits
C’est une machine à pile, d’une profondeur de 1 024 éléments, chaque élément étant un mot de 256 bits. Ethereum.org explique cette taille de mot par la cryptographie que la chaîne utilise chaque jour : les hashs Keccak-256 et les clés secp256k1 tiennent tous deux dans 256 bits. La plupart des opcodes prennent leurs entrées au sommet de la pile et y remettent leur résultat. ADD retire deux mots et empile leur somme, modulo 2^256.
La machine n’a pas de registres. Les instructions DUP et SWAP n’atteignent que les 16 éléments du haut, une limite que l’EIP-8024 (prévue pour Glamsterdam) lèverait avec trois nouvelles instructions, SWAPN, DUPN et EXCHANGE. Empiler un 1 025e élément, ou dépiler une pile vide, arrête l’exécution en cours avec une erreur.
Cinq endroits où garder des données, cinq durées de vie
Le code d’un contrat travaille avec plusieurs zones de données. Elles diffèrent par leur durée de vie et par leur coût, et cette différence façonne la manière d’écrire tout contrat.
| Zone de données | Ce qu’elle contient | Durée de vie | Coût typique (gas) | Qui peut y écrire |
|---|---|---|---|---|
| Pile | Jusqu’à 1 024 mots de 256 bits | Un cadre d’appel | 2 à 3 par opcode simple | Le code en cours d’exécution |
| Mémoire | Un tableau d’octets qui grandit à l’usage | Un cadre d’appel | 3 par accès à un mot, plus des frais d’extension croissants | Le code en cours d’exécution |
| Stockage (storage) | Paires clé-valeur de mots de 256 bits, par contrat | Permanente, fait partie de l’état du monde | 2 100 pour une première lecture (à froid), 100 à chaud ; 22 100 pour remplir un emplacement vide à froid | Seulement le code qui s’exécute dans le contexte de ce contrat |
| Stockage transitoire | Paires clé-valeur par contrat | Une transaction | 100 par TLOAD ou TSTORE | Seulement le code qui s’exécute dans le contexte de ce contrat |
| Calldata | Octets d’entrée de l’appel, en lecture seule | Un cadre d’appel | Payé par l’émetteur dans le gas intrinsèque | L’appelant |
Le stockage transitoire est la zone la plus récente. Il est arrivé avec l’EIP-1153 dans la mise à niveau Dencun du 13 mars 2024 (Cancun côté exécution) et ajoute deux opcodes, TLOAD (0x5c) et TSTORE (0x5d). L’EIP énonce sa durée de vie sans détour : « Toutes les valeurs du stockage transitoire sont supprimées à la fin de la transaction » (notre traduction). Il coûte une fraction du stockage et sert aux verrous anti-réentrance ou à passer des données entre contrats au sein d’une même transaction. Deux zones en lecture seule complètent le tableau : les données de retour du dernier appel, et le code du contrat lui-même.
Un programme de neuf octets, exécuté à la main
Le moyen le plus rapide de voir la machine, c’est de faire tourner un tout petit programme. Les neuf octets 0x600260030160005500 additionnent 2 et 3 et rangent le résultat dans l’emplacement de stockage 0. Chacun peut reproduire l’exécution avec la méthode eth_call d’un nœud public et un « state override » qui place ce code à une adresse vide.
60 02 PUSH1 0x02
60 03 PUSH1 0x03
01 ADD
60 00 PUSH1 0x00
55 SSTORE
00 STOP| Étape | Opcode | Pile après (sommet en premier) | Gas facturé | Gas d’exécution cumulé |
|---|---|---|---|---|
| 1 | PUSH1 0x02 | [2] | 3 | 3 |
| 2 | PUSH1 0x03 | [3, 2] | 3 | 6 |
| 3 | ADD | [5] | 3 | 9 |
| 4 | PUSH1 0x00 | [0, 5] | 3 | 12 |
| 5 | SSTORE (clé 0 au sommet, valeur 5) | [] | 22 100 | 22 112 |
| 6 | STOP | [] | 0 | 22 112 |
SSTORE prend la clé au sommet de la pile et la valeur juste dessous : l’ordre des empilements compte donc. Quatre instructions bon marché coûtent 12 gas au total ; l’unique écriture en stockage en coûte 22 100, car l’emplacement est touché pour la première fois dans la transaction (2 100) et passe de zéro à une valeur non nulle (20 000). Ajoutez les 21 000 gas que toute transaction paie avant qu’aucun code ne s’exécute, et la facture est de 43 112 gas. Le 10 novembre 2026, un nœud public a accepté l’appel avec une limite de 43 112 gas et l’a refusé avec 43 111, en répondant « out of gas ».
Cinq autres micro-programmes, exécutés de la même façon le même jour, donnent le prix des autres zones de données. Les chiffres ci-dessous sont du gas d’exécution, après la base de 21 000.
| Programme | Ce qu’il fait | Gas d’exécution mesuré (10 nov. 2026) |
|---|---|---|
| 0x60005400 | Lit une fois l’emplacement de stockage 0 (à froid) | 2 103 |
| 0x600054506000545000 | Lit deux fois l’emplacement 0 | 2 210 (2 100 à froid, puis 100 à chaud) |
| 0x600160005d00 | Écrit 1 dans l’emplacement transitoire 0 | 106 |
| 0x60005c5000 | Lit l’emplacement transitoire 0 | 105 |
| 0x600160005200 | Écrit un mot en mémoire | 12 (9 pour les opcodes, 3 pour agrandir la mémoire d’un mot) |
Comparez les lignes : remplir un emplacement de stockage vide a coûté 22 100 gas, une écriture transitoire 100, soit un rapport de 221 contre 1. Les concepteurs de contrats consacrent une bonne part de leurs efforts à éviter SSTORE.
Pourquoi chaque instruction a un prix
Le gas est d’abord un compteur, ensuite des frais
Le livre blanc de 2014 était franc sur le risque d’une chaîne programmable : l’EVM est Turing-complète, et « cela signifie que le code EVM peut encoder tout calcul concevable, y compris des boucles infinies » (notre traduction). Personne ne peut prédire en général si un programme s’arrêtera (le problème de l’arrêt), donc Ethereum n’essaie pas. Chaque transaction fixe une limite de gas ; la machine déduit le prix de chaque opcode avant de l’exécuter ; quand le compteur passerait sous zéro, l’exécution s’arrête avec une erreur de gas épuisé (out of gas), les changements d’état de cet appel sont annulés et le gas reste consommé. Une boucle sans fin finit simplement par manquer de gas. La leçon d’histoire raconte comment cette idée est née ; le mécanisme ci-dessus est ce qu’elle est devenue.
Les prix font partie du protocole. Le code source de Go Ethereum liste les valeurs en vigueur, et les EIP expliquent d’où elles viennent.
| Opération | Gas (règles du réseau principal en vigueur le 10 novembre 2026) | Source |
|---|---|---|
| ADD, PUSH1, MSTORE (base) | 3 chacun | Référence des opcodes d’ethereum.org |
| KECCAK256 | 30 plus 6 par mot de 32 octets haché | Paramètres du protocole de Go Ethereum |
| LOG0 à LOG4 | 375, plus 375 par topic, plus 8 par octet de données | Paramètres du protocole de Go Ethereum |
| SLOAD | 2 100 à froid, 100 à chaud | EIP-2929 |
| Accès à un compte (CALL, BALANCE, EXTCODESIZE…) | 2 600 à froid, 100 à chaud | EIP-2929 |
| CALL envoyant de l’ETH | 9 000 de plus ; 25 000 de plus si le compte destinataire n’existe pas | Paramètres du protocole de Go Ethereum |
| CREATE, CREATE2 | 32 000, plus 200 par octet de code déployé et 2 par mot de 32 octets de code d’initialisation ; CREATE2 ajoute 6 par mot pour hacher ce code | Paramètres du protocole de Go Ethereum |
| Base de la transaction (intrinsèque) | 21 000 | Paramètres du protocole de Go Ethereum |
Les prix à froid et à chaud ont une histoire. L’EIP-2929 (en anglais), activée avec la mise à niveau Berlin du 15 avril 2021 (bloc 12 244 000), a relevé le coût du premier accès à un compte ou à un emplacement de stockage dans une transaction, après les attaques par déni de service de 2016. L’EIP cite des rejeux où les transactions d’attaque mettaient de 20 à 80 secondes à s’exécuter, contre quelques millisecondes pour une transaction moyenne, et indique que multiplier ces prix par environ 3 ramène le pire cas à environ 7 à 27 secondes. Une analyse de transactions du réseau de test Goerli, ajoute-t-elle, a chiffré la hausse moyenne des coûts en gas à environ 2,36 %.
Ce que l’utilisateur paie au final, c’est le gas consommé multiplié par un prix par unité de gas, composé d’une base fee qui est brûlée et d’un pourboire pour le validateur. Ce mécanisme, l’EIP-1559 et l’histoire des frais relèvent de notre prochaine leçon sur le gas et l’EIP-1559. Pour la machine, deux limites comptent. Le bloc 26 383 691, produit à 09:43 UTC le 10 novembre 2026, avait une limite de gas de 60 millions, la valeur par défaut adoptée par les équipes de clients avec Fusaka (EIP-7935), et en a utilisé 33,57 millions, avec une base fee de 0,0549 gwei. Depuis la mise à niveau Fusaka du 3 décembre 2025, l’EIP-7825 plafonne aussi toute transaction isolée à 16 777 216 gas (2^24).
Déterministe par construction
Pour que des milliers de nœuds s’accordent sur une même racine d’état, chaque instruction doit donner partout le même résultat. L’EVM n’a donc ni nombres à virgule flottante, ni accès au réseau, ni système de fichiers, ni horloge autre que l’horodatage du bloc en cours. Tout ce qu’un contrat apprend du monde extérieur, un prix par exemple, doit être écrit sur la chaîne par une transaction, ce qui est le travail d’un oracle.
Cette rigueur est ce qui permet à des bases de code indépendantes, en Go, C#, Java et Rust, d’exécuter les mêmes blocs et d’aboutir à la même racine d’état. Les clients se vérifient aussi contre des suites de tests communes : ethereum.org note que tous les clients d’exécution qu’elle liste passent les tests des clients. Un utilisateur qui envoie une transaction par un nœud public n’a aucun moyen de savoir quel client l’a exécutée, et n’en a pas besoin.
Quand les contrats appellent des contrats
CALL, STATICCALL et DELEGATECALL décident quel stockage change
Un contrat peut en appeler un autre au milieu de sa propre exécution. Chaque appel ouvre un nouveau cadre, avec sa propre pile et sa propre mémoire. Trois opcodes font l’essentiel du travail, et le choix de l’un ou de l’autre détermine quelles données le code appelé peut toucher.
| Opcode (octet) | Code exécuté | Stockage modifié | Émetteur vu par l’appelé | Peut-il modifier l’état ? |
|---|---|---|---|---|
| CALL (0xF1) | Celui de la cible | Celui de la cible | Le contrat appelant | Oui, et il peut envoyer de l’ETH |
| STATICCALL (0xFA) | Celui de la cible | Aucun | Le contrat appelant | Non : toute tentative de modification échoue |
| DELEGATECALL (0xF4) | Celui de la cible | Celui de l’appelant | L’appelant de l’appelant | Oui, mais dans le stockage de l’appelant |
Le code source de Go Ethereum décrit DELEGATECALL comme l’exécution du code de la cible « avec l’appelant comme contexte », l’émetteur étant fixé à « l’appelant de l’appelant » (notre traduction). En clair, le contrat appelant emprunte la logique d’un autre contrat et l’exécute sur ses propres données.
C’est ainsi que fonctionnent les proxys évolutifs. Les 2 186 octets de l’adresse USDC sont un proxy : il garde les soldes dans son propre stockage et transmet chaque appel par DELEGATECALL à un contrat de logique distinct, dont l’adresse est conservée dans l’un des emplacements de stockage du proxy. Le 10 novembre 2026, cet emplacement pointait vers 0x4350…02dd. Remplacez l’adresse dans l’emplacement et le même jeton exécute un nouveau code. Qui détient ce pouvoir est une question de gouvernance que nous laissons à la leçon ultérieure sur les contrats évolutifs et les clés d’administration.
Un appel qui envoie de l’ETH transmet aussi une allocation de 2 300 gas au destinataire, trop peu pour écrire dans le stockage. Les anciens contrats qui comptent sur ce chiffre exact sont l’une des raisons pour lesquelles la révision des prix de Glamsterdam, décrite plus bas, est délicate.
CREATE et CREATE2 : où atterrissent les nouveaux contrats
Les nouveaux contrats naissent de l’exécution d’un code d’initialisation, dont le résultat devient le code stocké. Avec CREATE (0xF0), la nouvelle adresse dérive de l’adresse du créateur et de son nonce. Avec CREATE2 (0xF5), ajouté par l’EIP-1014 dans la mise à niveau Constantinople du 28 février 2019 (bloc 7 280 000), elle dérive de l’adresse du créateur, d’un sel (salt) choisi par le créateur et du hash du code d’initialisation. On obtient une adresse qui peut être calculée, et même approvisionnée, avant que le contrat existe, ce que les portefeuilles intelligents et les contrats usines utilisent largement.
La suppression de code a elle aussi changé. Depuis Dencun, l’EIP-6780 fait que SELFDESTRUCT ne supprime un compte que s’il est appelé dans la même transaction que celle qui a créé le contrat ; sinon, il se contente d’envoyer le solde ailleurs. La liste de Glamsterdam y ajoute l’EIP-8246, intitulée « Remove SELFDESTRUCT Burn ».
La mise à niveau Pectra du 7 mai 2025 a ajouté un rebondissement au hash de code des EOA. Avec l’EIP-7702 (en anglais), un EOA peut signer une autorisation qui écrit dans son propre champ de code un indicateur de délégation de 23 octets, 0xef0100 suivi d’une adresse de contrat. Les appels vers l’EOA exécutent alors le code du contrat délégué dans le contexte de l’EOA. Le 10 novembre 2026, un tel indicateur figurait dans le code d’au moins une adresse connue du réseau principal. Vous pouvez vérifier votre propre adresse de la même façon : un résultat d’eth_getCode qui commence par 0xef0100 signifie qu’elle est déléguée.
Les précompilés : du code natif aux adresses les plus basses
Certaines opérations seraient trop lentes ou trop coûteuses en bytecode EVM ; le protocole les fournit donc sous forme de contrats précompilés, à des adresses fixes. On les appelle comme n’importe quel contrat, mais ils s’exécutent en code natif à l’intérieur de chaque client. L’EIP-2929 les compte comme « à chaud » dès le début de chaque transaction.
| Adresse | Fonction | Arrivé avec |
|---|---|---|
| 0x01 | ecrecover : retrouve le signataire d’une signature secp256k1 | Dès le lancement, 2015 |
| 0x02 à 0x04 | SHA-256, RIPEMD-160, identité (copie de données) | Dès le lancement, 2015 |
| 0x05 | MODEXP : exponentiation modulaire | Byzantium, 16 octobre 2017 |
| 0x06 à 0x08 | Courbe alt_bn128 : addition, multiplication, vérification d’appariement | Byzantium, 16 octobre 2017 |
| 0x09 | Fonction de compression F de BLAKE2 | Istanbul, 8 décembre 2019 |
| 0x0a | Évaluation de point KZG (preuves de blobs) | Cancun, 13 mars 2024 |
| 0x0b à 0x11 | Sept opérations sur la courbe BLS12-381 | Prague (Pectra), 7 mai 2025 |
| 0x100 | P256VERIFY : vérifie les signatures secp256r1 (P-256) | Osaka (Fusaka), 3 décembre 2025 |
La liste vient des ensembles de précompilés du code source de Go Ethereum, un par fork. Les précompilés comptent aussi en dehors d’Ethereum : les chaînes qui se disent compatibles EVM ne livrent pas toujours le même ensemble, et un contrat qui en dépend peut échouer ailleurs.
Une transaction, de la signature au reçu
Les vérifications avant l’exécution du moindre code
Une transaction appartient à l’un de cinq types : 0 (historique, legacy), 1 (listes d’accès, EIP-2930), 2 (frais de l’EIP-1559, désormais la norme), 3 (transactions à blobs, EIP-4844) et 4 (autorisations de l’EIP-7702). Avant qu’un seul opcode ne s’exécute, le client vérifie que la signature permet de retrouver un émetteur, que le nonce correspond à celui du compte de l’émetteur, que le solde couvre la limite de gas multipliée par les frais maximaux plus l’éventuel ETH envoyé, et que la limite de gas couvre le gas intrinsèque : 21 000, plus des frais pour les calldata, les listes d’accès et la création de contrat. Depuis Fusaka, la limite de gas ne doit pas non plus dépasser 16 777 216. Une transaction qui échoue à ces contrôles n’est pas incluse du tout et ne coûte rien.
Exécution, annulation et validation
Une fois ces contrôles passés, le nonce de l’émetteur augmente, le gas est payé d’avance et l’EVM exécute le code de la cible. L’exécution se termine par STOP ou RETURN (succès), par REVERT (0xFD, un échec voulu qui peut renvoyer un message d’erreur) ou par un arrêt exceptionnel comme un manque de gas ou un opcode invalide. Un échec annule tous les changements d’état du cadre fautif, stockage transitoire compris, mais pas le gas dépensé. Une transaction échouée figure quand même dans son bloc, incrémente quand même le nonce et se paie quand même.
Libérer du stockage donne droit à un remboursement partiel de gas, plafonné depuis la mise à niveau London du 5 août 2021 à un cinquième du gas utilisé (EIP-3529). La liste de Glamsterdam comprend l’EIP-7778, qui cesse de compter les remboursements pour mesurer le remplissage d’un bloc.
Les portefeuilles demandent à un nœud d’estimer le gas dont une transaction a besoin, avec l’appel eth_estimateGas, et la réponse dépasse en général la consommation réelle. Pour notre programme de neuf octets, l’estimation du 10 novembre 2026 était de 43 488 gas, contre 43 112 réellement nécessaires. La marge est voulue : une transaction qui manque de gas échoue et paie quand même le gas qu’elle a brûlé.
Reçus et journaux : ce qu’une transaction laisse derrière elle
Chaque transaction produit un reçu : son statut (1 pour un succès, 0 pour un échec), le gas utilisé et les journaux (logs) qu’elle a émis. Les journaux sont écrits par les opcodes LOG0 à LOG4. Les contrats ne peuvent pas les lire ; ils existent pour les portefeuilles, les explorateurs et les applications, et coûtent bien moins cher que le stockage. L’en-tête du bloc s’engage sur tous les reçus par une racine des reçus, tout comme il s’engage sur l’état.
Un exemple réel : la transaction 0x7c26…416b, dans le bloc 26 383 708 le 10 novembre 2026, a appelé le contrat USDT avec le sélecteur 0xa9059cbb. Elle a fixé une limite de gas de 64 043, en a utilisé 63 209 et a réussi. Son reçu contient un journal du contrat USDT. Le premier topic, 0xddf2…b3ef, est le hash Keccak-256 de Transfer(address,address,uint256) ; les deuxième et troisième topics sont l’émetteur et le destinataire ; le champ de données est le montant, 58 709 442 en unités brutes, soit 58,709442 USDT puisque le contrat déclare six décimales. Notre guide pour lire un explorateur de blocs montre où ces champs apparaissent sur Etherscan.
Qui fait tourner la machine : cinq clients d’exécution et un lien avec le consensus
Geth, Nethermind, Besu, Erigon et Reth, comptés de différentes façons
En tant que spécification, l’EVM ne fait rien toute seule. Elle s’exécute dans des clients d’exécution, les programmes qui reçoivent les transactions, les exécutent et conservent l’état. Ethereum.org liste Geth (Go), Nethermind (C# .NET), Besu (Java), Erigon (Go) et Reth (Rust), plus le plus récent ethrex (Rust). Notre guide sur ce qu’est un nœud explique comment ils s’insèrent sur une machine.
Savoir combien de nœuds font tourner chaque client est plus difficile qu’il n’y paraît. Les sources mesurent des choses différentes et ne concordent pas.
| Source (pages lues le 10 nov. 2026) | Ce qu’elle mesure | Geth | Nethermind | Besu | Reth | Erigon |
|---|---|---|---|---|---|---|
| Ethernodes, affiché sur clientdiversity.org, mis à jour chaque jour | Nœuds visibles par un robot d’exploration avec des places libres pour des pairs | 50,13 % | 25,46 % | 9,45 % | 7,67 % | 6,53 % |
| supermajority.info, affiché sur clientdiversity.org, mis à jour à la main | Déclarations des opérateurs, 59,4 % du réseau couvert, dont une bonne part date de plus d’un an | 43 % | 43 % | 8 % | 3 % | 3 % |
| Instantané de supermajority.info du 26 oct. 2025, affiché sur ethereum.org | Déclarations des opérateurs | 41 % | 38 % | 16 % | 2 % | 3 % |
Clientdiversity.org avertit lui-même que les chiffres d’Ethernodes reflètent les clients qui affichent des places libres pour des pairs, qu’on comprend « mal » (« not well understood ») le lien avec ce que les opérateurs font réellement tourner, et il tient les données d’enquête d’execution-diversity.info pour la source la plus fiable. La page de diversité des clients d’ethereum.org affiche l’instantané d’octobre 2025 dans la dernière ligne, tandis qu’une autre phrase de la même page donne encore à Geth « environ 85 % » des nœuds, un chiffre des années précédentes. Le résumé honnête : Geth a perdu son ancienne supermajorité et, selon la méthode, il fait tourner entre quatre et cinq nœuds sur dix.
L’API Engine : comment l’EVM reçoit ses ordres depuis The Merge
Depuis The Merge du 15 septembre 2022 (bloc 15 537 394), un client d’exécution ne décide plus quel bloc vient ensuite. Un client de consensus distinct, comme Lighthouse, Prysm, Teku, Nimbus, Lodestar ou Grandine, fait tourner la preuve d’enjeu et dit au client d’exécution quoi faire par l’API Engine : engine_newPayload lui remet un bloc à exécuter et à vérifier, et engine_forkchoiceUpdated lui indique quelle tête de chaîne suivre ou lui demande de construire un bloc. La spécification de l’API Engine (en anglais) dit que la couche de consensus « pilote » (drives) la couche d’exécution, sur un port dédié (8551 par défaut) protégé par une authentification JWT. Le fonctionnement du côté consensus fait l’objet de notre leçon ultérieure sur The Merge et la preuve d’enjeu.
Pourquoi le bug d’un client compte : les seuils d’un tiers et de deux tiers
Sur la couche de consensus, les seuils sont arithmétiques. D’après ethereum.org, un bug dans un client de consensus utilisé par plus d’un tiers des nœuds pourrait empêcher la chaîne de se finaliser, et un bug critique dans un client qui a une majorité des deux tiers pourrait finaliser une chaîne invalide, laissant ses validateurs bloqués et exposés au slashing. Clientdiversity.org fixe le même objectif pour tous les clients, une part inférieure à 33 %, et dit que les risques « s’appliquent aussi bien aux clients de consensus qu’aux clients d’exécution » (notre traduction).
L’épisode Reth de novembre 2026 montre l’autre face de la pièce. Reth tourne sur 2 % à 8 % des nœuds Ethereum selon le décompte du tableau, loin du seuil du tiers. En revanche, Base, BSC-Reth de BNB Chain et Tempo font tourner des nœuds fondés sur Reth, et pour eux le même bug était une raison de corriger en quelques jours. Le risque d’un bug de client dépend du nombre de nœuds d’un réseau donné qui font tourner ce client.
La même machine sur d’autres chaînes
Compatible EVM, équivalent EVM et identifiant de chaîne
Comme l’EVM est une spécification publiée avec plusieurs implémentations ouvertes, des dizaines d’autres réseaux la font tourner. La liste des chaînes de DefiLlama, lue le 10 novembre 2026, en suit 422, dont 238 ont un identifiant de chaîne (chain ID) renseigné, le numéro que les portefeuilles EVM utilisent pour distinguer les réseaux. Les plus importantes par valeur totale verrouillée, selon DefiLlama à la même date, figurent ci-dessous.
| Chaîne | Valeur verrouillée selon DefiLlama (10 nov. 2026) | Chain ID | Remarque |
|---|---|---|---|
| Ethereum | 41,74 milliards de dollars | 1 | L’EVM de référence |
| Base | 5,72 milliards de dollars | 8453 | Couche 2 bâtie sur l’OP Stack |
| BNB Smart Chain | 5,10 milliards de dollars | 56 | Son propre ensemble de validateurs |
| Arbitrum | 1,40 milliard de dollars | 42161 | Rollup optimiste |
| Monad | 0,94 milliard de dollars | 143 | Couche 1 distincte |
| Polygon | 0,62 milliard de dollars | 137 | Chaîne Polygon PoS |
| Avalanche | 0,61 milliard de dollars | 43114 | C-Chain |
L’identifiant de chaîne est signé dans chaque transaction moderne (EIP-155, elle aussi de Spurious Dragon), si bien qu’une transaction valide sur un réseau ne peut pas être rejouée sur un autre. Les adresses, en revanche, ont le même format de 20 octets sur toutes les chaînes EVM. La même clé privée contrôle la même adresse sur Ethereum, Base ou BNB Chain, ce qui est pratique et explique aussi pourquoi des fonds envoyés sur le mauvais réseau peuvent arriver à une adresse que leur propriétaire n’avait jamais voulu utiliser là.
« Compatible EVM » signifie qu’une chaîne exécute le même bytecode avec la même sémantique de base. Cela ne promet ni des prix de gas identiques, ni les mêmes précompilés, ni les mêmes temps de bloc, ni les derniers opcodes. Les rollups qui se règlent sur Ethereum, comparés dans notre guide sur la couche 1 et la couche 2, tendent à suivre de près le réseau principal ; notre leçon ultérieure sur les couches 2 ira plus loin.
Les types 1 à 4 de zkEVM selon Vitalik Buterin
Les rollups à divulgation nulle de connaissance font face à une version plus difficile de la question, car ils doivent prouver l’exécution de l’EVM, et certaines de ses fonctions sont coûteuses à prouver. Dans un article du 4 août 2022, Vitalik Buterin a classé les zkEVM par types (en anglais). « Les ZK-EVM de type 1 s’efforcent d’être entièrement et sans compromis équivalents à Ethereum », a-t-il écrit (notre traduction) ; chaque type suivant sacrifie un peu d’équivalence pour des preuves plus rapides.
| Type | Ce qu’il conserve et ce qu’il change |
|---|---|
| 1 | Ethereum à l’identique, y compris les hashs et les arbres d’état : le plus lent à prouver |
| 2 | Équivalent à l’EVM, mais modifie des structures externes comme l’arbre d’état pour accélérer les preuves |
| 2.5 | Comme le type 2, avec des prix de gas plus élevés pour les opérations difficiles à prouver |
| 3 | Presque équivalent : abandonne ou modifie quelques fonctions, comme certains précompilés |
| 4 | Compile le code source Solidity ou Vyper vers un langage adapté aux preuves, sans passer par le bytecode EVM |
Cette classification date de 2022, et des projets ont changé de type depuis. Il revient à la documentation de chaque projet de dire dans quel type se range aujourd’hui son réseau.
Comment l’EVM continue de changer
Fork après fork : les mises à niveau qui ont changé la machine
La machine d’Ethereum n’a jamais été figée. Le tableau liste les mises à niveau qui l’ont le plus modifiée, avec les dates et les blocs de la page d’historique d’ethereum.org et le contenu tiré des EIP.
| Mise à niveau | Date (UTC) et bloc | Ce qui a changé dans l’EVM |
|---|---|---|
| Spurious Dragon | 22 nov. 2016, bloc 2 675 000 | Limite de code de 24 576 octets (EIP-170), identifiant de chaîne dans les signatures (EIP-155) |
| Byzantium | 16 oct. 2017, bloc 4 370 000 | Précompilés MODEXP et alt_bn128 |
| Constantinople | 28 févr. 2019, bloc 7 280 000 | CREATE2 (EIP-1014) |
| Istanbul | 8 déc. 2019, bloc 9 069 000 | Précompilé BLAKE2 |
| Berlin | 15 avr. 2021, bloc 12 244 000 | Prix d’accès à froid et à chaud (EIP-2929), listes d’accès (EIP-2930) |
| London | 5 août 2021, bloc 12 965 000 | Frais de l’EIP-1559, remboursements plafonnés (EIP-3529) |
| Shanghai (Shapella) | 12 avr. 2023, bloc 17 034 870 | PUSH0 (EIP-3855), limite du code d’initialisation (EIP-3860) |
| Cancun (Dencun) | 13 mars 2024, bloc 19 426 587 | Stockage transitoire, MCOPY, SELFDESTRUCT restreint, blobs et précompilé KZG |
| Prague (Pectra) | 7 mai 2025, bloc 22 431 084 | Délégation de code des EOA (EIP-7702), précompilés BLS12-381 |
| Osaka (Fusaka) | 3 déc. 2025, bloc 23 935 694 | Opcode CLZ, P256VERIFY, plafond de gas par transaction, limite de gas de bloc par défaut de 60 M |
Glamsterdam : une révision des prix qui pourrait casser les contrats au gas codé en dur
La prochaine mise à niveau, Glamsterdam, a une liste planifiée dans son EIP méta 7773 (en anglais). Outre ses fonctions phares, la séparation proposeur-constructeur intégrée au protocole (présentée dans notre guide sur la protection contre le MEV et la PBS) et les listes d’accès au niveau du bloc, elle touche directement l’EVM : un opcode SLOTNUM (EIP-7843), les instructions de pile plus profondes de l’EIP-8024, des contrats plus gros (EIP-7954), un journal pour chaque transfert d’ETH (EIP-7708) et un nouveau barème de gas.
Le nouveau barème est la partie sensible. L’EIP-8037 fixe le prix de la création d’état à l’octet : 1 530 gas par nouvel octet d’état. Un nouveau compte compte pour 120 octets, soit 183 600 gas contre 25 000 avec les règles actuelles ; un nouvel emplacement de stockage compte pour 64 octets, soit 97 920 gas contre 20 000. L’EIP-8038 relève le coût de lecture et d’écriture de l’état existant. Les deux EIP étaient au statut Last Call le 10 novembre 2026. L’article du 24 août 2026 de la Fondation Ethereum (en anglais) dit que le nouveau barème découle d’un objectif d’environ trois fois plus de débit de base, et que le rejeu de transactions historiques du réseau principal sous ce barème montre qu’« un petit ensemble de smart contracts » repose sur des hypothèses qu’il déplace. « La plupart des problèmes signalés se règlent par une hausse de la limite de gas », ajoute l’article (notre traduction). Les contrats qui peuvent casser même avec plus de gas sont ceux qui s’appuient sur des allocations fixes comme les 2 300 gas de transfer et send en Solidity, codent des valeurs de gas en dur dans leurs appels, se branchent sur le gas restant ou dépendent de transactions présignées à limite de gas fixe.
Tout le monde n’est pas rassuré. Le 8 novembre 2026, deux développeurs ont déposé des brouillons concurrents pour protéger les anciens contrats, comme le détaille notre article sur les propositions rivales pour Glamsterdam : la pull request 12638 de Leo Glisic versionnerait les opcodes pour que les contrats existants gardent les anciens prix, et la pull request 12637 de Giulio Rebuffo séparerait le gas qu’un contrat voit de celui qui lui est facturé. Les deux étaient encore ouvertes sur GitHub le 10 novembre 2026, sans code de client. Les développeurs du noyau se réunissent le 12 novembre (ACDC #191) et le 19 novembre (ACDE #249), et Glamsterdam n’a pas de date sur le réseau principal.
EOF : ni dans Fusaka ni dans Glamsterdam
L’EVM Object Format (EOF) était un plan préparé de longue date pour envelopper le bytecode dans un conteneur structuré qui sépare le code des données et qui est validé au déploiement. Il ne figure ni dans la liste finale de Fusaka (EIP-7607) ni dans la liste planifiée de Glamsterdam (EIP-7773), et son EIP méta, l’EIP-7692, est marquée Stagnant au 10 novembre 2026.
RISC-V : une proposition de 2025, pas un plan
Le 20 avril 2025, Vitalik Buterin a publié sur le forum Ethereum Magicians une proposition à long terme (en anglais) visant à « remplacer l’EVM par RISC-V comme langage de machine virtuelle dans lequel les smart contracts sont écrits » (notre traduction). Les comptes, le stockage et les appels entre contrats resteraient tels quels ; des opcodes comme SLOAD, SSTORE et CALL deviendraient des appels système ; les anciens contrats EVM continueraient de fonctionner et d’interagir avec les nouveaux. Sa raison, c’est la preuve : il écrivait que l’exécution des blocs représentait environ la moitié du travail des prouveurs à divulgation nulle de connaissance de l’époque, si bien qu’une machine virtuelle plus proche de ce que les prouveurs utilisent déjà aiderait. Des réponses dans le fil soulignent que l’EVM travaille nativement avec des nombres de 256 bits, qu’une machine RISC-V devrait découper en morceaux plus petits, au prix de la vitesse. Au 10 novembre 2026, l’idée ne figure dans la liste d’aucune mise à niveau.
Ce que la machine change pour les utilisateurs, les développeurs et les tribunaux
Pour un développeur, le modèle de coûts de l’EVM est le cahier des charges : chaque emplacement de stockage évité économise des milliers de gas, et chaque valeur de gas codée en dur est un pari sur un barème que Glamsterdam s’apprête à changer. Pour un utilisateur, deux habitudes découlent de cette leçon. Une transaction échouée coûte quand même du gas, donc l’alerte d’un portefeuille annonçant qu’une transaction va échouer mérite l’attention. Et un rapide eth_getCode sur votre propre adresse, ou l’onglet de code d’un explorateur, vous dit si elle porte une délégation EIP-7702 que vous n’avez pas voulue.
Un code sans propriétaire est aussi arrivé devant les tribunaux. Le 26 novembre 2024, dans l’affaire Van Loon v. Department of the Treasury, la cour d’appel fédérale du cinquième circuit des États-Unis a jugé que « les smart contracts immuables de Tornado Cash (les lignes de code logiciel qui protègent la vie privée) ne sont pas la « propriété » d’un ressortissant ou d’une entité étrangers » (notre traduction), de sorte que l’OFAC ne pouvait pas les bloquer en vertu de la loi de sanctions IEEPA, comme l’énonce l’opinion (en anglais). L’opinion explique que les développeurs avaient renoncé à leur contrôle sur les contrats des pools lors d’une « trusted setup ceremony » en 2020, après quoi ces contrats sont devenus irréversiblement immuables. Le 21 mars 2025, le Trésor a retiré Tornado Cash de sa liste de sanctions, en invoquant « les questions juridiques et politiques inédites » que soulève une telle sanction (notre traduction). La décision porte sur des contrats immuables ; un proxy dont la logique peut être remplacée, comme celui qui se trouve derrière USDC, n’était pas soumis à la cour.
Les prochaines dates à suivre sont les réunions des développeurs du noyau du 12 novembre (consensus) et du 19 novembre 2026 (exécution), toutes deux avec Glamsterdam à l’ordre du jour. Ce qu’ils décideront sur le barème de gas fera partie de la fonction qui transforme une racine d’état en la suivante.
