HomeEIPs
EIPsEIP-3541
EIP-3541

Reject new contract code starting with the 0xEF byte

FinalStandards Track: Core
Created: 2021-03-16
Alex Beregszaszi (@axic), Paweł Bylica (@chfast), Andrei Maiboroda (@gumb0), Alexey Akhunov (@AlexeyAkhunov), Christian Reitwiessner (@chriseth), Martin Swende (@holiman)
DiscussionsOriginal linkEdit
1 min read

EIP-3541 proposes to disallow new contract code starting with the 0xEF byte to be deployed in order to prevent already deployed contracts from being recognized as the EVM Object Format (EOF) and to limit the analysis to contracts existing before this fork. This change does not affect currently executable contracts and there are no known security risks posed by this change.

Videos

PEEPanEIP #36: EIP-3540 & EIP-3541 with Alex B., Paweł B., Andrei M.

Original

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).

Should the EVM Object Format proposal not be deployed in the future, the magic can be used by other features depending on versioning. In the case versioning becomes obsolete, it is simple to roll this back by allowing contracts starting with the 0xEF byte to be deployed again.

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 in May 2021, on 18084433 contracts in state, 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

Each test case below may be executed in 3 different contexts:

  • create transaction (no account code)
  • CREATE, with account code: 0x6000356000523660006000f0151560165760006000fd5b (Yul code: mstore(0, calldataload(0)) if iszero(create(0, 0, calldatasize())) { revert(0, 0) }),
  • CREATE2, with account code: 0x60003560005260003660006000f5151560185760006000fd5b (Yul code: mstore(0, calldataload(0)) if iszero(create2(0, 0, calldatasize(), 0)) { revert(0, 0) })
CaseCalldataExpected result
deploy one byte ef0x60ef60005360016000f3new contract not deployed, transaction fails
deploy two bytes ef000x60ef60005360026000f3new contract not deployed, transaction fails
deploy three bytes ef00000x60ef60005360036000f3new contract not deployed, transaction fails
deploy 32 bytes ef00...000x60ef60005360206000f3new contract not deployed, transaction fails
deploy one byte fe0x60fe60005360016000f3new contract deployed, transaction succeeds

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 and related rights waived via CC0.

Further reading
Anyone may contribute to propose contents.
Go propose
Adopted by projects
Anyone may contribute to propose contents.
Go propose

Not miss a beat of EIPs' update?

Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.

View all
Serve EIP builders, scale Ethereum.
Resources
GitHub
Supported by