Meeting Time: Tuesday, June 30, 2026 at 15:00 UTC (60 minutes)
This meeting focused on discussing Greg Colvin’s EIP proposal for introducing new opcodes and validation mechanisms to support static subroutines in Ethereum smart contracts. Greg explained that the proposal includes backward-compatible opcodes that allow for structured code with call and return subroutines, which would enable one-pass bytecode traversal and improve compiler optimization capabilities. The discussion covered implementation details including magic headers for validation at deployment time, performance considerations, and how the new features would affect both clients and compilers. Participants raised questions about security implications, backward compatibility concerns, and the practical benefits for code deduplication and optimization. Greg noted that while compilers like Solidity haven’t shown strong interest in implementing these features due to past failed attempts, the proposal aims to address long-standing technical debt in the ecosystem by making it possible to extract control flow graphs and perform static analysis more efficiently.
Greg Colvin discussed questions about validation code and ZK work following John Max’s passing, expressing uncertainty about the validation code’s correctness and ZK implementation. He proposed moving the validation code to the blockchain as a solution to reduce technical debt, suggesting that clients would only need to add a return stack and simple opcodes. Greg requested feedback from the team on this proposal and indicated he would follow up with Kev after the call.
Greg explained that the new opcodes are backwards compatible and can be used in both valid and invalid code, though validation is only required when the magic header is present. He clarified that the validation is important for clients trying to optimize code, as Luke had discovered when attempting to write an efficient compiler. The discussion revealed that while some developers initially objected to the lack of validation in earlier proposals, the current approach provides genuine backwards compatibility while allowing future improvements to the validation algorithm.
The team discussed implementing static jumps in the EVM, with Greg explaining that while this would be a first step, it wouldn’t fully address dynamic jumps. Luis raised concerns about performance overhead during contract creation and validation, but Greg confirmed the validation process would be efficient and one-pass. The discussion also covered security implications of call subroutines accessing previous operand stacks, with Greg noting that while there are potential concerns, the validation would still catch problematic behavior within current constraints. Greg advocated for implementing the simplest solution first rather than waiting for more complex proposals that might offer additional benefits.
The group discussed the potential benefits and challenges of implementing EIP-615, which aims to restrict jump statements in smart contracts. Greg explained that while compilers could theoretically benefit from these restrictions, it would impose additional requirements on them without providing clear advantages. Ben inquired about the feasibility of relying on marked “magic” contracts for static analysis, to which Greg confirmed that if compilers implement the EIP, it would enable easier extraction of control flow graphs and abstract syntax trees. Greg expressed skepticism about investing significant resources in implementing the EIP due to past experiences with similar efforts that ultimately failed.
The team discussed backwards compatibility constraints for new opcodes in non-validated code. Greg clarified that the constraints requiring call sub to be followed by enter sub and preceded by push only apply to validated code, not non-validated code. He explained that in non-validated code, incorrect usage of return sub would result in similar issues as current legacy code, potentially leading to exceptional halting states or executing invalid instructions. The discussion concluded with Greg noting that implementing backwards compatibility on-chain would require minimal additional code changes.
Ben offered to create a PR to clarify return subroutines in the legacy code, which Greg accepted. Greg expressed interest in pushing the work towards CFI as soon as possible but noted challenges in finding the right contacts at the foundation due to staff departures. The discussion also covered code deduplication benefits of subroutines and a separate EIP (11800) for deploying existing contracts efficiently, which Ben explained would allow on-chain library deployment without using delegate calls. Greg emphasized that subroutine jumping is a valid feature, not a bug, and that compilers should be able to optimize it effectively.
!3m!ibNu)!3m!ibNu)!3m!ibNu)YouTube recording available: https://youtu.be/bVr0mVZLC4o