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
On ACDE there has been a request to present demand and committed consumers of EXTENSION (0xae). Today a custom opcode risks a future collision with Ethereum, so few chains commit to one. EIP-8163 exists to unblock exactly that R&D.
Monad intends to use 0xae extension opcodes: MIP-7: Extension opcodes, which led directly to EIP-8163, adopts the reservation for Monad and specifies the encoding. Current needs for custom opcodes:
Cadence (planned MonadBFT replacement) - execution designs on top of it consider opcodes to introspect transaction inclusion and ordering
Flexible and Upgradeable Account Authentication - floats an opcode exposing the authentication result to contracts. EIP-8141 is not adoptable as is under delayed execution. Just as EIP-8141 needs TXPARAM, FRAMEPARAM and SIGPARAM, an alternative scheme needs its own opcodes.
Earlier designs that considered opcodes and took another route:
Early MIP-8: Page-ified Storage State had PSTORE and PLOAD to load kilobytes of storage into memory in one instruction (set aside for now)
Outside Monad, Rootstock specified DUPN, SWAPN and TXINDEX in 2016 (RSKIP26, RSKIP11), shipped and later removed them for Ethereum compatibility (RSKIP191). EIP-8141 now assigns 0xaa, the byte TXINDEX had. As noted above, Tron runs custom opcodes at 0xd0-0xdf.
To reiterate the benefits to Ethereum:
Ethereum gives up a single opcode in exchange for a space where custom opcodes live cleanly apart. The alternative is that a future successful opcode or chain ends up creating pressure on Ethereum not to use certain opcodes. Ethereum’s opcode set stays the globally compatible standard.
By encouraging experimentation with new opcodes elsewhere, Ethereum can draw on the results, successes and failures alike.
Alt-L1s and L2s can extend the EVM and stay inside it. That keeps them on Ethereum’s toolchain, keeps the EVM the default target for new chains, and lets them contribute to the shared tooling.
Lastly, deferring until consumers commit means repeating this conversation on ACD each fork, or having it once conflicts exist. EIP-8163 costs nothing to adopt now.
I’ve received feedback that the Specification section could be made smaller and also there was uncertainty, whether EIP-8163 requires clients to implement anything (it doesn’t). Fixed in a PR here, editorial changes only, if no objections I’ll merge shortly.