ETH2.0 Phase 0: basics for new contributors
Translations: 中文
- A broad background to blockchain: Blockchain for everyone in 300 words
Introduction
This simplification is intended to assist those approaching ETH2.0 for the first time and looking to join implementation efforts (Phase 0 at the time of writing).
The article intends to quickly put high-level components in context and introduce key terminology, without getting deep into implementation details. Links to further resources are provided at the end.
It is helpful if the reader is already familiar with some terminology around the current Ethereum blockchain (proof-of-work).
Phases
Justin Drake provides a great summary of Eth2.0 phases:
- Deposits: a smart contract on the Eth1 to bring in validators
- Phase 0 - System: The BeaconChain. Which this article intends to frame
- Phase 1 - Data: Parallel processing of transactions in “shards”
- Phase 2 - State: EVM 2.0, smart contracts
High-level
Objective: ordered transactions
The main Ethereum blockchain (or Eth1 mainchain) creates an ordered list of valid transactions agreed upon by independent connected computers running Ethereum mining software, or “mining nodes”. Although this objective is unchanged, the method for reaching consensus with transaction order in ETH2.0 is via Proof-of-Stake rather than Proof-of-Work.
Parallel processing
As in PoW, sets of recent transactions will be grouped into blocks. The difference with PoS is how nodes determine the order of blocks, ie how the most recent blocks are chained together.
Also, the Eth1 mainchain is only one chain of blocks, whereas Eth2.0 will have many shards creating chains of blocks in parallel (shard data chains), but this will be in phase 1. For these shards to work together, another blockchain will consolidate valid blocks between shards. This administrative blockchain is called the beacon chain.
The Eth2.0 specification of Phase 0 focuses on this beacon chain, other resources describe the complete solution.
Beacon Nodes build the beacon chain
An internet connected computer running beacon node software of an Eth2.0 client is a node on the Eth2.0 network. As in Eth1, connected nodes share messages to create/share new blocks to be built upon. There is some lag before all nodes reach agreement on the latest blocks of the chain(s).
How beacon nodes agree between themselves to create ordered blocks on the beacon chain is the core of Eth2.0 phase 0.
Random block creation
Without going into the ways centralised financial transactions can be bad, the design of decentralised systems has required a lot of careful consideration (see Bitcoin 2009).
One part of this is to ensure a large number of people on a distributed network have a chance to contribute to creating/validating data. For this to avoid centralisation/corruption:
- blocks must be proposed by random nodes on the network
- valid blocks rewarded and/or invalid blocks penalised
Proof-of-work uses computational labour to achieve this:
- randomised block production between block-proposers periodically (15s)
- a financial cost to create valid blocks (to have a chance at block rewards)
Proof-of-stake uses staked ETH (currency) to achieve the same:
- random allocation of staking participants across time slots (6s)
- financial penalties for invalid proposed blocks, reward for participating
Although we’ve mentioned that beacon nodes are creating blocks, they are not actually the ones staking Eth2.0 to participate in the network (and hence receive rewards for participating successfully). This is the role of validators.
Validator
A validator is a person’s addresses that has staked 32ETH (via an Eth1 mainchain smart contract) to participate in Eth2.0. They are tasked with frequently, yet randomly, signing newly created blocks they believe to be valid (amongst other things).
An internet connected computer running validator client software of an Eth2.0 client must connect to one beacon node (or many). It trusts the beacon node to respond with appropriate data and, only if valid, have it signed by the corresponding validator that the validator client manages. More details in the next section.
When Eth2.0 is at the stage where it has a pool of validators, they are pseudo-randomly shuffled before being grouped into committees. One or more committees are assigned to one slot to participate in, per epoch.
Each epoch, validators are tasked with signing either: a newly created block, or an attestation/vote towards a previously created block. At the end of the epoch, validators are reshuffled, and the process repeats.
Beacon Node
As well as managing the list of validators that have staked 32 ETH, beacon nodes are also responsible for:
- keeping timing of the slots (6s)
- creation of randomness
- assigning committees (of validators) per slot
- responding to connected validator clients
Hardware/Software
Connected computers
To be highly available and have enough randomness for block validation, a large pool of validators is desired (10,000 minimum). Ideally these validators are spread amongst many validator clients which connect to one or more beacon nodes that make the Eth2.0 network.
The hardware running a beacon node communicates with other connected beacon node instances, and shares signed blocks and signed attestations. A validator client connects to a trusted beacon node to learn which slots its validators are allocated to. Furthermore, a validator client requests data (blocks/attestations) for its managed clients to sign.
The topics of: incentives to run beacon nodes, running beacon nodes and validator clients on the same machine, and trusting beacon nodes; is outside the scope of this article. At the time of writing there is ongoing discussion.
The simplest configuration is one beacon node, with one connected validator client which manages one validator. But given that beacon nodes have greater requirements, and a validator client much less, there are likely to be far more validator clients than beacon nodes. And since the validator client could be a highly available personal computer at home, or even a RaspberryPi, it is likely only going to have a very small number of validators on it.
So a beacon node could have multiple validator clients connecting to it, but also a validator client may choose to connect to more than one beacon node. This way it has a fallback if one of the beacon nodes goes down, or worse still, provides data to sign at the wrong slot. Loss of availability incurs a little penalty to the validators staked ETH, whilst signing things incorrectly incurs a much higher penalty. The topic of penalties against a validators stake is referred to as slashing in the specification.
Software to data
As a potential implementer of an Eth2.0 client, it is helpful to understand how the instances of different software connect and communicate between each other in an implementation. For the phase 0 specifications this is out of scope, and it remains focused on the beacon chain as data, referring at a higher level to “nodes”.
There is a beacon state that all beacon nodes should reach consensus on. Changes to a beacon node’s state is done by applying the latest block to the old state to obtain the new state. This is what the phase 0 specification focuses on.
Next steps…
Hopefully you’re now in a more comfortable position to look deeper into the specifications and an implementation to work on.
From here some ideas of areas to look into next:
- How the validator stakes are deposited into an Eth1 smart contract and detected by beacon nodes (honest validator)
- How accounts in Eth2.0 are made, eg Account Manager in Lighthouse
- Highly recommend this video (Mar. 2019). Note, the audio improves.
Further Resources
Specifications
- Eth2.0: https://github.com/ethereum/eth2.0-specs#ethereum-20-specifications
- Lighthouse implementation: https://github.com/sigp/lighthouse/#lighthouse-ethereum-20
- Graphical summary: https://github.com/protolambda/eth2-docs#justification-and-finalization
Explanations
- Phase 0 specification + objects: Justin Drake (Mar. 2019): video
- Research and Sharding: Justin Drake (Sept. 2018): video
Updates
- Implementer’s call notes: https://github.com/ethereum/eth2.0-pm/tree/master/eth2.0-implementers-calls
- Lighthouse updates: https://lighthouse.sigmaprime.io/
Older reference
- Beacon Chain: Vitalik Buterin and Justin Drake (July 2018): video
