What is Ethereum 2.0?

Attention! The article is outdated and awaiting an update.

Ethereum 2.0 is an upgrade to the Ethereum network that was expected to occur during 2020.

Upon launch, Ethereum 2.0 will function mainly as a testnet to verify the Proof-of-Stake consensus mechanism. Most economic activity and smart contracts will continue to run on the original Ethereum network, which will remain as a system parallel to Ethereum 2.0. Developers will implement a path to move Eth1 to Eth2, but the reverse will be impossible.

Phase 0: Beacon Chain

This phase launches on 1 December 2020. It focuses only on validating the new Proof-of-Stake mechanism, so the network will be largely experimental, although real ether will be used. The following aspects of PoS are expected to be functional in this phase:

• Management of the validator set;
• Management of validator funds;
• A random number generator to help select block producers and staking curators (attesters);
• Validators voting on proposals on block size;
• Distribution of rewards and assignment of penalties to validators.

Phase 1: Sharding

An experimental network with 64 shards will be deployed initially. If Phase 0 is aimed at testing the basic PoS infrastructure in the absence of significant economic activity, Phase 1 tests the basic sharding model. During this phase, 65 blockchains will run in parallel — the Beacon Chain from Phase 0 and 64 new shards. Two-way interaction and a system of references between the Beacon Chain and all 64 shards will also operate.

Phase 1.5: Merging the PoW blockchain with the new PoS blockchain

This will not affect the historical data of the current network, since under the new mechanism the PoW blockchain will become one of the fragmented chains. Miners should note that the PoW blockchain will not support the PoW mechanism itself.

Phase 2: Implementing the new operating model

At this stage, smart contracts are expected to go live and economic activity to begin. Shards will no longer be raw data stores but will start to resemble virtual machines and Ethereum 1.0 smart contracts. Technical specifications for Phase 2 are still under development.

One-way deposit

After the launch of Ethereum 2.0, two networks — Eth1 and Eth2 — will operate in parallel. Initially, it will be possible to convert Eth1 coins into Eth2 coins, but not vice versa; therefore, in theory, Eth2 coins should trade at a price less than or equal to that of Eth1 coins. However, it is unlikely that in the early stages Eth2 coins will have a price or be supported by exchanges, since their only use will be staking. Even basic transactions will be impossible.

To move Eth1 to Eth2, a deposit contract on Eth1 must be used. This contract destroys coins on Eth1, and that destruction can be used as proof to issue new Eth2 coins. The coins are burned permanently, although recovery could be implemented via a protocol change in a hard fork.

Coins transferred to Eth2 automatically enter the validator pool.

Under Proof-of-Stake, a validator’s voting weight and reward are determined by the value of coins in stake. Eth2 specifications require each validator to have 32 ETH. If more than 32 ETH are sent to the contract, the staker does not receive rewards on the excess. If fewer than 32 ETH, the staker will not be activated. Therefore, ETH must be moved to Eth2 in increments of 32 coins. Each 32-ETH portion can be a separate validator.

Eth1 will continue to operate on Proof-of-Work, while Eth2 will run on Proof-of-Stake.

During this period, both miners and stakers will receive rewards, so Ethereum’s inflation rate will rise — at least until the two systems merge.

Eth2 issuance will depend on the number of tokens engaged in staking. The annual issuance rate will be based on an algorithm in which Eth2 is the number of ether engaged in the Proof-of-Stake validation pool (source: a post by Vitalik Buterin published in April 2019):

The formula assumes that the more ETH is moved to Eth2, the more new coins will be issued; however, investment returns will decline proportionally as the amount of coins in stake grows. The chart below illustrates the inflation rate of Ethereum 2.0:

Ethereum 2.0 inflation rate:

The issuance rate determines the size of rewards. Rewards are intended to motivate users to move coins to Eth2 and stake. The reward will decrease proportionally to the number of coins moved, since Eth2’s success will reduce the need for them. This model can ensure that enough coins are moved to enable significant network growth; at the same time, issuance will not become too high if Eth2 proves popular.
It appears to contradict the original plan for Ethereum of “permanent linear inflation”.

There are factors that could mitigate the impact of a potential rise in the inflation rate:

• In Phase 1, the fee system is expected to include two elements: a base fee, which is burned, and a premium fee for stakers. Burned coins will reduce inflation.
• If validators cannot participate in validation — for example, if nodes go down or lose network connectivity — the staking reward is nullified.
• If validators break rules, they are penalised, and confiscated coins are burned.

These mechanisms may result in a large number of ether being burned, potentially offsetting the effect of higher inflation.

In the longer term, over several years, Eth1 and Eth2 may merge back into a single system. In effect, Eth1 will become a shard within Eth2, enabling ether to move between shards in both directions, and the two coins will fuse into one. It is assumed that most economic activity currently occurring on Eth1 will continue within an Eth2 shard.

The next step could be the convergence of consensus systems. The Eth1 shard may gradually move to Proof-of-Stake.

