The All Core Devs meeting focused on updates and discussions across multiple Ethereum development topics. The team reviewed DevNet progress, with Stefan reporting gas accounting issues in Battle DevNet 3 and Barnabas noting stability problems with TPGS.Net 1. Mikhail presented proposed engine API changes related to block hashes and reorg handling, while the group debated whether to introduce new block tags like justified and confirmed logs. A significant portion of the meeting centered on account abstraction (AA) implementation, with disagreement over whether frame transactions should remain as a non-headliner proposal or be promoted to a headliner, leading to a discussion about Ben’s new ERC proposal versus the existing frame transaction approach. The meeting also covered history pruning targets, with Sina proposing to establish minimum requirements for how much blockchain history clients should maintain, and Barnabas presenting a request to add Server-Sent Events (SSE) to the Engine API for performance improvements.
Click to expand detailed summary
The meeting began with Nixo filling in for Oscar and welcoming attendees to All Core Devs meeting #234 on April 9th. Nixo outlined the agenda, which included updates on Glamsterdam, DevNet, API changes, housekeeping for Hakota, AA topics, and miscellaneous items. The meeting was in its early stages, with Nixo starting to discuss DevNet updates, but no specific decisions or action items were mentioned in the provided transcript.
Stefan reported issues with gas accounting following the launch of Battle DevNet 3, including problems with spillover gas and edge cases with special opcodes on reverts. The team discussed these issues in the Steel Discord and noted that Geth might be implementing the behavior correctly while other clients may not. Barnabas reported that TPGS.Net 1 launch has been problematic with clients disconnecting and consensus bugs, and the team is working to resolve these issues. Mikhail presented two engine API changes, one regarding allowing zero hashes for finalized and safe block hashes to be passed to the Execution Layer, and another about handling fork choice updates for EPBS cases with a 32-block reorg limit.
Mikhail raised a question about reusing the save block tag for fast confirmations, proposing to introduce justified and confirmed block tags to the engine API. The team discussed whether this change would require a hard fork, with Dustin suggesting it might not be necessary since the tag was never formally defined with specific semantics. The group also briefly touched on the debate between creating bal-devnet-4 versus glam-devnet-0, with Stefan suggesting that having a bal-devnet-4 might make more sense given the current state of development.
The team discussed merging DevNet versions, with Barnabas advocating for a merged DevNet before the end of April. They debated including two data repricing EAPs, with Toni noting that these were minimal changes already implemented by most clients. The group agreed to evaluate EPBS devnet stability by Monday, with plans to proceed to Glamsterdam DevNet Zero if stable, or DevNet 4 if not stable. Nixo summarized that frame transactions would be handled as a non-headliner proposal, with the team now able to proceed with non-headliner proposals and work through interop.
The team discussed the status of native account abstraction implementation, with Asanso advocating for reconsidering it as a headliner feature rather than a non-headliner CFI. Nixo proposed moving forward with keeping it as a non-headliner CFI for now, allowing the AA team to work on developing a proposal that could potentially become a headliner in a future release. Łukasz mentioned an alternative ERC solution published by Ben that doesn’t require consensus changes and handles most account abstraction features except post-quantum signatures. The team agreed to review Ben’s proposal before making further decisions.
The meeting focused on discussions around account abstraction (AA) and post-quantum infrastructure. Pedro expressed concerns about taking half-measures and emphasized the need for a truly native solution rather than another interim approach. There was debate about the maturity of proposal 8141 and whether it should be implemented natively or as an ERC. Ben Adams was scheduled to present an ERC proposal for wallet title deeds, which aims to abstract accounts through NFTs rather than traditional EOA bonding.
Ben Adams presented a proposal for using NFTs as transferable accounts to address key rotation and asset management challenges. He explained how this approach could enable programmable control, batch signing, and gas sponsorship without requiring additional infrastructure. The discussion included feedback from participants, including Hadrien and Parthasarathy, who noted that similar concepts had been built before and questioned the novelty of the proposal. The conversation also touched on concerns about decentralization and the potential need for centralized relayers, with lightclient emphasizing the importance of maintaining decentralization in transaction execution.
The meeting focused on the discussion of frame transactions and account abstraction proposals. Tomás raised concerns about the decision-making process for moving frame transactions from a headliner to a regular proposal, questioning the rationale behind this change and the treatment of a recently published ERC proposal. Pedro volunteered to champion a breakout session to address the “best path forward” for the AA proposal, with protocol support to follow up with him. Several participants, including Parthasarathy and Łukasz, expressed technical concerns about frame transactions and native account abstraction, particularly regarding statelessness, mempool compatibility, and post-quantum security. The group agreed to continue the detailed discussion in a breakout session, with lightclient mentioning a PR that incorporates ideas from scheme transactions into frame transactions.
The team discussed the design and complexity of frame transactions for AI app development, with Dragan emphasizing the need to focus on minimal mechanisms required for specific use cases. Lightclient defended the current approach, arguing that frame transactions provide more functionality than scheme transactions and that the core team has already described various use cases. Nixo encouraged participants to clearly define their minimum requirements and review existing proposals, bringing any issues to upcoming breakout sessions for further discussion.
The team discussed the Ethereum AA (Account Abstraction) conversation and debate around proposal 8141, with Prestwich noting that reaching universal agreement on design is unlikely and suggesting focus on use cases rather than debating indefinitely. The group agreed to hold a breakout call to discuss specific requirements and proposals, particularly around decoupling post-quantum transactions from AA. Sina raised concerns about history pruning targets, seeking input on how aggressively clients can prune history, with different opinions emerging including suggestions for pruning until finalization epoch or weak subjectivity period, though Geth requires maintaining at least 90,000 recent blocks for social recovery purposes.
The team discussed pruning targets and history retention requirements for execution clients. While specific numbers were debated, including proposals for 1 month, 18 days, and matching the CL’s 33,000 epochs period (approximately 5 months), no final decision was reached. The group agreed that clients should be able to define their own default retention periods as long as they meet a minimum standard, and Sina directed participants to follow up in the History Experiator Discord channel. Barnabas also presented a proposal to optionally bring SSE over REST to the Execution API for performance improvements, which he shared in a GitHub pull request.