Special thanks to proto.eth for help and valuable insights.

---

Table of contents

• The background

• The main things

  • Beacon Chain withdrawals

  • EOF

  • EIP-4844

  • Other EIPs

• The roadmap and timeline

  • Timeline

  • Shanghai Upgrade + Capella Upgrade

  • Next Cancun Upgrade

• Conclusions

---

The background

I was inspired to write this article by two people, CC and Vitalik.

They agreed that the best way to learn Ethereum is to watch all core dev meetings and read the relevant meeting notes, hackmd docs, issues & PRs, and EIPs until you are clear on Ethereum's current roadmap, what are the concerns and worries of core devs, what is the role of each upgrade/EIP, etc.

Besides that, I was inspired by the community.

Ethereum has an excellent open-source culture, you can see all the meeting videos on EF YouTube, and the agenda for future discussions in ethereum/pm (more, Tim and Kim's notes). The ethereum developers are doing their best to make the community understand the current upgrades and improvements to ethereum.

So I think writing articles like this is valuable to the community!

The main things

After Ethereum successfully merged on September 15, 2022, Ethereum shifted its attention to subsequent improvements, namely Shanghai Upgrade (Execution Layer) and Capella Upgrade (Consensus Layer).

There are mainly a few things 👇

• Beacon Chain Withdrawals

• EOF

• EIP-4844

• Other EIPs

They play different roles. Beacon Chain withdrawals is the core of Shanghai upgrade, and EOF will be included in Shanghai only if there is no delay withdrawal.

In addition, because EIP-4844 may cause withdrawal delay, it was moved out of the Shanghai upgrade (if the EOF delay is also moved out). But all of us know that EIP-4844 is a critical improvement to Ethereum, so we make it the center of the next upgrade (Cancun upgrade).

In case you are learning about Shanghai upgrade for the first time, I will explain the related terms and EIP separately.

Beacon Chain Withdrawals

Understanding "withdrawals" requires a basic understanding of the history and evolution of Beacon Chain.

No Beacon Chain

Before the Beacon Chain, Ethereum was a complete monolithic blockchain, its consensus engine (PoW) and execution engine (EVM) worked together without coupling and separation.

Phase 0

After that, Beacon Chain was launched in Phase 0 (December 2020).

Ethereum has changed from a monolithic chain to a combination of two parallel chains (i.e. Beacon Chain and Execution Chain).

The only way of communication between them is the deposit contract, deposit and lock your 32ETH to become a validator (this role is similar to a "miner" under PoW).

Altair

And soon, Beacon Chain ushered in the first hard fork within two weeks of its launch, which is the Altair upgrade. This upgrade makes some simple fixes. (the upgrades of the consensus-layer are named by stars)

Bellatrix

The second hard fork upgrade is called Bellatrix, also known as "the merge". We merged the Beacon Chain into the Execution Chain.

At this time, Ethereum has changed from two parallel chains to one chain but has two layers, namely the consensus layer and the execution layer. These two layers communicate through the Engine API.

At a total difficulty of 58750000000000000000000, Bellatrix upgrade (CL) and Paris upgrade (EL) were launched at the same time. Through EIP-3675 and EIP-4399, we successfully replaced the consensus of Ethereum from PoW to PoS!

Capella

This is the third hard fork upgrade of the Beacon Chain (named after the Capella star!), and it will also start at the same time as the Shanghai upgrade (EL). Through EIP-4895, the withdrawals from Beacon Chain to EVM is achieved.

This is also the current main work of the consensus layer and each client team. After the upgrade is completed, all validators can withdraw their ETH. The total deposits in Beacon Chain have exceeded 15,741,431 ETH, and dynamic validators are important to the economic layer of Ethereum.

EOF

As a super enthusiast of EVM, I believe many people have been looking forward to EOF for a long time. A few years ago, there were discussions and improvements related to "Ethereum account versioning". Until now, EOF has become a reality and has been finalized to be included in the scope of Shanghai upgrade (in fact, EVM has not changed much since Genesis Block).

Simply put, the current EVM has only one set of interpretation and validation rules to handle all existing contracts (we call them "legacy contracts").

And EOF (consisting of five EIPs) introduces a new smart contract format, which we call "EOF contracts". And the clients/EVM interpreter also has corresponding updates.

So we now have two sets of EVM interpretation and validation rules, and they exist in parallel. EVM will be able to handle both legacy contracts and EOF contracts (in the longer future, we may replace all legacy contracts with EOF contracts).

Why EOF, what benefits does it bring? 👇

• EVM versioning. This makes it easy to introduce or deprecate features, preventing the EVM from becoming more and more complicated and ugly. Adding features to the EVM is now more difficult than removing them, and EOF may change that.

• Add new control flow operations, completely abandon dynamic jump and runtime JUMPDEST analysis, more cost-effective. (And making code transformations easier, etc.)

• Move what the EVM validates at runtime (e.g. stack underflow, overflow) to deployment time. This makes the overhead of the EVM lower and makes the contract code more secure (potential bugs will not be deployed on Ethereum).

• Code and data are separated. We will have an executable-but-opaque code section, and a readable-but-unexecutable data section

In addition, EOF is mainly composed of five EIPs, and I will briefly introduce the role of each EIP. If you want to learn more about EOF, I suggest you go to past discussions, such as "EVM encapsulation format" and "Everything about EVM", and these five EIPs (there is a Unified specification). Very helpful! 👇

• EIP-3540: EVM Object Format (EOF) v1
  This EIP introduces the EOF container and specifies the fields contained in all EOF contracts (you can check the complete fields here). In addition, it relies on EIP-3541, which guarantees that the deployment of EOF format contracts will be rejected before Shanghai upgrade.

• EIP-3670: EOF - Code Validation
  This EIP is based on EIP-3540 and adds more validation rules for EOF contracts. The wrong EOF code cannot be deployed, you can see all code validation rules here.

• EIP-4200: EOF - Static relative jumps
  This EIP introduces new jump instructions - RJUMP, RJUMPI and RJUMV, which are used to point to relative locations of executed code. Through this EIP, we can initially remove JUMPDEST analysis (dynamic jump, JUMP and JUMPI).

• EIP-4750: EOF - Functions
  This EIP goes one step further, it introduces the concept of "EVM function" (which is an independent subroutine), and introduces CALLF and RETF to call & return EVM functions. Through EIP-4750 and EIP-4200, we can completely abandon JUMPDEST analysis (dynamic jump, JUMP and JUMPI).

• EIP-5450: EOF - Stack Validation
  This EIP adds more validation rules, and transfers stack underflow/overflow, inefficient gas, etc. from runtime checks to deployment-time checks. This can further reduce the overhead of the EVM (currently underflow/overflow is checked by the EVM interpreter when running the contract code).

Personally, I think EOF is a significant improvement for EVM, so I hope to see it deployed in Shanghai upgrade (and without delaying withdrawals).

For the EOF roadmap, we will keep both legacy contracts and EOF contracts at the beginning, and then we may transfer existing legacy contacts to EOF contracts (obviously not the highest priority). But this may have some impact on zkEVM. 👇

• Depends on the number of EOF contracts. If most of the contracts are legacy contracts, the existing zkEVM does not need to be modified too much to be compatible with EOF.

• If all existing contracts turn to EOF contracts, we need to add EOF-related constraints in all circuits (such as the separation of data and code, which may change the existing bytecode circuit).

• For opcodes, JUMP and JUMPI may be deprecated because EOF disables dynamic jumps. And according to vitalik's Proposal, CODECOPY and CODESIZE may also be abandoned in the future. Also, we need to write constraints for new opcodes (such as RJUMP, RJUMI, RJUMV, CALLF, RETF, etc.)

But in general, zkEVM always needs to change with EVM (zkEVM serves EVM), and when zkEVM is used for Layer 1 (type1), every EVM upgrade will also take zkEVM into account, and simultaneous upgrades (EVM + zkEVM) are possible. So I don't think it's a big deal to keep zkEVM updated.

For EOF. There are still many improvements in the future, such as considering banning EOF codes from being directly read by CODECOPY, CODESIZE, EXTCODECOPY, EXTCODESIZE and EXTCODEHASH, and achieve automatic-mandatory conversion of EVM versions (version n code can be automatically converted to version n+1). EVM code can even be converted to equivalents of other VM codes.

If we decide to change from the EVM to some other VM (eg. WASM, Cairo…) in the future, it would be possible to automatically transform EVM code into code of the new VM that has equivalent functionality.

EIP-4844

EIP-4844 is completely designed for Rollups to further reduce the cost of data submission and verification (according to L2fee, the transaction fee of L2s is already 4-20x cheaper than L1).

Proto-danksharding comes from proto.eth's simple implementation of Fully-Danksharding on ETH Denver. It is easier to implement than fully sharding, which is important for Ethereum scaling.

Although EIP-4844 is simple enough, its implementation still widely involves the following aspects. 👇

• EIP itself (done)

• Consensus-spec (WIP, roughly done)

• Engine-API spec (done)

• Client implementations (WIP. Refer to Geth and Prysm)

• KZG ceremony (done. You can join the ceremony here)

• Tooling, Devnets, etc. (WIP, roughly done)

• Testing (WIP)

Although the progress of EIP-4844 is very fast, there is still a lot of work to do (including client implementations and extensive testing). To prevent it from delaying withdrawals, ACD#151 decided to remove EIP-4844 from Shanghai upgrade (Péter Szilágyi and Dankrad Feist disagreed on this).

EIP-4844 is the next critical improvement for Ethereum, and we all know about it. This is why the next upgrade (Cancun upgrade) after the Shanghai will be centered on EIP-4844.

Other EIPs

In addition to Withdrawals and EOF, Shanghai upgrade also deploys three independent EIPs, which are 👇

• EIP-3651: Warm COINBASE
  This EIP complements EIP-2929 by adding a COINBASE address for the start of transaction execution.

• EIP-3855: PUSH0 instruction
  This EIP introduces a new instruction PUSH0, which is used to push the constant value 0 onto the stack.

• EIP-3860: Limit and meter initcode
  This EIP extends EIP-170. It limits the maximum size of initcode to 49152 and adds 2 gas for each 32-byte chunk of initcode.

The roadmap and timeline

Timeline

The Ethereum upgrade timeline determined in ACD#151 on December 8 is roughly like this👇

• January
  Complete the client implementation and testing of EOF before January 5 (the next ACD meeting), perform shadow forks for Shanghai upgrade on January 12, and complete the EOF cross-client Interoperability before January 19 (the 153rd ACD meeting).

• February
  More tests will be done in February to make sure EOF and withdrawals are stable enough. And deploy withdrawals on the public testnets (Sepolia, Goerli, etc.)

• March
  Launch Shanghai Upgrade (Beacon Chain Withdrawals on the mainnet! 🎉)

• April
  The focus shifts to the next Cancun upgrade (centered on EIP-4844), fully testing EIP-4844. Such as multiple mainnet shadow forks, and making EIP-4844 on the public testnets.

• May
  Launch Cancun Upgrade (EIP-4844 on the mainet! 🎉)

Shanghai Upgrade + Capella Upgrade

This upgrade centers on Beacon Chain Withdrawals. To avoid any potential delay of withdrawals, EIP-4844 was removed from Shanghai (you can see the full Shanghai spec here).

And EOF needs to follow a strict timeline, otherwise it will be removed. The two more important time points are January 5, 2023 (ACD #152, EOF needs to complete client implementation and testing) and January 19, 2023 (ACD #153, complete EOF cross-client interoperability).

The Shanghai upgrade is expected to happen in March (consensus layer and execution layer are upgraded at the same time). If all goes well, we will see EOF and Withdrawals on mainnet soon!

Next Cancun Upgrade

Since EIP-4844 was removed from Shanghai, we made it the center of the next upgrade (you can see all the Cancun spec here).

It is expected that the implementation and testing of EIP-4844 will be completed in April 2023, and deployed on the public testnets. Then Cancun upgrade can be launched in May-June to deploy EIP-4844 to the mainnet!

Conclusions

Today is the last day of 2022, and we have seen many significant technological advances in this year. For example, the success of merge, the completion of EIP-4844 spec, the rise of rollups, the innovation of zkp, and the progress of zkevm.

I am happy to witness this year. Also excited about these underlying improvements in Ethereum protocol.

Next year, we'll have even more crucial upgrades. They are Shanghai + Capella (withdrawals and EOF), Cancun + Deneb (EIP-4844), and Prague + Electra (to be determined).

It will continue to be a fantastic year, with a lot of work waiting to be done. We'll see more foundational ideas and research, so I think it's very appropriate to kick off 2023 with this article. Happy new year!