Special thanks to Sacha Yves Saint-Léger and Danny Ryan for their review.
In this article, we will discuss the consensus mechanisms behind eth2. Eth2 has a new approach to deciding which block is at the top of the chain, as well as which blocks are And are not part of the chain.
Using a hybrid between the two mechanisms, eth2 aims to achieve consensus that, in addition to being fast and secure when the network is behaving normally, remains secure even when attacked.
A trilemma
FLP impossibility is a key result in the field of distributed computing which states that in a distributed system it is not possible to simultaneously have security, liveness and complete asynchrony unless unreasonable assumptions can be made about your system.
Security is the idea that decisions cannot be undone while liveliness captures the idea that new things can be decided. A protocol is asynchronous if there is no limit on how long a message can take to be delivered.
If nodes could communicate reliably, always follow protocol honestly, and never crash, then consensus would be easy, but that’s not how the world works. When these assumptions are not verified, the FLP impossibility is evidence that at least one of the following: security, liveness, or complete asynchrony must be compromised.
The GHOSTS and their opinions on forks
Eth2 uses Most greedy subtree observed (GHOST) as a fork choice rule. GHOST selects the head of the chain by choosing the fork that has the most votes (it does this by considering all votes for each fork block and their respective child blocks).
In other wordswhenever there is a fork, GHOST chooses the side where the greatest number of newest messages support that block’s subtree (i.e. more newest messages support in charge of this block or one of its descendants). The algorithm does this until it reaches a block with no children.
GHOST has the advantage of reducing the effectiveness of attacks during periods of high network latency as well as minimizing the depth of chain reorganizations compared to the longest chain rule. Indeed, even if an attacker can effectively keep the building blocks on their own chain, thereby making it the longest, GHOST would choose the other fork because there are more votes for it in total.
In particular, eth2 uses a variant of GHOST that has been adapted to a PoS context called Latest Message Driven GHOST (LMD-GHOST). The idea behind LMD-GHOST is that when calculating the chain head, we only consider the last vote made by each validator, and not any votes made in the past. This significantly reduces the computation required when running GHOST, because the number of forks that must be considered to run fork choice cannot be greater than the number of validators ( in Big O notation).
According to GHOST rules, validators/miners can always try to add a new block to the blockchain (liveability), and they can do so at any time in the chain’s history (asynchronous). Since it’s live and completely asynchronous, thanks to our friend FLP, we know it can’t be safe.
Lack of security presents itself in the form of reorganizations where a chain can suddenly switch between forks of arbitrary depth. Obviously this is undesirable and eth1 solves this problem by asking users to make assumptions about how long it will take miners’ blocks to communicate with the rest of the network, this takes the form of waiting for confirmations. Eth2, on the other hand, makes no such assumptions.
The user-friendly gadget
A blockchain without any notion of security is useless because no decisions could be made and users could not agree on the state of the chain. Enter Casper the Friendly Purpose Gadget (Casper FFG). Casper FFG is a mechanism that prioritizes security over liveness when making decisions. This means that even though the decisions it makes are final, under poor network conditions it may not be able to decide anything.
FFG is a crypto-economic adaptation of the classic Practical Byzantine Fault Tolerance (PBFT) which has phases where the nodes first indicate that they would like to agree on something (justification) then agree that they agreed (finalization).
Eth2 does not try to justify and finalize each slot (the point at which a block is supposed to be produced), but only every 32 slots. Collectively, 32 locations are called a era. First, validators sign that they agree with all 32 blocks in an epoch. So, if do it, the blocking is justified. At a later epoch, validators have another chance to vote to indicate that they saw the earlier justified epoch and whether do this, the epoch is finalized and still part of the eth2 chain.
FFG employs a clever trick. The votes actually consist of two subvotes, one for the era that is being justified and another for an earlier era that needs to be finalized. This saves a lot of additional communication between nodes and achieves the goal of scaling to millions of validators.
Two ghosts in a trench coat
Consensus within eth2 relies on both LMD-GHOST – which adds new blocks and decides which chain leader is – and Casper FFG which makes the final decision on which blocks are And are not part of the chain. GHOST’s favorable liveness properties allow new blocks to be added to the chain quickly and efficiently, while FFG tracks to ensure security by finalizing epochs.
The two protocols are merged by running GHOST from the last finalized block as decided by FFG. By construction, the last finalized block is always part of the chain, meaning GHOST does not need to consider previous blocks.
In the normal case where the blocks are produced and validators vote on them, these blocks are added to the head of the chain by GHOST, and shortly after justified and finalized by FFG (which considers the last epochs).
If there is an attack on the network and/or a large portion of validators go offline, then GHOST continues adding new blocks. However, as GHOST is active, but not secure, it may change its mind regarding the head of the chain – in effect, new blocks are continually added to the chain, meaning nodes continue to learn new information. FFG, on the other hand, prioritizes security over liveness, meaning it stops finalizing blocks until the network is stable enough for validators to vote consistently again.
