Heartfelt appreciation to Sacha Yves Saint-Leger & Danny Ryan for their insight.
In this segment, we will explore the agreement mechanisms behind eth2. Eth2 utilizes a unique strategy to determine which block serves as the head of the chain, including which blocks are and are not included in the chain.
By employing a fusion of both mechanisms, eth2 aspires to achieve consensus that, apart from being swift and secure during normal network operations, also remains reliable under duress from attacks.
A Trilemma
FLP impossibility is a fundamental theorem in distributed computing that indicates it is not feasible to simultaneously achieve safety, liveness, and complete asynchrony in a distributed system without making certain unreasonable premises regarding your system.
Safety embodies the concept that decisions are irreversible, while liveness represents the ability to make new decisions. A protocol is considered asynchronous if there is no limit on the time it may take for a message to be delivered.
If nodes could interact reliably, consistently adhere to the protocol in good faith, and never fail, then consensus would be straightforward; however, that is not the case in reality. When these assumptions fail, FLP Impossibility demonstrates that at least one of safety, liveness, or complete asynchrony must be sacrificed.
GHOSTs and their perspectives on forks
Eth2 employs Greedy Heaviest Observed Subtree (GHOST) as its fork selection method. GHOST determines the chain’s head by selecting the fork that garners the most votes (this is accomplished by evaluating all votes for each fork block along with their corresponding child blocks).
To express it differently, every time a fork occurs, GHOST opts for the side that receives support from a greater number of the most recent messages for that block’s subtree (i.e., a larger number of the latest messages back either that block or one of its descendants). The algorithm continues this process until it encounters a block devoid of children.
GHOST is advantageous as it lessens the effectiveness of attacks when network latency is high and minimizes the depth of chain reorganizations compared to the longest-chain approach. This is due to the fact that while an attacker can efficiently build blocks on their chain making it the longest, GHOST would prefer the alternative fork, as it accumulates more total votes.
Specifically, eth2 utilizes a variant of GHOST tailored for a PoS scenario known as Latest Message Driven GHOST (LMD-GHOST). The principle behind LMD-GHOST is that when determining the head of the chain, only the latest vote from each validator is taken into account, disregarding any earlier votes. This significantly reduces the computational demands when operating GHOST, since the number of forks needing consideration to perform the fork selection cannot exceed the total number of validators (O(v)O(v) in Big O notation).
Under GHOST’s guidelines, validators/miners can consistently attempt to introduce a new block to the blockchain (liveness), and they are permitted to do so at any moment in the chain’s timeline (asynchrony). Since it is live and fully asynchronous, we acknowledge through FLP that safety cannot be guaranteed.
The absence of safety manifests as reorganizations where a chain can abruptly alternate between forks of any depth. Clearly, this is not ideal, and eth1 addresses this by requiring users to make assumptions regarding how long miners’ blocks will take to disseminate across the network, which is realized in the form of waiting for xx confirmations. On the other hand, eth2 does not rely on such assumptions.
The friendly finality gadget
A blockchain that lacks any semblance of safety is ineffective, as no conclusions could be reached and users would be unable to agree on the chain’s status. Enter Casper the Friendly Finality Gadget (Casper FFG). Casper FFG is a system that prioritizes safety over liveness in its decision-making processes. Consequently, while the conclusions it reaches are conclusive, under adverse network conditions, it may not arrive at any decision.
FFG is a crypto-economic adaptation of the traditional Practical Byzantine Fault Tolerant (PBFT), which involves phases where nodes initially express their desire to reach an agreement on an issue (justification) and subsequently affirm that they have witnessed one another agreeing (finalization).
Eth2does not seek to validate and finalize each slot (the moment when a block is anticipated to be generated), but rather only every 32 slots. Collectively, 32 slots are referred to as an epoch. Initially, validators affirm that they concur with all 32 blocks within an epoch. Subsequently, if ≥23geq frac{2}{3} do so, the block is deemed justified. In a subsequent epoch, validators receive another opportunity to cast their votes to signify that they have acknowledged the previously justified epoch and if ≥23geq frac{2}{3} do this, the epoch becomes finalized and is permanently integrated into the eth2 chain.
FFG utilizes a smart technique. Votes actually comprise two sub-votes: one for the epoch that is purportedly being justified and another for a preceding epoch that is designated to be finalized. This significantly reduces excessive communication among nodes and aids in achieving the objective of scaling to millions of validators.
Two ghosts in a trench coat
Consensus in eth2 hinges on both LMD-GHOST – which incorporates new blocks and determines what the chain’s head is – and Casper FFG which renders the conclusive decision on which blocks are and are not included in the chain. GHOST’s advantageous liveness characteristics permit new blocks to be swiftly and effectively appended to the chain, while FFG follows closely to ensure safety by finalizing epochs.
The two protocols are combined by executing GHOST from the most recently finalized block as determined by FFG. By design, the last finalized block is invariably part of the chain, which means GHOST doesn’t have to factor in earlier blocks.
In a typical scenario when blocks are being created and ≥23geq frac{2}{3} validators are casting votes on them, these blocks are incorporated into the head of the chain by GHOST, and shortly thereafter justified and finalized by FFG (which examines the last few epochs).
In the event of an attack on the network and/or a significant proportion of validators going offline, GHOST continues to append new blocks. Nevertheless, since GHOST is live but not secure, it may alter its stance regarding the chain’s head – this occurs because new blocks are continuously added, leading nodes to acquire new information. Conversely, FFG prioritizes safety over liveness, meaning it ceases finalizing blocks until the network stabilizes sufficiently for validators to vote consistently again.