Meeting Time: Thursday, April 23, 2026 at 14:00 UTC (90 minutes)
Orca Devs meeting 235 focused on updates and decisions related to Ethereum protocol development, particularly around the Glamstaden fork. The meeting began with Ansgar announcing Nixo as co-lead of Orca Devs alongside himself. Mario provided updates on DevNet 4, reporting that recent EIP 827 tests were consumed successfully by most client teams with no major issues reported. The team discussed EIP 786 regarding engine API reorg capabilities, ultimately deciding to proceed with the finality-based approach despite some implementation concerns, though this decision could be revisited if issues arise. Significant discussion occurred around EIP 837 testing concerns, where Mario highlighted that approximately 30% of tests required updates due to new account creation and block gas limit interactions, leading to concerns about test coverage and potential mainnet impacts. Piotr introduced EIP 8163 to reserve opcode AE for future Ethereum implementations, and Greg proposed EIP 7979 for adding industry-standard EVM instructions, though both proposals will need further discussion in upcoming breakout sessions. The conversation ended with a brief discussion of engine API performance optimizations for ZKVM use cases, where developers presented a new HTTP route proposal to improve execution witness generation times from 2 seconds to 1.2 seconds.
Ansgar announced that Nixo will join as co-lead of Orca Devs going forward. The team discussed updates on DevNet 4, with Mario reporting a recent release of EIP827. Most clients, including Besu, EthRex, and Aragon, confirmed they were able to consume the tests without issues. Barnabas provided an update on the progress with DevNet Zero, mentioning that tooling is updated to Alpha 5 and the spec sheet with parent images is available for local use. Stefan gave an overview of DevNet 3, noting an increase in gas limit to 100 million to correspond with EIP8037.
The team discussed two EIP proposals (786 and 770) related to reorg handling in the Ethereum network. After extensive debate about whether to implement a block cap or use a finality-based approach, the group decided to proceed with EIP 786, which allows reorgs up to the finalized hash. While some concerns were raised about implementation complexity and testing requirements, the team agreed to move forward with this approach pending further discussion at upcoming in-person events. The decision was made with the understanding that it could be revisited if significant issues arise.
Potuz proposed a change to improve syncing efficiency by allowing the consensus layer (CL) to execute state transitions without validating block hashes or downloading payloads, requiring new accumulator checks on the execution layer (EL) side. The team discussed whether to implement this in Glamsterdam, with Marius indicating it’s not suitable for their implementation, and Toni noting it would require changes to the block header and payload. Ansgar sought input on whether to consider adding this to Glamsterdam or wait for H-Star, though the discussion didn’t reach a clear decision on next steps.
The team discussed concerns about EIP 8037, particularly focusing on testing challenges. Mario highlighted that approximately 30% of tests required updates due to new account creation and block gas limit interactions, and expressed concerns about potential issues manifesting after deployment. The team also discussed challenges with benchmarking and refunding mechanisms coverage, with Potuz noting that implementing EIP 8037 in Hegota would be acceptable due to minimal technical debt. The discussion concluded with questions about whether these concerns were significant enough to request a simplified version of the EIP.
The team discussed challenges with EIP-8037, particularly around gas limits and costs. They debated between maintaining a dynamic gas cost model versus implementing a static gas cost with a schedule for increases. Maria suggested a middle ground approach with a preset schedule for gas increases between Lamsterdam and EIP-8037, while Ansgar emphasized the need for some version of state changes to enable scaling beyond current limits. The team agreed to prioritize finding the simplest possible version of the solution in upcoming work, rather than attempting to resolve all details in the current discussion.
The team discussed concerns about EIP-8037, particularly its complexity and implementation challenges. Anders presented a research post on dynamic gas pricing as an option, but noted it remains a guessing game regarding demand elasticity. The group expressed concerns about the EIP’s complexity, potential bugs, and whether the benefits justify the implementation effort. There was agreement to maintain the current spec for BaldevNet 4 and discuss potential changes in future meetings, with around 208 new tests added for EIP-8037.
The team discussed EIP-8037, focusing on its complexity and impact. Marius Van and Maria highlighted that while some aspects might be complex for testing, the multidimensional metering part is necessary for better state management and future pricing. The group agreed that pushing for significant changes to the EIP at this time wouldn’t be beneficial. Piotr introduced EIP-8163, proposing to reserve the AE opcode for non-Ethereum L1 EVM use. The team discussed the governance process and potential alternatives, ultimately deciding to put the proposal forward for PFI.
Greg proposed a simple ERP implementation that has been successfully deployed multiple times with clients and described it as low-risk. He explained that while the proposal addresses technical considerations, he separated motivational aspects into a higher-level informational EIP to address previous misunderstandings about the topic. The group discussed the current status of different EIP formats, with Greg clarifying that everything before EOF is deprecated while the current format remains active. Greg expressed interest in understanding opposition to the proposal and requested feedback either through discussion threads or a future breakout session.
The meeting focused on discussing EIP-7979, a proposal for adding CALLSUB and RETURNSUB instructions to the EVM. Greg explained that Solidity’s support was crucial for previous similar proposals, and emphasized the need for compiler teams’ buy-in due to the chicken-and-egg problem of implementation and adoption. Ben highlighted optimization challenges with current EVM contracts and supported the proposal for enforced structure. The group also discussed performance improvements for ZKVM use cases through changes to the engine API, with Developer presenting a PR that introduces a new HTTP route for faster witness generation. The conversation ended with a brief mention of Discovery V5 and Bosul’s request for feedback on a PR related to block propagation improvements.
Qeays5P+)Qeays5P+)Qeays5P+)YouTube Stream Links: