Ethereum Execution, Consensus & Networking

Modern Ethereum is two cooperating protocols, not the proof-of-work monolith described by early white and yellow papers. An execution client validates transactions and computes EVM state transitions; a consensus client runs proof-of-stake fork choice and finality. They exchange payloads and validity status through the Engine API.

One node, separate responsibilities #

flowchart LR
  U["users / wallets"] --> EL["Execution client<br/>mempool, EVM, state"]
  VC["validator client"] --> CL["Consensus client<br/>fork choice, attestations, finality"]
  EL <--> |"Engine API"| CL
  EL <--> EN["execution peers<br/>devp2p / RLPx"]
  CL <--> CN["consensus peers<br/>libp2p gossip"]

The consensus layer chooses a beacon-chain head and carries an execution payload. The execution layer re-executes that payload and reports whether it is valid. Consensus votes cannot make an invalid EVM transition valid; execution validity and consensus ordering compose.

Execution as a state transition #

Ethereum's world state maps addresses to account records. Externally owned accounts use a nonce to order transactions; contract accounts additionally reference code and storage. A transaction is signed, pays gas, and either transfers value, creates a contract, or invokes code. The EVM deterministically changes state, emits logs, and returns success or failure.

Gas prices each operation and caps total work. Even a reverted call consumes gas because replicas performed the computation; remaining state changes from the call are rolled back. Header roots commit to execution state, transactions, and receipts so nodes can detect disagreement.

Fork choice and finality #

Ethereum proof of stake combines LMD-GHOST fork choice for the current head with Casper FFG checkpoint finality. Validators attest to a head and source/target checkpoints. A supermajority link representing at least two-thirds of stake justifies a target; the protocol then finalizes an earlier justified checkpoint under its rules.

Head selection can change during ordinary operation, while finalized history has a stronger guarantee: reverting it requires violating accountable-safety assumptions and exposes at least one-third of stake to slashing. During prolonged non-finality, inactivity penalties reduce non-participating balances so the live side can eventually regain a supermajority.

Networking is layered #

• Discovery finds peers. Discovery v4 uses a Kademlia-like XOR routing table and signed node identity; ENRs advertise endpoints and capabilities.
• RLPx is the encrypted, authenticated TCP transport for execution-layer peers. It derives session keys during a secp256k1-based handshake and multiplexes capabilities.
• eth wire protocol exchanges execution-chain status, blocks, transactions, receipts, and synchronization data over RLPx. The current version is not the short 2014 PDF supplied in the folder.
• Consensus gossip is a distinct libp2p network for beacon blocks, attestations, and related objects.

Reading the supplied historical documents #

The original white paper is excellent motivation for a programmable state-transition system. The 2018 Yellow Paper precisely describes an older execution protocol, and the supplied wire/RLPx snapshots document early networking. Their proof-of-work, opcode, gas, transaction-envelope, and protocol-version details are historical. Current implementation work must start from the maintained execution, consensus, and devp2p specifications for the relevant fork.