Ethereum Mainnet 2021 Year-End Review: Rollup as the Best Short-Term Solution for Scalable Computation

Original Title: Ethereum Mainnet 2021 Year-End Review

Original Author: ECN

Tim Beiko from the Ethereum Foundation gave a talk in November titled "Understanding the Transition to Proof of Stake." In this presentation, he reviewed and organized the four hard forks that took place on the Ethereum mainnet in 2021, outlining the improvements made in each; traced the evolution of the Ethereum 2.0 roadmap, explaining why the focus is currently on rollups and the adoption of an executable beacon chain architecture; provided a detailed analysis of the post-merge Ethereum architecture and the transition process; and finally reviewed the progress made by client teams in exploring and testing the merge throughout 2021, detailing the current status and future implementation plans.

This talk serves as an excellent summary of the Ethereum mainnet over the past year. ECN has translated the speech portion of this video and included relevant article resources as supplements and references for readers to revisit and organize.

Four Hard Forks of Ethereum in 2021 Berlin Upgrade (April) Included EIPs:

➤ EIP-2565: ModExp Gas Cost

Repriced the previously introduced ModExp precompiled module from EIP-198 (Big Number ModExp), which allows us to introduce many cryptographic algorithms that require modular exponentiation, such as RSA signature verification. EIP-2565 proposed to lower the gas cost of the ModExp module (0x00..05) to be comparable to the cost of executing other operations.

➤ EIP-2718: Typed Transaction Envelope

This proposal introduced a new transaction type, a transaction envelope that makes it easier to support multiple transaction types. When Ethereum first launched on the mainnet, there was only one transaction type, with fields "To" (specifying the destination of the transaction) and "Data" (containing arbitrary data in the transaction), which required Ethereum clients to be in sync to ensure identical changes at the same time. Later, as transaction types evolved, EIP-155 (simple protection against replay attacks) was included during the Spurious Dragon hard fork, allowing clients to interpret fields differently. EIP-2718 does not resolve the complexity introduced by EIP-155 but prevents further complexity from being introduced, making it easier to add new transaction types, such as EIP-1559 type transactions.

➤ EIP-2929: Gas Cost Increases for State Access Opcodes

This EIP increased the gas cost for a transaction's first call to SLOAD, CALL, BALANCE, EXT, and SELFEDESTRUCT. Notably, this high cost only occurs on the first trigger for each address or storage slot, with subsequent calls consuming only 100 gas each. Increasing these gas costs can mitigate the impact of the largest DoS attack vectors still present in the Ethereum protocol and is also a step towards limiting the size of witness data for future implementation of stateless Ethereum.

➤ EIP-2930: Optional Access Lists

The purpose of this proposal is to address the disruption caused by EIP-2929 to existing contracts and to alleviate the issues arising from increased gas costs. This proposal introduces a new transaction type that includes an access list (containing addresses and storage item keys) that the transaction plans to access. By specifying an access list, clients can handle transactions more easily, allowing for a safe reduction in gas consumption.

Related Articles:

"Gas Costs After the Berlin Hard Fork"

"Ethereum Berlin Upgrade Announcement" London Upgrade (August) Included EIPs:

➤ EIP-1559: Fee Market Change for ETH1.0 Chain

EIP-1559 is one of the most anticipated changes in Ethereum's history and the EIP that brought the most significant changes in the London upgrade. This EIP introduces a "base fee" in network blocks that tracks gas prices based on the demand for block space. This means wallets and users can more easily predict the price of their transactions. Additionally, EIP-1559 introduces a new transaction type where users can specify a maximum fee they are willing to pay, and when they send this maximum fee to miners, they will receive a refund of the difference between the maximum fee and the sum of the base fee and miner tip. Finally, this EIP will lead to some transaction fees being burned, which is seen by most of the community as an important improvement in the economic model of the Ethereum network.

➤ EIP-3198: BASEFEE Opcode

This EIP is paired with EIP-1559. It simply adds a BASEFEE opcode that returns the base fee of the block in which the transaction is executed. This allows smart contracts to access this value on-chain, aiding in the submission of fraud proofs and the creation of trustless gas price derivatives.

➤ EIP-3529: Reduction in Refunds

Another significant change introduced in London is the elimination of gas refunds for the SELFDESTRUCT opcode and a reduction in gas refunds for the SSTORE opcode. While the intention behind establishing refunds was to incentivize developers to clear state when possible, the reality is that this led to the emergence of Gas Tokens, which increased state size instead. Utilizing these refunded gas, Gas Tokens could fill the state when gas prices were low and then receive refunds for executing those transactions when gas prices rose. Additionally, gas refunds could lead to variations in block execution times. EIP-3529 reduces "execution gas refunds" from 50% to a maximum of 20%. This change will help offset the additional block size variations introduced by EIP-1559, as EIP-1559 allows the gas used by blocks to be twice the current gas limit.

➤ EIP-3541: Reject New Contracts Starting with the 0xEF Byte

This EIP will prevent new contracts starting with the 0xEF byte from being deployed after the London upgrade, reserving them for future identification in accordance with EIP-3540 semantics. The EVM Object Format (EOF) proposed by EIP-3540 is a scalable and versioned EVM bytecode container format that will be validated once at deployment. Thus, EIP-3541 lays the groundwork for broader EVM improvements in the future.

➤ EIP-3554: Difficulty Bomb Delay to December 1st, 2021

