Ethereum Shanghai Hard Fork: Timeline and EIP Battle Continues

Introduction

The Ethereum merge happened two months ago, and now all eyes are glued on the next Ethereum update—the Shanghai Hard Fork. Ethereum enthusiasts and parties are curious to know a definitive timeline for Shanghai. Previously, EIP 4844, "Proto-danksharding," an update that will significantly enhance Layer 2 scalability, was said to ship alongside EIP 4895, "Beacon Chain Withdrawals." However, on December 8, during the latest Ethereum Core Developers Meeting, protocol support lead at the Ethereum Foundation, Tim Beiko, said that the main objective was to focus on Shanghai first to avoid delays from EIP 4844 if it isn’t ready.

Before I proceed please note that:

polarpunklabs @polarpunklabs

Ethereum is not a company. It is crazy this needs to be explained. It is an decentralised open source project with multiple client teams that operate autonomously from one another and who reach emergent consensus through transparent dialogue.

The Ethereum community is closely watching the debate between teams over which Ethereum Improvement Proposals (EIPs) should be included in the upcoming Shanghai network upgrade. Including certain EIPs, such as EIP 4895 for Beacon chain withdrawals, could have significant implications for stakers eager to access their funds.

During the December 8 All Core Developers (ACD) call, which was the 151st ACD call, developers agreed to include five EIPs related to EOF (EVM Object Format) implementation alongside EIP-3651: Warm COINBASE 59, EIP-3855: PUSH0 instruction 26, EIP-3860: Limit and meter initcode in the Shanghai upgrade.

This major code change targets the Ethereum Virtual Machine (EVM), which is the execution environment for all transactions on Ethereum. EOF implementation will be the first major change to the EVM and will help the EVM become more easily upgradeable, parse between smart contract code and data, and introduce gas savings for application developers.

EOF comprises several EIPs, which include: EIP-3540: EOF v1
EIP-3670: Code validation
EIP-4200: Static relative jumps
EIP-4750: Functions
EIP-5450: Stack validation
In later articles, we’ll have a look at each of them.

However, the inclusion of EOF implementation in Shanghai could delay the implementation of EIP 4895 for Beacon chain withdrawals. As Ethereum core developer Marius van der Wijden tells fortune.com,

"It’s hard to schedule because a lot of people want to get their EIP included in Shanghai, and they are in different states of readiness. It’s hard to gauge which EIPs are beneficial, easy enough to couple with withdrawals, and in a state to be implemented by all teams."

Bieko noted that these EOF upgrades are easy to remove from Shanghai if ETH devs haven’t finished working on them before Shanghai is ready.
If this is the case, the EOF will be removed and shipped later.

timbeiko.eth @TimBeiko

@ethereum @trent_vanepps @mkalinin2 @elbuenmayini @peter_szilagyi @benjaminion_xyz @alexberegszaszi @lightclients @vdWijden @yperbasis So, that's where we landed for Shanghai: Withdrawals, EOF & a few already implemented EIPs (PUSH0, Warm COINBASE, Limit/Meter initcode) are what we will go for. If by January, we don't meet the EOF milestones mentioned above, we'll remove it from Shanghai so withdrawals ship ASAP

At the moment, developers mostly agree that EIP 4844 for "protodanksharding" should be shipped separately from EIP 4895 for withdrawals. But the debate continues over which other EIPs should be included in Shanghai. In addition, the amount of testing and debugging required for the upgrade is difficult to predict, which could further impact the timeline.

EIP 1153 Drama: The ‘never’ EIP?

The Uniswap and Optimism teams are pushing for EIP 1153. Background: EIP 1153 suggested the introduction of temporary storage opcodes to reduce gas fees for end-users. It was previously presented on an ACD call by the Uniswap and Optimism teams. However, most ETH developers see this EIP as unnecessary at the moment.

During a conversation about the scope of Shanghai, Moody Salem, an advisor to the Uniswap team, questioned why EIP 1153 was not being considered for inclusion. Salem argued that EIP 1153 was ready to be tested on the testnet and had already been implemented in three of the five clients.

