Ethereum 2.0

Abstract: We examine Ethereum 2.0, which is set to launch as early as July 2020, assuming there are no further delays. However, the launch may not be as important of an event as it sounds. Initially, Ethereum 2.0 will mostly operate as a test network for the new proof of stake consensus system. Most of the economic activity and smart contracts will remain on the original Ethereum network, which will continue to exist as a parallel system to Ethereum 2.0. There will be a one way peg, where Eth1 can be transferred into Eth2, but the reverse will not be possible. Given the decision to scale via sharding, we believe Ethereum has little choice other than to attempt this incredibly complex multi year transition to a new network.

Overview

Ethereum is attempting to transfer its entire economy onto a new network, Ethereum 2.0. This transition is risky, highly complex and will take a considerable amount of time. In our view, the primary motivation for this is scalability. The Ethereum network has proved popular since it launched and transaction volumes have increased considerably. In order for this growth to continue, both full node operators and consensus agents (be they proof of work or proof of stake) will need to run larger and larger computers, which would become increasingly expensive. This could eventually lead to increased centralisation, which could degrade the censorship resistance characteristic of the system, until eventually the network becomes pointless.

The approach Bitcoin has taken in the face of this problem appears to be layer two solutions like lightning, while Bitcoin Cash appears willing to pretend the problem does not exist, at least to some extent. In Ethereum, the pathway chosen in the face of this dilemma is also becoming clearer: sharding.

The core issue with sharding is that one could argue it represents a significant change in the economic model of Ethereum. If Ethereum is an unstoppable single world computer, then it may not meet user expectations if it was broken up into multiple shards (multiple computers). If a smart contract on shard 1 wants to interact with a smart contract on shard 2, there could be a significant degree of friction, due to the need to agree a sequence of events and share information between shards. The experience will be different compared to when two contracts on the same shard interact, therefore the planetary scale computer vision may start to break down, to some extent. One could even argue that Ethereum and sharding are antithetical concepts. On the other hand, Ethereum may be filling several niche cases, with different subsections of users interested in different types of applications, which require little interaction between them. In this world, sharding can make sense and improve the flexibility of the network to handle different groups of users, all sharing the same underlying Ethereum token.

The fact that sharding represents such a fundamental change to how Ethereum operates, explains why the transition to sharding is a more disruptive change than many may have thought. The existing smart contracts cannot simply move into a sharded network. A new network will need to be constructed and smart contracts will need to be built again for this environment. The transition will be a painful process over many years. For the initial stages of Ethereum 2.0, it will exist as a parallel system alongside Ethereum 1.0 and at some point in the future the plan is to merge the two systems back into one.

Before Ethereum even launched, the plan was to adopt proof of stake rather than using proof of work as the consensus mechanism. This planned transition, just like sharding, has proven more complicated than expected and therefore it has also been delayed. With Ethereum moving over to a new network, it makes some sense to use it as an opportunity to launch the proof of stake system at the same time. The Ethereum virtual machine will also be upgraded to a new version, this time with the benefit of around five more years of technological advancements and experience of observing Ethereum in operation.

The three phases of the transition

The planned transition to Ethereum 2.0 takes place in three stages, as outlined below:

Phase	Title	Description
0	Beacon chain	The beacon phase is likely to launch shortly. It has been delayed in the past but now looks like it is set to launch in July 2020. This phase will consist of the proof of stake system and not much else, therefore the network can be considered as more of a test network, although the tokens involved will be real Ethereum. There are various aspects to the proof of stake system that need to function, for instance: Managing the set of stakers Managing the funds at stake A random number generator to help choose a block producers and staking committees Staker voting on block proposals Granting rewards or issuing penalties to stakers
1	Shard chains	Shard chains will initially be deployed with 64 shards. At this stage the network is again designed to be highly experimental. While phase 0 aims to test the basic proof of stake infrastructure without any other significant economic activity, phase 1 aims to test the basic sharding model. During this phase there are essentially 65 chains of blocks operating in parallel, the beacon chain that existed in phase 0 and 64 new shard chains. There will be two way communication and referencing between the beacon chain and all of the 64 shards.
2	State execution	In this phase significant economic activity (other than staking) and smart contracts are expected to be possible on the network. The shards will no longer be basic data containers and will begin to resemble the features of Ethereum 1.0, such as the virtual machine and smart contracts. The specifications for this phase are yet to be finalised and significant development work is required in order for the network to be ready for phase 2, in our view.

The one way peg

