A Deep Dive into Ethereum's Proof of Stake System

Hello Everyone…

Welcome to another day of exploring Web3 Engineering. It’s been a long time that Ethereum shifted from Proof-of-Work (PoW) to Proof-of-Stake (PoS) which has reduced the costs to become to run a node significantly as it now doesn’t require heavy hardware. Let’s explore this new procedure that provided this level of optimization to the network. So, without a further ado, let’s get started.

Post Merge Architecture

Before the merge, the entire codebase is split into Consensus and Execution layers. And when we want to run an Ethereum node, we need to run both of them.

Consensus Layer

The consensus layer is responsible for dealing with the consensus mechanism of the network, block producing, attestation, staking, node discovery, validator management etc. This layer has it’s own state called Beacon State which keeps the latest state of the node.

Execution Layer

The execution layer contains the Ethereum Virtual Machine (EVM), mempool management, transaction execution, Accounts management and contract management. All the smart contracts deployed on the network are stored in this layer and this layer is responsible for handling most of the RPC endpoints such as eth_getBalance, eth_call etc.

How does the consensus Work

Gasper is the consensus protocol used by Ethereum's Beacon Chain and post-merge mainnet. It is the combination of LMD-GHOST fork choice rule and Casper FFG finality gadget. This hybrid design is responsible for fast block production and finalization in a Proof-of-Stake system.

A fork choice rule is a set of instructions that blockchain nodes use to determine the "best" or canonical chain when there are multiple block heads available. In simple terms, rules to decide which one is the latest block when we have multiple options.

Finality refers to the point at which the transaction made can not be revoked.

Time in Ethereum PoS

• In Ethereum consensus, the timeline is divided into equal time intervals called Slots. Each slot at the moment is equal to 12 seconds right from the Genesis block and are numbered sequentially.

• Each slot should produce a maximum of 1 block and there are chances that slots will be empty without producing a block for various reasons such as no mempool transactions available, block syncing, gossip delay etc.

• There is also another notation called Epoch. 1 Epoch = 32 slots (32 × 12s). These Epochs are used to finalize the state.

Consensus Process

• Whenever a new epoch begins, a set of validators are picked up to produce the blocks in it. And for this set, these validators are all responsible for all the things in this epoch.

• And once, the epoch begins, in each slot, a random validator is picked up to produce the block.

• Once a slot begins, the validator who is selected for the producing the block (producer), validator client will makes necessary API calls to the Execution layer and creates a new block.

• Once the block generation is done, it will be forecasted via libp2p gossip pub to the network.

• Once the new block is received at the 4th second of the slot, the remaining validators (attestors) will verify the block and attests to it.

• These checks include

  • Whether the block follows the schema or not

  • Whether the previous block hash matches with their own block head or not

  • Presence of any faulty transactions

  • Blobs validations etc.,

• If all the details matches, then they emit an attestation to the network as below

{
  "aggregation_bits": "0x03",  // 2 validators aggregated (00000011)
  "data": {
    "slot": 123456,
    "index": 7,
    "beacon_block_root": "0xabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcd",
    "source": {
      "epoch": 3857,
      "root": "0x1234512345123451234512345123451234512345123451234512345123451234"
    },
    "target": {
      "epoch": 3858,
      "root": "0x5678956789567895678956789567895678956789567895678956789567895678"
    }
  },
  "signature": "0xb1aa1d5c456789abcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdef"
}

• If the new block is not received then they provide attestation to their current local head only which then creates multiple forks in the local chain.

• During this process, there’s an another actor that is selected from the validator set and is called Aggregator.

• This aggregator will collect all the attestation from the validators and then announces the new blockhead that receives the most number of attestations.

• Once all the attestations are received, the aggregator will publish the aggregated result. Then validator (producer / attestor) will update their local view of the chain with the block. And the slot ends.

• While adding the block, if the local network contains multiple fork choices, then the validator uses LMD-GHOST protocol to select the fork to which it can add the new block. And also we receive the start and end epochs as part of the attestation which are used by Casper FFG.

• Once the 32 slots are completed, then the Casper FFG protocol comes into play to finalize the epoch. If two consecutive checkpoints receive votes from at least two-thirds (≥66%) of validators, the earlier checkpoint is finalized. Any conflicting forks built on top of epochs earlier than the finalized one are considered invalid.Typically any block after 2 epochs is considered as finalized which is 12.8 seconds for better security.

Here is a second wise breakdown of the steps followed during a slot.

That’s all for this blog. As part of this series, we will keep digging deep into the consensus layer and the protocol stack used. Thank you