ETH2 for Real: Progress in 2021

Nov 2, 2021 8 min read
ETH2 for Real: Progress in 2021

Cool tech behind the next generation of Ethereum features and functionality.

Raleigh Illgen, also found on Twitter, contributed the following rundown of Extraterrestrial Human Tech, AKA the latest from the world of Ethereum.

Ethereum is due for a big update, about to undergo a series of upgrades that will change the consensus mechanism from proof-of-work (POW) to proof-of-stake (POS) both massively reducing the network's energy usage as well as enabling much higher transaction throughput via a mechanism called sharding. This will transition an unprecedented amount of on-chain value from a POW to a POS mechanism.

Higher transaction volumes are great news for everyone trying to build or use dApps with complex functionality like decentralized exchanges, DeFi contracts, or on-chain games. Recent spikes in ETH gas fees from network congestion have caused significant trouble by making smaller transactions uneconomical.

The changeover to POS has been planned since the earliest stages of Ethereum's development, but the path to get here hasn't been easy. Ethereum creator Vitalik Buterin suggested POS was less than a year away as far back as 2015, but as is to be expected from a software project as complex as the world's largest Turing-complete decentralized network, delivery has taken quite a bit longer.

Since ETH2 ship dates have continually slipped, estimated release dates for future phases will be omitted since they will have likely changed. Phase 0 has been successfully initiated and Phase 1 is upcoming next, as of October 2021.

Phase 0 — The Beacon Chain

The first upgrade occurred on Dec 1st, 2020 with the launch of the Beacon Chain which will manage the POS protocol and coordinate the shard chains in the future. Currently separate from the Eth1 mainnet, it will eventually be merged when POW gets turned off.

Staking is already live on the Beacon Chain! By staking 32 ETH you participate in the validator consensus which is a voting process to create new blocks. There are some risks involved, as any funds sent to the deposit contract won't be accessible until the merge takes place.

Another risk of running a validator node is that if your server is offline and you miss your voting slot, you'll actually lose ETH as a penalty. The chain is only validating empty slots right now, but that will change once the merge occurs.

More information on becoming a validator can be found here.

Phase 1 — Shard Chains

The next major milestone will be the launch of Phase 1, where 64 shard chains will be launched. Sharding is one of the primary ways ETH will increase its transaction bandwidth by distributing storage and the process of validation across many chains. This step is another kind of dry run, where the shards won't actually be validating transactions yet, but the health of the network will be assessed to make sure everything is running smoothly for the next step.

Accounts and smart contracts also won't be supported on the sharding infrastructure initially, as this is just a test of the networking and communication mechanisms.

Phase 1.5

Once the sharding process has been confirmed to be functional, the second half of phase 1 is to perform the merge. The ETH proof of work mainnet will then become one of the initial 64 shards.

Phase 2 — Execution Environments

In the last phase, the shard chains will begin processing accounts and smart contracts with the launch of eWASM (Ethereum flavored WebAssembly). This is a virtual machine (VM) that the shards will run and is an upgrade from ETH1's Ethereum Virtual Machine (EVM). WebAssembly has become an extremely popular choice for virtual machines lately due to its simple specification and secure design making it a great choice for ETH2's VM.

Phase 2 will also see the introduction of execution environments. This is a fairly technical concept, but basically, dApp developers will have new flexibility to optimize how their transactions get processed.

At this point, ETH2 should be completely functional with ETH1 and ETH2 interoperability working seamlessly. The ETH1 POW chain will eventually be killed when the "Ice Age" difficulty bomb makes mining unprofitable. This will cause the network to halt since blocks will stop being generated.

Do confirm that the wallet you use intends to support the transition — but practically all wallets should. You shouldn't need to do anything with balances prior to the Phase 2 launch since the EVM will be entirely contained in an ETH2 shard.

ETH2 Technical Details

ETH2 development has been underway for several years, and multiple technologies will be incorporated to try and reach Vitalik's predicted 100,000 transactions per second. The main pieces involved will be POS, sharding, and the eWASM VM. Rollups are also a recently introduced layer 2 (L2) solution that doesn’t require any ETH2 tech but has vastly increased transaction bandwidth.

Security audits for pieces of ETH2 including the consensus and networking specification and the ConsenSys ETH2 client, Teku, have respectively been performed by Least Authority and Quantstamp, according to Decrypt.

Proof of Stake

POS solves the Byzantine generals problem and sidesteps the need for energy-intensive POW through the use of staking. By staking a portion of the value of a network which essentially locks it up for a period of time, an agent (referred to as a staker) is given the opportunity to propose new blocks which are rewarded via a block reward and/or transaction fees.

While suffering from the same 51% attack vulnerability as POW, POS is probably at least equally, if not more secure. Particularly with respect to Ethereum, which likely has one of the widest distributions of all cryptocurrencies, making a single actor, or even party of actors, extremely unlikely to accumulate 51% of the network value.


