ETH2.0 Phase 0: basics for new contributors

James Zaki
Jul 7, 2019 · 6 min read

Translations: 中文

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).

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.

Image for post
Image for post
Validators, committees, slots, and epochs

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.

Image for post
Image for post
BN-BN: internet, VC-BN: internet or local. — (icons made by catkuro)

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

Explanations

  • Phase 0 specification + objects: Justin Drake (Mar. 2019): video
  • Research and Sharding: Justin Drake (Sept. 2018): video

Updates

Older reference

  • Beacon Chain: Vitalik Buterin and Justin Drake (July 2018): video
Image for post
Image for post

Coinmonks

Coinmonks is a non-profit Crypto educational publication.

Sign up for Coinmonks

By Coinmonks

A newsletter that brings you week's best crypto and blockchain stories and trending news directly in your inbox, by CoinCodeCap.com Take a look

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

James Zaki

Written by

Engineer and life-long learner/coder (Start-ups, IoT, Blockchain). Hobby rock-climber and gardener.

Coinmonks

Coinmonks

Coinmonks is a non-profit Crypto educational publication. Follow us on Twitter @coinmonks Our other project — https://coincodecap.com

James Zaki

Written by

Engineer and life-long learner/coder (Start-ups, IoT, Blockchain). Hobby rock-climber and gardener.

Coinmonks

Coinmonks

Coinmonks is a non-profit Crypto educational publication. Follow us on Twitter @coinmonks Our other project — https://coincodecap.com

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store