Ethereum's Epic Upgrade Roadmap: From The Merge to The Splurge, and the Future of Layer 2 and Layer 3

Ethereum's Epic Upgrade Roadmap: From The Merge to The Splurge, and the Future of Layer 2 and Layer 3Ethereum is undergoing an epic upgrade to enhance its scalability, security, and user experience. This isn't a single event, but a series of carefully planned phases, each representing a significant leap forward in Ethereum's technology and architecture

Ethereum's Epic Upgrade Roadmap: From The Merge to The Splurge, and the Future of Layer 2 and Layer 3

Ethereum is undergoing an epic upgrade to enhance its scalability, security, and user experience. This isn't a single event, but a series of carefully planned phases, each representing a significant leap forward in Ethereum's technology and architecture. This article delves into Ethereum's upgrade roadmap, from The Merge to The Splurge, and analyzes the future development of Layer 2 and Layer 3, aiming for a clear and concise depiction of Ethereum's evolution.

I. The Merge: Transitioning Consensus Mechanisms and Introducing PBS

The Merge is a landmark phase, signifying Ethereum's transition from a Proof-of-Work (PoW) to a Proof-of-Stake (PoS) consensus mechanism. This involved merging the Ethereum Beacon Chain with the main chain, achieving PoS consensus. To understand this shift, consider a simplified model of Ethereum's structure:

