Part 2: Technical Overview

Overview

Introduction

The last section gave a broad view of blockchain consensus; in this section we will tighten the focus to Ethereum's proof of stake consensus. I've tried to follow a path that gives enough information to make sense of things, without wandering off into the detailed technical weeds on either side. All those weeds are well explored in the annotated specification and other chapters, and I've included some links for those who want to branch off and go exploring.

The first thing we must cover is the Ethereum-specific terminology that we will be using throughout.

Nodes and Validators

The main participants in the Ethereum network are nodes. A node's role is to validate consensus and form the communication backbone with other nodes.

Consensus is formed by validators, which (in true Ethereum style) are horribly misnamed, as they don't really validate anything - that's done by the nodes. Each validator represents an initial 32 ETH stake. It has its own secret key, and the related public key that is its identity in the protocol. Validators are attached to nodes, and a single node can host anything from zero to hundreds or thousands of validators. Validators attached to the same node do not act independently, they share the same view of the world.¹

A interesting feature of proof of stake that sets it apart from proof of work is that, under PoS, we know our validator set. We have a complete list of all the public keys that we expect to be active at any time. Knowing our validator set enables us to achieve finality, as we can identify when we have achieved a majority vote of participants.²

Slots and Epochs

Time is strictly regimented in Ethereum's proof of stake consensus, which is a major change from proof of work, which only had casual relationship with time - PoW makes some attempt to keep block intervals constant on average, but that's all.

The two most important intervals are the slot, which is 12 seconds exactly, and the epoch, which is 32 slots, or 6.4 minutes. Slots and epochs progress regularly and relentlessly, whatever else may be happening on the network.

Blocks and Attestations

Every slot, exactly one validator is selected to propose a block. The block contains updates to the beacon state, including attestations that the proposer knows about, as well as the execution payload containing Ethereum user transactions. The proposer shares its block with the whole network via a gossip protocol.

A slot can be empty: a block proposer might be offline, or propose an invalid block, or have its block subsequently reorged out of the chain. These things should not happen often in a well-running beacon chain, but the protocol is intended to be robust when empty slots occur.

Every epoch, every validator gets to share its view of the world exactly once, in the form of an attestation. An attestation contains votes for the head of the chain that will be used by the LMD GHOST protocol, and votes for checkpoints that will be used by the Casper FFG protocol. Attestations are also gossiped to the whole network. Like blocks, attestations can be missing for all sorts of reasons, and the protocol can tolerate this to various extents - crudely, the quality of consensus will decrease as the participation rate of attesters decreases.³

The function of the epoch is to spread out the workload of handling all those attestations. By attesting, every validator is informing every other validator of its view of the world, which could amount to an immense amount of network traffic and processing load if it were all done at once. Spreading the attestation workload across all 32 slots of an epoch keeps resource usage low. In each slot, committees comprising only $\frac{1}{32}$ of the validators make attestations.

The protocol incentivises block and attestation production and accuracy via a system of rewards and penalties for validators. We don't need to go into these now; there is a whole separate chapter on all of that.

Slashing

In proof of work, producing a block is expensive. This is a strong incentive for miners to behave well, in line with the protocol's goals, to ensure that their blocks are included.

In proof of stake, creating blocks and attestations is almost free⁴. We need a way to prevent attackers from exploiting this to disrupt the network. This is the role of slashing. Validators that equivocate over blocks or attestations are subject to being slashed, which means that they are ejected from the validator set and fined some portion of their stake. Simply put, equivocation means saying two contradictory things. It might be proposing two different blocks for the same slot, or making two attestations that are inconsistent with each other, that no validator honestly following the protocol would have made.

The Ghosts in the Machine

With some terminology behind us we can begin to outline Ethereum's actual consensus mechanism.

Ethereum's proof of stake consensus protocol is actually a combination of two separate consensus protocols, known individually as LMD GHOST⁵, and Casper FFG⁶. These two have been "bolted together" to form the consensus protocol we have implemented for Eth2 - the combined protocol is sometimes known by the portmanteau "Gasper".

Combining the two in Gasper is an attempt to get the best of both worlds in terms of liveness and safety. In essence, LMD GHOST provides slot-by-slot liveness (it keeps the chain running), while Casper FFG provides safety (it protects the chain from long reversions). LMD GHOST allows us to keep churning out blocks on top of one-another, but is forkful and therefore not formally safe. Casper FFG modifies the LMD GHOST fork choice rule to periodically bless the chain with finality. Nevertheless, as previously discussed, Ethereum prioritises liveness. Therefore, in situations in which Casper FFG is unable to confer finality, the chain still continues to grow via the LMD GHOST mechanism.

This bolted-together consensus mechanism is not always pretty. We can sometimes see the joins, and the interaction between the two has led to subtle issues that we will discuss later. However, in the spirit of Ethereum, it is a workable engineering solution that serves us well in practice.

