Ethereum 2.0: A Complete Guide. Casper and the Beacon Chain.

Colin Schwarz
Published in
15 min readAug 6, 2019


Image Courtesy of CC Search. By Stan Levandovsky


Article One of this series outlined the history of the Ethereum network until the present day, and explained the major issues that will be addressed by the much anticipated Eth 2.0 update. Article two, Part One and Part Two, examined layer 2 scaling and sharding respectively. This article will delve into Casper, the anticipated change in Ethereum’s consensus protocol from proof of work to proof of stake, as well as the beacon chain that will deliver it.

Consensus Algorithms

In traditional networks for the exchange of value and information, there is usually a central intermediary that secures and validates the network. For example, banks guarantee the security of their customer’s assets and exercise centralized control over their online transactions and information. Since blockchain networks are decentralized, they lack such a central intermediary. Without this intermediary, blockchain networks must employ some sort of system to maintain security and to establish the validity of any new information that may be added to the ledger.¹ The majority of the network’s nodes must “reach consensus” on a single version of the network state in order for the network to remain secure. To facilitate this, blockchains use various “consensus algorithms,” which are sets of predefined rules, written into code, that allow the network to reach consensus and achieve finality. Finality means that “…once a particular operation has been done, it will forever be etched in history and nothing can revert that operation.”² Consensus algorithms determine: network security, confirmation speed, and the way in which transactions are ordered and verified in a distributed ledger, to “deliver a record of truth over a period of time”.¹ They ensure: “…that through decentralization, the next block to be added to the chain is the one and only version of the truth in the system.”¹ The first blockchain consensus algorithm, known as Proof of Work (PoW), was developed for Bitcoin. More recently, other consensus algorithms such as Proof of Stake (PoS), Delegated Proof of Stake (DPoS) and Proof of Authority (PoA), have been introduced by various blockchain projects for several reasons.

Why Proof of Stake?

A Proof of Work (PoW) system involves a number of miners who own computer hardware that is connected to a blockchain network. An algorithm sets a target value for each new block, and miners compete to be the first to find this target and append the new block. To do this, they run the proposed block’s header data through a hash function that will return a fixed link string of scrambled numbers. Miners change the “nonce value” of their input, until one of them generates a hash value that matches the specified target. At this point, the new block is broadcast to each node on the network to validate and add to their ledger, and the successful miner is awarded with Ether.³ The key aspect of this system is that it requires a lot of computational power to find the correct hash input, but it is very easy to verify the output once the correct input has been discovered. The difficulty of the mining process keeps the network secure, and the ease of validating each block makes it feasible for thousands of network nodes to maintain an up-to-date record of the blockchain. Unfortunately, the difficulty of finding each target through hashing requires a huge amount of computational power and electricity which reduces the efficiency of the network and the margins of the miners. Each miner must expend a significant amount of electricity and computation in their attempt to confirm the block and win the reward, yet only one of the miners will do so for each block. Because of this, each block mined results in a huge amount of wasted electricity and computation.¹ This means that although PoW algorithms are able to secure networks, they are very inefficient.

In addition to being inefficient, PoW blockchains are susceptible to market monopolization because they bestow unfair advantages on actors with more resources. Wealthy and powerful individuals and organizations can afford many faster and more powerful computers which gives them a much higher chance of successfully mining each available token. About 65% of bitcoin mining is done by 5 huge mining groups who could theoretically join together to control more than 50% of the market. This has created a situation where bitcoin and other blockchain networks are not nearly as decentralized as they were originally intended which endangers their independence and utility.

Proof of Stake first emerged in 2012 as an attempt to solve these issues of efficiency, cost and centralization.¹ In fact, the Ethereum team planned on transitioning to PoS from the very inception of the project, but has only more recently laid out a plan to do so with Casper. In a PoS system, the entire mining process is made virtual, removing the need for much expensive and inefficient hardware. The expenditure of energy is replaced by economic incentives and game theory as a means to secure and validate. In PoS, “miners” are replaced by “validators” who all posses tokens that are native to the network.² For each proposed block, validators stake a portion of their coins on a block which they think will be a valid addition to the chain. If that block gets appended, it will be added to the chain and any validator who bet on it will be granted an award proportional to their bet. Since there is no block award in a PoS system, validators are rewarded with transaction fees. This can be several thousand times more cost effective and energy efficient than a PoW system.

The “Nothing at Stake” Problem

