Vitalik Buterin (Ethereum Co-founder) – What Happens After the Merge (Apr 2021)

Chapters

Abstract

The Future of Ethereum: A Comprehensive Analysis of Post-Merge Developments and Innovations

Introduction

In the rapidly evolving landscape of blockchain technology, Ethereum stands at a critical juncture post-merge. This article delves into the significant changes and advancements shaping Ethereum’s future. From the shift to proof-of-stake in the merge to the implementation of sharding and state expiry, each development is a step toward a more efficient, secure, and scalable Ethereum.

Post-Merge Roadmap

The merge represents a minimalistic yet pivotal transition for Ethereum, shifting from proof-of-work to proof-of-stake. This move necessitates a post-merge cleanup, including removing the ETH1 data voting mechanism and enabling withdrawals. Crucially, the execution chain will fully transition to Simple Serialize (SSZ), enhancing compatibility with the beacon chain. Additionally, new beacon state access opcodes will facilitate applications’ interaction with the consensus layer. A contentious decision to cease support for the pre-merge proof-of-work chain aims to streamline consensus node operations.

Post-Merge Cleanup Fork:

The merge will transition Ethereum’s execution layer into a chain inside the consensus layer.

The post-merge cleanup fork will address issues resulting from the minimalistic merge.

Key improvements include removing the ETH1 voting data mechanism, enabling withdrawals, and potentially fully migrating the execution chain to SSZ.

The cleanup fork will simplify the protocol, remove unnecessary assumptions, and enhance efficiency.

Beacon State Access Opcodes:

Opcodes to access the beacon chain state will be introduced, including RANDAO and beacon block root opcodes.

These opcodes allow applications to utilize on-chain randomness and facilitate proving historical data, which is crucial for sharding.

Client Agreement on Pre-Merge Data:

At some point, clients should agree to stop downloading the pre-merge proof-of-work chain.

This will break the invariance of the base Ethereum protocol providing the entire history back to Genesis.

The rationale is that the Ethereum protocol should not be responsible for maintaining the entire history.

Accessing pre-merge data can be facilitated through alternative protocols or services.

Sharding and Scalability

Sharding emerges as a critical component of Ethereum’s scalability strategy, prioritized for post-merge implementation. It involves 64 data shards, each handling data blobs used by rollups, with shard blocks produced every 12 seconds. This staggered approach ensures rollups can quickly use new blocks, enhancing efficiency. Data availability sampling, a vital security feature, will enable clients to detect data unavailability, further bolstering the network’s robustness.

Sharding:

Sharding, initially planned before the merge, will now be implemented and activated after the merge.

This decision allows for a focused and staged approach to major protocol changes.

Data Sharding:

Data sharding involves dividing the blockchain data into manageable chunks called shards, which are essentially blobs of data.

These data shards are specifically designed to be utilized by rollups, which are a scaling solution that bundles multiple transactions into a single transaction.

Shard Blocks:

There will be 64 data shards in Ethereum 2.0, with each shard targeting an average size of either 256 or 512 kilobytes per shard block produced every 12 seconds.

Security of Shard Blocks:

Initially, the security of shard blocks will rely on a randomly selected committee that votes on the validity of the blocks. If the committee approves, the block is accepted.

Over time, higher levels of security will be added through mechanisms like proof of custody and data availability sampling.

Staggered Shard Blocks:

The concept of staggered shard blocks allows rollups to continuously use these new rollup blocks as soon as they become available, resulting in faster walk times compared to the 12-second tick time of the beacon chain.

Rollups and Initial Confirmation Times:

Rollups are currently seen as a promising strategy for achieving competitive initial confirmation times in the ETH2 system and its associated rollups.

By utilizing staggered shard blocks, rollups can have walk times that are much faster than the 12-second tick time of the beacon chain, making them competitive with more centralized chains.

Data Availability Sampling:

Data availability sampling is highlighted as a crucial security technology in Ethereum 2.0.

