PoS Ethereum Part 1: Beacon Chain For Dummies
06/23/235 min read
by Mantle
DeFi
Tutorials
Web3
In December 2020, Ethereum underwent phase 0 of a significant upgrade known as “The Merge”, which would eventually replace the old Proof-of-Work (PoW) system with a new consensus mechanism called Proof-of-Stake (PoS).
Prelude
“There are only two hard things in Computer Science: cache invalidation and naming things”
The Merge centered around a critical component called "The Beacon Chain," a name that draws inspiration from the National Institute of Standards and Technology's (NIST) project on Interoperable Randomness Beacons. In simple terms, a beacon serves as a trusted source of public randomness.
In Ethereum's context, the Beacon Chain has a distinct purpose: It stores and oversees the list of validators — participants who have staked 32 Ether — who are responsible for running the PoS Ethereum system.
The Beacon Chain
Imagine the Beacon Chain as a lighthouse, towering over a vast ocean of transaction data. It diligently scans the waves, verifying, gathering votes, and rewarding the validators who accurately attest to blocks. At the same time, it deducts rewards from those who are offline and punishes malicious actors by slashing their staked ETH.
It's worth mentioning that the Beacon Chain doesn't handle user transactions or smart contract interactions; its role is solely to uphold Ethereum's consensus.
We can see this being reflected in the
BeaconState object definition, whereby the information encapsulated focuses on managing validators. You can find a more exhaustive list of data structures and object definitions relating to the Beacon Chain on the official Ethereum consensus specification here.1 class BeaconState(Container): 2 # Versioning 3 genesis_time: uint64 4 slot: Slot 5 fork: Fork 6 # History 7 latest_block_header: BeaconBlockHeader 8 block_roots: Vector[Root, SLOTS_PER_HISTORICAL_ROOT] 9 state_roots: Vector[Root, SLOTS_PER_HISTORICAL_ROOT] 10 historical_roots: List[Root, HISTORICAL_ROOTS_LIMIT] 11 #Eth1 12 eth1_data: Eth1Data 13 eth1_data_votes: List[Eth1Data, SLOTS_PER_ETH1_VOTING_PERIOD] 14 eth1_deposit_index: uint64 15 # Registry 16 validators: List[Validator, VALIDATOR_REGISTRY_LIMIT] 17 balances: List[Gwei, VALIDATOR_REGISTRY_LIMIT] 18 # Randomness 19 randao_mixes: Vector[Bytes32, EPOCHS_PER_HISTORICAL_VECTOR] 20 # Slashings 21slashings: Vector[Gwei, EPOCHS_PER_SLASHINGS_VECTOR] # Per-epoch sums of slashed effective balances 22 # Attestations 23 previous_epoch_attestations: List[PendingAttestation, MAX_ATTESTATIONS * SLOTS_PER_EPOCH] 24 current_epoch_attestations: List[PendingAttestation, MAX_ATTESTATIONS * SLOTS_PER_EPOCH] 25 # Finality 26 justification_bits: Bitvector[JUSTIFICATION_BITS_LENGTH] # Bit set for every recent justified epoch 27 previous_justified_checkpoint: Checkpoint # Previous epoch snapshot 28 current_justified_checkpoint: Checkpoint 29 finalized_checkpoint: Checkpoint
At the core of the Beacon Chain is the
state_transition function, which takes in a pre-state, and a signed block, and outputs a new state (known as the post-state). Note that the state in this context does not refer to smart contract or account balance state, but rather consensus state.1 def state_transition(state: BeaconState, signed_block: SignedBeaconBlock, validate_result: bool=True) -> BeaconState: 2 block = signed_block.message 3 # Process slots (including those with no blocks) since block 4 process_slots(state, block.slot) 5 # Verify signature 6 if validate_result: 7 assert verify_block_signature(state, signed_block) 8 # Process block 9 process_block(state, block) 10 # Verify state root 11 if validate_result: 12 assert block.state_root == hash_tree_root(state) 13 # Return post-state 14 return state
What Does the Validator Do?
The main duties of a validator in the context of the Beacon Chain (phase 0) include two tasks:
-
Proposing blocks
-
Generating attestations
Block proposals occur less frequently, while attestations are created once per epoch (each epoch contains 32 slots, and each slot is 12 seconds: totalling 6.4 minutes).
Validators are rewarded for consistently confirming the legitimacy of the Beacon Chain, and face penalties if they neglect this responsibility. Validators also receive rewards for including attestations in their block proposals.
It's important to understand that validators can face penalties, known as slashing, where they lose a portion of their staked ETH. This can happen if they break the consensus protocol or produce two beacon blocks within a single epoch (Casper FFG is the chosen consensus protocol).
What Happens If There Is a Disagreement?
Enter: the fork choice rule. The fork choice rule is a mechanism used in blockchain systems to determine which chain of blocks should be considered the valid one when multiple branches, or "forks," exist. It is a crucial part of maintaining consensus, and ensuring that all participants in the network agree on the same version of the blockchain.
The Merge adopted the fork choice rule called LMD Ghost (Latest Message-Driven Greedy Heaviest Observed Subtree). LMD Ghost takes into account not only the length of a chain, but also the weight of individual blocks and the messages exchanged by validators. This helps determine the most reliable and widely supported branch of the blockchain.
We will explore LMD Ghost in more detail in the next article, and delve deeper into its inner workings and discuss its advantages and challenges.
Stay tuned!