Proof-of-Work may continue, but after a set number of blocks — for example, after every 100 blocks — block consensus would be determined by Proof-of-Stake. Eventually, Proof-of-Work could be dropped entirely: PoW block rewards would no longer be needed. That would give users and investors in Ethereum greater certainty about the inflation schedule.

Proof-of-Stake is a general concept for a fork-choice rule.

Preference is given to the chain for which the majority of coins vote. The key principles of Eth2’s voting system are the same as in Ethereum’s 2018 proposals and are based on the idea of the Casper Friendly Finality Gadget. However, the system has been updated by combining Casper Friendly Finality Gadget with the Latest Message Driven Greedy Heaviest Observed Subtree Fork choice rule (Casper FFG & LMD GHOST Fork Choice Rule).

The voting mechanism has the following components. First, there is a large pool of validators, each representing up to 32 ETH (32 ETH are required to activate a validator; this amount can fall to 16 ETH, which leads to deactivation). This pool does not vote on blocks directly — it is split into committees whose members are randomly selected from the wider pool.

The reason for committees is that not every validator can participate in voting for every block — otherwise the blockchain would contain too much voting data, making scaling impossible.

Committees also allow voting data to be aggregated into manageable chunks. Therefore, sub-groups of validators are chosen at random to vote within these committees.

According to the Eth2 specifications, the target number of validators per committee is 128 (the desired minimum). Developers believe this is large enough to provide a probabilistic guarantee of block selection. Vote signatures can be aggregated, reducing the required block size and enabling network scaling.

Committees are chosen randomly by a RanDAO-type system. The random choice is determined by a mnemonic phrase that is added whenever a block is proposed. To resist attacks aimed at splitting a block, a proposer has only two options that can affect the mnemonic phrase: propose a block or do not propose. Therefore the scope for manipulation is limited.

In addition to assigning validators to committees, there is another subcategory: blocks and checkpoint blocks.

One in every 32 blocks is a checkpoint, and the interval between checkpoints is called an epoch. Within each epoch there are 32 time slots of 12 seconds during which blocks can be proposed.

Thus, each epoch has 32 sets of slots for 32 committees. At the end of each epoch, committee members are reshuffled. Each time slot has a committee (desired minimum: 128 members). One member has the exclusive right to propose a block during the 12-second interval, and other members can vote for the block. This voting is also known as attestation.

Assigning validators to committees in the Beacon Chain (assuming one committee per slot):

In reality, things can be more complex than these diagrams. In Phase 0, up to 64 committees may be assigned to a single slot, not just one. Therefore, if each committee has 128 members, each epoch can accommodate up to 262,144 validators, which corresponds to approximately 8.4m ETH.

Each validator is assigned to one committee. The more validators there are, the more committees there will be. The maximum committee size is 2,048, which roughly corresponds to the entire ether supply used in each epoch (64 committees * 32 ETH * 32 slots * 2,048 validators per committee = 134.2m ETH).

The chart below illustrates how the number of committees and committee size vary depending on the amount of ETH in the staking pool. It shows that as the staking pool grows, the number of committees increases first to 64, and then, when the pool reaches roughly 8.4m ETH, committee size begins to grow.

Number of committees and members per committee:

To determine which blocks have the majority of votes, all votes across all committees must be summed. If voters behave properly, they can earn rewards from newly issued ether. If voters break rules, they can be penalised and lose part of their stake. Penalties are intended to prevent behaviour such as voting for two conflicting blocks, although in certain scenarios this may be allowed. Validators can also be deprived of rewards for going offline.

When committee members vote for a block, they vote not only for a specific block proposal but must also reference a specific historical checkpoint block and vote for it. This mechanism ensures that the voting process is stable. In effect, there are two Proof-of-Stake voting procedures, one inside the other. The diagram below shows how the two types of voting occur and which blocks can store these votes.

Voting and references under effective communication (assuming one committee per slot):

A block can become “confirmed” if a checkpoint block is created on top of it and, in the index of all committees within one epoch, more than two thirds of committee members reference that checkpoint in their vote.

The earliest a block can become “confirmed” is after two thirds of an epoch.

The next stage is finalisation. A block is finalised when the blockchain contains two confirmed blocks after it. Therefore, in most cases, when the two-thirds threshold is reached quickly thanks to efficient communications, a user will wait one epoch (6.4 minutes) for confirmation and two epochs (12.8 minutes) for finalisation. The process is illustrated below.

Confirmation and finalisation of a block on the Beacon Chain under a normal scenario:

Three scenarios in which voters can be punished:

• A block producer makes two conflicting proposals within one slot.
• Submitting two votes with conflicting references to checkpoint transitions at the same height.
• Submitting two votes with overlapping references to checkpoint transitions. For example, a vote marking a transition from checkpoint block 1 to checkpoint block 4, and another vote referencing a transition from checkpoint block 2 to checkpoint block 3.

