¶ Finality
¶ The World Computer
Ethereum is the World Computer, a single, globally shared computing platform that exists in the space between a network of 1,000s of computers (nodes). These nodes are real computers in the real world, communicating directly from peer to peer.
The purpose of the greater Ethereum apparatus is to offer a single shared computing platform - the Ethereum Virtual Machine (EVM).
These nodes must stay perfectly in sync, processing the same transactions and doing the same actions that every other node is doing.
The way Ethereum coordinates and stays in sync is through a process called Proof of Stake (PoS).
¶ Byzantine Fault Tolerance
Deep Dive: The Byzantine General's Problem and Byzantine Fault Tolerance
Ethereum's PoS system is built on a body of work called the Byzantine General's Problem.
Byzantine Fault Tolerance describes the ability to resist failures (and attacks) that don't provide clear, reliable data on whether the component has failed.
Practical Byzantine Fault Tolerance (pBFT) is an algorithm that efficiently solves the Byzantine General's Problem.
We can mathematically show that pBFT is both safe (honest participants can agree) and live (the system does not stall).
Tl;dr pBFT systems are built on a two-round system of voting; first, each participate votes on their proposed plan of action. Post-execution, they vote again.
It's after this second vote that pBFT guarantees that the group has irrevocably reached consensus.
¶ Ethereum PoS as pBFT
Deep Dive: Ethereum Time (Slots and Epochs)
At its core, Ethereum PoS looks like a pBFT system, based around two rounds of voting.
In PoS, we call each round of voting an epoch.
Every 12 seconds, Ethereum produces a new block, filling a slot. 32 slots = 1 epoch = 6.4 mins.
At the beginning of each epoch, the entire validator set is shuffled into 32 committees - one for each slot.
Over the next 32 slots, each committee will vote on the block proposed in its corresponding slot.
By the end of the epoch, every validator has voted 1 time.
This represents the first round of pBFT voting.
At this stage, we call blocks "justified," which they remained until they receive their second vote and become "finalized."
The second round happens during the next epoch.
As the epoch changes, the validators are reshuffled and the process begins again.
Each time a new transaction is entered into Ethereum, the transactions before it are explicitly accepted as canonical World Computer transactions.
By virtue of being explicitly voted on during their execution epoch and then implicitly voted on during the following epoch, every transaction on every block is voted on 2 times, fulfilling the requirements of pBFT.
And so, at this stage we call blocks "finalized."
¶ Finality
Finality is an incredibly important concept in Ethereum. Once a transaction/block/epoch is finalized, it cannot be changed without a significant amount (>1/3) of staked ETH being destroyed.
Once finalized, the transaction is permanent, guaranteed by the value of ETH.
To recap:
- Start of epoch, all validators are split into 32 groups/committees
- Each committee votes on one block
- By end of epoch, all validators have voted once
- By end of next epoch, all validators have voted twice (fulfilling pBFT and finalizing the blocks)
The net result of this system: Ethereum transactions cannot be considered final (and protected by the value of $ETH) until after at least 2 epochs (~13 mins).
For the record, this is still MUCH better than anything we have in trad-fi. But we can do better.
¶ Looking Forward
More astute readers might have noticed the relationship between the number of committees we break the validators up into and the amount of time it takes to reach finality.
Consider 16 committees, instead of 32: epochs = 16 slots = 3.2 mins.
Finality in 6.4 mins.
In fact, the less committees we have, the less time it takes to achieve finality.
Unfortunately, getting every single validator to inspect, vote and finish preparing a block within the 12 second cadence is exceedingly difficult.
The biggest bottleneck is in the aggregation of the validator's digital signatures.
Ethereum PoS validators use BLS signatures, leveraging their very powerful ability to aggregate millions of signatures into a single key.
There are currently ~500k validators actively participating in Ethereum PoS.
Each block needs to be signed by its committee, aggregated and finished within a slot or two. It's just not feasible to do the entire set every slot.
And so, 32 slots per epoch (and therefore 32 committees, ~13 mins to finality, even 32 $ETH per validator) are all determined by the logistical constraints imposed by the PoS system.
Improving BLS aggregation, stabilizing P2P networks, creating new voting structures... all of these are ways to drive Ethereum to its endgame:
Single-slot finality.
Instant, trustless settlement.
¶ Resources
Source Material - Twitter Link