One of the largest issues with implementing a proof of stake consensus algorithm is the “nothing at stake” problem. People have been experimenting with PoS consensus since 2013, and early adopters such as Peercoin quickly ran into this issue. Early renditions of PoS protocols allowed anyone with native tokens to act as a network validator. These projects assumed that those who owned tokens would have a vested interest in the success of the network. More validation rights were given to those with more tokens, under the assumption that those with more stake would have little incentive to carry out an attack. However, early PoS projects quickly realized that this logic was flawed. Usually, miners/validators are only presented with one possible block to validate. However, every so often as a result of latency, more than one block will be proposed and miners/validators will be presented with two blocks from which to choose. With a traditional PoW system, miners can only mine on one fork at a time. To successfully advance an illegitimate fork past the legitimate one would require over 50% of the network’s hashing power. With PoS, it is possible to validate blocks on two different forks simultaneously, at no extra charge. In fact, with early versions of PoS, it was theoretically in the financial self-interest of validators to bet on any fork available because by doing this, they would collect a transaction fee regardless of which fork was confirmed.⁴ The worst case scenario for this “nothing at stake” issue is based on several security assumptions:

  1. Validators will try to maximize personal profit even if it hurts the network
  2. No validators will act altruistically (validating blocks on only one chain)
  3. Validators will modify their software, or download modified software, that allows them to validate multiple forks. (standard software comes with internal logic for choosing the correct fork when one occurs)⁴

Multiple forks that arise from these assumptions can delay and complicate consensus, and could lead to major security vulnerabilities if left unaddressed. If every validator were actually validating blocks on every possible fork of a blockchain network, a malignant validator would be able to double-spend with as little as 1 percent of the validation rights. They could transfer tokens from one fork to an exchange, cash them out of that exchange, and then begin to only validate blocks on another fork. Since all other validators are hypothetically still validating on both chains, the second chain will gain more and more attestations and will eventually become the only true chain. This means the original tokens paid to and withdrawn from the exchange will no longer be valid. A successful double spend has occurred, and the exchange has been swindled out of however much money was involved in the attack.⁴ In reality, this is a nearly impossible scenario, as surely a significant number of validators are honest, and are only validating a single, correct fork. It is more likely that an attacker would need significantly more than 1% stake in the network, or to bribe or conspire with other validators to pull off a more complex group attack.⁴ Either way, early PoS algorithms were less secure from attack than PoW algorithms, which are secure up until a 51% attack is possible. In short, early attempts at PoS suffered from the lack of real value required as stake from each validator, which led to delays, complications and insecurities.

The Solution to Nothing at Stake: Casper

Luckily, the Ethereum team has learned from the shortcomings of early PoS projects and has designed the Casper protocol to eliminate the issue of nothing at stake. This idea for eliminating “nothing at stake” was first advanced by Vitalik in an article called “Slasher” in 2014. The article advances a simple solution: “…make the chain aware of other chains. Then, if a miner is caught mining on two chains at the same time, that miner can be penalized.” Although it has evolved a lot since its inception, this concept became the basis for the consensus algorithm that was developed for Casper, an algorithm designed to punish any validators who validate more than one fork or who otherwise do harm to the network.

The first implementation of Casper will use Ethereum’s current PoW proposal mechanism to introduce new blocks onto the blockchain. If two blocks are proposed simultaneously, validators will only be rewarded for betting on one chain, so it only makes sense to bet on the original chain, as this is the one that is most likely to succeed.² More importantly, the protocol introduces a mechanism that will instantly confiscate the entire stake of any validator who tries to support an invalid chain by validating more than one block at a time. This is done through a special protection mechanism that enforces two “Casper Commandments.” The first states: “Equivalently, a validator must not publish two distinct votes for the same target height.” The second commandment states: “Equivalently, a validator must not vote within the span of its other votes.” Any validator who violates either of these commandments is considered malignant, and their entire deposit (not just their stake) is slashed. Validators who’s nodes go offline are also punished in order to increase availability and reduce censorship of transactions. Vlad Zamfir likens this new PoS security mechanism to a PoW system in which the mining hardware of anyone participating in a 51% attack would immediately catch fire and burn down.² If implemented correctly, Casper will eliminate the nothing at stake problem and enable the Ethereum network to safely transition to proof of stake.

Ghosts and Gadgets

Casper is actually the amalgamation of two different but related research projects being undertaken simultaneously by the Ethereum Foundation: Casper the Friendly Finality Gadget (FFG), and Casper the Friendly GHOST: Correct-by-Construction (CBC).² Casper FFG is supposed to provide a smooth transition from the old consensus mechanism to the new. Accordingly, the Casper FFG model integrates a new PoS protocol by overlaying it on the current PoW protocol. Blocks are still mined using PoW but every 50th block becomes a PoS checkpoint at which finality is assessed by a network of validators. Casper CBC will be implemented after FFG and will complete the transition to PoS consensus.