[Insert simplified diagram of Ethereum's structure showing the Beacon Chain, execution layer, and shard relationships.]

Under PoW, miners packaged blocks and secured the network. PoS introduces validators who stake ETH to participate in block validation. The post-Merge PoS workflow is as follows:

1. Transaction Submission to Rollup: User transactions are initially submitted to a Rollup, a Layer 2 scaling solution.

2. Validator Adds Transactions to Shard Block: Rollup validators add transactions to the shard block they are responsible for.

3. Beacon Chain Selects Block Proposer: The Beacon Chain selects a validator as the block proposer, responsible for constructing a new block.

4. Committee Verifies Shard Block: Remaining validators form a randomly selected committee to verify the proposed shard block.

5. Block Proposal and Verification: Block proposal and verification must be completed within a slot (typically 12 seconds).

6. Epoch Cycle: Every 32 slots constitute an epoch. Each epoch reshuffles validator order and re-elects committees.

Post-Merge, Ethereum's consensus layer implements Proposer-Builder Separation (PBS). Vitalik Buterin argues that all blockchains will ultimately converge towards centralized block production and decentralized block validation. Due to the dense data of sharded Ethereum blocks, centralized block production is necessary to ensure data availability. Simultaneously, a mechanism is required to maintain a decentralized validator set responsible for verifying blocks and performing data availability sampling. The separation of miners (proposers) and block validators allows miners to focus on block construction, submitting blocks to validators who then determine block validity through bidding and voting.

Sharding, as a partitioning method, distributes computational tasks and storage workloads across the P2P network. Each node only needs to maintain information related to its partition (or shard), rather than the entire network's transaction load. Each shard has its own validator or node network.

However, sharding introduces security challenges. For example, if a network has 10 shard chains, compromising the entire network requires 51% of the network's hashpower, but compromising a single shard only requires 5.1%. To address this, Ethereum plans to introduce the Sufficiently Secure Fragmentation (SSF) algorithm to prevent 51% attacks. Vitalik Buterin notes that transitioning to SSF is a long-term roadmap and will be implemented after the complete rollout of PoS, sharding, and Verkle trees, despite significant progress already made.

The Beacon Chain plays a crucial coordination role. It generates random numbers, assigns nodes to different shards, captures snapshots of individual shards, and facilitates inter-shard communication and network synchronization. The Beacon Chain's execution steps are as follows:

1. Block Producer Commits Block Header and Bid: The block producer submits the block header and bid to the Beacon Chain.

2. Beacon Chain Selects Winning Block: Validators on the Beacon Chain select the winning block header and bid; the block proposer receives the proposer reward regardless of whether they ultimately produce the block body.

3. Committee Votes to Confirm Block Header: A randomly selected committee of validators votes to confirm the winning block header.

4. Block Proposer Reveals Block Body: The block proposer ultimately reveals the block body.

II. The Surge: Rollup-centric Scaling

The Surge phase aims to drive Rollup-centric scaling. Surge refers to adding Ethereum shards, a scaling solution designed to further reduce Rollup costs and simplify user operations.

[Insert simplified diagram of Ethereum's sharding structure.]

Consider zkRollups as an example. A zkRollup consists of a sequencer and an aggregator. The sequencer orders and batches user transactions, sending them to the aggregator. The aggregator executes transactions, generating a previous state root (prevstateroot) and a post-state root (poststateroot), along with a proof. Finally, the aggregator sends the prevstateroot, poststateroot, transaction data, and proof to a contract on L1, which verifies the proof's validity; transaction data is stored in calldata.

The data availability of zkRollups allows anyone to reconstruct the global account state based on the on-chain transaction data. However, using calldata is expensive. Therefore, EIP-4844 (subject to change) proposes increasing block size to 1-2MB, laying the groundwork for future Rollups and data sharding. Currently, Ethereum block sizes are approximately 60KB-100KB; EIP-4844 could increase this limit by 10-34 times. This new block format is called a blob (also referred to as data shard).

III. The Scourge: Addressing MEV Issues

The Scourge phase focuses on resolving Maximal Extractable Value (MEV) problems. Initially known as Miner Extractable Value (MEV), it refers to the ability of miners (or now, validators in PoS) to manipulate transaction order and inclusion for profit.

MEV arbitrage opportunities include:

1. Compressing Storage Space: Gaining a price difference in gas fees by compressing storage space.

2. Front-running Arbitrage: Searching the mempool for profitable transactions and executing them first with higher gas fees.

3. Liquidation Target Finding: Quickly parsing blockchain data to find borrowers who can be liquidated and submitting liquidation transactions first.

4. Sandwiching: Monitoring large transactions on DEXs and executing optimal buy and sell orders before and after to profit.

MEV's drawbacks:

1. Deteriorated User Experience: Some MEV forms, like sandwiching, increase slippage and worsen transaction execution.

2. Network Congestion: Front-running causes network congestion, increasing gas fees for other users.

3. Blockchain Instability: If MEV profits significantly exceed block rewards, miners might be incentivized to reorganize blocks, leading to consensus instability.

Most MEV is extracted by independent network participants called searchers, using complex algorithms and bots to automatically submit profitable transactions. MEV on Ethereum causes network congestion and high fees.

IV. The Verge: Verkle Trees and Stateless Clients

The Verge phase will implement Verkle trees (a mathematical proof) and stateless clients. Verkle trees allow users to become network validators without storing vast amounts of data on their machines. This is a step towards Rollup scaling.

In zkRollups, the aggregator submits proofs; the L1 verification contract only needs to verify the KZG commitment and generated proof in the blob. The KZG commitment ensures all transactions are included. The Verge ensures the verification process is straightforward, requiring only the download of a small amount of data and basic computation to verify the Rollup's submitted proof.

Various zkRollup schemes exist (stark, snark, bulletproof), each with advantages and disadvantages. SNARKs are currently easier to implement than STARKs but, as STARKs technology iterates, a shift towards quantum-resistant STARKs is expected.

While EIP-4844 expands block capacity with blob transactions, the main bottleneck for zero-knowledge proofs remains the proof algorithms themselves. Improvements to algorithms and hardware stacking to enhance proof efficiency are needed, fostering the ZK mining sector.

V. The Purge: Reducing Storage Space

The Purge phase aims to reduce the amount of space needed to store ETH, simplify the Ethereum protocol, and reduce the need for nodes to store historical data, greatly improving network bandwidth.

EIP-4444 proposes that clients no longer need to store more than a year's worth of historical data and allows for the import and export of historical data.