Reserve 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.
Currently, non-Ethereum-L1 EVM chains cannot innovate on the EVM by introducing new instructions, because they run a risk of becoming incompatible with the Ethereum L1 EVM and the EVMs on other chains, in the event that these decide to implement new features using overlapping opcodes.
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.
Similarly, making it easier for innovations to happen inside the EVM should generally improve the EVM tooling by strengthening the network effects. In other words, it is beneficial for an innovation X to happen within the EVM, even if not on Ethereum Mainnet.
In particular, the extension opcode might be adopted by Ethereum L2 EVMs, allowing them to specialize and experiment, potentially expanding the catalogue of extensions relevant to the L1.
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, except, optionally, for their presentation layer (e.g., traces), which is irrelevant to consensus.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
EXTENSION (0xae)Reserve a new opcode EXTENSION (0xae) which MUST behave exactly like INVALID (0xfe) (see EIP-141) on all Ethereum L1 chains (Ethereum Mainnet, Testnets, etc.). In particular:
EXTENSION MUST cause an exceptional halt (exit current execution frame and consume all gas, same as INVALID).EXTENSION byte in the bytecode MUST NOT impact JUMPDEST analysis in any way, i.e. all jump destinations' validity MUST NOT be affected.EXTENSION byte in the bytecode in any way other than how INVALID would affect it.Outside of Ethereum L1, EXTENSION MAY have meaningful behavior during execution, but it is up to the particular EVM implementations to decide.
However, in these EVMs which execute EXTENSION, the JUMPDEST analysis MUST still be unaffected by EXTENSION, i.e. the set of valid jump destinations MUST be identical to that obtained on Ethereum L1.
The particular behavior of the EXTENSION instruction on non-Ethereum-L1 EVMs adopting it MUST be determined by bytes following EXTENSION as immediate args. If such immediate args contain any JUMPDEST (0x5b) byte which remains a valid jump destination, execution MUST result in an exceptional halt.
The non-Ethereum-L1 EVM implementers SHOULD coordinate via the discussion thread of this EIP on their specific usage of EXTENSION.
JUMPDEST analysisAn alternative considered was to have EXTENSION:
0x5b byte following it as a jump destination andPUSHx instructions following ithowever that would require this EIP to prescribe the size of the immediate arguments.
It would also run into conflict with any opcodes with immediate arguments introduced in the EVM via other EIPs.
Lastly, it could cause different jump destination validity for same bytecode when analyzed on and outside Ethereum L1 EVM, causing code to not be portable between chains.
It is therefore presumed that a 0xae5b sequence cannot be a valid extension instruction and its second byte will be a valid jump destination. 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 (since PUSHx instruction data is already skipped during JUMPDEST analysis).
| Bytecode sequence | JUMPDEST (0x5b) validity | Possible extension opcode execution |
|---|---|---|
0xae5b... | valid | Invalid extension |
0xae015b... | valid | Valid extension with 0x01 argument |
0xae60 | N/A | Invalid extension (truncated) |
0xae605b... | invalid | Valid extension with 0x5b argument encoded in PUSH1 data |
0xae60605b... | valid | Valid extension with 0x60 argument encoded in PUSH1 data |
0xae61605b... | invalid | Valid extension with 0x605b argument encoded in PUSH2 data |
0xae615b | invalid | Invalid extension (truncated) |
This EIP chooses to not define any extension encoding scheme, in order to limit its scope as much as possible. Any such extension encoding scheme can be introduced and discussed in a separate proposal.
We explicitly prohibit any multi-byte opcode support using EXTENSION on the Ethereum L1 EVM. If one is desired in the future, it should be implemented using a different prefix.
In the event a feature implemented using EXTENSION needs to be ported back, a distinct opcode is chosen in a separate EIP. Once that EIP is in turn adopted in the originator EVM, that EVM will operate with two alternative ways to access the feature.
The opcode EXTENSION is currently invalid in Ethereum, and it doesn't impact JUMPDEST analysis, thus no code containing it will change behavior.
Will be provided in the Ethereum Execution Layer Specs format.
None, Ethereum Execution Layer clients' behavior does not change.
None, Ethereum Execution Layer clients' behavior does not change.
Copyright and related rights waived via CC0.