The Beacon Chain

Casper’s Proof of Stake mechanism will be delivered via the beacon chain, a separate but connected chain that runs parallel to the PoW chain. The beacon chain will be the “system chain” for Ethereum 2.0. It’s main responsibilities will be to store and maintain a registry of validators, to process cross-links between itself and the mainchain, and to process the finality gadget. Validators will be allowed to participate in the beacon chain proof of stake protocol via a smart contract on the current Ethereum blockchain. Anyone who wishes to be a validator must make a deposit of exactly 32 Eth into this smart contract. The deposit will generate a receipt and will likely contain an ID that indicates the shard to which the validator is assigned (check out this article for more information on shards and sharding). Once the deposit is made, the would be validator will become a pending validator on the beacon chain. After a period of time, they will become an active validator who can participate in the PoS protocol. A validator is “activated” only after the beacon chain processes deposit receipts from the Eth 1.0 blockchain.

Active validators will take turns to propose new blocks and vote on their validity. Early versions of Casper will use the existing PoW proposal mechanism. Later versions will use something more efficient. Vitalik envisions “…converting the block proposal into some kind of PoS round-robin block signing scheme.” In order to prevent the validators from colluding to orchestrate an attack, the beacon chain uses a “random number heartbeat” to randomly sample validators to different shards for voting duties and block proposal. Not knowing when they will be selected helps to prevent validators from planning an attack in advance. In the event of a fork, validators will use their client’s beacon chain fork choice rule to automatically choose the correct chain. This rule “…combines justification and finality with Latest Message Driven (LMD) Greediest Heaviest Observed SubTree (GHOST).” The rule states: “Follow the chain containing the justified checkpoint of the greatest height.” A would be attacker would have to manually modify or eliminate this rule in order to validate the wrong chain.

For each block, an active validator is selected to propose a new block and the other active validators must all vote on its validity. Early versions of Casper required validators to send an on-chain transaction for each attestation they submitted. This would have increased load on the mainchain and exacerbated the very scalability issues that Eth 2.0 is trying to solve. With the current design, the beacon chain is in charge of the PoS mechanism so that votes do not compete for space on the PoW chain or shard chains. Attestations represent the largest source of load on the beacon chain so it is important that they are aggregated as efficiently as possible. Attestations can be votes for both a shard block as well as proof of stake votes for a block on the beacon chain. Once enough attestations for each shard block are collected, the block is appended and a crosslink to the beacon chain is created to keep it up to date. These crosslinks are also needed to facilitate asynchronous cross-shard communication.

The previous system of votes as mainchain transactions would have imposed a major limit on the number of validators that could realistically participate in the protocol. This would have been detrimental to the growth of the Ethereum ecosystem as more validators means improved security and decentralization. The new system uses “aggregate signatures” to solve this problem. For each block to be appended, a petition is sent off-chain to each validator using a peer to peer protocol. The validators can then decide whether or not to sign their support for the block. The block is only incorporated into the mainchain once enough signatures have been collected from the validators. The previous design could have only supported an estimated 900 validators. With the aggregate signatures system, it is estimated that over 300,000 validators will participate in the system although the system could hypothetically support up to ²²² or about 4.2 million. As a result, the minimum Eth deposit to become a validator has been reduced from 1,500 to 32 ETH. This will make the network more secure and allow a wider range of individuals to participate as validators by drastically reducing the barrier of entry, further democratizing consensus. Because validators only need to interact with the beacon chain in a limited way, it will not include an execution engine such as the EVM or Ewasm. Since aggregate signatures do not require any arbitrary computations, there will be no gas costs on the beacon chain, making it very cost effective.

To help people understand the functions and components of the beacon chain, Vitalik has divided it into two sets: quickly changing information, which he calls the “active set” and slowly changing information which he calls the “crystal set.” The active set includes the random number generator (RNG) and various bitfields to indicate which validators participate and at what height and cross-link. It also includes a series of crosslink hashes and data related to records of in progress cross-links. The crystal set will include active validators, pending validators and exiting validators. In order to be considered complete, each Beacon chain block needs a signature from a proposer, an attestation using aggregate signatures from a certain number of validators, a “bitfield” (a bitfield is a list of bits that represent the validators for that block), a “pointer” to the parent chain and a pointer to the beacon chain. The only point in the beacon chain that contains pointers to shards is at a cross-link. The pointers are necessary to establish secure and consistent communication between the beacon chain, the PoW chain, and the shards. Each beacon chain client needs to have access to the PoW chain to see what all the block hashes are and to know what the deposit receipts have been between any two checkpoints. Finally, the dependency relationship between each shard and the PoW chain will be similar to the dependency relationship between the beacon chain and the PoW chain. Establishing the details of how each of these three components will communicate with one another is one of the most important tasks still facing the Eth 2.0 development team. Beacon chain state transitions will consist of two parts, per slot transitions and per-epoch transitions. The former occur at every slot and only affect certain parts of the state. The latter happen at every epoch boundary, (every one hundred blocks), and affect the entire state. Per slot transitions focus on “…verifying aggregate signatures and saving temporary records relating to the per-slot activity in the BeaconState.” Per-epoch transitions “…focus on the validator registry, including adjusting balances and activating and exiting validators, as well as processing crosslinks and managing block justification/finalization.”