When Ethereum 2.0 launches, there will be two Ethereum networks operating in parallel, Eth1 and Eth2. Initially, it will be possible to convert Eth1 coins into Eth2, however it will not be possible to convert Eth2 back into Eth1. Therefore, in theory, Eth2 should trade at a price less than or equal to the price of Eth1. However, in the early stages of the transition it is unlikely that Eth2 will even have a price or be supported by exchanges, as the coin may not be used for anything other than staking. Basic transactions are not even possible.

In order to transfer Eth1 into Eth2, one must use the deposit contract on Eth1. This contract essentially destroys the coins on Eth1 and then this destruction can be used as proof to issue new Eth2 coins. The coins are essentially burnt forever, although it may be possible to recover the coins on the Eth1 chain with a hardfork protocol change. Coins transferred to Eth2 automatically go into the proof of stake validator pool. As explained in our proof of stake piece in 2018, the idea behind proof of stake is that the voting weight and rewards attributable to consensus agents are determined by the value of coins at stake. In the Eth2 specification, each staking agent requires 32 ETH. If more than 32 ETH are sent to the contract, then the staker does not receive benefits from these additional coins and if less than 32 ETH are sent, the staker will not activate. Therefore to transfer ETH into Eth2, one should do it in batches of 32 coins. Each batch of 32 ETH can be a seperate staking agent.

Coin issuance

As explained above, there will be two parallel systems existing simultaneously. Eth1 will continue as a proof of work chain while Eth2 will operate under the new proof of stake system. During this period, both sets of consensus agents, miners and stakers, require incentives. Therefore the Ethereum inflation rate will increase, at least temporarily, until the two systems eventually merge. This may be considered a disadvantage, but it may be a price worth paying to ensure a successful transition to Eth2.

As for the Eth2 inflation schedule, the issuance rate will depend on the amount of Ethereum participating in the staking process. The annual issuance schedule will be based on the following algorithm:

Where Eth2 is the number of Ethereum participating in the proof of stake validation pool. These figures appear to have originated from this post by Vitalik Buterin in April 2019.

The idea behind the above formula is that the more ETH are transferred into Eth2 the more new coins will be issued, however the investment return available will decline the more coins are staked. The inflation schedule can be seen below:

Figure 1 – Ethereum 2.0 inflation rate

ETH staking	Max annual issuance	Max annual Eth2 inflation rate
65,000	46,151	71.0%
100,000	57,243	57.2%
1,000,000	181,019	18.1%
10,000,000	572,433	5.7%
100,000,000	1,810,193	1.8%
134,217,728	2,097,152	1.6%

(Source: BitMEX Research)
(Notes: There is a minimum threshold of around 65,000 ETH required in order for the beacon chain to start)

Figure 2 – Ethereum 2.0 Inflation rate

The justification for the issuance schedule is all about incentives. The rewards should ensure that initially there is a large incentive to move coins into Eth2 and stake, while the incentive to switch would get lower and lower the more coins move across, since fewer coins are needed if Eth2 is already successful. This ensures enough coins move across such that the new network is significant in size, while coin issuance does not become too high if Eth2 proves popular.

Of course with all this new coin issuance some may be thinking how this fits into the original Ethereum plan of “permanent linear inflation”.

The permanent linear supply growth model reduces the risk of what some see as excessive wealth concentration in Bitcoin, and gives individuals living in present and future eras a fair chance to acquire currency units, while at the same time discouraging depreciation of ether because the “supply growth rate” as a percentage still tends to zero over time.

(Source: Ethereum Whitepaper)

There are potential factors which could mitigate the impact of this potentially elevated inflation rate:

• In phase 1 the fee system is expected to have two elements, a base fee where coins are destroyed and another element, the premium fee, which is awarded to stakers. These burned coins will reduce the inflation rate.
• If validators fail to participate in the validation process, for example if nodes crash or become disconnected from the network, staking rewards would fall.
• If validators behave inappropriately and misbehave they can be given penalties and these coins would also be burnt.

The above mechanisms could result in destroying Ethereum which could dampen the impact of the elevated inflation rate, however it is difficult to predict the magnitude of these factors and therefore there is significant uncertainty over the issuance rate.

For what it’s worth, we are unsure of the efficacy of any part of transaction fees being burnt. It seems more logical from an economic point of view that the interests of consensus agents and users are aligned, with users paying a fee to consensus agents for a service. If consensus agents are funded entirely by user fees rather than block rewards, conflicts between the two groups may be less likely. At the same time, attempting to arbitrarily determine the correct reward schedule may result in inefficiencies, compared to leaving it to the fee market. Bitcoin has of course not succeeded in this yet either, with block rewards still significant. As for Ethereum, in the long term it may be more sustainable for all the transaction fees to go to stakers and the inflation schedule could be reduced to offset the impact of this. Afterall, validators are only there to secure user activity, if users are not doing anything they don’t need security. This may make it easier to strike the difficult balance between security and inflation.

