3.5 KiB
| eip | title | author | discussions-to | status | type | category | created |
|---|---|---|---|---|---|---|---|
| 3541 | Reject new contracts starting with the 0xEF byte | Alex Beregszaszi (@axic), Paweł Bylica (@chfast), Andrei Maiboroda (@gumb0), Alexey Akhunov (@AlexeyAkhunov), Christian Reitwiessner (@chriseth), Martin Swende (@holiman) | https://ethereum-magicians.org/t/evm-object-format-eof/5727/4 | Draft | Standards Track | Core | 2021-03-16 |
Abstract
Disallow new code starting with the 0xEF byte to be deployed. Code already existing in the account trie starting with 0xEF byte is not affected semantically by this change.
Motivation
Contracts conforming to the EVM Object Format (EOF) are going to be validated at deploy time. In order to guarantee that every EOF-formatted contract in the state is valid, we need to prevent already deployed (and not validated) contracts from being recognized as such format. This will be achieved by choosing a byte sequence for the magic that doesn't exist in any of the already deployed contracts. To prevent the growth of the search space and to limit the analysis to the contracts existing before this fork, we disallow the starting byte of the format (the first byte of the magic).
Specification
After block.number == HF_BLOCK new contract creation (via create transaction, CREATE or CREATE2 instructions) results in an exceptional abort if the code's first byte is 0xEF.
Remarks
The initcode is the code executed in the context of the create transaction, CREATE, or CREATE2 instructions. The initcode returns code (via the RETURN instruction), which is inserted into the account. See section 7 ("Contract Creation") in the Yellow Paper for more information.
The opcode 0xEF is currently an undefined instruction, therefore: It pops no stack items and pushes no stack items, and it causes an exceptional abort when executed. This means initcode or already deployed code starting with this instruction will continue to abort execution.
The exceptional abort due to code starting with 0xEF behaves exactly the same as any other exceptional abort that can occur during initcode execution, i.e. in case of abort all gas provided to a CREATE* or create transaction is consumed.
Rationale
The 0xEF byte was chosen because it resembles Executable Format.
Contracts using unassigned opcodes are generally understood to be at risk of changing semantics. Hence using the unassigned 0xEF should have lesser effects, than choosing an assigned opcode, such as 0xFD (REVERT), 0xFE (INVALID), or 0xFF (SELFDESTRUCT). Arguably while such contracts may not be very useful, they are still using valid opcodes.
Analysis at block 18084433 showed that there are 0 existing contracts starting with the 0xEF byte, as opposed to 1, 4, and 12 starting with 0xFD, 0xFE, and 0xFF, respectively.
Test Cases
TBA
Backwards Compatibility
This is a breaking change given new code starting with the 0xEF byte will not be deployable, and contract creation will result in a failure. However, given bytecode is executed starting at its first byte, code deployed with 0xEF as the first byte is not executable anyway.
While this means no currently executable contract is affected, it does rejects deployment of new data contracts starting with the 0xEF byte.
Security Considerations
The authors are not aware of any security or DoS risks posed by this change.
Copyright
Copyright and related rights waived via CC0.