Meeting Summary:
The meeting focused on updates and decisions related to the upcoming Ethereum upgrades, Glamsterdam and Hekota. The team discussed the status of DevNets, noting some issues with block import times and spamming, and client teams reported on their progress. There was extensive discussion about deprecating MPlex and enabling QUIC for network connections, with consensus to make QUIC the default for Glamsterdam and deprecate MPlex after the upgrade. The group confirmed the Sepolia testnet fork date for October 6th and discussed the need for client releases and security reviews, acknowledging the shortened timeline. For Hekota, the team reviewed and made decisions on several EIPs, agreeing to CFI some and DFI others, with a notable debate on EIP 8365 regarding BLS credential deprecation and forced exits, ultimately deciding to adjust its scope. The contentious topic of issuance changes was tabled for future discussion due to its broader community impact. The conversation ended with reminders about client releases for the Sepolia fork.
Click to expand detailed summary
The team discussed two main topics: testnet forks and networking protocol changes. For the Sepolia to Amsterdam fork scheduled for October 6th, client teams agreed to release updates by September 29th at the latest, with preference for earlier releases to allow time for security reviews. The group decided to make QUIC the default networking protocol for Glamsterdam releases while deprecating Mplex, with plans to fully remove Mplex after Amsterdam. Regarding the Hoodie fork, the team agreed to wait for a successful Sepolia fork before scheduling, with a tentative plan to potentially schedule Hoodie for October 27th pending successful Sepolia transition. The discussion also covered the importance of implementing circuit breakers on testnets to prevent potential DOS attacks.
Kamil presented EIP 8411, which proposes splitting large execution payloads into 64 segments to improve efficiency and reduce bandwidth waste. The group discussed whether to PFI (Propose for Implementation) this EIP for the upcoming Hegota fork, with some concerns raised about complexity and forward compatibility. While there was general support for the EIP’s concept, the team agreed to PFI it for consideration but decided to delay the final CFI (Confirm for Implementation) decision to allow more time for analysis, rather than immediately including it in the Hegota fork.
The team discussed PFI approval for a payload broadcast EIP, with general agreement to proceed and defer the final decision to a future scoping call. Ansgar requested that the decision on this EIP be made toward the end of the scoping process due to its different considerations from block and blobs. The group agreed to review 23 non-headliner EIPs, with plans to handle universally supported EIPs immediately and more ambiguous ones in future calls.
The team discussed EIP rankings and decided to focus on clearly supported items for CFI and DFI decisions. They agreed to start with two non-controversial top-rated EIPs and all clearly supported DFI items (everything below 8237), while tabling more ambiguous EIPs for future discussion. The group reviewed and approved EIP-8015, which removes unused EIPs, and began discussing EIP-8365 regarding BOS withdraw credential retirement, though they noted scope questions about the EIP’s features that needed further examination.
The team discussed the scope of EIP 8365, focusing on whether to include forced exits for BLS 00 validators at the fork. While some clients supported removing forced exits to give affected validators more time to migrate, others argued that deprecating without exits would not effectively signal the transition. The group explored the possibility of implementing a two-fork approach, where the first fork would close new deposits while the second fork would handle forced exits, providing a clear timeline for affected validators to prepare.
The team reached consensus on moving forward with a reduced-scope version of the EIP, with plans to CFI (Consensus Focused Implementation) the updated 8365 by the next call. They decided to defer discussion on issuance-related EIPs due to their wide-reaching community impact and lack of clear client support. The group also discussed the potential inclusion of PQ roadmap items in the fork, with Kevaundray noting ongoing ecosystem discussions about implementation around JSTAR.
The team discussed several EIPs and made decisions on which ones to DFI (include in the fork). They decided to DFI EIPs 8237, 8341, 8367, and 8375, but tabled the decision on issuance-related EIPs for further discussion. The group acknowledged that the issuance topic requires broader community input and expert opinion beyond just Core Developers, and agreed to develop a plan for how to handle such decisions in future meetings. They also noted that while clients generally support DFIing these EIPs, there are concerns about the process and legitimacy of making issuance changes without proper community consultation.
Next Steps:
- stokes: Draft and publish a blog post announcing the Sepolia fork date (October 6) as soon as possible (today or tomorrow).
- Client teams: Release client versions for the Sepolia fork as soon as possible, with an absolute deadline of September 29.
- Client teams: Implement and test P2P circuit breakers on DevNets and testnets, especially for builder connections.
- stokes: Propose a concrete date for the Hoodie fork (tentatively October 27) by the next ACD call (October 8), pending a smooth Sepolia fork.
- Client teams: Review and rank EIP-8411 (payload broadcast) for consideration in the Hegota fork.
- NC: Update EIP-8365 to remove the forced exit of 0x00 validators, keeping only the deprecation of new 0x00 deposits, and present the updated version for CFI at the next call.
- stokes: Develop a plan for how to handle the decision process for the issuance EIP (EIP-8363) and present it at the next call.
- Client teams: Begin work on Post-Quantum (PQ) related preparations, such as registering validator PQ material, in preparation for potential inclusion in the I-Star fork.
Recording Access: