EIP-2315
Closed this issue · 6 comments
Should be very little discussion time needed at meeting (that is what this issue is for) just a go/no-go as to whether EIP-2315 can be reconsidered for London.
https://eips.ethereum.org/EIPS/eip-2315
I've recently seen two major objections to EIP-2315.
- It did not provide security guarantees that it was not designed to provide.
The proposal we had previously agreed to specified a simple two-stack mechanism for returning from jumping to and returning from subroutines. No more, no less. This mechanism was first proposed for EIP-615 in 2016, has been a standard approach since 1970, and should not be controversial by now.
The current Draft shows how to provide security guarantees. Essentially: deprecate dynamic uses of JUMP and JUMPI, and use RETURNSUB rather than a dynamic jump to return from subroutines. Precise rules are stated and an algorithm given for enforcing them. When and how to start enforcing those rules can be a separate discussion.
EIP-615 proposed immediate arguments to JUMPSUB, which are not backwards-compatible. EIP-2315 requires instead that jump destinations be pushed as constants, and thus remains backwards-compatible.
- It did not provide evidence of potential users.
Such evidence would not be appropriate in a technical specification.
At this point I can say that over the years that I have been working on subroutines for the EVM many people have expressed support for my proposals, especially people doing various forms of static analysis. I cannot make a list, but it goes well beyond two compiler teams. EIP-2315 has been publicly announced for long enough that there are no doubt others waiting to use it.
So far as compiler teams being users, if we do deprecate static jumps then all compiler teams will require another mechanism for returning from subroutines. EIP-2315 provides a good one.
From the Eth R&D discord:
Alexey, TurboGeth:
EIP-2315 - not to be considered for London, because there are still lots of things to work out there about validation. Also, these changes do require full cooperation with compiler teams, because the roll-out plan will require core devs and compiler devs to make changes in lock-step. So inclusion of "reborn" EIP-2315 is still premature.
2315 should not be included. The 'reborn' is same as previous. It is a Feature-eip, and adding any features need to be backed solidly by showing that there is a demand for the feature. As neither Vyper nor Solodity demands/wants it, I don't see why we would include it.
( same comment being posted to BEGINDATA)
I don't think this should target London. The EVM encapsulation format I think is what the first step should be. From there we can impose rules on the EVM bytecode that will make evolution easier.
The restrictions around multi-byte instructions because of the EVM's tolerance of invalid opcodes restricts too much space for evolution, and the design for subroutines suffered because of that.
@shemnon I agree this should not be in London. Since this proposal is backwards-compatible no encapsulation is needed, but that is a discussion for another time.
My understanding was that this was off of the table for London. I don't have a revised proposal ready for review.
Ok, I will remove it from the agenda, then. I agree it's extremely unlikely it would make it in, given the conversations about other EIPs on the last call.