Repository navigation
All Core Devs - Execution (ACDE) #246, September 24, 2026 #2223
Description
Activity
⚡ Protocol Call Resources:
✅ Zoom: Join Meeting
✅ Calendar: View | Add to Calendar
✅ Discourse: Discussion Topic
✅ YouTube Live: Watch LiveEIP-7979: Call and Return Opcodes for the EVM should be considered for inclusion in Hegotá.
In the end the decision may be to not include this proposal in this fork. We declined to consider this proposal for inclusion in the last fork, and I have made every effort since to engage with the reasons it was declined. To not consider this proposal for inclusion is not now the best way to decide not to include it.
EIP-7979 itself makes a strong argument for these industry-standard operations. Two companion proposals strengthen the argument, and the prototypes and testing reported below answer questions about the difficulty of implementation and the amount of technical debt.
- EIP-8173: Foundations of EVM Control Flow
A brief tutorial on the VM and ZK fundamentals underlying these proposals, including why static control flow is essential to efficient validation, compilation, formal analysis, ZK-proving and more. Recommended reading. - EIP-7979: Call and Return Opcodes for the EVM
Three instructions for building subroutines, an essential facility provided by almost all other blockchain VMs, making it possible to write EVM code with static control flow. - EIP-8337: Validated EVM Code
This proposal efficiently validates the static control flow of EIP-7979 code at CREATE time. The reference validator takes less than five hundred lines of Python.
We now have EIP-7979 prototypes for Solidity, Vyper, geth, and evmone. (Thank you Claude.) As detailed on the Magicians' thread, they don't take much space: a total of 608 lines of code, 167 lines of comments, and 677 lines of tests for all four. For Solidity only 289 new lines of code were needed.
We also have reference specifications for implementation, EELS, EIP-7979, at 245 lines of code, docstrings, and comments and 1,025 lines of tests, and for validation, EELS, EIP-8337, at 471 lines of code, docstrings, and comments and 679 lines of tests.
Neither is it a complex change: it scores at most 13 on the STEEL complexity scale (preliminary self-assessment), versus 15 for FOCIL and 38 for Frame Transactions. Among execution-layer feature EIPs proposed for Hegotá, this is the smallest surface.
And so far it is a well-tested change: Solidity's full semantic test suite passes on a patched evmone that implements the instructions. Also, all 1,756 of Solidity's single-source test contracts, and all 17 of Vyper’s examples, compile to code that validates under EIP-8337.
EIP-8337 could have been proposed in this fork, but the EOF work, discussions on previous calls and the breakout indicate to me that it belongs in a later fork, after we have gained more experience with EIP-7979. There are always tradeoffs between the simplicity and power of the validation algorithm. The current algorithm is solidly specified and tested here against EIP-7979 on both Solidity and Vyper. And the EOF algorithm is solid work, thoroughly tested. So I am confident that EIP-8337, or a similar algorithm, will serve the purpose.
Only clients need to make any immediate changes. Compilers and other tools can adopt this EIP on their own schedule.
Reacted by nixo, rodiazet and Pooja Ranjan- EIP-8173: Foundations of EVM Control Flow
Re: EIP-8163 "Reserve
EXTENSION (0xae)opcode"ACD asked for feedback from L2s and Alt-L1s to voice support for this it before considering it. Offchain definitely supports including this EIP. One reason we don't currently consider adding opcodes to Arbitrum Nitro is that such a reserved opcode doesn't exist.
Reacted by Daniel Von Fange, pdobacz and nixoStaying on the subject of EIP-8163, I would like to add advancing it to CFI to the agenda.
As requested, I posted demand examples in: https://ethereum-magicians.org/t/eip-8163-reserve-extension-0xae-opcode/27756/8. tl;dr: EIP-8163 exists to unblock R&D on EVM extensions in the first place, and there are already examples to name: Monad's MIP-4, MIP-8, execution designs on top of Cadence, and flexible account authentication. All of these consider or have considered adding custom opcodes. MIP-7 is Monad's framework spec for deploying opcodes on top of EIP-8163.
Outside Monad, Rootstock and Tron have or had custom opcodes, and per comment above, Arbitrum Nitro would also like to see the reservation.
Reacted by nixoI'd like to discuss scheduling a gas limit increase in Sepolia:
Reacted by nixoReacted by danceratopzReacted by nixoI just wanted to raise two independent, yet coupled, decisions that were discussed without resolution in ACDT 97 #2225.
The most relevant background is in this Eth R&D thread in #interop.
Still TBD:
- Post-EIP-8061, what should be the size of the CL block retention window for Glamsterdam?
- Should the BAL retention period on the EL match the value of the CL block retention window (i.e., the value from 1.).
Other people involved in the ACDT discussion: @nerolation, @potuz.
In ACDT, this was deemed to be non-blocking for testnets @parithosh.
Reacted by nixoThis meeting occurred more than 24 hours ago. Closing automatically.
Reacted by Justin Traglia
UTC Date & Time
September 24, 2026, 14:00 UTC
today's facilitator: @nixorokish
Agenda
Call Series
All Core Devs - Execution
Autopilot Mode
🔧 Meeting Configuration
Duration
90 minutes
Occurrence Rate
bi-weekly
Use Custom Meeting Link (Optional)
Display Zoom Link in Calendar Invite (Optional)
YouTube Livestream Link (Optional)