Meeting Summary:
This was Execution meeting #243 on August 13th focused on DevNet 8 updates and EIP proposals for the upcoming Glasgow (Glas) and Hagada forks. Barnabas reported that DevNet 8 (PlatoBerget) launched recently with growth activation planned for the following week, and the Glasgow fork would go live on Thursday at 7:50 AM UTC. Joachim presented final gas repricing results, confirming that broadcast limits could be safely raised to 200 million gas (three times the current limit) without requiring re-release of client specifications. The team discussed EIP 8061 for introducing a new gas limit configuration parameter to allow staged increases, which was approved by consensus layer clients. Kev discussed history expiry requirements for 2TB node operators, with most clients planning to drop history to approximately 5 months or fork minus one. The meeting then moved through 17 EIP proposals for Hagada, covering topics including linear page-based memory costing, refund removal, call-up code optimization, net gas metering for account changes, and precompiles for post-quantum cryptography. The final major discussion centered on Native Account (AA) implementation, where there was debate between EIP 8130 and 8141, with concerns raised about EIP 8141’s impact on L2s and potential incompatibilities across the ecosystem.
Click to expand detailed summary
The team discussed updates for DevNet 8 (PlatoBerget), which launched recently and will have growth activated in about a week. Jochem presented final gas repricing results, confirming that the broadcast limits can be safely raised to 200 million gas at the Glamsterdam fork, which is more than three times the current limit. Barnabas explained a new configuration parameter in EIP-8261 that allows hard-coding gas limit schedules ahead of time, providing an optional default value for clients while maintaining the ability for users to override local settings.
The team discussed implementing a gas limit increase with a stepwise approach starting at 60 million and gradually increasing to 200 million over multiple epochs. Multiple client representatives including Prysm, Lodestar, and Teku expressed support for the incremental approach, with only minor concerns raised by Dustin about the timing and safety implications. The group agreed to move forward with the optional change, noting that it would not affect the timeline before the Amsterdam upgrade.
The team discussed history expiry strategies for G star, with most clients planning to implement either a 5-month window or fork minus 1 approach. Nethermind and Aragon representatives shared their current implementations, while other clients like Besu and Gaff indicated they were reviewing options. The group agreed to converge on a single standard for history expiry in the ETH R&D history expiry channel and decided that EIP proposers need to have clear champions to discuss their proposals, with a preference list for PFI finalization required by September 10th.
The meeting focused on reviewing several EIPs related to Ethereum’s EVM. Jochem-Brouwer presented three EIPs: 7923 (linear page-based memory costing), 3298 (removal of refunds), and 5920 (pay-up code). The discussion centered on EIP 3298, where Dragon suggested removing only the problematic refund for clearing storage while keeping the reset refund. The group agreed to discuss this refinement asynchronously. Jochem-Brouwer also noted that EIP 5920 (pay-up code) no longer has a champion and may need to be closed.
The meeting focused on reviewing several EIPs, with Dragoranita presenting EIP-8358 on net gas metering for account changes and EIP-8374 on persisting warm access sets across reverts. Danno raised concerns about the complexity of implementing EIP-8374, particularly regarding supporting both pre-Hegaton and post-Hegaton modes in the same binary. The discussion ended with nixo introducing EIP-8368, which was proposed by Maria but she was not present on the call.
Toni provided an update on EIP-8368, explaining it involves recalibrating a constant from EIP-8037 to support scaling the gas limit to 600 million. Csaba presented on two EIPs: 8094 regarding blob-aware mempool efficiency and 8077 about announcing transactions with nonce metadata to improve mempool scaling capabilities. The discussion included feedback about potential DoS concerns and the importance of considering transaction size limits when implementing metadata announcements.
Danno proposed EIP-8355 for MLDSA precompiles, arguing that it is the most widely used post-quantum cryptography algorithm and offers benefits like existing test vectors and support across major programming languages. Kevandray raised concerns about the need for multiple precompiles for different security levels and gas costs, while Danno explained that including multiple security levels allows for future cryptographic agility if security levels are reduced. The discussion also touched on signature and public key storage sizes, with Danno noting that the FIPS 204 encoding reduces output size compared to previous methods.
Anders presented EIP 8372, a solution to address potential issues with gas allocation between execution and state creation in Glamsterdam, involving a one-time calibration of fault boundaries to adjust costs and limits based on observed demand. Ben discussed EIP 8375 (EMBR), proposing a mandatory burn mechanism for execution rewards to reduce security impact, with a focus on maintaining builder competition and setting floors through PDC observations. @ritzdorf introduced EIP 8219, proposing checked arithmetic opcodes to optimize execution gas usage, reduce bytecode size, and align with developer expectations for safe arithmetic operations. The group discussed potential concerns and alternatives for these EIPs, with ongoing feedback and questions in the chat.
The team discussed two main topics: EVM implementation changes and the frames proposal for Native Account Abstraction (NAA). Regarding EVM changes, Danno raised concerns about checked arithmetic operations and gas efficiency, while the group debated whether reducing gas costs was still important given increasing gas limits. For the frames proposal, Nethermind and Ben confirmed support, though there were concerns about EVM ecosystem compatibility and potential breaking changes for chains not implementing the update. The discussion highlighted the need for majority execution client support before proceeding, with ongoing debate about whether to make frames a headliner feature and address potential EVM incompatibility issues.
The meeting focused on comparing EIPs 8130 and 8141 for implementing native account abstraction (AA) on Ethereum. Chris presented arguments in favor of EIP 8130, highlighting its completeness, post-quantum readiness, and flexibility for L2 implementations. Tsahi and others expressed concerns about EIP 8141’s current design, particularly regarding its impact on L2s and block builders. The group agreed to continue discussions in an upcoming AA breakout call on the 25th, with the goal of reaching consensus by the 27th ACDE meeting. Key action items include bringing specific concerns to the breakout call and exploring potential modifications to EIP 8141 to address L2 concerns while maintaining L1 goals.
Next Steps:
- Barnabas: Ensure validators and builders make deposits and onboard before GLOS goes live on Thursday at 7.50 a.m. UTC.
- jochem-brouwer: Finalize and deliver the report on maximum allocatable EVM memory with linear memory cost via Ethereum editions before the next ACDE.
- Kevaundray: Converge on a single number for history expiry in the history expiry channel on ETHRND and decide where to spec it.
- nixo: Message Helkemein to ask if he wants another chance to talk about his EIPs on the next ACDE, otherwise close the PRs.
- Execution Layer (EL) clients: Come up with a preference list for EIPs by September 10th.
- Matt and Mark: Host the AA breakout call on August 25th at 14 UTC to address concerns and come to a conclusion for the next ACDE on the 27th.
- AA breakout call participants: Bring concerns and work towards a conclusion on the specific Native AA implementation (Frames vs. 8130) for the next ACDE on the 27th.
Recording Access: