主页EIPs
EIPsEIP-7620
EIP-7620

EOF Contract Creation

Introduce `EOFCREATE` and `RETURNCONTRACT` instructions
ReviewStandards Track: Core
创建时间: 2024-02-12
关联 EIP: EIP-170, EIP-3540, EIP-3541, EIP-3670
Alex Beregszaszi (@axic), Paweł Bylica (@chfast), Andrei Maiboroda (@gumb0), Piotr Dobaczewski (@pdobacz)
社区讨论原文链接编辑
1 分钟了解
欢迎补充好内容
去提交
相关视频
欢迎补充好内容
去提交
正文

Abstract

EVM Object Format (EOF) removes the possibility to create contracts using CREATE or CREATE2 instructions. We introduce a new/replacement method in form of pair of instructions : EOFCREATE and RETURNCONTRACT to provide a way to create contracts using EOF containers.

Motivation

This EIP uses terminology from the EIP-3540 which introduces the EOF format.

EOF aims to remove code observability, which is a prerequisite to legacy EVM contract creation logic using legacy-style create transactions, CREATE or CREATE2, because both the initcode and code are available to the EVM and can be manipulated. On the same premise, EOF removes opcodes like CODECOPY and EXTCODECOPY, introducing EOF subcontainers as a replacement to cater for factory contracts creating other contracts.

The new instructions introduced in this EIP operate on EOF containers enabling factory contract use case that legacy EVM has.

Specification

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.

Parameters

ConstantValue
GAS_KECCAK256_WORDDefined as 6 in the Ethereum Execution Layer Specs
TX_CREATE_COSTDefined as 32000 in the Ethereum Execution Layer Specs
STACK_DEPTH_LIMITDefined as 1024 in the Ethereum Execution Layer Specs
GAS_CODE_DEPOSITDefined as 200 in the Ethereum Execution Layer Specs
MAX_CODE_SIZEDefined as 24576 in EIP-170

We introduce two new instructions on the same block number EIP-3540 is activated on:

  1. EOFCREATE (0xec)
  2. RETURNCONTRACT (0xee)

Execution Semantics

  • The instructions CREATE, CREATE2 are made obsolete and rejected by validation in EOF contracts. They are only available in legacy contracts.
  • If instructions CREATE and CREATE2 have EOF code as initcode (starting with EF00 magic)
    • deployment fails (returns 0 on the stack)
    • caller's nonce is not updated and gas for initcode execution is not consumed

Overview of the new contract creation flow

In EOF EVM, new bytecode is delivered by means of creation transactions (with an empty to) in the form of an EOF container (initcontainer). Such a container may contain arbitrarily deeply nesting subcontainers. The initcontainer and its subcontainers are recursively validated according to all the validation rules applicable for the EOF version in question. Next, the 0th code section of the initcontainer is executed and may eventually call a RETURNCONTRACT instruction, which will refer to a subcontainer to be finally deployed to an address.

EOF creation transactions (ones with an empty to and with data starting with EF00 magic) are defined in detail in a separate EIP.

EOFCREATE instruction is in turn a replacement of the CREATE and CREATE2 legacy instructions allowing factory contracts to create other contracts. The main difference to the creation transaction is that the initcontainer is selected to be one of the subcontainers of the EOF container calling EOFCREATE. It is worth noting that no validation is performed at this point, as it has already been done when the factory contract containing EOFCREATE was deployed.

Details on each instruction follow in the next sections.

