Ethereum 2.0

Ethereum’s rise over the last three years has been extraordinary. A whole new industry of software developers, innovators, and entrepreneurs are building products on Ethereum.

As a small sample these companies are:

  • Saving journalism — Civil
  • Disrupting digital advertising — BAT
  • Decentralizing insurance — Etherisc
  • Securing digital voting — Horizon State
  • Improving supply chain transparency — Provenance
  • Re-engineering charitable giving — Giveth
  • Allowing music creators to grow and thrive — Ujo
  • Democratising energy markets — PowerLedger
  • Solving data privacy — Uport

Despite its success, Ethereum is still a nascent technology, to support these applications and those not imagined yet, it needs to address a key issue.


Spend more than 5 minutes in the blockchain space and you hear that scalability is a problem. The current Ethereum blockchain can process 15 transactions per second but to reach its full potential it would need to handle thousands of transactions per second. Ethereum wants to do this: on-chain and without resorting to masternodes (that reduce decentralisation and compromise security).

Ethereum 2.0 addresses scalability, but it also considers sustainability, efficiency, and flexibility. It combines several streams of work and will be rolled out incrementally over the next few years.

Of course on-chain scaling is best but, that said, there is no need to wait. Many applications can scale today using off-chain techniques such as Plasma, Plasma Cash and State Channels.

New Design

The Ethereum 2.0 roadmap isn’t definitive, it is in flux as new ideas are incorporated — as we found out when the original Casper design (EIP 1011) was deprecated in favor of a new design.

At Rocket Pool we fully support the new design because it will deliver a massively scalable blockchain faster. The new design incorporates two ideas (beacon chain, aggregate signatures) that make a huge difference to the scalability and decentralisation of Ethereum. The new plan also makes a lot of sense from a resourcing perspective.

Right! Let’s get into the meat and potatoes.

Current Ethereum Chain

In the medium term, it is business-as-usual for the current Ethereum blockchain. It will remain a proof-of-work blockchain and continue breeding crypto-kitties.

Current blockchain — blocks containing transactions

The new design will be developed separately from the current chain and will run in parallel. In the future, the current Ethereum blockchain will be incorporated into the new system.

Proof-of-stake (PoS)

For many reasons Ethereum is migrating its consensus protocol from proof-of-work to proof-of stake.

A consensus protocol is a set of rules that incentivises untrusted validators to maintain a consistent and secure blockchain. It protects the blockchain by providing economic security — to tamper with the blockchain ledger, an attacker would pay a huge cost, ensuring the attack is economically infeasible.

Proof-of-stake is a family of consensus protocols that uses cryptocurrency deposits to secure the blockchain. It requires validators to propose and vote on new blocks of transactions. Validators are rewarded with interest on their deposits if they follow the protocol’s rules. If they act dishonestly their deposits are penalised.

Beacon Chain

The beacon chain is a brand new proof-of-stake blockchain running in parallel with the current Ethereum blockchain.

Deposit process and beacon chain structure

A smart-contract on the current Ethereum blockchain will allow validators to participate in the proof-of-stake protocol by taking deposits of exactly 32 eth.

When validators deposit into the smart-contract they are put into the pending validator set on the beacon chain. Eventually they become active validators and will participate in the proof-of-stake protocol.

The beacon chain generates a random number heartbeat, used to randomly sample validators for block proposal and voting duties. This random sampling is important as it stops validators colluding and influencing the system.

A problem with the previous design was that it required validators to submit a transaction per vote. These transactions would have exacerbated the current blockchain scalability issues by increasing load. The current chain would have become a bottleneck. In the new design, the beacon chain manages the proof-of-stake mechanism so transactions do not compete.

The beacon chain will not include an execution engine (like the EVM) because validators can only interact with the chain in a very limited way. No longer having to process votes using the EVM means voting is much more efficient. There is no arbitrary computation that needs to be metered so all beacon chain transactions will be gas free — making the whole process cost effective.

Aggregate Signatures

If each vote was a transaction, the blockchain would have to process all the vote transactions sequentially within a tight time period. This puts a limit on the number of validators that can participate in proof-of-stake. The more validators that can participate the better because it improves security and decentralisation.

Aggregate signatures work like a petition — the petition is sent to each validator, who applies their signature in support. To reduce load on the beacon chain these petitions are sent off-chain (using a p2p protocol) and only fully incorporated into the blockchain when the petition has enough support.

With aggregate signatures, many more validators can participate in the proof-of-stake protocol. In the previous design it was estimated that the maximum number of validators that could be supported was 900. In the new design it is estimated that over 300,000 validators will participate but the system can support a up to 2²² validators. Consequently the minimum deposit to participate has been reduced from 1,500 eth to 32 eth.


Sharding is how Ethereum will realise the performance gains necessary to scale.

Every machine that runs the Ethereum blockchain has to process the transactions in sequence. These transactions cannot be processed in parallel, despite being run on thousands of machines. So from a scalability perspective, the current Ethereum blockchain is a single pipe that all transactions have to be pushed through. Sharding is like adding X number of additional pipes to take more transactions.

In reality, each shard is a separate blockchain with its own state (account balances, smart-contracts) and transaction history. What makes sharding different to just a bunch of blockchains, is that they all share the same proof-of-stake consensus with the beacon chain. The registered validators on the beacon chain will become a global pool of validators, that validate blocks of transactions on the beacon chain and the shards. To break the consensus protocol of one shard you have to break the protocol for the whole lot.

As the shards are separate, a cross-shard communication mechanism will be implemented so that, for example, a smart-contract on one shard, can talk to another smart-contract on another. This communication is likely to be asynchronous.

If this sounds complicated, that’s because it is.

As a user of Ethereum you won’t have to worry about this complexity. Software developers will hide this complexity from you.

Consider that the Internet is run on the TCP/IP protocol but as a user you never give it a thought.

With the beacon chain and aggregate signatures approach the potential number of shards has increased from 100 shards to 1,024 shards.

It is expected that a sharded Ethereum will be able to process more than 15,000 transactions per second.


Smart-contracts are the life-blood of Ethereum. They make all the really interesting stuff work. Ethereum smart-contracts are currently written in Solidity/Vyper and compiled down into EVM code which is executed by every Ethereum node. The Ethereum Virtual Machine (EVM) is itself becoming a performance bottleneck; the more efficiently you can execute code the better.

eWASM is being developed as a replacement to the EVM. eWASM is based on the WASM (WebAssembly) instruction-set which is designed as an open standard by a W3C Community Group and is actively being developed by engineers from Mozilla, Google, Microsoft, and Apple.

eWASM will make a significant difference to how many transactions can be processed and subsequently added to a block — further increasing transaction throughput.

If eWASM executes 2x faster, then 2x more transactions can be put into a block.

As well as being faster, the new instruction-set will:

  • Be more secure (because it is standardised)
  • Support more languages (not just Solidity)
  • Be portable (execute anywhere)
  • Benefit from the WASM ecosystem’s tooling

The Ethereum shards will not use the existing EVM but will jump straight to using eWASM. Compilers will be developed that convert Solidity and Vyper into the new eWASM instruction-set.

How do you find out more?

As the research is still ongoing and there are new developments everyday. We will track the development of Ethereum 2.0 and keep you posted.

Ethereum has come a long way but it has only scratched the surface of its potential. It is a very exciting time to be in this space and in the Ethereum community.

A big thank you to Danny Ryan (Ethereum Foundation) for the great feedback

Credit to Hsiao-Wei Wang (Ethereum Foundation) — as her fantastic diagrams were the inspiration for some of our diagrams