This technique involves randomly selecting a subset of nodes to verify the availability of data in the shards, ensuring that malicious actors cannot hide or tamper with data.

Security Enhancements

Post-merge Ethereum will see several security improvements. The Single Secret Leader Election and Verifiable Delay Functions (VDFs) will provide secure randomness for committee selection, reducing risks of DoS attacks and collusion. Proof of Custody will compel nodes to validate block data, thus preventing centralization.

Data Availability Sampling:

Introduces state availability sampling to verify data availability guarantees probabilistically.

Clients can detect data availability failures and reject shard blocks that are unavailable.

Preserves the property that a 51% attacker can revert the chain but cannot force clients to accept invalid or unavailable data.

Achieved by redundantly encoding each block with polynomial commitments.

If 50% of the block is available, the entire block can be recovered.

Random sampling is used to check that enough of the block is probably available.

Single Secret Leader Election:

Ensures that proposers of beacon blocks and shard blocks are not publicly visible.

Mitigates denial-of-service issues, collusion risks, and improves security.

Verifiable Delay Functions (VDFs):

Provides secure randomness for choosing committees.

Increases the security of the system, making it more difficult to attack committees.

Reduces the required percentage of honest nodes for security from 70% to around 57-60%.

Proof of Custody:

Ensures that nodes download, keep, and validate block data.

Acts as an anti-centralization measure.

Address and State Management

Ethereum’s address length will increase from 20 to 32 bytes, enhancing security and collision resistance. Alongside, the network will implement statelessness and state expiry, addressing the unsustainable growth of the current state size. Stateless clients will use witnesses and cryptographic proofs for block verification, a move complemented by EIP-2929, which reworks gas costs for storage reads.

Address Extension:

Addresses will increase from 20 bytes to 32 bytes for improved security and collision resistance.

Version numbers will be added for future compatibility.

This change is necessary for state expiry proposals.

Statelessness and State Expiry:

Key issue for the Ethereum execution layer is managing state size growth.

Statelessness involves creating two classes of nodes: state-storing nodes and stateless nodes (aka stateless clients).

Stateless nodes verify blocks using witnesses that provide the relevant state portions and cryptographic proofs.

Vertical trees and code verticalization are essential for keeping witness sizes small.

EIP-2929:

Contributed to statelessness viability by establishing a low balance on state accesses per block.

Reduced gas costs for some transactions, especially more expensive ones.

Ensured a balance on witness sizes to prevent propagation issues.

Final Gas Cost Change:

Along with code verticalization, a gas rule will be added to charge gas for every chunk of code accessed.

This change will complete the shift towards statelessness.

Advanced Ethereum Features

Looking to the future, Ethereum is exploring account abstraction, EVM improvements like EVMX, and potential consensus mechanisms like CBC Casper. Additionally, the use of ZK-SNARKs and STARKs is under investigation to improve efficiency and scalability. These developments, coupled with a focus on quantum security, aim to future-proof Ethereum against emerging technological threats.

Non-Financial Applications on Ethereum

Vitalik Buterin emphasizes the significance of enabling non-financial applications on Ethereum, highlighting examples such as ENS, NFTs, proof of humanity, Colony, and DAOs.

These applications require significantly cheaper transactions, which roll-ups and sharding will provide, allowing the Ethereum ecosystem to thrive as a platform for these innovative use cases.

Timeline for SNARKs and STARKs

Vitalik explains that SNARKs rely on SNARK-friendly hash functions, which require time for de-risking, academic testing, and cryptanalysis.

Additionally, creating a SNARKed version of the EVM is a complex engineering and research task that will take time.

Prioritizing State Expiry

Vitalik acknowledges that while SNARKs and STARKs are important, state expiry is a higher priority for implementation.

State expiry is crucial for sustainability and allowing more gas growth.

Social Recovery Wallets Inside Roll Ups

