Ethereum Mainnet 2021 Year-End Review: Four Hard Forks and the Evolution of the Eth2.0 Roadmap

Original title: Ethereum Mainnet 2021 Year-end Review

Tim Beiko of the Ethereum Foundation gave a speech in November titled "Understanding the Process of Transitioning to Proof of Stake". In this sharing, he reviewed and sorted out the four hard forks that the Ethereum mainnet underwent in 2021, outlining the improvements made in each area; sorted out the evolution of the Ethereum 2.0 roadmap, explaining why it is currently centered on rollups and adopts an executable beacon chain architecture; analyzed in detail the merged Ethereum architecture and the transition process; and finally reviewed the client team's exploration of the implementation and testing of the merger in 2021, and explained the current progress and future implementation plans.

This speech is very suitable as a summary of the Ethereum mainnet in the past year. ECN has specially translated the speech part of this video and attached relevant article resources as supplements and indexes to facilitate readers to review and organize.

Ethereum’s four hard forks in 2021

Berlin Upgrade (April)

Included EIPs:

➤ EIP-2565: ModExp Gas Cost

Repricing EIP-198 (Large Number Modular Exponentiation) which introduced a precompiled module for modular exponentiation, which enables us to introduce many cryptographic algorithms that require modular exponentiation, such as RSA signature verification. EIP-2565 proposes to reduce the gas cost of this module ModExp (0x00..05) to the same level as the cost of performing other operations.

➤ EIP-2718: Typed Transaction Envelop

This proposal introduces a new transaction type, a transaction envelope, that makes it easier to support multiple transaction types. Ethereum initially launched on the mainnet with only one transaction type, with fields "To" (specifying where the transaction is sent) and "Data" (arbitrary data included in the transaction), which required Ethereum clients to work in lockstep and make sure to make exactly the same changes at exactly the same time. Later, as transaction types changed, EIP-155 (Simple Protection from Replay Attacks) was incorporated during the Spurious Dragon hard fork, allowing clients to interpret the fields differently. EIP-2718 does not solve the complexity introduced by EIP-155, but it can prevent the introduction of more complexity in the future and make it easier to add new transaction types, such as EIP-1559 type transactions.

➤ EIP-2929: Gas cost increases for state access opcodes

This EIP increases the gas cost of a transaction when calling SLOAD, CALL, BALANCE, EXT and SELFEDESTRUCT for the first time. But it is worth noting that for each address or storage slot, such high cost only occurs in the first trigger, and subsequent multiple calls only consume 100 gas each time. Increasing these gas costs can, on the one hand, mitigate the impact of the largest DoS attack vector still remaining on the Ethereum protocol, and on the other hand, limit the size of witness data for the future realization of stateless Ethereum.

➤ EIP-2930: Optional access lists

The purpose of this proposal is to correct the damage caused by EIP-2929 to existing contracts and alleviate the problems caused by increased gas costs. This proposal adds a new transaction type, which contains an access list (the content is the address and storage item key) that the transaction plans to access. By specifying an access list, clients can more easily process transactions, and gas consumption can be safely reduced.

Related reading:

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 history and the EIP that brings the biggest changes in the London upgrade. This EIP will introduce a "basefee" to the network blocks, which will track the gas price from the transactions that the network will accept based on the demand for block space. This means that wallets and users will be able to more easily predict the price of their transactions. In addition, EIP-1559 adds a new transaction type where users can specify a maximum limit they are willing to pay. When they send this maximum limit fee to the miner, they will receive a refund of the difference between the maximum limit fee and the sum of the base fee and the miner's tip. Finally, this EIP will also cause some transaction fees to be burned, which is considered by most of the community to be an important improvement to the economics 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 the transaction was executed in. This will allow smart contracts to access this value on-chain, which will help submit fraud proofs and create trustless gas price derivatives.

➤ EIP-3529: Reduction in refunds

Another major change introduced in London was the removal of gas rebates for the SELFDESTRUCT opcode and the reduction of gas rebates for the SSTORE opcode. While the original intention of the rebates was to incentivize developers to clear state when possible, the reality is that this led to the creation of Gas Tokens, which increased state size. With this gas rebate, Gas Tokens can fill up the state when gas prices are low, and then get rebates for executing these transactions when gas prices rise. In addition, gas rebates can also cause changes in block execution times. EIP-3529 reduces the "execution gas rebate" from 50% to a maximum of 20%. This change will help offset the additional block size changes introduced by EIP-1559, which allows blocks to use twice the gas limit.

➤ EIP-3541: Reject new contracts starting with the 0xEF byte

This EIP will make it impossible to deploy new contracts starting with 0xEF bytes after the London upgrade. They will be retained as a way to identify EIP-3540 semantics. The EVM Object Format (EOF) proposed by EIP-3540 is an extensible and versioned EVM bytecode container format that will be verified once during deployment. Therefore, EIP-3541 lays the foundation for more extensive EVM improvements in the future.

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