One might assume this rule will be replaced by a more logical one, whereby all references to block transitions must be in sequence. However, it is possible that an honest node may miss a checkpoint block, and the result of sequential voting could be legitimate. The diagram illustrates such a scenario:

Developers claim that once a block is finalised, users receive assurances that their transactions cannot be double-spent. However, such systems are extremely difficult to evaluate by parameters such as convergence and finality.

It is possible that the entire process — committees of voters, indices of such committees, references to checkpoint transitions, and the need to wait two epochs for finality — is an unnecessary abstraction, an attempt to split the Proof-of-Stake voting system into components to complicate it and conceal a fundamental weakness in the form of the “nothing at stake” problem.

On the other hand, the process may indeed strengthen network security.

The multiplicity of components — for example, staking rounds within staking rounds — ensures that changing staking clients in a way that encourages rule-breaking will be technically difficult.

In Phase 1, shards are added to the system. The initial plan was to start with 1,024 shards, but this number has been reduced to 64. The Beacon Chain is still considered the main or parent chain, but it now also contains references to shards. Because there are 64 shards and each Beacon block can be linked to 64 shards, it is assumed that under normal operation each Beacon block can be linked to every shard.

There is a two-way referencing mechanism — shard blockchain blocks reference Beacon blocks (with the hashes of those blocks), and Beacon blocks can reference shard blockchain blocks (cross-links). References to some shards may be absent in Beacon blocks, but each shard blockchain block must reference the Beacon Chain.

Diagram: Structure of blocks in Ethereum’s sharding system (shows two shards)

In Phase 1, the sharding system and the staking process become interconnected. Validator committees by slot from Phase 0 are mapped into shards. Each shard is assigned its own committee of validator-stakers, which changes during each proposer’s “committee period”.

Similarly, in the Beacon Chain, one committee member is tasked with producing a block within a set time interval, and other committee members vote on each proposal. A key factor is that when the Beacon Chain references shard blockchains via cross-links, all voting data are included in the Beacon Chain.

The diagram below illustrates a possible allocation of stakers into shard blockchains. In Phase 1, stakers are distributed randomly — either to the Beacon Chain or to a specific shard. If fewer than 8.4m ETH are in stake, there will not be enough stakers to fully service all shards, so shard operation may slow to some extent.

Possible distribution of validator committees across shards:

Thus, the Beacon Chain remains with only one validator committee per slot. However, each shard blockchain contains the hash of the latest Beacon block, and each Beacon block can contain all voting data from shards (cross-links).

Therefore, all voting and staking on shard blockchains can also be used in the fork-choice rule and in finalisation for the main Beacon Chain. The Proof-of-Stake system operates as before, except that the Beacon Chain contains voting data not in a committee index but from each shard.

Individual shard blockchains have no checkpoint blocks and no confirmation or finalisation processes. To be sure a transaction within shards is complete, one must wait for the Beacon Chain. Once the relevant blocks in the Beacon Chain are finalised, users can be confident that transactions in shards have taken place.

Cross-links enable:

1. Counting staker votes in shard-committee voting as votes on the main Beacon Chain.
2. Finalising and confirming shard blockchain blocks.
3. All other types of shard interaction — for example, moving ETH or other assets from shard to shard.

The mechanisms needed for this are not yet sufficiently developed. They may become relevant with Phase 2.

The sharding structure enables node operation with flexibility — a node can process everything, including the Beacon Chain and every shard. One can run only the Beacon Chain, which includes headers for individual shard blocks.

There is also a third option: run a node that verifies the Beacon Chain and a chosen slice of shards. If a user prefers not to run a node processing every shard, they must rely on other users to verify authenticity within those shards. Nevertheless, it is likely that some users will choose to attest these shards, thereby providing assurance.

Holders of ether tend to experiment with sophisticated systems — DAO, Maker, DeFi.

Some members of the Ethereum community are concerned that the technology has existed for five years but still lags behind, so in their view new technologies are needed.

Ethereum 2.0 satisfies the community’s demand for new ideas, and significant funds and staking rewards can be expected (possibly billions of dollars in ETH).

In the short term, a significant amount of ETH may be locked in the Beacon Chain, as users are attracted by the opportunity to earn from block creation. Thus, the supply of ETH on the market may decrease and the price may rise. On the other hand, ETH may simply be drawn from other contracts where it is considered locked. For Ethereum 2.0 to be a catalyst for long-term price growth, supply must not only be constrained; demand must also be in place.

For the Ethereum 2.0 network to be successful, Proof-of-Stake and sharding must work and be convincing enough to attract economically significant components of the Ethereum ecosystem.
Smart contracts and DeFi systems will have to choose which shard suits them and invest in upgrading their technologies to be compatible with the constraints of a sharded system.

Ethereum 2.0 is exceptionally complex. With numerous committees, shards and different types of voting, there is a high risk of glitches and delays in implementing upgrades.