Thanks to Danny and Joe for their review.
As the beacon chain launch draws closer and eth2 becomes more and more definitive, now is the time to quickly get the community in sync with the latest information on the inner workings of eth2 and the concrete requirements, incentives and the experience of the validator. This article will provide a high-level overview of eth2 that will form the basis of a series on all aspects of eth2 relevant to validators. eth2 has been in the works for a long time and has improved significantly over the years. What were initially separate sharing and proof-of-stake (PoS) efforts managed via smart contracts have evolved into a highly interconnected design that delivers dramatic improvements in efficiency, scalability, and security.
The phases
As parts of eth2 have become more interconnected, other parts have been separated into steps to enable a better pipeline of different aspects of eth2. At the time of writing, Phase 0 is about to launch as developers put the finishing touches on the client software. Meanwhile, the Phase 1 specification is being completed and Phase 2 is under active R&D.
- Phase 0 is concerned about the tag stringthe eth2 core, which manages validators and shard coordination. The beacon chain is the ground truth source from which all other aspects of eth2 are started.
- Phase 1 builds on this by allowing data to be placed in fragments. The implementation complexity of this component is much smaller than that of the others, because phase 0 constitutes most of the groundwork for fragments.
- Phase 2 adds execution to eth2, essentially upgrading eth2 from a robust database to a fully decentralized computing platform.
What exactly is phase 0?
As mentioned earlier, the beacon chain tracks the state of both the set of validators and fragments. In practice, this means that if you (periodically) track what’s happening on the beacon chain, you’ll know enough to check everything that’s happening in eth2. Trust, but verify.
For a PoS system to work, there must be consensus on who the validators are and each of their stakes in order to know how much their votes are worth, and to reward and/or punish them appropriately for their behavior. The beacon chain also manages the sharding aspects of eth2 by assigning validation tasks within shards as well as tracking the current state of each shard.
Part of what differentiates eth2 from other PoS systems is the large number of validators that can participate in the protocol. Unlike the tens, hundreds and thousands of participants possible in other systems, eth2 scales to hundreds of thousands or even millions of validators. This level of decentralization is only possible thanks to the intermediate levels of consensus reached by groups of validators called committees. The beacon chain uses the eponymous random beacon at its core to assign validators to committees responsible for evaluating what is and is not part of beacon and shard chains. A committee’s votes are then cryptographically aggregated into a certificate which means that verifying the votes of an entire committee requires only slightly more effort than verifying a single vote. Therefore, to verify the validity of the tag 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 corresponding deposits so that new validators can join eth2 by sending 32 Ether to the deposit contract on eth1. Through beacon chain voting on the eth1 chain, eth2 will, at some point in the future, improve the security of eth1 by providing an economic guarantee for the blocks that are part of the eth1 canonical chain.
Nodes vs clients
eth2 distinguishes between beacon nodes and validator clients, and validators will need both to accomplish their tasks. A beacon node (or just node) is concerned with maintaining a view of the tag chain as well as fragments that may be needed by a user or validator.
As their name suggests, validating clients (or just customers) handle the logic of a single validator. This is achieved by communicating with the beacon node to understand the current state of the chain, also attesting and proposing blocks where appropriate, and finally asking the beacon node to send this information to its peers.
If you’re not running a validator, a beacon node contains all the information you need to confidently interact with eth2, much like a full node in eth1.
Here are some of the many arguments in favor of this separation:
- Each validator must be initiated with a deposit of exactly 32 Ether and therefore people who wish to stake more ETH will need to run multiple validator instances. Node-client separation allows these users to run only a single beacon node with multiple validators connected, reducing compute, memory, and storage requirements.
- By making validator nodes separate modules, they will likely be more secure because it is easier to write, reason about, and audit smaller modules of code.
- For users particularly concerned about redundancy, multiple nodes can be run in parallel, reducing the risk of a validator going offline.
- Because validator clients can only interact with the rest of the eth2 network through a beacon node, and even then through a Restricted APIthe attack surface of a validator node is significantly reduced.
- For users who want to interact with eth2, but don’t want to be a validator, all they need to do is mine a beacon node which will give them access to the beacon chain and any shards they need.
Design Philosophy
The eth2 design philosophy provides useful context for all decisions made within eth2 and in many cases summarizes the differences between eth2 and other protocols.
- Protocol above all: Recognizing that everything is a trade-off, the security and liveness of the protocol takes precedence over other design wishes.
- Let’s hope for the best, but expect the worst: eth2 assumes that validators will be lazy, take bribes, and attempt to attack the system unless they have an incentive not to. Furthermore, it is assumed that the network is not entirely reliable and that catastrophic events could force a large number of validators offline. For these reasons, eth2 should be able to survive World War III.
- Minimally viable complexity: Where possible, eth2 has been simplified because it makes it easier to reason, explain to others, audit, write bug-free clients, and generally avoid edge cases.
- Maximum decentralization: Proof of stake protocols typically compromise the number of validators that can participate, eth2 is designed to scale to millions of validators while encouraging those validators to work independently of each other.
- Expect the unexpected: All components of eth2 are resistant to quantum computers or can be replaced with those that are in the event of a quantum apocalypse.
- By the people for the people: eth2 should be able to run on a consumer laptop. The lower the barrier to entry, the greater the number of people who can participate, resulting in a higher degree of decentralization.
Conclusion
Now that you have the basics of eth2 under your belt, the next few articles in this series will dive into the juicy details of what makes eth2 tick.
