Ethereum is set out to be one of the killer blockchain platforms in the space.
While the whole vision has not been fully implemented just yet, Ethereum aims at becoming the go-to world computer one day. This means millions, perhaps billions of people, will use Ethereum dapps to access decentralized finance – or defi (like lending) – retail rewards, real estate deeds, and many other digital data pieces owned directly by the user.
To accomplish these major goals, the Ethereum community is releasing a brand new software version soon, dubbed Ethereum 2.0 (aka ETH2.0 or Serenity).
In this piece, I’ll look into the features of Serenity, its completely new design goals, the brand new Ethereum 2.0 stack and, finally, how each phase will interact and get deployed.
If you are interested in learning how Ethereum works under the hood or how to program Ethereum dapps and get in-depth professional knowledge we recommend Ivan on Tech Academy.
I hope you’re ready for a technical overview of Ethereum 2.0. I know I am!
Why does Ethereum need an upgrade? Or a completely new stack?
Why is the Ethereum network changing consensus mechanics and betting on layer two solutions?
If you’ve been wondering about these questions and others, not entirely sure why there’s a clear need for Ethereum to change its inner working mechanics, perhaps discussing the design goals can clear plenty of personal doubts.
Ethereum currently runs on a proof-of-work (PoW) blockchain, similar to Bitcoin, which has some serious downfalls. With PoW, miners use expensive hardware and relatively large amounts of electricity to compete with each other while trying to solve a forever increasing difficulty mathematical cryptographic problem. The difficulty adjusts depending on the number of active miners, requiring more equipment and more electricity the more miners there are – a feedback loop that makes this method of consensus inefficient and prohibitively expensive for most users.
Another issue is with database bloating. Essentially, there’s an ongoing problem with the size of the Ethereum blockchain, meaning when new nodes join the network they most likely need to trust a historical node to verify initial (and older) blocks. Another issue is with the centralization of development and API services, like Infura.
To counter some of the problems discussed above, the design rationale behind Serenity is the following:
- Simplicity: as in (i) minimizes development costs, (ii) reduces the risk of unforeseen security issues, and (iii) allows protocol designers to more easily convince users that parameter choices are legitimate.
- Long-term stability: by minimizing changes to the core protocol (use layer 2 solutions).
- Sufficiency: by allowing any class of applications to be deployed.
- Defense in depth: guarantee the protocol liveliness under any security assumption (network latency, fault count, the motivations of users).
- Full light-client verifiability: any client verifying data should have assurances about the liveliness and availability of any piece of data.
Before diving into how ETH 2.0 will look like in terms of stack and functionality, it’s important to take a step back and analyze the recent past.
Looking at the drawing board above, Ethereum 1.0 was composed of three major parts:
- Homestead and
- Metropolis (Byzantium & Constantinople).
Each update helped ETH 1.0 reaching software adulthood, meaning: transactions were processing as expected, miners were securing the main chain, dapps were getting deployed and the number of users and transactions grew to millions.
While ETH 1.0 was the basis for the very first world computer, it couldn’t possibly scale to what is required to sustain an ever-growing number of users and dapps. Meaning the Ethereum foundation had to introduce a brand new stack to satisfy its user-base.
This is where Ethereum 2.0 comes in, with its layered approach.
Layer 1 vs Layer 2
While Ethereum 1.0 consisted of a single base-layer protocol and multiple side-chains, Ethereum 2.0 aims at improving both scalability (layer 1 + layer 2) and interoperability (side-chains).
To understand the layered design choice, let’s discuss trade-offs. There is a tradeoff in any blockchain protocol between introducing more features at layer 1 (i.e. at consensus layer), vs building a more simplified protocol and allowing those features to be built at layer 2 (i.e. as applications on top). Proponents of the second, layered, approach argue benefits range from:
- Reduced complexity of the consensus layer (see simplicity above),
- Reduced need to modify the consensus layer (see long-term stability above),
- Reduced consensus failure risks (see defense-in-depth and full light-client verifiability above).
Now that you understand the layered approach to the brand new Ethereum, let’s check how it will work and be implemented.
Let’s get back to the drawing board. Above I’ve highlighted how Ethereum 2.0 will be deployed.
Essentially, Serenity will have two major phases. During Phase 0 the Beacon chain will interact with the old ETH 1.0 PoW chain. On Phase 1 shards will communicate with the Beacon chain and, lastly, the stateless execution environment will get deployed for each sharded environment (most likely, on phase 2).
While phase 0 focuses on the deployment of proof-of-stake, through the use of the Casper protocol by the Beacon chain, phase 1 will focus on adding sharding and layer two functionality.
Despite existing multiple versions of the Casper PoS protocol, I will focus on the one chosen by the Ethereum community, Casper FFG.
Casper FFG introduces the concept of finality, something quite different from the current Nakamoto-consensus where the longest chain wins. To achieve this outcome Casper adopts the following mechanics:
- Rising the cost of attack: by introducing a slashing mechanism, where a validator that is detected to have misbehaved can be penalized (from 1% to 100% of its stake).
- Introducing the concept of finality: where a block is confirmed in such a way that a large portion (ie. 1/3) of validators would need to misbehave and get slashed for that block to get reverted in favor of some conflicting block.
Hence, the ETH 2.0 stack will be based on the Beacon chain, further discussed below.
Ethereum 2.0 Phase 0
Phase 0 represents the initial deployment of the Beacon chain, which introduces proof-of-stake (PoS). Significant advantages of PoS include security, reduced risk of centralization, and its energy efficiency.
The major change in Phase 0 is, in fact, the Beacon chain. This “lighthouse” has the goal of being an anchor to the entire Ethereum network. Some of its features are:
- One chain to rule them all,
- Proof-of-stake chain (Casper),
- The consensus layer for everything,
- Manages validators,
- Applies rewards and penalties,
- Serves as an anchor point for the shards through cross-links.
The Beacon chain will also introduce a brand new cryptocurrency, ETH2. At the moment, any user who wishes to validate transactions on the Beacon chain will have to stake at least 32 ETH2.
In chain-based PoS, the algorithm pseudo-randomly selects a validator during each time slot (i.e. every 10 seconds), and assigns that validator the right to create a single block. This forged block must point to some previous block and over time most blocks converge into a single constantly growing chain.
Essentially, the following features will be implemented in Phase 0:
- Managing validators and stakes,
- Organizing and electing committees and proposers,
- Applying consensus rules,
- Rewarding and slashing.
Ethereum 2.0 Phase 1
After phase 0 is completed and the Beacon chain deployed, Serenity should move into Phases 1 and 2.
Since phase 2 has no official release date, I’m adding its features in phase 1, just to make sense of the whole thing.
Phase 1 will bring sharding to the Beacon chain, as well as the introduction of the new Ethereum Virtual Machine (EVM), powered by Ewasm, a deterministic smart contract execution engine, which will allow for the creation of interoperable execution environments (which come in Phase 2).
By implementing sharding and cross-shard communication Ethereum is making its EVM insanely scalable. Since it will be possible for node operators to specialize in application-specific shards, we could see new services popping up soon.
To conclude, Phase 1 will implement sharding and Phase 2 will implement the execution environments. Looking at the features that will get added:
- Constructing the shard chains and blocks,
- Anchoring (cross-linking) shard blocks to the Beacon chain,
- Ewasm based virtual machine for the execution environments,
- Every shard has access to all execution environments,
- Ability to make transactions within execution environments,
- Ability to run and interact with smart contracts,
- Cross-shard communication.
A list of important resources is provided below:
- Ivan On Tech Academy,
- Ivan On Tech ETH 2.0 code review,
- Ivan On Tech ETH 2.0 discussion,
- ETH 2.0 Specs,
- Proof-of-Stake Rationale,
- ETH 2.0 Phases,
- ETH 2.0 For Humans,
- ETH 2.0 Presentation by Danny Ryan
This article is not financial advisement. Changes may happen that the author is unaware of. Always check the resources provided!