Clearing Up Casper, Proof Of Stake, And Beacon Chain Confusion, Once And For All

Recently, I read yet another conflicting report about the proof-of-stake (PoS) mechanism to be adopted in Ethereum 2.0, and I about lost my mind. I thought I understood what was coming, but with every new Medium post, tweet, and news article I read my certainty diminishes. I figure, if I spend roughly 50 hours a week reading and writing about Ethereum and I don’t know, odds are that a lot of you don’t either.

I’ve heard that Eth2.0 will bring «pure proof of stake.» I’ve read that Casper FFG is the PoS mechanism to be implemented in Serenity but that Vlad Zamfir’s Casper CBC is the real pure proof of stake. I’ve read that Casper FFG is only a finality gadget to be used every 50 blocks, or every 100 blocks, over a PoW system for block finality.

So what’s actually going on?

There are existing, accurate articles, but amid the confusion, correctness seems to need signal boosting. (If you’re looking for a solid software engineer-centered analysis focusing more heavily on the rollout process, I’d check out James Prestwich’s article on Hacker Noon.) This article is focused on disambiguating between what has been considered for Ethereum 2.0, what is currently planned, and the relationship between Casper CBC, Casper FFG, the fork-choice rule, proof of stake, the beacon chain, and Ethereum 2.0.

A Refresher Course: Terms You Need to Know to Understand This Article

Ethereum 2.0: The future, scalable version of the network (aka ETH2.0 aka Serenity aka Shasper aka Ethereum with sharding and Casper).

Beacon chain: Ethereum is moving from proof of work to proof of stake. This has always been in the stars, but the logistics and roadmap have evolved over time. Once upon a time, it was imagined that proof of stake would be rolled out on the existing chain. Since June 2018, though, the plan has been to roll out proof of stake on a «beacon chain» to allow easier integration of PoS and sharding research and rollout. The beacon chain will be a proof-of-stake chain, eventually with sharding, that is rooted to the existing proof-of-work chain.

Casper: Ethereum’s version of proof of stake, which addresses the «nothing at stake» problem (the basics of proof of stake and Casper research are beyond the scope of this article, but an easy explainer is available here).

Casper CBC and Casper FFG: Two competing areas of Casper research.

Finality: Finality is an extra layer of security against Sybil attacks. Once blocks are finalized, they cannot be reverted, even in the case of a 51 percent attack against the network.

Fork-choice rule: The mechanism by which miners (PoW)/validators (PoS) decide which chain is the canonical chain.

First, Let’s Disambiguate the Caspers

Notes on Casper CBC

CBC stands for «correct-by-construction» and is not unique to Casper, Ethereum, or blockchain technology. Rather, CBC is an approach to software, hardware, and firmware engineering.   

Casper CBC, an area of research pioneered by Vlad Zamfir, is often described as the competing finality gadget, or PoS system, to FFG (see below). Strictly speaking, Casper CBC is neither of those things. Casper CBC is a family of consensus protocols and a technique for creating them.

Some version of Casper CBC is, at some point, expected to replace the proof-of-stake system slated for the initial ETH2.0 implementation, but CBC research remains more abstract and idealistic than practical.

Buterin has suggested that some aspects of Casper CBC research could be implemented in the beacon chain, but for now, CBC is absent from the beacon chain spec.

What Is the Actual Deal with Casper FFG?

Casper FFG is in fact slated for Eth2.0.

In an August tweet storm, Buterin stated that FFG is a finality overlay that could be used over a proof-of-work or proof-of stake-protocol (though I wouldn’t blame you if that clarification got lost among the 74 other tweets and the five-or-so months since he posted it). Casper FFG periodically selects the canonical chain, and «finalizes» the blocks in it, such that they become impossible to revert.

The Casper FFG white paper describes Casper as a proof-of-stake finality system that overlays an existing block-proposing mechanism.

The white paper states that FFG is a «partial consensus mechanism combining proof of stake algorithm research and Byzantine fault tolerant consensus theory,» but it is just that: a part of a bigger PoS mechanism. Casper FFG does not specify how blocks are proposed or by whom, how validators choose which competing chain to build on, how blocks are validated, or who validates them. All of those specifications are also required for building network consensus to decide upon a canonical chain.

Casper FFG is a consensus mechanism in that it is the means by which the network comes to consensus about which blocks are to be finalized, now and forever. In that sense, Casper FFG is the consensus mechanism. However, in the current Ethereum 1.0 chain, as core developer Danny Ryan stated on the Lighthouse Gitter channel, «there is no concept of finality.» He elaborated:

«At each subsequent block mined, we have a stronger probabilistic guarantee that the previous blocks will remain in the canonical chain. That is why exchanges and other users rely on «confirmations» of pow chains to a certain block depth, we all just assume the blocks won’t revert at some point and that we can essentially count it as finalized. As seen with 51% attacks, this type of probabilistic finality breaks down when you have a >50% (by hash power) coordinated attack. The cool thing in a pos chain with finality is that the coordinate attack cannot revert past the last finalized block. Also, in certain types of attacks, we can hold people accountable for their bad deeds and slash them [edited for grammatical consistency; emphasis my own].»

