The Beacon Chain and Ethereum 2.0 — where it came from and where it’s going.

The key function of the Beacon Chain is to manage the proof-of-stake protocol for itself and all of the shard chains. There are a number of aspects to this: managing validators and their stakes; nominating the chosen block proposer for each shard at each step; organising validators into committees to vote on the proposed blocks; applying the consensus rules; applying rewards and penalties to validators; and, being an anchor point on which the shards register their states to facilitate cross-shard transactions.

Before we look at these functions in more depth, a note on terminology. The name Beacon Chain has its origins in the idea of a “random beacon” — such as NIST’s — that provides a source of randomness to the rest of the system, and the random beacon concept was adopted in a blockchain context by Dfinity. Although the name “beacon” suggests a central point, broadcasting to the rest of the system, of course it’s not like that on the blockchain: everything is decentralised. Each participating node maintains its own local Beacon Chain, striving to stay in lockstep with the other nodes. Perhaps the image with the conductor above is misleading. While the Beacon Chain does conduct the rest of the system, the conductor is decentralised, like each musician’s own internal sense of the rhythm.

Introducing the Beacon Chain

Let’s look at some of the functions of the Beacon Chain.

Managing Validators

A major part of the work of the Beacon Chain is maintaining the set of validators, which is the set of nodes that have placed the required stake of 32 Ether, who are responsible for running the Ethereum 2.0 system. There are several statuses that a validator can have, but only those marked as “active” take part in the Ethereum 2.0 protocol.

Nodes join the validator set by sending their stake to a contract on the Proof-of-Work chain (the current Mainnet). After some validity checks, the stake is locked up and the contract emits a log entry (an “event” in Solidity) which can be picked up by Beacon Chain clients. The node is then inducted into the validator set on the Beacon Chain.

Once active, validators participate in the protocol by proposing blocks, when chosen to do so, on both the Beacon Chain and, once they have been implemented, the shard chains. They also join committees that vote for blocks, as described below.

Validators can signal that they wish to exit the system and cease being involved. After a period of time (currently 97 days, but may be made more flexible), their stakes, plus rewards, minus penalties, will be returned into one of the shard chains. It will not be possible to unlock the initial stake on the PoW Mainnet, unless, perhaps, the whole system were to fail and the community agrees to a fork that refunds stakers.

All of this is managed by the Beacon Chain.

Providing Randomness

Good quality randomness is really hard to generate in blockchain systems, but a key requirement of the proof-of-stake protocol is a source of randomness that is distributed, verifiable, unpredictable, and (reasonably) unbiasable. The Beacon Chain is responsible for providing this randomness to the rest of the system: several of the protocol features described below depend on it.