EIP-3554 delays the difficulty bomb, also known as the Ice Age. The difficulty bomb or Ice Age is a mechanism introduced by Ethereum that "freezes" mining as the network transitions to proof of stake. Since the transition to proof of stake is not yet ready, we need to postpone the "explosion" of the bomb. This has been done three times in the past: in Metropolis (EIP-649), Constantinople (EIP-1234), and Muir Glacier (EIP-2384).

Related Articles:

"Overview of the London Upgrade"

"London Mainnet Upgrade Announcement and Related Code Changes"

"Why EIP-1559 is Needed"

"Why I Believe the Block Capacity Changes from EIP-1559 are Not a Concern"

"MEV and EIP-1559"

"Analyzing the Transaction Packaging Market Under EIP-1559 from the MEV Perspective"

"When the Ethereum London Upgrade is Complete (Issue 37 of Ethereum Weekly)"

"EIP-3529: Reduction in Gas Refunds" Beacon Chain Altair Upgrade (October) Altair is an upgrade to the beacon chain that includes new features such as:

• Support for light client sync committees

• Incentive calculation reform to reduce specification complexity

• Modification of proof rewards to improve incentive compatibility

• Separate accounting for each validator's slashing penalties

• Update of penalty parameters to the originally intended penalty levels

Related Articles:

"Altair Mainnet Upgrade Announcement"

"Modeling the Impact of the Altair Upgrade"

"Finalized no.24"

"Altair Upgrade Explanation (Issue 30 of Ethereum Weekly)"

Updates on Consensus Layer Progress Arrow Glacier Upgrade (December) Arrow Glacier is another network upgrade similar to Muir Glacier. It will only include one EIP—delaying the difficulty bomb until next summer to prevent the blockchain from freezing, i.e., the "Ice Age."

Related Articles:

“History of the Ethereum Difficulty Bomb”

“Arrow Glacier Upgrade Announcement”

Evolution of the Ethereum 2.0 Roadmap

At a seminar in Taipei in 2018, Ethereum core developers outlined a three-phase Ethereum 2.0 roadmap, with the deliverables for each phase being:

• Phase 0 will bring the beacon chain

• In Phase 1, data sharding will be introduced

• In Phase 2, virtual machines will be added to each shard to implement computation within the system.

By the end of 2020, just before the beacon chain was about to launch, although work on Phase 1 was progressing smoothly, there were still many unresolved issues regarding the implementation of computation on the sharding introduced in Phase 1 in Phase 2. Meanwhile, rapid progress was being made in rollups (i.e., layer 2 scaling solutions). Multiple teams announced plans to launch testnets and achieved encouraging early results. Around this time, Vitalik published a lengthy article on the Ethereum Magicians forum arguing that we should focus our short- and medium-term scaling efforts on rollups. They would not only launch on the mainnet before Phase 2 is completed but would also be the biggest beneficiaries of Phase 1.

In November of the same year, Mikhail Kalinin published "Executable Beacon Chain," proposing the current merge architecture and providing several insights:

• The beacon chain has launched and can now be used as a consensus engine;

• Rollups are the best short-term solution for scaling computation;

• The current Eth1 clients are the best foundation for the execution layer post-merge;

• Transitioning to proof of stake can be achieved in a way that minimally impacts currently running applications.

In the article, Mikhail proposed using proof of stake as a new consensus algorithm for client usage.

Related Articles:

"Detailed Explanation of Ethereum 2.0 Beacon Chain"

"Vitalik: Ethereum Roadmap Centered on Rollups"

"Executable Beacon Chain"

"Ethereum Core Developers Meeting Update 006"

“Vitalik: The Final Picture of Ethereum Centered on Rollups”

Post-Merge Architecture and Transition Process

In summary, after the merge, clients will switch from determining Ethereum's latest valid block based on the PoW chain to the PoS chain. Moreover, most of the client's functionalities, and more importantly, the EVM, its state, and how it executes transactions, remain unchanged. The current Eth1 and Eth2 clients become Ethereum's execution layer and consensus layer (or engine), respectively. This means that node operators running either the Eth1 or beacon chain client will need to run the "other half" of the stack to have a complete validating node.

During the merge process, the beacon node will monitor the current PoW chain, and when the Total Difficulty of a block reaches the set TERMINALTOTALDIFFICULTY, that block becomes the last PoW block, and subsequent blocks will be constructed and proven by validators on the beacon chain. When this block is finalized on the beacon chain, the merge is complete.

Related Articles:

“Ethereum Core Developers Meeting Update 007”

“Ethereum The Merge Key Summary”

Journey and Plans for Implementing the Merge

The three landmark events for implementing the merge are: the Rayonism hackathon in April, the Amphora workshop in October, and the Kintsugi plan launched in November.

To validate the feasibility of the executable beacon chain architecture, the client team prototyped and built the Nocturne testnet during the month-long Rayonism hackathon, demonstrating that the executable beacon chain is a viable architecture.

By October, during the Amphora workshop, the client team gathered again to resolve outstanding issues in the specifications. At the end of the event, the client team built a development testnet that ran through the transition process of all client combinations and finalized the blocks post-merge.

After the Amphora event, following four brief development testnets, developers launched the Kintsugi testnet plan. Between November and mid-December, developers launched a new development testnet each week, improving upon the previous one. During the Christmas holiday, a long-term public testnet was launched, encouraging everyone to participate in testing.

Currently, the implementation work is about 80% to 90% complete, and Arrow Glacier has delayed the difficulty bomb until next June, indicating that more testing work will take place before next June.

Related Articles:

“Amphora: An Important Milestone for the Merge”

“Kintsugi Merge Testnet Announcement”