Ethereum 2.0 - The How
We delve deeper into the inner workings of the protocol post the merge, covering the beacon chain, and the functioning of Ethereum's proof-of-stake mechanism
In an earlier post, we spoke of the ‘Merge’ and why it holds monumental significance in the Ethereum ecosystem.
So while our former post was all about the WHY, this is all about the HOW. We delve deep into the inner-workings of Eth 2.0, the beacon chain, and the functioning of the new Proof-of-Stake consensus mechanism
To be fair, unpacking this is definitely not necessary. It’s a bit like explaining TCP/IP protocols to understand the internet. But this is a novel technology, so down the rabbit hole we go...
Overview of Eth 2.0
Ethereum 1.0 today has one main (canonical) chain that runs on a Proof-of-Work consensus mechanism.
Ethereum 2.0 will undergo major changes in phases:
Phase 0 - Beacon Chain that introduced Proof-of-Stake to the ethereum ecosystem
Phase 2 - Sharding i.e. splitting up the chains into parallel chains to increase throughput. It’s the equivalent of increasing lanes in a highway as opposed to increasing speed limit to reduce congestion. We’ll touch upon this in a separate post later
Phase 2 - Execution
Phase 0, i.e. the Beacon chain went live in Dec 2020. Since then, while the main Proof-of-Work chain still remains as the main blockchain of record, there is a parallel chain that has been running on a Proof-of-Stake mechanism
The ‘Merge’ is the term used to describe the event in future, when the current main chain plugs into the beacon chain (like a tributary into a river), after which the beacon chain becomes the main chain, and we retire the POW mechanism. This is expected to happen sometime in Q3 2022
So naturally, a good place to start this story will be at the functioning beacon chain
Please note that the ethereum community is phasing out the terminology of eth 1.0 and eth 2.0 to avoid confusion of two seperate systems. They are now also referred to as the ‘execution layer’ and ‘consensus layer’ of what will be a single blockchain post the merge. For our purposes, we’ll still continue to call it by the colloqial terms
Beacon chain
Before we delve into how it works, it’s useful to recap the objectives of what the beacon chain is trying to achieve.
At the simplest level, the blockchain is a shared ledger that contains some data in a serialized order (i.e. a chain of blocks).
Let’s take a hypothetical village, where there are 100,000 people. These 100,000 people transact frequently amongst themselves with IOUs, so they decided to record all these IOUs with the village accountant. The problem was that the accountant’s ledger book was prone to getting edited, or sometimes even bribed to make changes.
To counter this, multiple villagers suggested maintaining their own versions of the ledger, so bad actors cannot tamper with several of them. Which leads us to the massively complex problem of ensuring that the ledgers of all honest villagers reflect the same information
We’ll explore the workings of the beacon chain within the realm of this village analogy
Step 0 - Genesis of the chain and Validators
So to kickstart this new ledger, a number of villagers came forward to act as ‘validators’, doing the job of validating the blockchain, and in return, hoping to earn some rewards for their work.
Each of them individually put in a minimum of 32 ETH, which is now considered ‘staked’. If they do anything underhanded, their stake may be impounded or ‘slashed’, and they may be kicked out of the system
The beacon chain begins when 16,384 villagers came forward as validators, and this timestamp is called Genesis. The Beacon chain is now officially live at this point (we’ll come to how this number is derived later)
Step 1 - Shuffling validators into committees
Let us introduce two new concepts here - slots and epochs.
A slot simply is a place for a block to be added. A new slot is serially added every 12 seconds in the chain.
An epoch is a collection of 32 slots. Once 32 slots are done, the epoch is said to be completed, and a new epoch has begun. So an epoch lasts for 6.4 minutes (32 x 12 seconds)
Now, the beacon chain acts like a coordinator. At the start of an epoch, the chain shuffles the villager-validators randomly into committees of a minimum of 128 validators. This is done by an algorithm called RANDDAO (you can read the technical aspects of RANDDAO here)
Each epoch is made of 32 slots, so with 16,384 validators, you have a minimum of 4 committees assigned to each slot. (32 * 128 * 4 = 16,384). Over time, Ethereum is planning to expand to 64 sharded chains, so the validator number requirements are set to increase. Which is not necessarily a problem - Ethereum has over 300k validators live today. You can track the active validators and total staked amounts here
So at this time, validators have been shuffled, and assigned to a slot. Now, the chain also randomly assigns one validator to be the block proposer for that slot.
Step 2 - Block proposal and validation
Now assume that there are lots of unverified transactions going around waiting to be confirmed. Villager A may broadcast, “I would like to pay villager B an amount X, and would like this added to the chain”.
When it is the block proposer’s slot, the block proposer gathers all unverified transactions that are broadcast and checks for transaction properness (e.g. no double spending, no transactions beyond the stored amount, etc.). The proposer puts the transactions in a block, that links to the hash of the previous block, and broadcasts this to other validators.
At this point, all the committees assigned to the slot will check if the proposed block is valid. This process of voting for validity is called an attestation. And the attestation is done by a technical vote called the LMD GHOST vote. This stands for Latest Message Driven, Greedy Heaviest Observed Subtree (LMD GHOST) vote.
Put it simply, if an attacker is building a forked chain, the co-ordinator will always choose the chain that has the most votes (heaviest) based on the latest messages, even if the other chain is longer. Read more about LMD GHOST here
There are also complexities of cross-linking to shard chains, which we won’t get into now, but will cover in a subsequent post
Once validated, the block proposer gets a monetary reward, which is inversely proportional to the number of validators on the chain.
If the vote fails or there are two blocks proposed, then the block proposer’s staked amount is slashed, and they may be given a timeout, or banned from the system
Step 3 - Epoch finality
This block addition process continues, and goes all the way upto slot 32. At this point, the epoch is considered to be complete, and the shuffling process reinitiaties.
There is one other piece though. In addition to casting their attestation vote for the block, each validator also casts a vote for an epoch checkpoint that they see. The block in the first slot of any epoch is considered to be the checkpoint (and if for some reason, the proposer missed adding a block, then the previous block is considered the checkpoint). This is done so that all the validators (across committees) have a same shared view of the chain.
This vote is called the CASPER FFG vote (humuorously termed Casper Friendly Finality Gadget). Without getting into the technicality, here’s a simple analogy:
LMD GHOST vote is like voting for your local MLA or municipal body. Only members of the committee assigned to that slot are allowed
CASPER FFG vote is like voting for the national government. Every validator in that epoch votes for it
When 2/3 of the active validators vote for a checkpoint, the checkpoint is considered to be in a state of ‘justified’.
And the moment a checkpoint in a subsequent epoch is justified, all previous checkpoints are considered final. And these transactions are (for all practical purposes) immutable.
Average finality time for a transaction
Now there’s a very important implication here for how long it takes for a transaction to become final. Consider this situation:
A transaction is added in a block in Epoch 1 - On average, the transaction will be added in the middle of the epoch, so let’s say block 15. Which means another 16 blocks are added after that in Epoch 1
Epoch 2 - 32 blocks are added here from block number 32 to 63. The checkpoint here is block 32, so when 2/3rds of epoch 87 votes for block 32 as the checkpoint, it and all previous blocks get justified
Epoch 3 - Blocks are added here from 64 to 95. Now, when 2/3rds of the validators vote on block 64 as the checkpoint, it gets justified. And this automatically finalizes block 32 and every block before that
So transaction would on average require 16 blocks in epoch 1, 32 blocks in epoch 2, and about 22 blocks in epoch 3 (2/3rds). So on average, it would take about 14 minutes for someone to be sure about a finalized transaction. Good for business txns. Definitely not for retail commerce, but that’s the design choice made ****
In conclusion, I’m adding a caveat - there are a ton of simplifications made here and details glossed over, espeically in the edge cases. But the core process was still fascinating to understand and watch it happen. Two recommendations:
Watch the beacon chain live here - https://beaconcha.in/ - Seeing blocks being proposed and added live is a powerful aid in understanding the concepts
Stake a little Eth - If you have some ETH in your own custodial wallet (e.g. Metamask), consider staking it in a staking pool like Lido, or I’d recommend Rocketpool. It’s a way to earn some APY (~4%) and also is a minor contribution from you to the functioning of the chain
And if you don’t have your Eth in your own custodial wallet, I strongly urge you to do so. Any tokens kept in an exchange wallet is not in your custody, but theirs, with their private keys. Not your keys, not your tokens.