Beacon chain: Conductor of the ETH 2.0 orchestra

• Beacon chain implementation aims to ensure that validators are playing by the rules while proposing the blocks in Proof of Stake design
• ETH 2.0 design aims to increase processing power by having multiple blockchains (shards) processing transactions parallely. Beacon chain is crucial for communication among different shards

Ethereum 2.0, sometimes referred to as Serenity, is a major protocol upgrade for the Ethereum network. Ethereum has long been dogged by scalability issues. With every node required to verify and execute every transaction, problems arise when the system is overloaded. Ethereum has been using a Proof-of-Work (PoW) mechanism since its inception. However, the rollout of Ethereum 2.0 will cast this aside to make way for a new Proof-of-Stake (PoS) mechanism.
Improvements in this rollout will pass through three major phases, and the beacon chain is fundamental to the process.

Phase 0

This is when the beacon chain will be implemented. Scheduled to be released on 30th June 2020, it will introduce the new PoS consensus mechanism, as well as store and manage the registry of validators1.

Phase 1

This second phase will integrate shard chains (explained below), which will help improve Ethereum’s scalability and is slated for 2021.

Phase 2

The third phase of Ethereum 2.0 is scheduled for 2022. It implements eWASM2, a new and enhanced virtual machine.

A musical analogy aids understanding here. In Phase 0, the conductor (Beacon Chain) of an orchestra gets on stage. In phase 1, the instruments (Shard Chain), are arranged on the stage. Finally, in Phase 2, the musicians (transactions and smart contracts) come into play, bringing life to the orchestra. This article focuses on the beacon chain. However, to understand how it will facilitate migration to Ethereum 2.0, we first need to get to grips with sharding. This is because the beacon chain will manage the sharding system, not to mention managing and storing states of validators.

Three key components comprise a blockchain system: decentralization, security, and scalability. Public blockchains are good at two out of the three parameters mentioned. This is known as the blockchain Trilemma. So far, Ethereum has been sufficiently secure3 and decentralised but lacks desired scalability. Sharding is an attempt to improve this scalability shortfall.

The word sharding comes from taking a database and separating it into multiple logical databases that can still communicate with each other. Put simply, Ethereum takes this concept but applies it to its blockchain which is a form of a database. So, the Ethereum 2.0 blockchain will be split, like lots of mini databases, into 644 different shard chains. More may be deployed over time as the hardware scales. They all live separately but need the beacon chain to communicate with one another. As a result, transactions, data storage, and processing occur in parallel with each other, improving performance by a factor of the number of shards.

The figure below illustrates how sharding and PoS come together in a single design. The beacon chain manages the PoS protocol for itself, unifying all the 64 shard chains. That means at least 64 times the throughput of Ethereum 1.0, and more data by a factor of several hundred.

Figure 1: Ethereum 2.0 Architecture

The migration involves two primary considerations, with the beacon chain crucial in the process – moving the ether (ETH) itself; and moving the state of the chain.

In Phase 0, Ethereum 1.0 users will be given the option to lock their ETH in a contract, with the same amount of new asset called Beacon ETH (BETH or ETH2) then credited to them on the beacon chain. Once completed, it can be staked on the Ethereum 2.0 chain to earn rewards. There will be a one-way bridge for the ETH migrating to Ethereum 2.0. That means it cannot be sent back.

During phase 0, ETH2 will be used only by validators on the beacon chain. The PoS blockchain gets funded ETH2 in two ways. The first way is by depositing ETH to a deposit contract (ETH1.X5 contract) which burns the deposited ETH and mints the same amount of ETH2 on the beacon chain. The second way will be as a reward for validating the beacon chain (in Phase 0) and to validate shard chains (starting in Phase 1). Except for asset migration and asset creation, there are five key functions of beacon chain, all of which are pivotal to the success of the migration.

Beacon Chain’s Major Functions

• Crosslink Management

The beacon chain processes crosslinks, which link together the entire sharded system. Crosslinks are a set of signatures from a committee6 attesting to a block in a shard chain, which can be included in the beacon chain. Crosslinks serve as the primary way through which the beacon chain becomes aware of the shard chains’ updated statuses. They also play an infrastructural role in cross-shard communication, which describes instances where a transaction needs to be shared between two or more shards.

• Randomness provision

When sharding a blockchain, the key challenge presented is security. Validators spread out across shards so that a single shard could not be taken over by a bad actor. This is partly achieved through validator shuffling, wherein a pseudo-randomly chosen committee of validators is assigned to each shard block. The beacon chain is responsible for providing this to the rest of the system, and this random shuffling makes it very unlikely for a shard to be attacked.

• Validator management

The beacon chain is required to maintain the set of nodes7 that keep the Ethereum 2.0 network running. To join the beacon chain validator set, the ETH owner sends their staking amount (32 ETH) to a contract on the current PoW chain. Once the validity of the transfer has been checked, it can be detected by the beacon chain client8. When selected, the active validators take part by proposing blocks on the beacon chain. Note also that when the shard chains are implemented in Phase 1, the validators will be able to propose blocks on their respective shards.

• Managing Committees

Committees are formed by a randomly selected group of validators appointed by the network to validate the blocks on each shard. The committee’s votes on which blocks represent the chain’s actual history are crucial for maintaining security on the PoS blockchain. By counting votes (also known as attestations) from its committee, the beacon chain can confirm its history, otherwise known as finality9.

• Overseeing Rewards and Penalties

The beacon chain will keep track of validator deposits, updating them too. If a validator fails to follow the rules, they are sanctioned through system removal and slashing10. The beacon chain also removes validators if their deposit dips under 16 ETH.

As is clear, the role played by the beacon chain in facilitating migration to Ethereum 2.0 will be thorough and pivotal. Not only does it serve as the basis for the new PoS mechanism, but it also will facilitate communication between the shard chains and crosslinks. Now, after years of effort, the much-heralded beacon chain is expected in the coming months. And with the conductor’s baton in hand, it will just be a matter of time before the Ethereum 1.0 we know so well becomes just another shard among shards.

¹Validators are people who stake on Ethereum’s PoS network in return for rewards. ↵
²The Ethereum WebAssembly (eWASM) will replace the current Ethereum Virtual Machine (EVM) and is a restricted subset of WASM that has been adapted just for the Ethereum network. ↵
³As we have not observed any takeovers or rollbacks we can assume that it is sufficiently secure ↵
⁴The number of shard chains Ethereum will support is still a discussion within the community. In our explanation we assume that there will be 64 shard chains, however this is subject to change. ↵
⁵ETH1.X is a codename for all the Ethereum main net upgrades to be adopted in the upcoming months ↵
⁶The network appoints a randomly selected group of validators to form a committee to validate blocks on each shard ↵
⁷The network appoints a randomly selected group of validators to form a committee to validate blocks on each shard ↵
⁸A beacon chain client is responsible for managing the state of the beacon chain, validator shuffling, and other tasks. ↵
⁹Finality implies finalisation of all previous blocks, back to the genesis block mined in 2015 ↵
¹⁰If validators fail to follow the protocol, they will have their deposits “slashed” (confiscated) ↵