Good evening,
Tonight, Iâm diving into EIP 8254, a proposal to cap validator deposit requests per block on the execution layer. Itâs a new EIP for consideration in Glamsterdam.
It was proposed after the Ethereum Foundation (EF) developer operations team, EthPandaOps, demonstrated that sufficiently large blocks, exceeding a 193 million block gas limit, would break constraints on the consensus layer.
The issue traces back to EIP 6110, an upgrade that dramatically improved Ethereumâs validator deposit processing system but also embedded a hard consensus-layer limit that developers did not anticipate one day needing to exceed.
Hindsight is always 20/20, but there are ways developers could improve their foresight.
Letâs get into it.
Yours truly,
Christine D. Kim
P.S. Iâll be discussing EIP 8254 and the other important takeaways from the Ethereum Soldogn Interop event with the EthPandaOps teams at the next All Protocol Devs meetup, happening next Wednesday, April 13.
Sign up for the event here.
đď¸ Call Minutes
First, a quick summary of the latest Ethereum developer call, All Core Developers Execution (ACDE) #236.
Glamsterdam Devnet Updates
Last week, during the Soldogn Interop, developers tested client implementations of the Glamsterdam upgrade across several devnets: Glamsterdam-Devnet-0, 1, 2, and Bal-Devnet-6.
Notably, Glamsterdam-Devnet-2 features a new Ethereum Improvement Proposal (EIP), EIP 8061, which increases the validator exit and consolidation churn. This is the only other consensus layer (CL) focused change in Glamsterdam that developers have started testing on a devnet aside from EIP 7732, also known as enshrined proposer builder separation (ePBS).
During the Soldogn Interop, developers agreed to simplify EIP 8045, another CL-focused change in Glamsterdam, and remove EIP 8080 from the scope of the upgrade. There are now only two CL-focused changes for inclusion on a Glamsterdam devnet remaining: EIP 8045 and EIP 7688.
On the execution layer (EL) side, developers are continuing to test a handful of code changes in isolation from CL changes on Bal-Devnet-6. Ethereum Foundation (EF) Developer Operations Engineer Stefan Starflinger said developers will launch one more EL-focused devnet, Bal-Devnet-7, before migrating all testing efforts over to the shared Glamsterdam devnets.
Refer to this Google spreadsheet for an overview of the testing and inclusion status of all Glamsterdam EIPs.
Scheduled for Inclusion Discussion
EF Protocol Support Lead and ACDE Call Co-Chair Nixo Rokish shared a new proposed definition for labelling EIPs as scheduled for inclusion (SFIâd).
EF Protocol Prototyping Lead Toni Wahrstätter raised concerns that the definition does not help developers prioritize which EIPs to include for testing on devnets.
EF Testing Engineer âspencer-tbâ has opened a pull request on GitHub to formally update the status of nine Glamsterdam EIPs to SFI in accordance with the new proposed definition.
Glamsterdam Code Changes
In line with the new
engine_getblobsv4API method, developers have updated the description and design of EIP 8070, a non-consensus-breaking change for improving node bandwidth consumption.Developers have not reached a consensus on the appropriate EL client behavior during a deep chain reorganization. Developers agreed to conduct further testing and simulation with clients before reaching a decision.
Developers also discussed how to work around the CL cap on validator deposits and withdrawals, which may be exceeded if they follow through with their planned increase of the block gas limit to 200 million gas post-Glamsterdam. One proposal is to cap deposits on the EL so that even at higher block gas limits, the CL cap cannot be exceeded.
Developers agreed to include EIP 8246, remove
SELFDESTRUCTburn, in Glamsterdam to fix a minor edge case related to a deprecated opcode. This would help simplify and remove longstanding tech debt in the protocol.Developers discussed ways to prevent the use of the deprecated opcode,
SELFDESTRUCT, in the future. They agreed it is too late in the Glamsterdam development process to consider them for the upgrade, as such methods would require more time for planning and communication, especially with users and smart contract developers.
Hegota Proposals
Developers discussed three proposals for consideration in Hegota, the upgrade scheduled after Glamsterdam. They were: EIP 7709, EIP 8253, and account abstraction.
Miscellaneous
Ethereum developer Mercy Boma Naps Nkari requested feedback from client teams on an execution API change removing methods no longer used since Ethereumâs Merge upgrade in 2022.
đ Thatâs all for my summary of ACDE #236. Continue reading for my insights on Ethereum development and governance. To read the rest of the newsletter, make sure you are signed up for a premium subscription:
đ Interested in being a featured sponsor of this newsletter? Learn more about sponsorship opportunities available for ACD After Hours:
đ I also run a research and advisory firm called Protocol Watch for businesses building on Bitcoin and Ethereum. Learn more about how I can help your business understand and stay ahead of protocol changes:
đ Insights
Last week, a group of over 100 Ethereum protocol developers and researchers met up in Longyearbyen, Svalbard. The gathering, called the Soldogn Interop, was hosted by the Ethereum Foundation (EF).
In the Foundationâs recap of the week, they announced that meaningful progress had been made on the Glamsterdam upgrade.
Specifically, developers agreed they could more than triple transaction throughput post-Glamsterdam by increasing the block gas limit from 60 million gas to 200 million gas.
âBy Friday, the three threads converged on the headline number for the week: a credible 200M post-Glamsterdam gas limit floor. This significant increase is possible because ePBS structures the slot to give execution more time, BAL optimizations give clients the throughput headroom under that structure, and 8037 ensures the higher gas limit doesn't translate into runaway state growth.â
The credibility of this 200 million gas figure was immediately thrown into question after developers who attended the interop insisted the estimate was too conservative and the likely increase would be much higher than 200 million.
Prysm client developer âPotuz,â who is leading development on one of the main scaling improvements in Glamsterdam, EIP 7732, said on X:
Nethermind client developer Ben Adams echoed this sentiment, saying:
Contrary to the commentary on X, developers expressed concerns at the latest All Core Developers Execution (ACDE) call about exceeding a block gas limit of 193 million gas.
EF Developer Operations Engineer Barnabas Busa said:
âWe could safely do 190, but, as soon as we go over 193, we are gonna have issues.â
Thus, despite the initial fanfare about a 200m block gas limit in Glamsterdam, itâs unclear what the final value will be and how soon an increase of this magnitude could be reached on mainnet.