The beacon chain will be released during phase 0 of Eth 2.0. The tentative launch date is early 2020. However, launch can only occur once a minimum number of deposits is registered and there are at least three production ready clients.¹¹ Subsequent phases 1 and 2 are anticipated to be rolled out about a year apart, in 2021 and 2022. Phase 1 will introduce basic shards but will essentially be a test run for how a fully sharded system will work. As such, it will not immediately deliver the full scalability potential of sharding. This phase will address consensus and finality on shard chains, and will allow the beacon chain to monitor the execution of shard chains. Phase 2 will see the emergence of a fully sharded and integrated Ethereum 2.0. Shards will be upgraded from “rudimentary data markers” to “fully-functional chains.” Phase 2 will also see the introduction of Ewasm as Ethereum’s new virtual machine (stay tuned for the final article on Ewasm!). It should be noted that although these phases are divided conceptually, large parts of them will be worked on simultaneously because of their interconnected nature. Furthermore, efforts to improve the Ethereum 1.0 blockchain, often referred to as Eth 1.x, are still underway, and will continue well into the Eth 2.0 roll-out. The stated goals of Eth 1.x are to boost transaction throughput via client optimization, to implement “state fees” to ensure the sustainability of operating a full node, to stabilize transaction fees and to develop a finality gadget that can link the Eth 1.x chain to the Eth 2.0 chain.

Thanks for reading! If you enjoyed this article and want to find out more about Eth2, check out my other articles in this series:

Eth2.0: Introduction

Eth2.0: Scaling Part 1

Eth2.0: Scaling Part 2

Eth2.0: Ewasm

Special thanks to Marin Petrunić and Aidan Hyman for reviewing this article and making many valuable suggestions. Furthermore, this article would not have been possible without the work done by many other great writers and researchers in the space. Thanks to all of those involved in the creation and publication of the sources cited below!

  1. PoW vs PoS — the debate defined.”
  2. “What is the Ethereum Casper Protocol?”
  3. “How Ethereum Mining Works.”
  4. “Understanding Proof of Stake: The Nothing at Stake Theory.”
  5. “Slasher: A Punitive Proof-of-Stake Algorithm.”
  6. “Casper the Friendly Finality Gadget.”
  7. “Eth 2.0 Specs.” Github.
  8. “Ethereum 2.0.” Medium.
  9. “Beacon Casper Chain Talk.”
  10. “Ethereum Casper Update Expected in 2019, Sharding in 2020.”
  11. Words of Marin Petrunić.

Works Cited

Blockgeeks. “What are Ethereum Nodes And Sharding?” Accessed September 17, 2018.

Blockgeeks. “What is the Ethereum Casper Protocol?” Accessed October 12, 2018.

Buterin, Vitalik. “Slasher: A Punitive Proof-of-Stake Algorithm.” Ethereum Blog. Jan 15, 2014.

Buterin, Vitalik and Justin Drake. “Beacon Casper Chain Talk.” Filmed at Sharding Meeting #2 in Berlin. Published July 16, 2018. Video.

Buterin, Vitalik and Virgil Griffith. “Casper the Friendly Finality Gadget.” Ethereum Foundation. last revised 15 Nov 2017.

Chan, Justin. “PoW vs PoS — the debate defined” Brave New Coin. Mar 1, 2018.

“Eth 2.0 Specs.” Github. Accessed November 14, 2018.

Hertig, Alyssa. “How Ethereum Mining Works”. Coindesk. Accessed February 11, 2019.

Kramer, Melanie. “Ethereum Casper Update Expected in 2019, Sharding in 2020.” Unhashed. July 7, 2018.

Langley, Darren. “Ethereum 2.0.” Medium. August 7, 2018.

Martinez, Julian. “Understanding Proof of Stake: The Nothing at Stake Theory.” Jun 7, 2018.

Vidrih, Marko. “Roadmap Change at Ethereum — Sharding and Casper at the Same Time?” Medium. Jun 17, 2018.



Colin Schwarz

Helping to build Web3 for a better world. Passionate about product and usability.