The EIP reserves an opcode `EXTENSION (0xae)` which will be guaranteed to not become a valid opcode on Ethereum L1 EVM, but which will be available to be used in other EVMs as a prefix to encode extension instructions.
By setting aside a single opcode and agreeing that it will never become a valid instruction on Ethereum L1 EVM, we open up to extensions which can be implemented on other EVM chains. If these extensions prove out to be successful outside of Ethereum L1, then they can be back-ported into Ethereum L1 EVM, to the benefit of the entire EVM ecosystem.
The extension opcode is designed in such a way to not only have **no impact** on Ethereum L1 EVM behavior, but also to not require any Ethereum Execution Layer Client modifications relevant to consensus.
I think this is a very worthy goal. Thanks for pushing this through.
Some chains have already extended the EVM with their own opcodes. It may be helpful to enumerate them, and best if some previous extensions could be compatible.
For example the TRON blockchain populated the 0xD* range with their opcodes.
I think this is a pretty good value add for EVM (and notably, the EVM+) ecosystem at a substantially low amount of long-term risk. That said, I’m interested in the critiques for this proposal (if any).
But seriously, MIP-7 chose 0xee, but that’s still taken up, at least officially, as pointed out elsewhere. Without speculations on whether or not that “other” 0xee is still relevant, I think EXTENSION 0xae by definition should be in a slot minimizing any potential conflict.
It can be anywhere where it doesn’t get in the way.
Push range opcodes are ok, if they are used to introduce multi-byte immediates:
0xae60-0xae7f byte sequences will not be valid extension instructions, unless the PUSH1 (0x60)-PUSH32 (0x7f) byte is used to introduce JUMPDEST-neutral immediate arguments