History

The detailed history of Gasper is bound up with the development of the individual components, LMD GHOST and Casper FFG, which we will review in their respective sections. But we note here that Casper FFG was never designed to be a standalone consensus mechanism.

As stated in the Casper FFG paper,

Casper the Friendly Finality Gadget is an overlay atop a proposal mechanism – a mechanism which proposes blocks.

So, there is an underlying block proposal mechanism – which implies an underlying consensus mechanism – that Casper FFG sits on top of, delivering a kind of meta-consensus that confers finality on the blockchain.

The original plan was to apply Casper FFG as a proof of stake overlay on top of Ethereum's proof of work consensus. Casper FFG would confer finality – a property that proof of work chains lack – on the chain on a periodic basis, say, every 100 blocks. This was intended to be the first step in weaning Ethereum off proof of work. With the finality guarantee, we could have reduced the proof of work block reward, and thereby reduced the overall hash power as an interim step towards replacing mining with full proof of stake at some future date.

By the end of 2017, this plan had become quite advanced. EIP-1011, Hybrid Casper FFG, describes the architecture in detail, and there was even a testnet that went live on the 31st of December, 2017.

In early 2018, however, that plan was superseded. The limited bandwidth of the Ethereum Virtual Machine constrained the size of the validator set that EIP-1011 could support, in turn leading to a minimum stake of 1500 ETH, which was seen as undesirable. Around the same time, paths towards a full, much more scalable proof of stake protocol became clearer, and we began working on the design that became Ethereum 2.0.

Due to its generic nature, Casper FFG was able to survive the redesign and was adopted into Ethereum 2.0, not as an overlay on proof of work, but as an overlay on a new proof of stake protocol called LMD GHOST.

A finality gadget

When we say that Casper FFG overlays an existing block proposal mechanism, we mean that it takes an existing block tree and prunes it in a specific way. Casper FFG modifies the fork choice of the underlying block tree by making some of its branches inaccessible.

Consider this block tree produced by some underlying consensus mechanism, whether it be proof of work, or LMD GHOST in proof of stake.

In this situation, I have three candidate head blocks, $I$, $E$, and $M$. Under proof of work's longest chain rule, the choice of head block is obvious: I must choose M since it has the greatest block height, or (almost) equivalently the greatest amount of work done. Under LMD GHOST we can't choose a head block from this information alone, we'd need to see the votes from the other validators in order to make a choice.

The challenge is that the chain from blocks $J$ to $M$ might be from an attacker. The attacker might have mined that chain in secret and revealed it later in a so-called 51% attack. Proof of work nodes would have no choice but to reorg to make $M$ the head, thereby favouring the attacker's chain and potentially becoming vulnerable to double-spends.

The value that Casper FFG brings is that it confers finality. Let's say that block $D$ is marked as final by Casper FFG (which automatically finalises blocks $A$, $B$, and $C$). Finalisation modifies the fork choice rule of the underlying protocol so that any branch with blocks that competes with block $D$ – that is, any block not descended from $D$ – is excluded. Equivalently, branches are pruned so that there are no forks prior to the finalised block.

When block $D$ is finalised, the fork choice must ignore the branches that begin with blocks $F$ and $J$. We end up with a single candidate head block, $E$.

Essentially, the finality delivered by Casper FFG prevents long reorganisations (reversions). No finalised block, or ancestor of a finalised block, will ever be reverted. In Ethereum's Casper FFG implementation we must qualify "ever", with, "without burning at least 1/3 of the entire amount of staked Ether". This is the economic finality that the proof of stake chain provides.

Conclusion

As a reminder, this is the sentence we are trying to understand in all its parts.

The Proof-of-Stake (PoS) Ethereum consensus protocol is constructed by applying the finality gadget Casper FFG on top of the fork choice rule LMD GHOST, a flavor of the Greedy Heaviest-Observed Sub-Tree (GHOST) rule which considers only each participant's most recent vote (Latest Message Driven, LMD).

We've spent some time on what a consensus protocol is and does, and touched a little on proof of stake. We talked about finality, and at a high level I've illustrated how Casper FFG forms a "finality gadget" applied on top of LMD GHOST as a block proposal mechanism.

Much work remains, however. In the next sections we will take deeper dives into LMD GHOST, Casper FFG, and how they combine to form the Gasper protocol.

See also

On the history of how everything came together, Vitalik made a terrific tweet storm. Consolidated versions are available here and here. He discusses weak subjectivity a little, which we will deal with later.

The Proof of Stake FAQ remains an excellent primer on many of the topics we'll be covering.

Joachim Neu's presentation, The Why and How of PoS Ethereum's Consensus Problem (at ETHconomics, Devconnect 2022), is a very accessible insight into the availability–finality trade-off, and how Ethereum seeks to manage it. We'll pick up again on the idea of "nested ledgers" when we get to the Gasper protocol.