ACDE #209: Call Minutes
The call where developers considered many more EIPs in Fusaka
Good evening,
Today, Ethereum developers reconfirmed May 7 as the expected date for Pectra mainnet activation. They spent most of the call debating which execution layer (EL) focused Ethereum Improvement Proposals (EIPs) should be considered for inclusion in the Fusaka upgrade. They agreed to strongly consider 7 more EL-focused proposals and initiatives to pursue alongside PeerDAS and EOF in Fusaka.
Below is the full call summary for the latest All Core Developers (ACD) call, ACDE #209.
Yours Truly,
Christine D. Kim
Programming note: Due to my travels in Asia, next week’s ACD After Hours posts will be published later than usual.
Date and time: April 10, 2025, 14:00-15:30 UTC
Duration: 90 minutes
Pectra Updates
Ethereum developers are putting the final touches on the Pectra upgrade, which is still expected to go live on mainnet May 7, 2025 at 10:05 UTC. Tim Beiko of the Ethereum Foundation, who was chairing the call, emphasized that final client releases for Pectra should be ready by the end of next week or early the week after.
Piper Merriam of the Ethereum Foundation, who leads history expiry efforts, reminded client teams to review the newest version of the Ethereum Wire Protocol, eth/69. As background, the Ethereum Wire Protocol dictates how Ethereum nodes communicate with each other over the internet. eth/69is the latest proposed version of the protocol that will allow nodes to advertise they have dropped historical block data from before the Merge upgrade.
Geth developer Felix Lange expressed his support for finalizing eth/69 by May 7. Nethermind developer Ben Adams highlighted that coordination for eth/69 can happen independently from the Pectra upgrade as the changes to networking between nodes are non-breaking changes.
EIP-7702 Receipts
Then, developers discussed a proposal to include authorization results directly in the transaction receipt of EIP 7702 transactions. As background, EIP-7702 will allow user-controlled accounts, also called Externally Owned Accounts (EOAs), to have smart-contract-like functionalities. A developer by the screen name "Lucas" explained that determining the authorization results of EIP 7702 transactions is currently a pain for smart contract developers as it requires multiple RPC calls. The proposal would help improve the developer experience for using EIP 7702.
Lange said changes to transaction receipts are invasive and should not be included in Pectra so close to the upgrade's activation on mainnet. He said:
The only other thing in order to really correctly serve this [data] for all time is we would have to store the success into the [transaction] receipt itself into the client database and like I said we can no longer make this type of change now so late into the pipeline.
Lucas pointed out that he is not a client developer, so he was not aware that his proposal would require invasive changes to client code. He agreed that the proposal should be ignored if it involves too much work from client teams to implement. Based on comments in the Zoom chat, Beiko suggested other workarounds for smart contract developers to easily retrieve EIP 7702 transaction authorization results that do not require a hard fork. Lange emphasized that any changes to transaction receipts would require breaking changes. Client teams should not diverge from the standards set in the specifications without full consensus and coordination between all clients.
Lange suggested that one potential workaround that does not require a hard fork and that would allow smart contract developers to retrieve at least recent transaction authorization results easily could be the creation of a custom RPC call that combines multiple calls.
For now, Beiko affirmed that no changes will be made to EIP 7702 for now and that developers should continue to workshop non-consensus breaking workarounds to the pain points raised by Lucas on Ethereum Magicians.
Fusaka Scoping Discussion
Developers then moved on to discussing the scope of Fusaka. Beiko said that April 10 is the deadline developers set to finalize the EIPs that will be considered for inclusion (CFI'd) in the upgrade. All EIPs not CFI'd will be de facto declined from Fusaka. CFI'd EIPs will only progress to actual inclusion in Fusaka and be labeled as "scheduled for inclusion" (SFI'd) once existing SFI'd EIPs are stable and implemented on a Fusaka devnet. The only EIPs that have been SFI'd already for Fusaka are:
✅ PeerDAS
✅ Mega EOF (EVM Object Format)
Beiko stressed that all client teams are in unanimous consensus about activating Fusaka on mainnet before the end of the year and prioritizing PeerDAS in the upgrade. Beiko reminded developers that so far developers have already agreed to CFI the following EIPs:
🟡 EIP 7883, ModExp gas cost increase
🟡 RIP-7212: Precompile for secp256r1 Curve Support
🟡 Additional EOF EIPs:
Beiko asked what other EIPs developers should CFI on the call.
eth/69
Adams proposed finalizing eth/69 by Fusaka. Beiko said he was confused by this proposal as he had assumed client teams would be ready to finalize this by Pectra. Erigon developer Andrew Ashikhmin clarified that his team's preparations for history expiry would not be ready by Pectra mainnet activation and would need a few more months for preparation. Adams recommended bumping up the status of eth/69 to CFI as a signal of client teams' intention to ship this non-breaking change sometime after Pectra and before Fusaka.
Beiko pushed back on including eth/69 as a formal EIP in Fusaka as client teams can coordinate changes to the Ethereum Wire Protocol asynchronously from hard forks. Lange said that in the past, developers have included EIPs like the deprecation of the SELFDESTRUCT opcode in upgrades as purely a signaling mechanism without any core protocol changes. Thus, developers could include eth/69 in Fusaka for a similar reason to indicate developers' intention to finalize a non-consensus-breaking change.
Beiko said that he did not want to spend more time on the call discussing the logistics for eth/69 activation. He added that he would find a way to best include the finalization of the new Wire Protocol version in Fusaka after the call.
Raising the Gas Limit
Another code change developers discussed for inclusion in Fusaka that does not have a formal EIP number is changes in clients that would support higher block gas limits on Ethereum. As background, the block gas limit, which dictates how many transactions can be included in a block on Ethereum, is determined by validators. Last year, validators voted to increase the block gas limit from 30m to 36m gas. There is support among various Ethereum stakeholders to increase the limit to 100m gas and further improve the scalability of Ethereum as an execution environment.
Ashikhmin reminded developers that Erigon developer Giulio Rebuffo proposed EIP 7783 last year as a way to automate a gradual increase to the block gas limit. Beiko said that the discussion is not about including EIP 7783 in Fusaka, but rather about the intention of client teams to work on fixing any technical limitations to supporting block gas limits higher than 36m. Geth developer Marius van der Wijden said that the Geth client indeed hits performance issues at higher gas limits and that these bugs would need to be resolved before validators can safely raise the limit beyond 36m.
If developers are serious about increasing the block gas limit by Fusaka, Adams said developers should formally include EIP 7825 in the upgrade to ensure that a single transaction cannot fill up the space of an entire block. Geth developer "Lightclient" expressed concerns about how this EIP may negatively impact EIP 7702 transactions and recommended waiting to see how EIP 7702 is used on mainnet before committing to EIP 7825. Beiko said that developers should CFI EIP 7825 in Fusaka for now and discuss its implementation details later.
As a side note, Carl Beekhuizen of the Ethereum Foundation noted that the current version of Rollup Improvement Proposal (RIP) 7212 contains a bug and needs updating to a new fixed version. Beiko said once a new RIP number has been determined by rollup teams, the relevant documents and GitHub pages associated with RIP 7212 should be updated.
EIP-7907: Initcode Size Limit Increase
Then, developers discussed the inclusion of either EIP 7907 or EIP 7903 in Fusaka. These are two competing proposals to increase the maximum size of code related to smart contract logic, also called initcode, from the current 24KB limit to allow for the creation of more complex decentralized applications. EIP 7903 removes the limit on initcode entirely, while EIP 7907 raises the limit but keeps an upper bound on its maximum size. Developers like van der Wijden and Lightclient supported EIP 7907 over 7903. Beiko recommended labeling EIP 7907 as CFI'd for Fusaka.
EIP-7918 and EIP-7762: Blob Fee Market Upgrades
Developers discussed two EIPs for improving the efficiency of the blob fee market. Ethereum Foundation Researcher Ansgar Dietrichs explained that blob base fees can be slow to adjust from periods of low to high blob demand. He acknowledged two proposals for fixing the issue of slow blob base fee adjustments. He framed EIP 7762 as the simpler change, which introduces a fixed minimum blob base fee, and EIP 7918 as the more complex change, which introduces a dynamic repricing model for the blob base fee based on gas prices for regular transaction. Dietrichs said:
"I think that, personally, [EIP 7918] is very reasonable. Two downsides [of it] I see. One is that it's a bit more complex, at least conceptually. And also, I think it has not necessarily had that much review yet … [so] basically the other [argument] is just that it's been like a very recent proposal. So, I personally would be fine with either of those two, Anders’ more principled solution, or maybe the original Max Resnick proposal that's a bit simpler."
Adams said he prefers EIP 7918 as it feels "less arbitrary" and has "good vibes." Ethereum Foundation Researcher Dankrad Feist said EIP 7762 feels more "right" and "natural" to him. Due to the lack of consensus on either of these proposals, Beiko recommended labeling both as CFI'd in Fusaka and picking one or the other later. Beiko said he would create a dedicated channel for further discussion on this topic.
Other EIPs Proposed for Inclusion in Fusaka
Developers discussed a few more EIPs for consideration in Fusaka. Hadrien Croubois, a smart contract engineer at OpenZeppelin proposed EIP 7819 to improve the smart contract developer experience by building upon the frameworks created by EIP 7702. Van der Wijden pushed back on its inclusion in Fusaka, saying that he did not fully understand it. Beiko agreed that the EIP should not be CFI'd.
Responding to a comment about the deadline for SFI'd EIPs in Fusaka in the Zoom chat, Beiko said that developers should refrain from setting any deadline for SFI'd EIPs in Fusaka as it is not likely that developers will be able to meet such a deadline. Instead, he suggested that developers focus on stabilizing PeerDAS and EOF on a combined devnet. Then, discuss what CFI'd EIPs to include in the following devnet alongside PeerDAS and EOF.
Beiko tried to summarize the decisions that had been made on the call so far regarding the scope of Fusaka.
Assuming developers do increase blob capacity in Fusaka, Adams suggested an additional change that would limit the number of blobs per transaction. Van der Wijden agreed this would be a good addition to Fusaka. Lightclient proposed including the change in the PeerDAS EIP itself. Beekhuizen noted in the Zoom chat defining the limit in a separate EIP may be "cleaner" in case developers want to change this parameter in the future. There was more discussion on how to implement the limit on blobs per transaction. Ethereum Foundation Developer Operations Engineer Barnabas Busa suggested including the limit in blob parameter only hard forks that occur after Fusaka to ensure this change does not delay PeerDAS activation.
Beiko said that he forgot to include EIP 7892, blob parameter only hard forks, in the CFI'd list of EIPs list. He acknowledged that this was indeed a decision developers had already made on last week's ACD call.
Beiko confirmed that there is broad support for capping the number of blobs per transaction but that developers would refrain from formalizing it as a separate EIP from the PeerDAS EIP.
Lin Oshitani, protocol researcher at Nethermind, proposed EIP 7917 for inclusion in Fusaka. As it is a CL-focused EIP, Beiko recommended raising it for discussion on next week's ACD call, which will focus on CL-related code changes. For context, EIP 7917 was already proposed on last week’s ACD call by another developer, “ETHDreamer” and presumably also already CFI’d.
Ethereum Foundation Researcher Alex Stokes, who chairs the ACDC call series, requested that CL client teams review EIP 7917 again in advance of next week's call.
A developer by the screen name "Charles" proposed EIP 7923, a new pricing model for memory usage in the EVM, for inclusion in Fusaka. Beiko said that since the EIP is not urgent for inclusion in Fusaka, it should be considered for the next hard fork, Glamsterdam. Charles agreed. Charles also expressed concerns about the lack of communication and transparency from developers about the EIP process, saying:
"I am wondering if there is ever any time to have like a meta discussion about how EIPs get proposed because for people who aren't close to the process, there's like a two-to-four-week window at random times where we can propose things, and it's very easy to miss the window."
Beiko acknowledged Charles' concerns but noted that the planning for Fusaka is unique and different from other upgrades because it contains overflow EIPs from the Pectra upgrade. Beiko said:
"We kind of overloaded the [Pectra] fork too much, so we to split it into two. I think for Glamsterdam, we definitely need to make this [process] much clearer. … [But] I want to make sure we can at least move forward with the Fusaka scope today before getting into how we plan the next fork."
Beiko reviewed the list of CFI'd EIPs for Fusaka again. This time he ran through a short list of EIPs proposed for inclusion in Fusaka that would not be included in the fork. Some developers like van der Wijden noted in the Zoom chat that certain EIP champions such as Nimbus developer Etan Kissling were not present on the call to argue for the inclusion of their EIPs.
Independent Ethereum developer Danno Ferrin said developers had CFI'd EIP 7823 with EIP 7883. Both EIPs make changes to the MODEXP precompile that will pave the way for further increases to the block gas limit. Representatives from the Nethermind and Geth teams expressed their support for EIP 7823. Beiko agreed to CFI EIP 7823.
The New CFI'd List for Fusaka
The new CFI list for Fusaka contains the following EIPs and initiatives. The new EIPs or initiatives that were confirmed for inclusion in the CFI list on ACDE #209 are highlighted by an orange circle.
CFI'd EIPs for Fusaka:
🟡 EIP 7883, ModExp gas cost increase
🟡 RIP-7212: Precompile for secp256r1 Curve Support [NEW RIP NUMBER PENDING]
🟡 Additional EOF EIPs:
🟠 EIP 7892, Blob parameter only hard forks
🟠 EIP 7823, Set upper bounds for ModExp
🟠 EIP 7825, Transaction gas limit cap
🟠 EIP-7907, Meter contract code size and increase limit
🟠 EIP-7918, Blob base fee bounded by execution cost
🟠 EIP-7762, Increase minimum blob base fee
Other Initiatives
🟠 Finalizing eth/69
🟠 Limiting the number of blobs per transaction
All other EL-focused EIPs proposed for inclusion in Fusaka have been rejected. Next week's call will focus on finalizing the CFI list for Fusaka for CL-focused EIPs.
Reconfiguring AllCoreDevs
Beiko briefly touched on his proposal to revamp the ACD call process. At a high level, Beiko's proposal recommends repurposing the weekly Monday testing calls to become an official ACD call series called All Core Developers Testing (ACDT) calls, where developers can coordinate and discuss matters necessary for shipping the next immediate hard fork. In doing so, the All Core Developers Execution (ACDE) and All Core Developers Consensus (ACDC) calls can focus primarily on planning and scoping out future forks beyond the next immediate one.
Beiko's hope is that the ACDT calls will allow for more dedicated time on ACDE and ACDC calls to discuss matters related to future fork planning by moving discussions related to implementing the next immediate hard fork to a separate call. Beiko proposed implementing this proposal once the Pectra upgrade goes live on mainnet by moving Fusaka-related discussions to the ACDT calls and reserving discussions on ACDE and ACDC for Glamsterdam-related discussions.
Prysm developer “Potuz” noted that it is "impossible" to avoid conversations about the Fusaka upgrade on ACDE and ACDC calls when developers have not finalized the upgrade scope and plan on iteratively growing the upgrade scope over time. Beiko acknowledged that any decisions about the scope of Fusaka should still be agreed on during ACDE and ACDC calls. However, once these decisions are made, their execution should be discussed on ACDT calls moving forward.
Dietrichs highlighted the newly launched Protocol Research call series hosted by Ethereum Foundation Research Co-Lead Barnabe Monnot as another forum for even longer-term planning for Ethereum's future.
Beiko said that if there are no major objections to his proposal for creating the ACDT call series over the next week, then he will assume everyone agrees with trying it after Pectra activation on mainnet.
Pectra Pages
Trent van Epps and Nixo Rokish, both from the Ethereum Foundation, are working on a compilation of perspectives from Ethereum protocol developers about the Pectra upgrade. Van Epps said on the call that similar compilations have been created for prior Ethereum upgrades like the Merge and Dencun. Any developers who would like to contribute to the project, dubbed "Pectra Pages," should submit their perspectives by April 28, 2025.
That’s all for my summary on ACDE #209. If you made it this far into today’s post, well done! You are now officially caught up on the state of Ethereum protocol development and governance.
Despite my best efforts, this week’s call minutes are even longer than last week’s. (:/) I’ll try again next week to make these minutes shorter and more digestible. Stay tuned for my insights on ACDE #209 coming out tomorrow.
In case you are not completely exhausted by now reading through today’s call minutes, below are links for further reading on some of the topics discussed on today’s ACD call.
Dencun Diary: Perspectives on Dencun by Ethereum core contributors
Merge Manual: Perspectives on the Merge by Ethereum core contributors
Thank you for subscribing to ACD After Hours! If you like what you read, consider sharing it with a friend who might also enjoy the content.
I am actively sourcing feedback on the ACD After Hours newsletter. So, if today’s post sparked any thoughts, opinions, or questions, I’d love to hear them. Please share your feedback on today’s newsletter by responding to the poll below or leaving a comment. Your feedback is appreciated!
Special thanks to Shinhye Kim for the graphics in this newsletter.
It's long but good. There's value in various formats, from Nixo's monthly updates to these detailed ones and others in the middle.