---
title: "Ethereum Virtual Machine (EVM)"
description: "Guide sensible au fork sur les transactions EVM, les appels de message, le bytecode, la pile, la mémoire, le stockage, le gas, REVERT, DELEGATECALL, les précompilés, les reçus et le rapprochement d'état."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Ethereum Virtual Machine (EVM)
> À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.
## Réponse directe
L'Ethereum Virtual Machine est la machine de transition d'état de la couche d'exécution qui interprète le bytecode selon les règles d'un fork donné. À pré-état valide, transaction ou message de premier niveau, environnement de bloc et spécification de fork identiques, les clients conformes doivent calculer le même post-état ou résultat d'échec. L'EVM ne choisit pas l'ordre des transactions, n'assure pas la finalité du consensus, n'authentifie pas une interface et ne confère pas à toute chaîne compatible EVM la sécurité d'Ethereum.
Une transaction signée de l'extérieur est un objet protocolaire de premier niveau. L'activité entre contrats se compose d'appels de message et de cadres d'appel imbriqués, et non de transactions indépendantes possédant leur propre nonce, reçu ou hash. Chaque cadre contient code, compteur ordinal, pile de 256 bits, mémoire, calldata, returndata, gas et contexte d'exécution ; le stockage persistant appartient à un compte, tandis que le stockage transitoire dure le temps de la transaction selon les règles du fork.
## Fonctionnement
1. Figer l'instantané d'exécution : chaîne et `chainId`, réseau, numéro et hash du bloc, statut canonique ou finalisé, fork, client et révision de spécification, pré-état ou racine d'état, type de transaction, octets signés, hash et reçu. Le déterminisme dépend de ce contexte exact.
2. Décoder l'enveloppe et séparer la validité préalable de l'exécution. Vérifier signature et émetteur, nonce, destination ou création, valeur, calldata, limite de gas, champs tarifaires, liste d'accès et champs propres au type. Un rejet avant inclusion n'est pas une transaction incluse dont l'exécution a fait revert.
3. Construire le message de premier niveau et l'arbre d'appels complet. Consigner les cadres `CALL`, `STATICCALL`, `DELEGATECALL`, de création et de précompilé, ainsi que l'appelant, l'adresse de contexte, l'adresse du code, `msg.sender`, `msg.value`, le transfert de valeur, calldata, returndata, le gas transmis et l'indicateur de succès. L'étiquette « transaction interne » d'un explorateur est une vue de trace, pas une transaction signée.
4. Retracer pour chaque cadre le compteur ordinal, la pile, la mémoire, calldata, returndata, les logs, le stockage persistant et le journal du stockage transitoire. `CALL` utilise l'adresse et le contexte de stockage de l'appelé ; `DELEGATECALL` exécute le code cible dans l'adresse et le stockage de l'appelant tout en conservant l'émetteur et la valeur en amont ; `STATICCALL` interdit toute modification d'état.
5. Appliquer les règles de gas du fork : gas intrinsèque, coûts dynamiques des opcodes, expansion mémoire, accès cold et warm, transmission aux appels, stipend, précompilés, remboursements et plafonds de remboursement. Calculer ensuite les frais séparément de la valeur à partir du gas consommé et du prix effectif. Une estimation de gas est conditionnelle, pas garantie.
6. Résoudre les résultats selon leur portée. `RETURN` ne valide le cadre que si ses ancêtres sont ensuite validés. `REVERT` annule le cadre et ses descendants, renvoie des données et ne consomme pas nécessairement tout le gas restant du cadre ; les arrêts exceptionnels diffèrent. Un parent peut intercepter l'échec d'un appel bas niveau et poursuivre, si bien que le statut du reçu peut être `1` malgré l'échec d'un enfant. Un échec de premier niveau inclus consomme néanmoins le nonce et le gas payé.
7. Rapprocher le statut du reçu, le gas utilisé, les logs, l'adresse créée et les données renvoyées avec les soldes, nonces, code, stockages persistant et transitoire, registres de tokens, traces et racine d'état avant et après. Si nécessaire, réexécuter avec un client indépendant et auditer séparément implémentations proxy, agencements de stockage, précompilés, cibles EVM du compilateur et changements de fork par rapport à la finalité du consensus.
## Exemples détaillés
- **Revert de premier niveau et registre des frais.** Une transaction de type 2 a une limite de gas de `80,000`, consomme `52,000`, avec un base fee de `20 gwei`, un max priority fee de `3 gwei` et un max fee de `40 gwei`. Le prix effectif vaut `min(40, 20 + 3) = 23 gwei` ; les frais réels sont `52,000 * 23 gwei = 0.001196 ETH`, dont `52,000 * 20 gwei = 0.001040 ETH` brûlés et `52,000 * 3 gwei = 0.000156 ETH` de priority fee. Les `28,000 gas` inutilisés ne sont pas facturés. Si l'exécution de premier niveau fait revert, stockage, transfert de valeur et logs sont annulés, mais le nonce et les frais réels demeurent.
- **Échec enfant intercepté.** Le contrat A commence à `A.x = 5`. Il appelle B ; B écrit `B.y = 9`, émet un log et exécute `REVERT`. L'écriture et le log de B sont annulés. A observe `success = false`, écrit `A.x = 7` et se termine normalement. Le statut final du reçu est `1`, `A.x = 7` et B conserve sa valeur antérieure. Le succès de premier niveau ne prouve donc pas la réussite de chaque appel enfant.
- **Contexte de stockage de DELEGATECALL.** Un proxy possède `slot0 = 5` et le compte d'implémentation `slot0 = 99`. Le code lit le slot 0, ajoute `7` et stocke le résultat. Exécuté par `DELEGATECALL`, il porte le proxy à `slot0 = 12`, tandis que l'implémentation reste à `slot0 = 99` ; l'adresse et le stockage du proxy s'appliquent, et l'émetteur ainsi que la valeur en amont sont conservés. Un agencement incompatible peut corrompre l'état du proxy.
- **SELFDESTRUCT propre au fork.** Sous la règle EIP-6780, un contrat existant détenant `2 ETH` exécute `SELFDESTRUCT` au bénéfice de B. B reçoit `2 ETH` et le solde du contrat devient nul, mais le compte, le code et le stockage existants ne sont pas supprimés. La suppression ne subsiste que si le contrat a été créé et autodétruit dans la même transaction. Cette règle est propre au fork, non rétroactive et pas nécessairement commune à toute chaîne EVM.
## Risques
- Réexécuter sur la mauvaise chaîne, le mauvais bloc, fork, client ou pré-état.
- Traiter comme final un état non canonique ou réorganisé.
- Confondre rejet préalable et revert inclus.
- Supposer qu'une simulation pending correspondra à l'état lors de l'inclusion.
- Ignorer un revert de premier niveau, un arrêt exceptionnel ou un manque de gas.
- Manquer l'échec d'un enfant intercepté par son parent.
- Mal interpréter contexte, adresse du code, appelant, émetteur ou valeur.
- Corrompre le proxy par incompatibilité d'agencement avec `DELEGATECALL`.
- Autoriser une réentrance ou un transfert externe dangereux de valeur et de contrôle.
- Faire confiance à des returndata, indicateurs de succès ou erreurs personnalisées non validés.
- Traiter logs ou traces comme état final faisant autorité.
- Mal calculer accès cold et warm, mémoire ou gas transmis.
- Mal appliquer remboursements, plafonds, stipend ou règle des `63/64`.
- Employer la mauvaise adresse, entrée, tarification ou sémantique de fork pour un précompilé.
- Confondre les durées du stockage persistant, de la mémoire et du stockage transitoire.
- Attendre une modification d'état dans `STATICCALL`.
- Appliquer à `SELFDESTRUCT` les anciennes hypothèses de suppression antérieures à EIP-6780.
- Manquer une dérive de l'implémentation proxy, de l'admin ou de la cible du compilateur.
- Exécuter des règles client divergentes ou non mises à jour.
- Déduire la sécurité du consensus, d'un bridge, d'un token, de la gouvernance ou de la finalité de la seule compatibilité EVM.
## Idées reçues
- Le code source Solidity est l'objet directement exécuté on-chain.
- Une transaction incluse qui fait revert ne coûte rien et ne modifie pas le nonce.
- Le statut `1` du reçu prouve que chaque appel interne a réussi comme prévu.
- Un événement ou une trace constitue l'état faisant autorité pour les actifs et le stockage.
- La compatibilité EVM garantit des opcodes, un gas, des précompilés, un consensus et une sécurité identiques.
## Sujets connexes
- [Modèle basé sur les comptes](/fr/crypto/account-based-model/)
- [Frais de gas](/fr/crypto/gas-fee/)
- [Smart contract](/fr/crypto/smart-contract/)
## Sources
- [Ethereum Virtual Machine (EVM)](https://ethereum.org/developers/docs/evm/) - Ethereum.org (consulté le 2026-08-12)
- [Ethereum Yellow Paper: a formal specification of Ethereum, a programmable blockchain](https://ethereum.github.io/yellowpaper/paper.pdf) - Ethereum Foundation (consulté le 2026-08-12)
- [Ethereum Execution Layer Specification](https://ethereum.github.io/execution-specs/) - Ethereum Execution Specs (consulté le 2026-08-12)
- [Introduction to Smart Contracts](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html) - Solidity Documentation (consulté le 2026-08-12)
- [EIP-7: DELEGATECALL](https://eips.ethereum.org/EIPS/eip-7) - Ethereum Improvement Proposals (consulté le 2026-08-12)
- [EIP-140: REVERT instruction](https://eips.ethereum.org/EIPS/eip-140) - Ethereum Improvement Proposals (consulté le 2026-08-12)
- [EIP-2929: Gas cost increases for state access opcodes](https://eips.ethereum.org/EIPS/eip-2929) - Ethereum Improvement Proposals (consulté le 2026-08-12)
- [EIP-6780: SELFDESTRUCT only in same transaction](https://eips.ethereum.org/EIPS/eip-6780) - Ethereum Improvement Proposals (consulté le 2026-08-12)
Source: https://wiki.fcontext.com/fr/crypto/evm/index.mdx