Merging the chains

The eventual plan, and in our view this may be several years away, is to merge Eth1 and Eth2 back into the same system. This will work by essentially making Eth1 a shard inside Eth2. It will then be possible to transfer Ethereum between shards, in both directions and the two coins would have merged. It is planned that much of the activity currently occurring on Eth1, could now continue inside of this Eth2 shard.

The next step could be that the consensus systems eventually merge. The Eth1 shard could gradually transition to proof of stake. At first, proof of work could continue, but after a set number of blocks, for example every 100 blocks, consensus of the block could be determined by the proof of stake system. Proof of stake would essentially take precedence over proof of work and then within these proof of stake checkpoints, proof of work could reign supreme. Eventually proof of work could be entirely phased out and the proof of work block rewards would no longer be necessary and could be switched off. This would then give Ethereum users and investors more certainty over the inflation schedule.

Proposed network constants

The below is a set of some of the constants in the Eth2 specification we believe are most significant and informative.

Phase	Potential initial network configurations settings	Value
0	Block time interval	12 seconds
	ETH initially required per staker	32
	Number of blocks per checkpoint	32
	Target staker committee size	128
	Maximum number of committees per slot (To be removed in phase 1)	64
1	Number of shards	64
	Maximum number of shards referenced in each beacon block	64
	Shard staker committee target size	128
	Shard staker committee period	27 hours
	Max shard block size	1 MB

(Source: BitMEX Research, Ethereum 2.0 Specs)

Proof of stake

Proof of stake is the general idea of a fork choice rule based on the most accumulated stake (i.e. the chain with the most coins voting for it). There is of course the matter of how to structure this voting process. The core principles behind the voting system for Eth2 are unchanged from the 2018 Ethereum proposals and it is still based on the Casper Friendly Finalty Gadget idea. However, the system has now been updated, based on a combination of the Casper Friendly Finalty Gadget and the Latest Message Driven Greedy Heaviest Observed Subtree Fork choice rule (Casper FFG & LMD GHOST Fork Choice Rule).

We will try to explain the basic mechanics of the voting system by breaking it down into several component parts. The first thing to consider is there is a large pool of stakers, each represented by up to 32 ETH. This pool does not directly vote on blocks, instead it is arranged into various voting committees, whose members are randomly selected from the wider pool.

The reason for committees is that not every staker can participate in voting for each block, otherwise the blockchain would contain too much data about the votes and it would not scale. Committees are also useful for the aggregation of voting data into manageable chunks. Therefore a random subset of stakers are chosen to vote in these committees. The Eth2 specification has chosen 128 as the target number of stakers in each committee. The idea is that this is a large enough number to provide probabilistic assurances over the selection of blocks, even though only a minority of the wider staking pool will back any particular block proposal. The signatures which sign the votes can be aggregated, to reduce the block space required and ensure the network can scale.

The committees are selected at random, by a ”RanDAO” type system. This random selection is determined by a seed, which is added to each time a block is proposed. To defend against stake grinding attacks the block proposer only has two options which can impact the seed, to propose a block or not. Therefore the scope for manipulation is limited.

In addition to breaking down the stakers into committees, there is another subcategorization to consider. There are blocks and checkpoint blocks. One in every 32 blocks is a checkpoint block and the period between these checkpoints is sometimes called an epoch. Within each epoch there are 32 timeslots of 12 seconds in which blocks can be proposed. Each epoch therefore has 32 sets of slots for 32 committees. After each epoch the committee members are all shuffled around. Each timeslot has a committee of 128 members, one member who is given monopoly rights to propose a block in the 12 second period and another 127 members to vote on the block. This voting is sometimes referred to as attestation.

This allocation of the staking agents into committees is illustrated in Figure 3 below:

Figure 3 – Illustrative allocation of staking agents in the beacon chain (Assuming one committee per slot)

In actual fact the situation is a little more complicated than the above diagram implies. During phase 0 there can be up to a maximum of 64 committees of 128 validators per slot, not just one as the above diagram implies. Therefore, each epoch could contain a set of up to 262,144 stakers, representing around 8.4 million ETH. As a staker, in each epoch, you could either be allocated to one of the committees, or if all the space is taken up, you would just need to wait for the next epoch. To determine which blocks have the most votes, one needs to add up all the votes in all the committees.

