• Berlin hard fork has been launched on the testnet: it is time to start the development of apps and wallets on the testnet!
• London hard fork is in preparation stage: EIP-1559 implementation is in progress, and in order to complete the upgrade before the July or August deadline, the scope of the upgrade is very narrow.
• The upgrade focus of the Shanghai hard fork is still under discussion: either the core developers will concentrate their efforts on the eth1->eth2 merger, or the deployment of those high-voiced EIPs after the prototyping is merged

Berlin upgrade

The Berlin upgrade content has been deployed on all major test networks and will be launched on the main network on April 14th with a block height of 12,244,000. This upgrade will improve the security of Ethereum and prepare for the deployment of EIP-1559 in the London upgrade. If the reader is running a node and has not updated the client version, update it as soon as possible! As for the updated version of the client, there is an announcement in the "Ethereum Berlin Upgrade Announcement".

In terms of security, the gas fee for accessing Ethereum state opcodes is too low compared to its computational cost, and EIP-2929 can solve this problem. Taking advantage of the fact that the gas cost of opcodes is too low, malicious participants can create blocks that repeatedly call these opcodes, and the processing speed of these blocks is several orders of magnitude slower than ordinary blocks. EIP-2929 alleviates this problem by providing approximately 3 times the gas cost. On the client side, database management has been improved. For example, the snapshot database format of the Geth client also helps to more effectively process blocks with more state access.

However, in order to alleviate the negative impact of EIP-2929 on users, Berlin upgraded and introduced its supporting EIP-2930. It allows users to specify an "access list" when submitting a transaction to use a gas fee lower than 2929. Among them, the calculation method of gas fee is a bit complicated, but from a high-level perspective, if the client knows in advance which part of the state the transaction will involve, they can preload it and charge less gas for these accesses. I encourage everyone to refer to this EIP for accurate calculations.

For application and wallet developers who want to experience the function of generating "access list", the Geth client will soon launch related tools 🔜 You can click here to view the development process. More broadly, if you are an app or wallet developer, now is the time to test the Berlin upgrade on the testnet!

Regarding EIP-1559, Berlin provides assistance in two ways. First of all, EIP-2929 solves the biggest risk of EIP-1559: DoS attacks will be carried out on blocks twice as large as the current ones. This is the first reason client developers oppose EIP-1559, and this issue is discussed every time 1559 is discussed in the core developer meeting. In other words, if there is no 2929, we cannot safely go online with 1559.

Second, Berlin introduced support for multiple transaction types at the protocol level through EIP-2718. The "access list" creation function introduced by EIP-2930 requires a new transaction type, so EIP-2718 provides a comprehensive framework to support multiple transaction types. This means that the implementation of 2718 and 2930 in Berlin allows the client team to do architectural foundation work ahead of time to prepare for supporting 1559-type transactions.

Finally, everyone has another worry about the Berlin upgrade, worrying that EIP-2929 will increase the cost of DeFi transactions. However, the introduction of EIP-2930 will offset some (and not all of them). The obvious solution to prevent this type of transaction gas fee from increasing is to increase the block gas limit.

However, doing so is always good and bad: increasing the block capacity will accelerate state growth, which makes it more difficult for nodes to synchronize with the network. On the other hand, not increasing the block gas limit will increase the transaction cost of network users (pay expensive gas fees). Perhaps this is a fair compromise: introduce 2929 to reduce the risk of DoS, and then slowly increase the block capacity until the gas fee raised by 2929 is gradually offset.

London Upgrade

As the Berlin hard fork is about to launch the mainnet, the core developers are now focusing on the next network upgrade: London. This upgrade is a bit special. Since the difficulty bomb will occur in August, the London upgrade must be deployed before that. In other words, the development and update of the next upgrade (London) must be started before the previous upgrade deployment. This is the first time that core developers have encountered this situation.

The London upgrade will deploy the long-awaited EIP-1559 on the main network. If readers are new to this EIP, I have compiled a list of resources and documented the development process of the past year.

The changes brought about by this EIP alone to Ethereum are greater than the total upgrade of all EIPs in Berlin. Moreover, the implementation and testing time is shorter than the previous upgrade, so the core developers are trying to narrow the scope of the London upgrade to complete it on time. So far, the London upgrade only includes EIP-1559 and EIP-3238 (it is proposed to postpone the difficulty bomb until the second quarter of 2022). After the implementation and testing of 1559 are over, the core developers will be in a more proactive position and will then decide which EIPs to add.

Shanghai upgrade

As the upgrade scope in London has been deliberately narrowed, core developers have begun high-level planning for the upgrade in Shanghai. We have the following two main possibilities:

First, we can implement EIPs that are impossible to deploy in London, such as:

EIP-3074: Allow "funded transactions", etc.
EIP-2537: Add support for BLS-12381 curve (used by beacon chain)
EIP-2327: Good for the Solidity and Optimism teams
EIP-2935: helpful for light clients and stateless clients
Or, the community is paying more and more attention to the merger between the consensus (eth2) and application (eth1) layers, which is simply merge™️. The Eth2 specification library has included the PR of the "simplified merge specification" proposal, and it is very close to the prototype that the client team should be able to produce.

Although the merge specification may be relatively simple, there are still several engineering issues that need to be resolved in order for application-layer clients to use the beacon chain as their consensus engine. Letting the client developers on both sides pay attention to these problems is our way of discovering and solving them.

The client team still needs to better digest these specifications and start building prototypes before they can decide whether we are ready to shift all our energy to the merger work, or whether we need a small working group before everyone can participate. Do more work. To speed up this process, clients from the application and consensus layers will develop prototypes of the latest specifications during the Scaling Ethereum hackathon.

The end of the Ethereum hackathon event coincides with the completion of most of the work in London and the Altair upgrade (which will be carried out in June). This means that the prototype should be prepared in time so that we can make a decision about the Shanghai upgrade.