EOF - Creation transaction

Abstract

Creation transactions (i.e. the ones with empty to) can be used to deploy EOF contracts by providing EOF initcontainer concatenated with calldata for initcontainer execution in transaction's data. Initcontainer execution is similar to its execution during EOFCREATE instruction, ending with RETURNCODE instruction. New account address calculation is based on sender's address and nonce.

Motivation

Creation transaction is one of the three ways alongside creation instructions provided by legacy EVM to deploy new code. Given that legacy creation instructions (CREATE and CREATE2) are not allowed to deploy EOF code, supporting EOF in creation transactions is the only way to get the first EOF on-chain.

The mechanism for providing constructor arguments to initcontainer is exactly the same as for deploying legacy code (just concatenating them with initcontainer), therefore existing deployment tooling can be used as is to deploy EOF.

Specification

Wherever not explicitly listed, the rules of EOF contract creation should be identical or analogous to those of legacy creation transaction. This includes but is not limited to:

• behavior on accessed_addresses and address collision (EIP-684 and EIP-2929)
• EVM execution frame created for the initcode - memory, account context etc.
• nonce bumping of the account of newly created contract EIP-161
• balance checking and transfer for the creation endowment

Parameters

In case a creation transaction (transaction with empty to) has data starting with EOF_MAGIC, data is interpreted as a concatenation of EOF initcontainer and calldata. More specifically:

1. Intrinsic gas cost rules and limits defined in EIP-3860 for creation transactions apply. The entire data of the transaction is used for these calculations.
2. Find the split of data into initcontainer and calldata:
   • Parse EOF header
   • Find intcontainer size by reading all section sizes from the header and adding them up with the header size to get the full container size.
3. Validate the initcontainer and all its subcontainers recursively.
   • Unlike in general validation, initcontainer is additionally required to have data_size declared in the header equal to actual data_section size.
   • Validation includes checking that the initcontainer does not contain RETURN or STOP
4. If EOF header parsing or full container validation fails, transaction is considered valid and failing. Gas for initcode execution is not consumed, only intrinsic creation transaction costs are charged.
5. calldata part of transaction data that follows initcontainer is treated as calldata to pass into the execution frame.
6. Execute the container and deduct gas for execution.
   1. Calculate new_address as keccak256(sender || sender_nonce)[12:]
   2. A successful execution ends with initcode executing RETURNCODE{deploy_container_index}(aux_data_offset, aux_data_size) instruction. After that:
      • load deploy-contract from EOF subcontainer at deploy_container_index in the container from which RETURNCODE is executed,
      • concatenate data section with (aux_data_offset, aux_data_offset + aux_data_size) memory segment and update data size in the header,
      • let deployed_code_size be updated deploy container size,
      • if deployed_code_size > MAX_CODE_SIZE instruction exceptionally aborts,
      • set state[new_address].code to the updated deploy container (rules of EIP-3541, prohibiting deployment of code starting with EF from creation transactions, do not apply in this case).
7. Deduct 200 * deployed_code_size gas.

Rationale

Irregular state change to deploy Creator Contract

Originally it was proposed to deploy the first EOF contract via irregular state change. This contract would execute TXCREATE instruction and could be used then as an entry point to deploy any other EOF code. This would also require an introduction of InitcodeTransaction, required by TXCREATE. It was decided against this variant for the benefit of reduced scope of changes.

Constructor arguments outside of initcontainer vs in data section

Alternative mechanism for providing constructor arguments to initcontainer execution was considered, where they are concatenated with data section of the initcontainer and are accessed via DATA* instructions instead of CALLDATA*. This has a benefit of not requiring the step finding the split of transaction.data into initcontainer and calldata, as entire transaction.data is an EOF container. However it was rejected for the following reasons:

• Existing tooling could not be used for deploying EOF without modification. To construct EOF creation transaction, the tooling would need to append constructor arguments to the container, as well as update data section size in the EOF header. Compiler could predict the size of constructor arguments to put the anticipated data size in the header, but it would not be possible for variadic length constructor arguments.
• In case a specialized EOF creation transaction is introduced in a later upgrade (such as the InitcodeTransaction), it would have a dedicated field for initcontainer execution input (calldata), and it will be accessed with CALLDATA* instructions in initcode. It is better to avoid the situation where compilers would need to generate initcontainer code differently depending on which context it will be used in.
• As a general argument, data section can be seen to contain the data that execution considers validated and being closely coupled with the code definition, whereas calldata is an input from the outside that may be arbitrary and not validated.

Backwards Compatibility

Creation transactions deploying legacy code are not affected, because any such transaction starting with EF byte previously would fail on executing invalid instruction.

Security Considerations

TBA

Copyright

Copyright and related rights waived via CC0.