If voters behave well, they can be given rewards from a pool of newly issued Ethereum coins. On the other hand, if the voters conduct certain types of malicious behavior, they can receive a penalty and lose a portion of their stake. These penalties for malicious behavior are designed to prevent things such as a stakers voting for two conflicting blocks. However, it can be legitimate to vote for conflicting blocks in certain scenarios and therefore the penalty rules are not straightforward, we discuss these rules later on in the report. Stakers can also lose rewards for going offline.

Finalisation

When committee members vote for a block, they do not only vote on the particular block proposal, but they must also reference and vote for a particular historic checkpoint block. Or more precisely reference to the transition from one checkpoint block to another (a source checkpoint and a target checkpoint). It is this mechanism that helps give assurance that the voting process has been settled. There are therefore essentially two proof of stake voting procedures occurring, one inside of the other. Figure 4 below illustrates the two types of voting occurring and which blocks these votes may be stored in.

Figure 4 – Voting and references assuming perfect communication (Assuming one committee per slot)

A block can become “justified” if a checkpoint block is built on top of it and more than two thirds of the committee members reference that checkpoint in their votes, across the index of all committees. (We are unable to determine precisely which group of committees this two third requirement applies to and exactly when it is assessed). The next stage is finalisation, a block is finalised when the blockchain contains two justified blocks after it. Therefore in most scenarios, where the two thirds voting threshold is achieved reasonably quickly due to strong communication channels, a user will need to wait around one epoch (6.4 minutes) for justification and two epochs (12.8 minutes) for finalisation. This is illustrated in Figure 5 below.

Figure 5 – Justification & finalisation process in the beacon chain in the normal scenario

Slashing conditions

As we mentioned above, the slashing conditions are not straightforward, voters cannot simply be punished for voting for two conflicting blocks. There are therefore three scenarios in which voters can be slashed.

Conditions where slashing is possible:

1. A block producer proposing two conflicting block proposals within its assigned slot.
2. Producing two votes, which contain conflicting references to checkpoint block transitions at the same height.
3. Producing two votes with overlapping checkpoint block transition references. For example a vote referencing the transition from checkpoint block 1 to checkpoint block 4 and a vote referencing a transition from checkpoint block 2 to checkpoint block 3. One may think this rule should be replaced by a more obvious rule, that all block transition references should be in sequence, however it is possible an honest node could miss a checkpoint block and an out of sequence vote may be legitimate. This behaviour is illustrated in Figure 6 below.

Figure 6 – Example of a slashing condition – Overlapping/surrounding checkpoint transition references

Evaluation of the proof of stake process

It is claimed that after finalisation users can have strong assurances that their transactions cannot be double spent. However, these systems are extremely difficult to evaluate, certainly when evaluating the degree of convergence and finalisation.

It is possible this whole process of voting committees, indexes of voting committees, referencing checkpoint block transitions and waiting for two epochs for finalisation is an unnecessary abstraction, merely breaking down proof of stake voting system into different components to add complexity and obfuscate the fact that the security model is fundamentally broken, due to the nothing at stake problem. On the other hand, perhaps breaking the proof of stake process down into these sub-components does genuinely add security characteristics to the network. On the balance of probability, we think the various aspected to these voting processes may improve security to some extent. The complexity in the process, such as staking rounds within staking rounds, ensures altering staking clients to any profit maximizing non-convergent behavior is likely to be technically very challenging, this adds a degree of security. As to whether this will make the system robust enough to to survive and thrive in the long run, is very much an open question, in our view. However, we would like to caveat our commentary and analysis by making it clear that our understanding of this system is incomplete.

Please note that our description above is meant as a basic outline of the process, there are many oversimplifications and aspects of the system we have not mentioned. For instance we didn’t touch on issues such as entering or exiting the staking pool, how rewards and penalties are calculated for each staker, how much block space all the voting data occupies or how staking votes are aggregated and counted.

Sharding

In phase 1, shards are added to the system. The original plan was to start with 1,024 shards and this has now been scaled down to just 64. The beacon chain is still considered the main or parent chain, only now it also contains links to the shards. Since there are 64 shards and each beacon block can link to up to 64 shards, the assumption is that under normal operation each beacon block can link to every shard.

There is then two way referencing in place, shard chain blocks reference the beacon blocks (with a hash of the beacon blocks) and beacon blocks may reference shard chain blocks (this is called a crosslink). It is possible that some shards referencing could be missed in some beacon blocks, however every shard chain block must link to the beacon chain.

