Understanding Phase 0, The Current Stage of ETH 2.0 Development

You may have heard that progress is being made in ETH 2.0 development: however, you may have questions regarding where we are in this development process. Most of the information available is either highly technical or excessively general, so we created this post to clear up any confusion.

We are currently in Phase 0, the phase in which the Beacon Chain, the heart of ETH 2.0’s Proof-of-Stake (PoS) system, is tested and launched. This post will explain the role of the Beacon Chain and the work that is being done to get us to its official launch. 

What is the purpose of the Beacon Chain?

One of the goals of ETH 2.0 is to divide the work of processing and storing transactions amongst shards in order to scale transaction capacity. Shards are desirable because, currently in ETH 1.0, every full node is required to validate all Ethereum transactions and store the entire state of Ethereum. This means that every full node is managing all economic activity on Ethereum. 

Considering that Ethereum aims to host all economic activity worldwide, storing the world’s economic activity on every single full node presents challenges. As the state continues to grow on ETH 1.0, it becomes less accessible to run a full node which means Ethereum would become less decentralized. Also, although Ethereum has not achieved mainstream adoption, it is already reaching transaction capacity limits.

With ETH 2.0, shards will relieve these limitations by coordinating and finalizing data through the Beacon Chain. The Beacon Chain serves as the source of truth. 

The Beacon Chain uses PoS to reach consensus and finalize shard data

The Beacon Chain will use PoS in order to validate shard data. In PoW blockchains, miners are incentivized to be good actors because, if they choose to attack the network by mining on a fork, they will be unable to collect the block rewards and transaction fees necessary to cover sunken costs like electricity and mining equipment. 

The Beacon Chain changes how security and data validation works on the blockchain. Instead of securing the blockchain via the inability for miners to pay off sunken costs, security is enforced by deleting or “burning” ether belonging to validators. In order to be eligible to validate ETH 2.0 and earn ether for doing so, potential validators first need to submit (aka stake) at least 32 ETH to the system. If a validator attempts to submit false data to the network or if they are offline for too long, some or all of the ether that they previously submitted to the network is deleted. 

What is the status of Phase 0 development

Launching the Beacon Chain is a delicate endeavor. In order to make sure that this is a smooth process, developers are testing client implementations that follow these Beacon Chain specifications.

Clients are the heart of decentralized systems because they eliminate central points of failure. In ETH 1.0, full clients eliminate central points of failure by:

• Maintaining the entire state of Ethereum (aka all of the economic activity and balances, etc),
• Sharing the latest blockchain information with peers (other clients) such as newly mined blocks and pending transactions, AND
• Enforcing network rules by validating information they receive before sharing it with other clients.
  

The current phase of ETH 2.0 development centers on various independent teams developing and testing these clients. Prysm, the ETH 2.0 client that is being audited by Quantstamp, is a client developed by Prysmatic Labs. This client is currently being tested in the Onyx testnet, where any individual can download the client and run the mock ETH 2.0 Beacon Chain. The purpose of this testnet is to detect problems that may occur when Prysm clients share messages about the current state of the Beacon Chain. 

Keeping ETH 2.0 safe with multiple implementations

In order for ETH 2.0 to thrive in the wild, it needs multiple clients to be active at the time of the Beacon Chain launch. If we rely on a single client, a single bug in that client can have devastating effects on the network, including throwing the network out of consensus or preventing blocks from being finalized. 

With numerous client implementations, a bug in a single client is much less likely to have a devastating effect on the network. If a bug were to be found in a single client, this client would fall out of consensus, but the network would continue to operate and finalize transactions because other clients are unlikely to contain the exact same bug. In other words, the other clients would maintain consensus. Multiple clients enhance network security. 

The goal of a testnet is to simulate an environment that replicates real-world conditions that the Beacon Chain will experience once it hits mainnet. In order to see if any bugs reveal themselves when multiple clients share messages (blocks, transactions, etc), ETH 2.0 client implementations are actively speaking to each other in multi-client testnets. 

Schlesi, the first multi-client testnet, launched on April 27th and, at one point, had 4 synced client implementations operating the testnet Beacon Chain including: 

• Prysm by Prysmatic Labs,
• Teku by PegaSys and funded by ConsenSys,
• Lighthouse by Sigma Prime, and 
• Nimbus by Status.

‍
On May 17th, a consensus bug in one of the clients caused a fork in the Schlesi multi-client testnet. After the bug was discovered, client developers decided to end the Schlesi testnet and start a new multi-client test network from block 0 called Witti. It should be noted that finding bugs in testnets is a normal part of the development process. Many such bugs were found in ETH 1.0 testnets before Ethereum was officially launched. 

Launching the Beacon Chain and beyond

ETH 2.0 is expected to launch before the end of the year, but this is not a hard deadline. The Beacon Chain will not be launched until multi-client testnets demonstrate stability for a sufficient period of time.

Once the Ethereum community achieves a certain level of social consensus regarding this stability, the Deposit Contract will be published on ETH 1.0. The role of the Deposit Contract is to collect stakes from potential ETH 2.0 validators so that they are eligible to validate data on the Beacon Chain. Once a predetermined quantity of ETH has been deposited, the Beacon Chain will activate and blocks will be produced. 

The launch of the Beacon Chain will mark the end of Phase 0. After the Beacon Chain is launched, both ETH 1.0 and 2.0 chains will exist in parallel for a time. ETH 1.0 will eventually become a shard in the ETH 2.0 system.

Quantstamp will be covering future developments in ETH 2.0. Follow us on Twitter and visit our blog to stay up to date!

‍

Update [Nov 24, 2020]

The Deposit Contract was successfully deployed on October 14th, 2020. On November 23rd, 2020, the Deposit Contract surpassed the threshold necessary (524,288 ETH) to launch the Beacon Chain. The Beacon Chain genesis will take place on Dec 1st!