Marius van der Wijden and Andrew Ashikhmin from the Erigon (EL) client team disagreed, saying that EIP 1153 was not a significant improvement to the Ethereum protocol and would take up "headroom" even though it was not a technical lift.

Drama continues on Twitter 

Ethereum Independent researcher and software dev Alexery Sharp tweeted that EIP-2200 was a mistake because of its complexity and that EIP 1153 is a better alternative he also noted that the Uniswap team didn't exist when EIP 1153 was written (2018).

Alexey Sharp 🦦🧬🚛🚚🚛🚚🚛 @realLedgerwatch

FYI: when EIP-1153 was written (in 2018), Uniswap did not exist. It was written as an alternative to EIP-2200, because I believed 2200 is too complex and ugly solution to whatever problem it was solving. Once EIP-2200 was in, I forgot about EIP-1153. Don't shoot the messenger

Alexey Sharp 🦦🧬🚛🚚🚛🚚🚛 @realLedgerwatch

And I still do believe that EIP-2200 was a mistake (too much complexity for too little gain), and EIP-1153 should have been done instead.

Inventor and CEO of Uniswap Protocol- Hayden Adams quickly threaded the importance of EIP 1153 

hayden.eth 🦄 @haydenzadams

1/24 TLDR: EIP 1153 is a technical gas optimization EIP with a ton of uses written by a prominent core dev before uniswap v1 was launched https://t.co/ymuBh3xc4G

Alexey Sharp 🦦🧬🚛🚚🚛🚚🚛 @realLedgerwatch

FYI: when EIP-1153 was written (in 2018), Uniswap did not exist. It was written as an alternative to EIP-2200, because I believed 2200 is too complex and ugly solution to whatever problem it was solving. Once EIP-2200 was in, I forgot about EIP-1153. Don't shoot the messenger

Hudson Jameson, ex-EIP editor, threw more light on this EIP

Hudson Jameson @hudsonjameson

Look Mama! I'm a theadoooorrrr. Here are my thoughts on the process around EIP-1153's potential inclusion in Ethereum. I have immense respect for Hayden, but feel like this thread he made, in particular, doesn't paint the entire picture. 1/26

hayden.eth 🦄 @haydenzadams

1/24 TLDR: EIP 1153 is a technical gas optimization EIP with a ton of uses written by a prominent core dev before uniswap v1 was launched https://t.co/ymuBh3xc4G

Now it gets messier from the back-and-forths between Adam Cochran popular industry leader and Hayden. Cochran tweeted a thread saying EIP 1153 isn’t a good EIP

Adam Cochran (adamscochran.eth) @adamscochran

1/24 So Uniswap seems to think that EIP-1153 is not being included because of them. But I'd argue it isn't a good EIP. It aims to solve a real problem, but does so in a problematic manner. Let's break it down:

Okay that’s the end for now 🍿 

hayden.eth 🦄 @haydenzadams

@adamscochran You continue to be a total fucking hack who spreads misinformation like almost no one else on crypto Twitter.

Cancun

The next network upgrade, Cancun, is currently scheduled for later in 2023 and is expected to include the long-awaited Ethereum 2.0 upgrade. However, the exact timeline and proposals for Cancun are still being debated by the Ethereum community.

Tim Beiko encouraged developers to start considering which proposals (beyond EIP 4844) should be included in the upcoming Cancun upgrade. Participants in the call suggested several proposals for consideration.
EIPs considered include:
EIP 663- next step to EOF implementation.
EIP 2537- aims to improve interoperability between Ethereum and the Beacon Chain, as well as enhance the functionality of decentralized staking pools, by adding a BLS precompile to Ethereum.
EIP 6046- an alternative to deactivating Ethereum's self-destruct function, which minimizes disruption to existing decentralized applications.
EIP 5988- aids ZKRollup functionality.

Conclusion

Overall, the battle of the EIPs continues as teams debate which proposals should be included in the Shanghai upgrade and when stakers can expect to access their funds. While March is currently the likely timeline for the upgrade, this could change depending on the proposals that are included and the amount of testing and debugging required.