Figure 7 – Illustrative structure of blocks in the Ethereum shard system (displaying two shards)

It should be noted that in phase 1, the sharding system and staking process become interrelated. The multiple validator committees per slot from phase 0 are now mapped to the shards. Each shard is therefore given its own staker voting committee, which changes during each proposer committee period. In the same way as for the beacon chain, one member of the committee is then given the task of producing a block in an allocated time slot, while the remaining committee members then vote on each proposal. A key point to consider is that that when the beacon chain references the shard blocks via crosslinks, all this voting information is included in the beacon chain.

The diagram below attempts to illustrate a possible allocation of stakers to the shard chains. In phase 1, staking agents are allocated randomly, either to the beacon chain, a particular shard or to nowhere.

Figure 8 – Ethereum potential staker committee allocation among shards

The beacon chain is therefore left with only one validator committee per slot. However, as Figure 7 illustrates:

• Each shard block contains a hash of the latest beacon block, and,
• The beacon block may contain the all voting data from the shards (crosslinks). 

Therefore all the voting and staking on the shard chains can also be used in the fork choice rule calculation and finalisation process for the main beacon chain. The proof of stake system works just as before, except rather than the beacon chain containing voting information in an index of committees, it contains voting information from each shard. 

There are no checkpoint blocks within individual shard chains, nor is there a justification or finalisation process. Instead, to get assurance over transaction finality inside of the shards, one must wait for the beacon chain. Once the relevant blocks in the beacon chain become finalised, users in the shard chain can gain assurance over the transactions in shards. 

The crosslinks therefore have three functions:

• To enable stacker votes in the shard chain block committees to be counted as votes on the main beacon chain, and
• To enable the finalisation and justification of shard chain blocks,
• All other forms of cross shard communication, such as transferring ETH or other assets across shards, although as far as we can tell the mechanics of this have not yet been completely worked out. While this topic may not arise until phase 2, this is likley to be another area resulting in an imperfect compromise between scalability and usability. One could even argue the challenges here are so great as to bring the whole sharding model into question.

The sharding structure provides flexibility to those wishing to run nodes. One could run a node that processes everything, the beacon chain and every shard. One could run the beacon chain only, which includes block headers for some shard blocks. There is also a third option, which is running a node which verifies the beacon chain and a selected subset of the shards. If one chooses not to run a node processing every shard, then one is relying on others to check on the authenticity of the processes in those shards, however the idea is that some users will choose to validate those shards and therefore the degree of assurance one has is probabilistically high.

Conclusion

Ethereum holders like to experiment with new and complex systems, be it The DAO, ICOs, Maker and now DeFi. Some members of the Ethereum community have expressed concerns to us that Ethereum technology is now five years old and falling behind, and they want something new. Ethereum 2.0 therefore satisfies a need in a community keen on trying new ideas. Therefore we predict that a considerable amount of funds will move into Ethereum 2.0 and earn the staking rewards, perhaps billions of dollars worth of ETH.

Many have asked us what impact the launch of Ethereum 2.0 will have on the price. Of course in the short term, a significant amount of ETH could be locked inside the beacon chain, attracted by the ability to earn the new block rewards. This could restrict the supply of ETH on the market and drive up the price, on the other hand it could merely attract ETH from other contracts where they are considered locked. However, the real question is whether Ethereum 2.0 will drive long term value and for that, supply does not only need to be restricted, there needs to be sustainable demand.

For the Ethereum 2.0 network to succeed, the proof of stake and sharding system need to work and be compelling enough to attract the economically significant components of the Ethereum ecosystem over to it. Smart contracts and DeFi systems would need to choose which shard is appropriate for them and invest in upgrading their technology to be compatible with the complexities and limitations of a sharded system. Therefore it will be many years before a significant part of the Ethereum ecosystem can make the switch. Ethereum 2.0 is an incredibly ambitious project and we consider it highly unlikely that it will succeed as planned, without major hiccups.

In writing this report there is one thing that stands out to us above everything else, Ethereum 2.0 is exceptionally complicated. With so many committees, shards and voting types it seems reasonably likely that something will go wrong and that there will be significant further delays. However, despite all these potential issues, Ethereum 2.0 is still probably still worth a try. If this does succeed, the potential rewards are considerable.

Disclaimer

Whilst many claims made in this note are cited, we do not guarantee accuracy. We welcome corrections.

The post appeared first on Blog BitMex