"Berlin" update content overview

Editor's Note: This article comes fromEthereum enthusiasts (ID: ethfans)Editor's Note: This article comes from

Ethereum enthusiasts (ID: ethfans)

Ethereum enthusiasts (ID: ethfans)

, Author: Pooja Ranjan, translation: A Jian, reprinted by Odaily with authorization.

Following the "Muir Glacier" upgrade, the Ethereum blockchain plans to implement the "Berlin" upgrade. According to its specifications, the Ethereum mainnet blockchain is expected to activate at block height 12_244_000 on April 10, 2021. The specific time may be advanced or delayed due to fluctuations in the block generation time.

It's been 15 months since the last network upgrade, and we've made a lot of progress in that time. The client side of the Ethereum network is ready to activate 4 proposals to improve the performance of the network and lay the groundwork for further upgrades in the future.

Slightly different from previous Ethereum network upgrades, the content and progress of this upgrade will not be reflected in a single EIP. If you want to know what it is, read the "Berlin" network upgrade spec and track its progress in the eth1.0-specs repo.

What changes will be included in the "Berlin" upgrade?

The "Berlin" upgrade will introduce the following EIPs to the Ethereum network:

EIP-2565: Change the gas overhead of modulo/exponentiation operations

The EIP-2565 proposal is a repricing of the previous EIP-198 (modulo exponentiation of large numbers); initially, EIP-198 introduced a precompiled module for modulo exponentiation that allowed us to import many Cryptographic algorithms that require modulo exponentiation, such as the verification of RSA signatures. EIP-2565 reduces the gas overhead of this module to be on par with the overhead of performing other operations. Watch Kelly Olson's explainer video for an overview of the proposal and some interesting graphs on gas repricing.

EIP-2718: Standardized Transaction Envelopes

This EIP introduces a new transaction type, which itself acts as an envelope to more easily enable support for multiple transaction types.

When Ethereum first launched on mainnet, there was only one transaction type, with fields "To" (indicating the purpose of the transaction) and "Data" (to include arbitrary data in the transaction). For Ethereum clients to reach consensus, they must be in lock step, guaranteeing that they apply the same state changes when processing the same transaction. So, if the "To" field is 0, all clients must interpret the "Data" field as a deployment contract and execute it in a specific way.

Over time, the need for transaction types changed. The EIP-155 (Simple Protection against Replay Attacks) proposal embodies this (Translator's Note: EIP-155 uses the "chain ID" field to prevent transactions from being replayed on different networks compatible with the Ethereum protocol). However, no new transaction types were introduced at that time, and it was the client team that reached a social consensus and adopted different interpretations of this field. The "Spurious Dragon" (i.e. EIP-155 incorporated) hard fork is a consensus change hard fork because all clients need to agree on the interpretation of this field. EIP-2718 can't help untangle the complexity introduced by EIP-155, but it can prevent more complexity from being introduced in the future, and it also makes it easier to add new transaction types (such as transactions in the form of EIP-1559) . For an in-depth understanding of the proposal, watch the video Micah Zoltu explaining EIP-2718.

EIP-2929: Increase gas overhead for state access opcodes

This EIP increases the Gas consumption of a transaction when calling SLOAD, *CALL, BALANCE, EXT* and SELFDESTRUCT for the first time. For example, it increases the gas consumption of the CALL family of functions from 700 to 2600, and the gas consumption of the SLOAD family from 800 to 2100. However, (within a transaction) this high cost is only triggered once for any address or storage slot, and if called multiple times, subsequent calls only consume 100 Gas each time.

The purpose of increasing the Gas consumption of these operations is to mitigate the remaining DoS attack surface of the Ethereum protocol. Additionally, it also helps limit the size of witness data in a stateless Ethereum post-implementation environment. Currently, the bandwidth required to incorporate Merkle proofs is far greater than the reasonable size required to validate a block, so everyone is looking for some way to impose an upper limit on witness data. While EIP-2929 doesn't fix everything, it does go a step further. Another benefit is that calls to precompiled modules will become cheaper: this EIP removes the extra 700 Gas payment for accessing precompiled modules.

EIP-2930: Optional access lists

The idea behind this proposal is to correct the damage caused by EIP-2929 to existing contracts and alleviate the problem of increased Gas consumption caused by EIP-2929. The proposal would introduce a new type of transaction that could contain an access list (a list of addresses and storage item keys) that would allow the transaction to indicate the state it plans to access. By specifying an access list, clients can process transactions more easily, and gas consumption can thus be safely reduced.

Watch Vitalik B. and Martin S.'s explainer video on EIP-2929 and 2930 for more details and their benefits for the Ethereum blockchain.

What's the news on EIP management and Ethereum governance?

Curious babies who have doubts about the upgrade time interval, look here!

The "Muir Glacier" upgrade contains only one proposal, which is to postpone the ice age of Ethereum PoW mining. The Muir Glacier upgrade happened in January 2020 because we couldn't wait to deploy with any of the other proposals.

In order to design a better network upgrade program, volunteers from the Ethereum community, including EIP editors, EIP authors, client developers, Ethereum Cat Shepherds and other community members, jointly established the EIPIP organization. Ethereum Cat Herders also hosts a key Ethereum installed base survey to better understand the current state of Ethereum client diversity.

That said, progress knows no bounds. Your feedback is vital as we continue to improve the quality of the upgrade process.

I am a node operator/miner, what should I do?

Please download the latest version of the Ethereum client you are using.