Backwards-incompatibly changing and/or removing EVM features
Closed this issue · 6 comments
We have a unique opportunity to make some backwards-incompatible changes to the EVM that could be valuable for Ethereum in the long term. I wrote up a doc with some of the key ones, though there are certainly others (as well as those outside the EVM proper, like for example moving block structure to SSZ and changing the state tree) that are also arguably worth doing. The portion of applications that would need to be rewritten as a result of these changes is quite small, but it is nevertheless nonzero.
It would be good to start talking about this earlier, so that any such changes can be on developers' radar with as long a lead-time as possible.
https://hackmd.io/@HWeNw8hNRimMm2m2GH56Cw/evm_feature_removing
I would suggest https://eips.ethereum.org/EIPS/eip-2488 as an addition.
Also hoped to get rid of PC to restrict the opportunity for dynamic jumps, but unfortunately it is in use: chi gas token and optimism.
I'd love to deprecate CALLCODE.
Why would we want to restrict dynamic jumps? I would actually even argue the contrary, that we should be trying to deprecate static jumps and make all jumps relative to the current PC, as that makes it easier to move code around, prepend and take pieces of code, etc.
Proposals to change EVM control structures take a long time to get right and even longer to (fail to) get consensus on accepting. Unless the merge is at least two years out I wouldn't go there.
But to go there slightly - the ideas look very interesting, and worth fleshing out if there really is time. And whether the jump is relative to the PC or the start of the bytecode is I think independent of whether the address is static or dynamic.
Why would we want to restrict dynamic jumps? I would actually even argue the contrary, that we should be trying to deprecate static jumps and make all jumps relative to the current PC, as that makes it easier to move code around, prepend and take pieces of code, etc.
I think what you are talking about getting rid of absolute jumps and making everything relative jumps. I think that could make sense, but I would go around it the following way:
- Introduce new jump instructions which take relative offsets, such as
RJUMP <offset>andRJUMPI <offset> <condition>(R for relative) where offset is a signed value. - Change the specification of the current
JUMP <offset>toRJUMP <offset - PC> - Remove PC over time, as it is not needed.
After that we can argue that dynamic jumps would not be needed to accomplish your use case, and everything could be static relative jumps.