Skip to content

Ethereum: Shanghai Upgrade

A major update for Ethereum is coming - Shanghai upgrade. What will this new upgrade bring to one of the main blockchains in the world?

Almost two months ago, a historic event happen on the Ethereum network, and in the crypto industry as a whole – The Merge. We have been writing about it since the birth of our news agency. But, Ethereum has not stopped developing and continues its path to Web3 dominance.

New features are waiting for us in the upcoming Shanghai upgrade. It, as planned by the developers of Ethereum, is the next major step in the development of the blockchain and will bring what The Merge did not bring - the ability to withdraw staked ETH. As well as other interesting changes.

The developers discussed the upcoming Shanghai upgrade at the 147th Ethereum Core Devs Meeting (ECDM) on September 15. But, potential Ethereum improvement proposals (EIP), which will be put into use together with the Shanghai upgrade, appeared even earlier. After the 129th ECDM release, which happen on January 7 of this year, an approximate list of potential EIPs appeared on Ethereum GitHub, from which several priorities had to be selected. The list looked like this:

List of potential EIPs. Source: Ethereum GitHub

On September 9, a discussion appeared on the Ethereum Magicians website, in which Tim Beiko presented the EIPs being considered for inclusion. There are already fewer of them than in the original list. Now the following changes have become a priority:

EIPs Considered for Inclusion. Source: Ethereum Magicians website

What does it all mean and why is it needed? Let's take it in order.

EIP-3540: EVM Object Format (EOF) v1

This change involves the introduction of “an extensible and versioned container format for the EVM with a once-off validation at deploy time.” One of the main functions of the protocol is the separation of code and data.

“This separation is especially beneficial for on-chain code validators (like those utilised by layer-2 scaling tools, such as Optimism), because they can distinguish code and data (this includes deployment code and constructor arguments too). <…> Code and data separation can result in ease of use and significant gas savings for such use cases.”


In this case, "COINBASE" is not a company of the same name, but a term. "COINBASE" transaction is the first transaction in a block.

This innovation is necessary in order to adjust the gas price for direct COINBASE payments.

“Direct COINBASE payments are becoming increasingly popular because they allow conditional payments, which provide benefits such as implicit cancellation of transactions that would revert. But accessing COINBASE is overpriced; the address is initially cold under the access list framework introduced in EIP-2929. This gas cost mismatch can incentivize alternative payments besides ETH, such as ERC20, but ETH should be the primary means of paying for transactions on Ethereum.”

EIP-3670: EOF - Code Validation

This proposal offers the introduction of code verification when writing smart contracts in the EOF format (EIP-3540).

“Reject contracts which contain truncated PUSH-data or undefined instructions. Legacy bytecode (code which is not EOF formatted) is unaffected by this change. <…> Currently existing contracts require no validation of correctness and EVM implementations can decide how they handle truncated bytecode or undefined instructions. This change aims to bring code validity into consensus, so that it becomes easier to reason about bytecode. Moreover, EVM implementations may require less paths to decide which instruction is valid in the current execution context.”

EIP-3855: PUSH0 instruction

This will add a new PUSH0 (0x5f) instruction. It puts a constant value of 0 into the stack. This is necessary to optimize smart contracts.

“Many instructions expect offsets as inputs, which in a number of cases are zero. <…> They can achieve that today by PUSH1 0, which costs 3 gas at runtime, and is encoded as two bytes which means 2 * 200 gas deployment cost. <…> To put the “waste” into perspective, across existing accounts 340,557,331 bytes are wasted on PUSH1 00 instructions, which means 68,111,466,200 gas was spent to deploy them. In practice a lot of these accounts share identical bytecode with others, so their total stored size in clients is lower, however the deploy time cost must have been paid nevertheless.”

EIP-3860: Limit and meter initcode

This innovation is designed to expand the EIP-170. And also introduce a new gas fee.

“We extend EIP-170 by introducing a maximum size limit for initcode (MAX_INITCODE_SIZE = 2 * MAX_CODE_SIZE = 49152). Furthermore, we introduce a charge of 2 gas for every 32-byte chunk of initcode to represent the cost of jumpdest-analysis. Lastly, the size limit results in the nice-to-have property that EVM code size, code offset (PC), and jump offset fits a 16-bit value.”

EIP-4895: Beacon chain push withdrawals as operations

This proposal is the last on the list, but non the less important. It is quite possible that will attract public attention to the upcoming Shanghai upgrade. This innovation will allow validators to withdraw funds from the beacon chain.

“The architecture is “push”-based, rather than “pull”-based, where withdrawals are required to be processed in the execution layer as soon as they are dequeued from the consensus layer. Withdrawals are represented as a new type of object in the execution payload – an “operation” – that separates the withdrawals feature from user-level transactions. This approach is more involved than the prior EIP-4863 but it cleanly separates this “system-level” operation from regular transactions. The separation simplifies testing (so facilitates security) by reducing interaction effects generated by mixing this system-level concern with user data.”

The main question is - when? There isn’t a  definite answer yet. It probably doesn't even make sense to wait for the Shanghai upgrade by a specific deadline. Remember how long we waited for The Merge and how many times we were disappointed by the news about the delay. But, to roughly understand when the Shanghai upgrade will take place, you can see the list of what needs to be done, which is published in the Shanghai Network Upgrade Specification document on Ethereum GitHub page. The list is quite impressive.

Shanghai upgrade checklist. Source: Ethereum GitHub

Were you concerned about The Merge happening, and now there's nothing to wait for? Congratulations to those who need to wait for something, because now we will all be waiting for Shanghai upgrade together. Do not be upset when if it is delayed. And we continue to observe.