Vitalik Buterin is a strong advocate for social recovery wallets, which provide a more user-friendly and secure way to manage crypto assets by allowing users to designate trusted individuals or entities as “guardians” who can help recover access to their wallets in case of loss or theft.

He believes that roll-ups, which are a layer-2 scaling solution for Ethereum, present an ideal opportunity to implement social recovery wallets and encourage their adoption among users.

Economic and Ecological Considerations

Ethereum’s economic model is also under revision. Limiting the number of active validators is one such measure to manage transaction processing costs effectively. Moreover, the network seeks a stable state where core developers transition to maintenance mode, reducing the pace of functionality changes.

Near-Term Focus:

Ethereum developers are concentrating on security improvements, economic sustainability enhancements, and new features.

Once these core aspects are addressed, the focus will shift to layer two solutions, allowing Ethereum to enter a maintenance mode.

The goal is to reduce the development burden and the risk of centralization by creating a stable and feature-rich core system.

Long-Term Vision:

Ethereum’s development pace may decrease after key security improvements are made, ensuring the system’s long-term stability.

The focus will be on perfecting and refining the existing features rather than introducing frequent changes.

Tweaks to economic logic and potential new virtual machines (VMs) are still under consideration but are not immediate priorities.

Exploring protocol features to facilitate smooth transitions between different VMs is a potential area of research.

Statelessness and Expiry Management:

Combining statelessness and expiry management is more efficient because it involves transitioning from a single state tree to a state tree per epoch.

This approach allows for more effective pruning of old data, reducing storage requirements and improving overall performance.

State Expiry Simplifies State Tree Upgrades:

State expiry involves transitioning from a single state tree to a model with one state tree per epoch, enabling easier upgrades to the state tree format.

With state expiry, upgrading the state tree format only requires applying the upgraded version to new epochs, simplifying the process compared to the current complex protocol.

Benefits of State Expiry for Statelessness:

State expiry facilitates statelessness by making it easier to upgrade the state tree, a crucial step toward achieving statelessness.

By introducing epochs and expiring old ones, state expiry streamlines the process of upgrading the state tree, making it more feasible and efficient.

Data Availability-Centric Sharding Roadmap:

The focus on data availability-centric sharding is driven by the imminent release of rollups and the fact that data-only sharding provides an immediate scalability boost for rollups.

Data sharding is a necessary stepping stone to data and execution sharding, as it involves solving foundational problems that are common to both types of sharding.

Reducing Technical Debt Pre-Merge:

The continuation of the social norm requiring Ethereum clients to process everything from Genesis to the current point hinders the reduction of technical debt pre-merge.

Moving away from this norm in the long run will allow for more efficient client implementations and facilitate the adoption of new technologies.

Protocol History Removal:

Ethereum clients may only need to verify recent history, reducing the code base and simplifying the protocol over time.

Removing the ability to sync pre-merge proof-of-work history will lead to a single chain and simpler execution clients.

Layer 3 Definition:

The term “Layer 3” lacks a clear definition and can vary in meaning among different individuals.

It may refer to the application layer, layer two protocols for reading state, or application layer constructions like oracles.

EVM and eWASM:

Vitalik Buterin’s interest in eWASM has diminished due to research showing worst-case bugs and limited performance improvements over the EVM.

Extending the EVM (e.g., EVM 384 or EVMX) is a more promising approach, allowing for faster execution and cryptography with backward compatibility.

Optimal Number of Validators:

The current number of validators is sufficient for the merge, and there is no concern about having too few or too many.

Contract Composability Post-Merge:

The merge itself will not directly impact contract composability.

Roll-ups will provide valuable insights into asynchronous interaction and interoperability between different systems.

Zones may emerge as a concept for synchronous interaction within specific boundaries.

Positive Effects for Consumer-Facing Use Cases:

Roll-ups and sharding will significantly increase scalability and reduce transaction fees.

This will positively impact consumer-facing use cases by making Ethereum more accessible and affordable.

Increased scalability will enable more applications and use cases to be built on Ethereum.

Notes by: crash_function