Ethereum Consensus & Nodes

How Ethereum Reaches Consensus

Ethereum uses Proof of Stake (PoS) (since The Merge). Validators stake ETH and run nodes to propose and attest blocks. Consensus ensures all nodes agree on the same chain and the same state.

How Proof of Stake Works in Ethereum

Ethereum launched with Proof of Work (PoW), where miners used hash power to produce blocks. In 2020, Ethereum introduced the Beacon Chain as the PoS consensus layer, running in parallel until The Merge moved Ethereum fully from PoW to PoS.

To become a validator, funds must be committed on-chain through Ethereum’s staking/deposit mechanism. This stake acts as economic collateral: validators earn rewards for correct participation and risk penalties if they violate consensus rules.

For each slot, the protocol pseudo-randomly chooses a block proposer and also assigns a committee of validators to attest (vote) on block validity. Over time, these attestations finalize checkpoints and make chain history increasingly hard to revert.

  • Honest behavior: Propose valid blocks, attest on time, and stay online to earn rewards.
  • Offline / poor performance: Missed attestations reduce rewards and can incur inactivity penalties.
  • Dishonest behavior: Actions like double-signing or conflicting attestations can trigger slashing, burning part of the validator’s stake.
Key idea: In Ethereum PoS, security comes from putting real economic value at risk. Attacking consensus means risking your own staked ETH.

Block Structure

Based on Ethereum's block structure (as shown on Etherscan), a block contains the following components:

Ethereum block explorer view showing block overview: height, status, timestamp, transactions, gas, fees, hashes and roots

Block details (block explorer): Overview of an Ethereum block showing header fields, gas and fees, and cryptographic hashes (hash, parent hash, state root, withdrawals root, nonce).

Block Header

  • Block Height/Number: The position of the block in the blockchain
  • Timestamp: When the block was created
  • Hash: Cryptographic hash of the block header
  • Parent Hash: Hash of the previous block (creates the chain)
  • State Root: Root hash of the state trie (all account balances and data)
  • Transactions Root: Root hash of the Merkle tree of all transactions
  • Receipts Root: Root hash of transaction receipts
  • Gas Limit: Maximum gas allowed in the block
  • Gas Used: Total gas consumed by transactions in the block
  • Base Fee Per Gas: Minimum gas price required (post-London upgrade)
  • Extra Data: Optional data that can be included by the block proposer
  • Nonce: Value used in proof of work (pre-Merge) or other consensus data

Block Body

  • Transactions: List of all transactions included in the block
  • Transaction Count: Number of transactions in the block
  • Withdrawals: Validator withdrawal requests (post-Shanghai upgrade)

Consensus Information (Post-Merge Ethereum)

  • Slot: The slot number in the beacon chain
  • Epoch: The epoch number (32 slots = 1 epoch)
  • Proposer Index: Identifier of the validator who proposed the block
  • Block Reward: Total reward received by the block proposer
  • Fee Recipient: Address that receives transaction fees

Additional Block Information

  • Status: Whether the block is finalized or pending
  • Size: Size of the block in bytes
  • Burnt Fees: Amount of ETH burned (post-London upgrade)
  • Total Difficulty: Cumulative difficulty (pre-Merge)
Note: The block structure has evolved over time. Ethereum's transition from Proof of Work to Proof of Stake (The Merge) changed some block fields. Always refer to the current network's specifications when working with blocks.

How Blocks Create the Chain

Each block contains a reference to its parent block through the "Parent Hash" field. This creates an immutable chain:

  1. Block 1 contains transactions and references "genesis" (no parent)
  2. Block 2 contains transactions and references Block 1's hash
  3. Block 3 contains transactions and references Block 2's hash
  4. And so on...

This chaining makes it extremely difficult to alter past blocks. Changing any block would require recalculating all subsequent blocks, which becomes computationally infeasible as the chain grows.

Types of Nodes in the Ethereum Ecosystem

Different nodes play different roles. You don’t need to run one to use Ethereum, but understanding them helps.

Execution layer nodes

  • Full node: Stores and validates all blocks and state. Can serve RPC and participate in execution (if also running consensus client).
  • Archive node: Full node that keeps full history (every state at every block). Used for indexing, analytics, and advanced tooling.
  • Light node (e.g. light client): Validates only what it needs (headers + Merkle proofs). Uses fewer resources; depends on full nodes for data.

Consensus layer nodes

  • Validator node: Runs execution + consensus client, holds staked ETH, proposes and attests blocks. Required for staking.
  • Beacon node (non-validating): Runs consensus client only; follows the chain and can serve other clients but does not stake or attest.

Other roles

  • RPC node: Exposes JSON-RPC (e.g. for wallets and dApps). Can be a full node, archive node, or a gateway to one.
  • Bootnode: Helps new nodes discover peers; only participates in discovery, not in validating blocks.
In practice: Many users rely on third-party RPC providers (e.g. Infura, Alchemy, public endpoints) instead of running their own node. For learning and testing, you can submit a signed transaction to Sepolia via such an endpoint.