Current Ethereum

Current Ethereum


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 👇

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 to withdrawals.

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.

Monolithic Chain

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 similar to a “miner” under PoW).

Pre-merge

Altair

And soon, Beacon Chain ushered in the first hard fork, which is the Altair upgrade. This upgrade makes some simple fixes. (the upgrades of the consensus-layer is 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!

Post-merge

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.

Total deposits

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? 👇

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 the past discussions, such as “EVM encapsulation format” and “Everything about EVM”, and these five EIPs (there is a Unified specification). Very helpful! 👇

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. 👇

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. The reason for this is proto danksharding doesn’t actually “shard” the data, or require data availability sampling: it has each node download all the data, but discard it after ~2 weeks.

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

This is my prediction of the current work progress of EIP-4844 (please take it with caution), and I hope to see EIP-4844 deployed to the Ethereum mainnet before June.

EIP-4844

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 👇

The roadmap and timeline

Timeline

The Ethereum upgrade timeline determined in ACD#151 on December 8 is roughly like this👇 (It should be reminded that this time may change dynamically)

The timeline

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 of 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).

Next year 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!