Thanks to Danny and Joe for review.

As the launch of the beacon chain grows nearer and eth2 becomes ever more final, the time has come to fast-sync the community with the latest on the inner workings of eth2 and on the concrete requirements, incentives and experience of being a validator. This article will provide a high-level overview of eth2 which will form the basis for a series on all aspects of eth2 relevant to validators. eth2 has been in the works for a long time now and has improved dramatically over the years. What were initially separate sharding and Proof of Stake (PoS) efforts managed via smart contracts has transmogrified into a highly interconnected design which yields dramatic improvements regarding efficiency, scalability and security.

The phases

As parts of eth2 have become more interconnected, other pieces have been separated out into phases to allow for better pipelining of the different aspects of eth2. At the time of writing, Phase 0 is nearing launch as developers put the finishing touches on the client software. Meanwhile, the specification for Phase 1 is being completed, and Phase 2 is under active R&D.

What exactly is Phase 0?

As mentioned previously, the beacon chain tracks the state of both the set of validators and the shards. In practice this means that if you (periodically) follow what is happening on the beacon chain, you will know enough to verify anything said to be happening within eth2. Trust, but verify.

In order for a PoS system to function, there needs to be consensus on who the validators are, and on what each of their stakes are in order to know how much their votes are worth, and to appropriately reward and/or punish them for their behaviour. The beacon chain also manages the sharding aspects of eth2 by assigning validator duties in the shards as well as tracking the current state of each shard.

Part of what differentiates eth2 from other PoS systems is the sheer number of validators that can participate in the protocol. In contrast to the 10s, 100s, and 1000s of participants that are possible in other systems, eth2 scales to hundreds of thousands or even millions of validators. This level of decentralisation is only possible due to the intermediate levels of consensus achieved by groups of validators called committees. The beacon chain uses the eponymous random beacon at its core to assign validators to committees which are tasked with evaluating what is and isn’t a part of the beacon and shard chains. A committee’s votes are then cryptographically aggregated into an attestation meaning that verifying an entire committee’s votes is only marginally more effort than checking a single vote. Therefore, to check the validity of the beacon chain, only a few aggregated signatures need to be considered to evaluate the votes of many validators.

The beacon chain also tracks the eth1 chain and the deposits thereupon so that new validators can join eth2 by sending 32 Ether to the deposit contract on eth1. As a result of the beacon chain voting on the eth1 chain, eth2 will, at some point in the future, enhance the security of eth1 by providing an economic guarantee that blocks that are a part of the canonical eth1 chain.

Nodes vs. Clients

eth2 makes the distinction between beacon nodes and validator clients, and validators will need both in order to perform their duties. A beacon node (or just node) concerns itself with maintaining a view of the beacon chain as well as whichever shards may be needed by a user or validator.

As their name suggests, validator clients (or just clients) handle the logic of a single validator. This is achieved by communicating with the beacon node to understand the current state of the chain, by attesting to and proposing blocks as well when appropriate, and finally by asking the beacon node to send this information on to its peers.

If you are not running a validator, a beacon node contains all of the information you need to trustlessly interact with eth2, much like a full node in eth1.

carlimg1

Below are some of the many arguments for this separation:

Design Philosophy

The design philosophy of eth2 provides useful context for all the decisions made within eth2 and in many instances encapsulate the differences between eth2 and other protocols.

Wrapping up

Now that you have the basics of eth2 under your belt, the next posts in this series will tackle the juicy details of what makes eth2 tick.