EIP-3554 Delayed Difficulty Bomb, also known as Ice Age. The Difficulty Bomb or Ice Age is a mechanism introduced by Ethereum to "freeze" mining while the network transitions to Proof of Stake. Since the transition to Proof of Stake is not ready yet, we need to delay 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 reading:

London Upgrade Overview

《London Mainnet Upgrade Announcement and Related Code Changes》

Why do we need 1559?

Why I don’t think EIP-1559’s block size changes are a cause for concern

《MEV and EIP-1559》

"Analysis of the transaction packaging market under EIP-1559 from the perspective of MEV"

When the Ethereum London Upgrade is Completed (The 37th Seven Days of Ethereum)

《EIP-3529: Reduce GAS Returns》

Beacon Chain Altair Upgrade (October)

Altair is an upgrade of the beacon chain. Its new features include:

• Sync Committee supporting light clients

• Reform of incentive calculations to reduce regulatory complexity

• Modifying proof of stake rewards to improve incentive compatibility

• Calculate each validator’s idleness penalty separately

• The penalty parameter is updated to the original penalty level

Related reading:

《Altair Mainnet Upgrade Announcement》

《Modeling and Analyzing the Impact of Altair Upgrades》

Finalized No.24

Altair Upgrade Explanation (Issue 30: Seven Days of Ethereum)

Consensus Layer Progress Updates

Arrow Glacier Upgrade (December)

Arrow Glacier is another network upgrade similar to Muir Glacier. It will include only one EIP - postponing the difficulty bomb until next summer to prevent the blockchain from freezing, aka an "ice age".

Related reading:

The History of Ethereum’s Difficulty Bomb

Arrow Glacier Upgrade Announcement

Ethereum 2.0 Roadmap Evolution

At a seminar in Taipei in 2018, the core developers of Ethereum made a three-phase Ethereum 2.0 roadmap, and the content delivered in each phase is:

• Phase 0 will bring the Beacon Chain

• In phase 1, data sharding will be added

• In phase 2, virtual machines are added to each shard to implement computations in the system.

By the end of 2020, just before the beacon chain was ready to launch, while work on Phase 1 was progressing well, Phase 2, which would implement computational functionality on the shards introduced in Phase 1, still had many unresolved issues. At the same time, very rapid progress was being made on rollups, the second-layer scaling solution. Multiple teams announced plans to go live on testnets, with encouraging early results. Around this time, Vitalik published a long post on the Ethereum Magicians forum arguing that we should focus our short- and medium-term scaling efforts on rollups. Not only will they be on the mainnet before Phase 2 is complete, they will also be the biggest beneficiaries of Phase 1.

In November of the same year, Mikhail Kalinin published “Executable Beacon Chain”, which proposed the current merged architecture and brought out several insights:

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

• Rollup is the best short-term solution for scaling computation;

• Current Eth1 clients are the best foundation for a merged execution layer;

• Moving to proof-of-stake can be done with minimal impact on currently running applications

In the article, Mikhail proposed to use proof of stake directly as a new consensus algorithm used by clients.

Related reading:

《Detailed Explanation of Ethereum 2.0 Beacon Chain》

Vitalik: Ethereum roadmap centered on rollup

《Executable Beacon Chain》

Ethereum Core Developers Meeting Update 006

Vitalik: The final picture of Ethereum centered on rollup

Post-merger structure and merger process

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

During the merging process, the beacon node will monitor the current PoW chain. When the Total Difficulty of a block reaches the set TERMINAL_TOTAL_DIFFICULTY, the block becomes the final PoW block, and subsequent blocks are constructed and certified by the validators on the beacon chain. When the block is finalized on the beacon chain, the merge is complete.

Related reading:

Ethereum Core Developers Meeting Update 007

Ethereum The Merge Key Points Summary

The process and plan to achieve the merger

The three landmark events that led to the merger were the Rayonism Hackathon in April, the Amphora Workshop in October, and the Kintsugi Project in November.

In order to verify the feasibility of the executable beacon chain architecture, the client team conducted prototype design and built the test network Nocturne in the month-long Rayonism hackathon, proving that the executable beacon chain is a feasible architecture.

In October, the client teams came together again to resolve outstanding issues in the specification at the Amphora workshop event. At the end of the event, the client teams built a development testnet, which ran the conversion process for all client combinations and finalized the merged blocks.

After the Amphora event, after four short development testnets, developers launched the Kintsugi testnet plan. From November to mid-December, developers will launch a new development testnet every week and improve on the previous one. During the Christmas holiday, a long-term public testnet has been launched, and everyone is encouraged to participate in the test.

Currently, 80% to 90% of the implementation work has been completed. Arrow Glacier has postponed the difficulty bomb to June next year, which means that more testing work will be done before June next year.

Related reading:

Amphora: A major merger milestone

《Kintsugi Merged Test Network Announcement》