Rollups are an L2 scaling solution already in use where a set of transactions is bundled or computation is executed off-chain into a single cryptographic proof then put on-chain in one transaction via a smart contract. This provides a huge scaling benefit reducing storage and CPU requirements but comes at a price.

Since your transaction is likely being bundled by a 3rd party you may have to wait longer for more transactions to be queued. In addition, it's possible the 3rd party may generate a fraudulent proof (although there are options to mitigate this risk).

There are currently two main kinds of rollups being used, optimistic and zero-knowledge (ZK) rollups.

Optimistic rollups let the 3rd party contract act like a notary where transactions that happen off-chain are pushed to the main chain as a Merkle tree via a cheap opcode, tx CALLDATA. This removes the computationally expensive parts of potentially many transactions from hitting layer 1, the main chain. However, the 3rd party could post a potentially fraudulent proof.

To combat this, the rollup contract should implement a kind of function where proofs can be challenged for a certain period of time. In the event a fraudulent transaction is detected and someone submits a successful fraud proof, all transactions from that point are reverted. As an important security measure, make sure any optimistic rollup contract you interact with implements this kind of function.

ZK rollups are an improvement over optimistic rollups which use ZK-SNARKS (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge), a type of proof that removes the need for interaction between the prover and verifier of a statement. The rollup contract can then be simplified to eliminate the dispute resolution process and potentially long lockup times for L1 funds. Transaction batches are checked for validity by the contract itself eliminating the possibility of fraudulent submissions.

There are, of course, potential drawbacks. To achieve non-interactivity (that means there's only one message required between prover and verifier, not multiple messages) ZK-SNARKS are generated with common reference strings shared between prover and verifier that must use secret randomness. If someone could access that randomness they could generate fraudulent proofs.

Sharding and Crosslinking

Sharding is a common technique in computer science, sometimes also referred to as horizontal partitioning, where a workload is distributed over multiple instances to increase availability, storage, and throughput. In the context of ETH2, sharding will involve splitting the chain into 64 separate parallel and interoperable shard chains. The possibility for additional shards to be added in the future also opens the door to future horizontal scaling.

Complicating matters, dApps will have to choose a shard to run on. Since cross-shard communication isn't instantaneous, dApp developers will have to anticipate this. This has the potential to become a particularly sticky point for developers to navigate.

Communication and coordination between shards will occur via crosslinks. These are messages managed by the Beacon Chain that govern Beacon Chain voting and communication between shards like transfers of assets. The Beacon Chain is also responsible for finality, which is where a block is considered as a valid part of its respective shard chain.


A virtual machine (VM) is a system where software is emulated, acting like it runs on a separate physical computer. A "blockchain computer" like Ethereum runs as client software on many separate physical distributed computers to achieve a single reproducible state through a process of consensus creating a single VM instance. The VM is made from a specific set of instructions similar to assembly language that determines what an ETH2 client will do when it receives a particular message.

A VM operating as a massive "world computer" must possess the following three behaviors: determinate, terminable, and isolated execution.

For a VM to be determinate it must produce the same output for a given set of inputs. Modern computing is built on multiple complex layers from compilers to OSs and networks that largely make the average piece of software somewhat indeterminate, even if your CPU is pretty determinate. So to have predictable behavior to instill confidence in smart contracts that contain millions of notational dollar value, the contract must have highly determinate behavior.

Because the eWASM VM is Turing complete, we need a way to limit execution since we can’t evaluate a computer program to know if it will ever finish (also known as the halting problem). The ability to stop a program from executing in a predictable way is called terminable behavior. In Ethereum this is implemented via the gas mechanism which causes a smart contract to cease operating or transaction to fail if the amount of ETH spent as gas is insufficient.

Finally, the virtual machine must provide isolation. This means if a particular smart contract gets exploited it must not impact any other contracts. A breach here would cause a massive loss of confidence in the network.

Execution Environments

Execution environments (EEs) are a complex topic which are still in the research stage. They have the potential to make ETH2 more flexible and possibly cheaper to use by providing different methods of storing state i.e. account balances, contract variables. They also eventually may provide entirely different transaction models which could reduce transaction fees. They will add a fair amount of complexity though to allow different EEs to interact with each other.

Additional Reading

What is ETH2?

ETH2 roadmap:


Execution environments:

Did you learn something? Follow Raleigh on Twitter, check out his blog, and of course subscribe to the Hedgehog newsletter for more!

Header photo with Ethereum graphic by Antonio Gonzalo.

Great! Next, complete checkout for full access to Hedgehog Array Blog.
Welcome back! You've successfully signed in.
You've successfully subscribed to Hedgehog Array Blog.
Success! Your account is fully activated, you now have access to all content.
Success! Your billing info has been updated.
Your billing was not updated.