Couche d'Exécution (Execution Layer)
Le composant d'une blockchain modulaire responsable du traitement des transactions, de l'exécution des smart contracts et de la mise à jour de l'état du réseau, distinct du consensus.
Avant 'The Merge' (septembre 2022), les clients comme Geth géraient à la fois l'exécution et le consensus Proof-of-Work. The Merge a supprimé la logique PoW, transformant Geth en un pur client de Couche d'Exécution.
graph LR
Center["Couche d'Exécution (Execution Layer)"]:::main
Pre_smart_contracts["smart-contracts"]:::pre --> Center
click Pre_smart_contracts "/terms/smart-contracts"
Rel_consensus_layer["consensus-layer"]:::related -.-> Center
click Rel_consensus_layer "/terms/consensus-layer"
Rel_data_availability_layer["data-availability-layer"]:::related -.-> Center
click Rel_data_availability_layer "/terms/data-availability-layer"
Rel_account_abstraction["account-abstraction"]:::related -.-> Center
click Rel_account_abstraction "/terms/account-abstraction"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧒 Explique-moi comme si j'avais 5 ans
Imagine la [blockchain](/fr/terms/blockchain) comme un restaurant. La Couche d'Exécution est la cuisine : elle prend les commandes (transactions), suit les recettes ([smart contracts](/fr/terms/smart-contracts)) et prépare les plats (met à jour l'état). La Couche de Consensus est le gérant : il ne cuisine pas, mais vérifie que la cuisine a respecté les règles et valide les tickets de caisse. Sur [Ethereum](/fr/terms/ethereum) aujourd'hui, la cuisine et le gérant sont deux programmes séparés qui discutent entre eux.
🤓 Expert Deep Dive
L'Engine API : La séparation EL/CL nécessite un canal sécurisé. La CL est le 'pilote'. Elle utilise engine_newPayload pour transmettre un bloc à l'EL pour validation, et engine_forkchoiceUpdated pour dicter la tête de la chaîne. Clients d'Exécution : La diversité des clients (Geth, Nethermind, Erigon, Besu) est cruciale pour éviter qu'un bug dans un client majoritaire (Geth) ne corrompe le réseau. Rollups en tant qu'EL : Dans l'approche modulaire, les Rollups (Arbitrum, Optimism) sont de pures couches d'exécution qui externalisent le calcul de L1 tout en y publiant leurs preuves.
❓ Questions fréquentes
What is the difference between the Execution Layer and the Consensus Layer?
The Execution Layer processes transactions, runs smart contracts (EVM), and updates user balances. The Consensus Layer does not process transactions; instead, it coordinates validators to vote on which blocks are valid and ensures the network agrees on a single, final history of the chain.
What were the Execution Layer and Consensus Layer called before The Merge?
Historically, the Execution Layer was referred to as 'Eth1' (the original Ethereum PoW chain), and the Consensus Layer was referred to as 'Eth2' (the Beacon Chain). The Ethereum Foundation deprecated these terms in favor of EL and CL to emphasize that they are two components of a single, unified network, not sequential upgrades.
How do Layer 2 Rollups fit into this model?
Layer 2 Rollups (like Arbitrum or Base) are essentially standalone execution layers. They handle all the heavy transaction processing off-chain, and then use Ethereum (Layer 1) strictly for consensus, data availability, and final settlement.