EOFCREATE

  • deduct TX_CREATE_COST gas
  • read immediate operand initcontainer_index, encoded as 8-bit unsigned value
  • pop value, salt, input_offset, input_size from the operand stack
  • peform (and charge for) memory expansion using [input_offset, input_size]
  • load initcode EOF subcontainer at initcontainer_index in the container from which EOFCREATE is executed
    • let initcontainer_size be the declared size of that EOF subcontainer in its parent container header
  • deduct GAS_KECCAK256_WORD * ((initcontainer_size + 31) // 32) gas (hashing charge)
  • check that current call depth is below STACK_DEPTH_LIMIT and that caller balance is enough to transfer value
    • in case of failure return 0 on the stack, caller's nonce is not updated and gas for initcode execution is not consumed.
  • caller's memory slice [input_offset:input_size] is used as calldata
  • execute the container in "initcode-mode" and deduct gas for execution. The 63/64th rule from EIP-150 applies.
  • increment sender account's nonce
  • calculate new_address as keccak256(0xff || sender || salt || keccak256(initcontainer))[12:]
  • an unsuccesful execution of initcode results in pushing 0 onto the stack
    • can populate returndata if execution REVERTed
  • a successful execution ends with initcode executing RETURNCONTRACT{deploy_container_index}(aux_data_offset, aux_data_size) instruction (see below). After that:
    • load deploy EOF subcontainer at deploy_container_index in the container from which RETURNCONTRACT is executed
    • concatenate data section with (aux_data_offset, aux_data_offset + aux_data_size) memory segment and update data size in the header
    • if updated deploy container size exceeds MAX_CODE_SIZE instruction exceptionally aborts
    • set state[new_address].code to the updated deploy container
    • push new_address onto the stack
  • RETURN and STOP are not allowed in "initcode-mode" (abort execution)
  • "initcode-mode" is not transitive - it is only active for the frame executing the initcontainer. If another (non-create) call is made from this frame, it is not executed in "initcode-mode".
  • deduct GAS_CODE_DEPOSIT * deployed_code_size gas

RETURNCONTRACT

  • read immediate operand deploy_container_index, encoded as 8-bit unsigned value
  • pop two values from the operand stack: aux_data_offset, aux_data_size referring to memory section that will be appended to deployed container's data
  • cost 0 gas + possible memory expansion for aux data
  • ends initcode frame execution and returns control to EOFCREATE/4 caller frame where deploy_container_index and aux_data are used to construct deployed contract (see above)
  • instruction exceptionally aborts if after the appending, data section size would overflow the maximum data section size or underflow (i.e. be less than data section size declared in the header)
  • instruction exceptionally aborts if invoked not in "initcode-mode"

Code Validation

We extend code section validation rules (as defined in EIP-3670).

  1. EOFCREATE initcontainer_index must be less than num_container_sections
  2. EOFCREATE the subcontainer pointed to by initcontainer_index must have its len(data_section) equal data_size, i.e. data section content is exactly as the size declared in the header (see Data section lifecycle)
  3. RETURNCONTRACT deploy_container_index must be less than num_container_sections
  4. RJUMP, RJUMPI and RJUMPV immediate argument value (jump destination relative offset) validation: code section is invalid in case offset points to the byte directly following either EOFCREATE or RETURNCONTRACT instruction.

Data Section Lifecycle

For an EOF container which has not yet been deployed, the data_section is only a portion of the final data_section after deployment. Let's define it as pre_deploy_data_section and as pre_deploy_data_size the data_size declared in that container's header. pre_deploy_data_size >= len(pre_deploy_data_section), which anticipates more data to be appended to the pre_deploy_data_section during the process of deploying.

pre_deploy_data_section
|                                      |
\___________pre_deploy_data_size______/

For a deployed EOF container, the final data_section becomes:

pre_deploy_data_section | static_aux_data | dynamic_aux_data
|                         |             |                  |
|                          \___________aux_data___________/
|                                       |                  |
\___________pre_deploy_data_size______/                    |
|                                                          |
\________________________data_size_______________________/

where:

  • aux_data is the data which is appended to pre_deploy_data_section on RETURNCONTRACT instruction.
  • static_aux_data is a subrange of aux_data, which size is known before RETURNCONTRACT and equals pre_deploy_data_size - len(pre_deploy_data_section).
  • dynamic_aux_data is the remainder of aux_data.

data_size in the deployed container header is updated to be equal len(data_section).

Summarizing, there are pre_deploy_data_size bytes in the final data section which are guaranteed to exist before the EOF container is deployed and len(dynamic_aux_data) bytes which are known to exist only after. This impacts the validation and behavior of data-section-accessing instructions: DATALOAD, DATALOADN, and DATACOPY, see EIP-7480.

Rationale

Data section appending

The data section is appended to during contract creation and also its size needs to be updated in the header. Alternative designs were considered, where:

  • additional section kinds for the data were introduced
  • additional fields describing a subcontainer were introduced
  • data section would be written over as opposed to being appended to, requiring it to be filled with 0 bytes prior to deployment

All of these alternatives either complicated the otherwise simple data structures or took away useful features (like the dynamically sized portion of the data section).

EOF validation checking initcode-mode

Extra EOF validation rules were considered:

  • Each EOF subcontainer must either be referenced by an EOFCREATE or a RETURNCONTRACT instruction, but never both
  • Each EOF subcontainer may either contain RETURNCONTRACT or RETURN / STOP instructions, but never a mix of these two kinds
  • A subcontainer referenced by an EOFCREATE must never contain a RETURN / STOP instruction, whereas a subcontainer referenced by a RETURNCONTRACT must never contain a RETURNCONTRACT

These rules were not adopted to avoid the extra logic and complexity (esp. the last rule causes EOF validation of subcontainers to not be self-contained).

Backwards Compatibility

This change poses no risk to backwards compatibility, as it is introduced at the same time EIP-3540 is. The new instructions are not introduced for legacy bytecode (code which is not EOF formatted), and the contract creation options do not change for legacy bytecode.

CREATE and CREATE2 calls with EF00 initcode fail early without executing the initcode. Previously, in both cases the initcode execution would begin and fail on the first undefined instruction EF.

Test Cases

Creation transaction, CREATE and CREATE2 cannot have its code starting with 0xEF, but such cases are covered already in EIP-3541. However, new cases must be added where CREATE or CREATE2 have its initcode being (validly or invalidly) EOF formatted:

InitcodeExpected result
0xEFinitcode starts execution and fails
0xEF01initcode starts execution and fails
0xEF5finitcode starts execution and fails
0xEF00CREATE / CREATE2 fails early, returns 0 and keeps sender nonce intact
0xEF0001as above
valid EOFv1 containeras above

Security Considerations

It is the EOF creation transaction (specified in a separate EIP) which needs a detailed review and discussion as that is where external unverified code enters the state. Among others:

  1. Is its complexity under control, ruling out any DoS attempts
  2. Is it correctly priced and always charged for
  3. Is the validation comprehensive and not allowing problematic code to be saved into the state

Copyright and related rights waived via CC0.

扩展阅读
欢迎补充好内容
去提交
相关项目
欢迎补充好内容
去提交

不想错过最新的 EIP 动态?

订阅 EIPs Fun 周刊以跟进相关更新,建⽴你与 EIP 之间的连接 ,更好地建设以太坊。

详情
支持以太坊贡献者,推动生态建设
资源
GitHub
支持社区