Proof of Stake in Ethereum 2.0 – and the Rest of the Consensus Mechanism

The beacon chain will be a brand new, «pure» proof-of-stake chain, right from the start (though sharding will come later). It is not a proof of work/proof of stake hybrid as is sometimes claimed, though it would be understandable to think this, as the white paper states that the first FFG implementation will be for PoW block finality. However, the only thing proof of work about the beacon chain is that it is rooted to the existing Ethereum 1.0 chain. This is evidenced in the beacon chain spec.

The caveat to the beacon chain’s PoS purity is that the beacon chain will be developed in phases, and while it will always be proof-of-stake, during the first two phases, data transfers will not be possible. There will be no virtual machine yet, and no EDCCs (aka smart contracts). Until eWasm is introduced in Phase 2 (starts at Phase 0), the PoW chain will still be necessary to process data transactions. In other words, the first phases of the beacon chain will only serve to establish the system and will be essentially useless as far as end users go. It will still be 100 percent proof of stake, though.

A Short Beacon Chain Proof-of-Stake Rundown

The details of how proof of stake is to work on the beacon chain are complicated and layered, but I’ll explain in the most basic terms possible. As I stated above, there must be (and are) mechanisms for determining how blocks are proposed, who proposes them, who validates the proposer’s claim, how those validators are chosen, and how proposers know which blocks to build upon.

Block Proposers

Proof of stake, as I will assume you know, uses validators to create blocks, rather than miners. To become a validator, a person or entity deposits 32 Ether into a Casper EDCC (or smart contract). Once this is done, that person gets registered as a validator on the beacon chain and begins accumulating interest as a reward for participation. If that validator then breaks certain rules (called slashing conditions), a portion of their deposit is slashed. If a validator’s deposit drops to 16 Ether, they are ejected from the system.

In the beacon chain’s specification, there are two classes of validators (though all validators act as both): proposers (those who propose blocks) and attesters (those who vote on block validity).

Validators are selected pseudo-randomly every six seconds using a mechanism called RANDAO+VDF to serve as block proposers. The six-second periods between proposer selections are called slots. During each slot, there is a proposer who proposes a block containing some information about the current and previous block, as well as a signature proving their RANDAO+VDF-defined authority to propose said block.

Block Validity Attesters

Under Ethereum 2.0’s proof-of-stake system, attesters (those who vote on block validity) are formed into committees of between 111 to 128 individual attesters. This way, not every attester needs to validate every block, allowing for efficiency and scalability. As part of a committee, the Github specification for phase 0 of the beacon chain specifies that attesters «sign off on a beacon chain block while simultaneously creating a link (crosslink) to a recent shard block on a particular shard chain.»

Attesters can continue to vote on blocks (one vote per validator) until a pre-designated number of slots has passed; this pre-defined set of slots is called an epoch, and is currently defined as 6.4 minutes (or 64 slots). At the end of every epoch, validators are shuffled to create new committees.

Fork-Choice Rule

I said before that validators need to have a way to know which blocks to build on. It may happen that there are two chains sprouting from a single block, so there needs to be a mechanism by which the canonical chain is determined. The existing PoW chain has a fork-choice rule (longest chain wins), and the beacon chain (and its shard chains) will have a new one.

The fork-choice rule for the beacon chain is called Latest Message Driven (LMD) Greediest Heaviest Observed SubTree (GHOST), or, thankfully, LMD GHOST for short. In combination with Casper FFG, LMD GHOST both dictates which block head to build on and achieves finality for some previous block. (In the current specification, finality is achieved for the block two epochs prior.) 

Through LMD GHOST, the canonical chain is determined by considering the most recent validator-signed block created on a given chain and comparing it against the most recent validator-signed block on a competing chain. Committee attestations give weight to a given block and that block’s descendants.

Source

With LMD GHOST, the chain with the heaviest most recent validator-approved block wins. Usually this is also the longest chain, but not necessarily; if two blocks are created that both stem from the same parent block, then the attestations for both blocks give weight to their parent block, ultimately making it possible that a block at a lower slot height has more votes backing it than a block of a higher slot height without many uncles. As Vitalik Buterin pointed out in a December blog post, «The longest chain rule fails to capture this nuance.»

Looking Forward

This article provides an overview of much of what is planned for the Ethereum beacon chain, with almost no attention paid to the logistics of sharding or cross-shard communication. This is in large part due to the incomplete state of specifications for the beacon chain rollout beyond phase 0, which does not yet enable sharding. But there’s plenty of time to worry about that later – maybe after ConstantiNOPEle has become CANT.STOP.inople.