EVM Object Format (EOF) removes the possibility to create contracts using creation transactions (with an empty to
field), CREATE
or CREATE2
instructions. We introduce a new instruction: TXCREATE
, as well as a new transaction type (InitcodeTransaction
), to provide a way to create contracts using EOF containers in transaction data.
This EIP uses terminology from the EIP-3540 which introduces the EOF format.
Creation transaction and creation instructions CREATE
and CREATE2
are means provided by legacy EVM to deploy new code, but per requirement of removing code observability, they are not allowed to deploy EOF code. To allow Externally Owned Accounts (EOAs) to deploy EOF contracts, there must be a way to create EOF contracts using bytecode delivered in transaction data.
Additionally, the new instruction and transaction type introduced in this EIP enable contracts to create other contracts using initcode from the transaction data, which in legacy EVM is achieved via a combination of CREATE
or CREATE2
and loading the initcode from calldata.
This mechanism complements EOFCREATE
and RETURNCODE
instructions from EIP-7620, and thus all use cases of contract creation that are available in legacy EVM are enabled for EOF.
Since TXCREATE
is not restricted to EOF containers, it also serves the purpose of bootstrapping EOF contracts into the state.
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.
Constant | Value |
---|---|
INITCODE_TX_TYPE |
Bytes1(0x06) |
MAX_INITCODE_COUNT |
256 |
TX_CREATE_COST |
Defined as 32000 in the Ethereum Execution Layer Specs |
STACK_DEPTH_LIMIT |
Defined as 1024 in the Ethereum Execution Layer Specs |
GAS_CODE_DEPOSIT |
Defined as 200 in the Ethereum Execution Layer Specs |
TX_DATA_COST_PER_ZERO |
Defined as 4 in the Ethereum Execution Layer Specs |
TX_DATA_COST_PER_NON_ZERO |
Defined as 16 in the Ethereum Execution Layer Specs |
MAX_CODE_SIZE |
Defined as 24576 in EIP-170 |
MAX_INITCODE_SIZE |
Defined as 2 * MAX_CODE_SIZE in EIP-3860 |
Introduce new transaction InitcodeTransaction
(type INITCODE_TX_TYPE
) which extends EIP-1559 (type 2) transaction by adding a new field initcodes: List[ByteList[MAX_INITCODE_SIZE], MAX_INITCODE_COUNT]
.
The initcodes
can only be accessed via the TXCREATE
instruction (see below), therefore InitcodeTransactions
are intended to be sent to contracts including TXCREATE
in their execution.
initcodes
items data costs the same as calldata: transaction gas of an InitcodeTransaction
is extended to include tokens in initcodes
alongside tokens in calldata
. Using the conventions from EIP-7623, the transaction gas is calculated as:
STANDARD_TOKEN_COST = 4
TOTAL_COST_FLOOR_PER_TOKEN = 10
tokens_in_calldata = zero_bytes_in_calldata + nonzero_bytes_in_calldata * 4
tokens_in_initcodes = 0
for initcode in initcodes:
tokens_in_initcodes += zero_bytes_in_initcode + nonzero_bytes_in_initcode * 4
tx.gasUsed = (
21000
+
max(
STANDARD_TOKEN_COST * (tokens_in_calldata + tokens_in_initcodes)
+ execution_gas_used,
TOTAL_COST_FLOOR_PER_TOKEN * (tokens_in_calldata + tokens_in_initcodes)
)
)
InitcodeTransaction
is invalid if there are zero entries in initcodes
, or if there are more than MAX_INITCODE_COUNT
entries.InitcodeTransaction
is invalid if any entry in initcodes
is zero length, or if any entry exceeds MAX_INITCODE_SIZE
.InitcodeTransaction
is invalid if the to
is nil
.Under transaction validation rules initcodes
are not validated for conforming to the EOF specification. They are only validated when accessed via TXCREATE
. This avoids potential DoS attacks of the mempool. If during the execution of an InitcodeTransaction
no TXCREATE
instruction is called, such transaction is still valid.
Other creation transactions that support contract creation (specifically type 0 "Frontier," type 1 "AccessList," type 2 "FeeMarket" transactions with an empty to
field) will not attempt to parse EOF containers in their input
field and will execute the code as non-EOF code. This will result in immediately executing the undefined 0xEF
instruction and halting.
Given the definitions from EIP-2718 the TransactionPayload
for an InitcodeTransaction
is the RLP serialization of:
[chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, initcodes, y_parity, r, s]
TransactionType
is INITCODE_TX_TYPE
and the signature values y_parity
, r
, and s
are calculated by constructing a secp256k1 signature over the following digest:
keccak256(INITCODE_TX_TYPE || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, initcodes]))
The EIP-2718 ReceiptPayload
for this transaction is rlp([status, cumulative_transaction_gas_used, logs_bloom, logs])
.
Wherever not explicitly listed, the rules of EOF contract creation, as well as the TXCREATE
instruction, should be identical or analogous to those of CREATE2
instruction. This includes but is not limited to:
accessed_addresses
and address collision (EIP-684 and EIP-2929)TXCREATE
initcode - memory, account context etc.value
argument)Introduce a new instruction on the same block number EIP-3540 is activated on: TXCREATE
(0xed
).
TXCREATE
TX_CREATE_COST
gasstatic-mode
.tx_initcode_hash
, salt
, input_offset
, input_size
, value
from the operand stack[input_offset, input_size]
initcodes
array which hashes to tx_initcode_hash
TransactionType
other than INITCODE_TX_TYPE
initcontainer
be that EOF container, and initcontainer_size
its length in bytesSTACK_DEPTH_LIMIT
and that caller balance is enough to transfer value
initcontainer
is additionally required to have data_size
declared in the header equal to actual data_section
size.initcontainer
does not contain RETURN
or STOP
[input_offset:input_size]
is used as calldatasender
account's noncenew_address
as keccak256(0xff || sender32 || salt)[12:]
, where sender32
is the sender address left-padded to 32 bytes with zeros0
onto the stackREVERT
edsender
's nonce stays updatedRETURNCODE{deploy_container_index}(aux_data_offset, aux_data_size)
instruction (see EIP-7620). After that:deploy_container_index
in the container from which RETURNCODE
is executed(aux_data_offset, aux_data_offset + aux_data_size)
memory segment and update data size in the headerMAX_CODE_SIZE
, instruction exceptionally abortsstate[new_address].code
to the updated deploy containernew_address
onto the stackGAS_CODE_DEPOSIT * deployed_code_size
gasNote that the implementations are expected to cache the result of container validation for the time of current transaction execution, and therefore the cost of each container's validation is sufficiently covered by InitcodeTransaction
intrinsic cost (initcodes charge).
TXCREATE
failure modesTXCREATE
has two "light" failure modes in case the initcontainer is not present and in case the EOF validation is unsuccessful. An alternative design where both cases led to a "hard" failure (consuming the entire gas available) was considered. We decided to have the more granular and forgiving failure modes in order to align the gas costs incurred to the actual work the EVM performs.
TXCREATE
in legacy EVMEOF contract creation requires an exceptional possibility of calling an EOF opcode in legacy code - TXCREATE
, because otherwise neither legacy contracts nor create transactions can deploy EOF code to bootstrap. The alternative approach was to continue using legacy creation mechanisms, by either still relying on fetching the initcode from memory and not satisfy the overarching requirement of code non-observability, or to abuse the legacy creation transactions mechanism, or to introduce a predeployed Creator Contract into the state.
This also makes EIP-7698 (EOF - Creation transaction) no longer an essential requirement for deploying EOF contracts onto the chain. The EIP could be removed from EOFv1 and withdrawn.
TXCREATE
uses the scheme new_address = keccak256(0xff || sender32 || salt)[12:]
, same as EOFCREATE
instruction. The decision whether to include initcontainer hash into salt is left to the TXCREATE
caller. See EIP-7620 for detailed rationale.
Relying on the EOF creation transactions as the alternative solution makes it impossible for smart contract wallets to deploy arbitrary EOF contracts (only EOAs can). At the same time, it is a use case current legacy creation rules allow, thanks to CREATE
and CREATE2
instructions. A workaround where those arbitrary EOF contracts are first "uploaded" to a factory contract, and then deployed using an EXTDELEGATECALL
-EOFCREATE
sequence, is very expensive, as it requires the deployed contract to be put on-chain twice. Because of this, the approach proposed in this EIP is more compatible with the Account Abstraction (AA) roadmap, where smart contract wallets should have feature parity with EOAs.
On top of this, relying on nonce-based hashing scheme to obtain addresses of newly created contracts, like in the case of the EOF creation transactions, would prevent EOF contracts from being deployed counterfactually to deterministic, cross-chain addresses. Introduction of the TXCREATE
instruction, supports this out of the box. ERCs can be written to provide toehold contracts which will cater for the deployment patterns, such as salt-less deployment and hashing in the sender's address as part of the salt.
0xEF00
prefixed code in existing transaction types.Three existing transaction types (type 0 "Frontier," type 1 "AccessList," type 2 "FeeMarket") accept code as part of their input data in certain configurations. This code can start with EF
as it is initcode and not a deployed contract.
One possible way of handling potential EOF containers in these transactions is to make them invalid if they are attempting to execute an EOF container as initcode. Specifically the transactions is invalid if the input data begins with 0xef00
and if the to
field is set to nil, signaling a contract creation transaction. This would make blocks containing these transactions invalid, whereas before the fork including this EIP they would have been valid.
One impact that would be seen by this would be block builders, as they would need to ensure that the transactions that are invalid are not included in a block. There is precedent for this, as EIP-7623 established a new floor for the gas limit in transactions, prior to its adoption the limit was lower. However, block builders have an existing check on gas limits and transactions and that change was adjusting the formula and constants.
We should also consider the treatment EIP-7702 delegation designations receive if they show up as code in a contract creation transaction. The transaction is valid, is executed as plain bytecode, ad the first operation executed is 0xEF
, which is an invalid opcode and would cause the whole transaction to abort.
Letting the inputdata of a type 0, 1, and 2 contract creation transaction execute as plain EVM code irrespective of the magic 0xEF00
bytes keeps a consistent behavior in client code and keeps block builders from having to update their logic in older transaction types.
This change poses no risk to backwards compatibility, as it is introduced at the same time EIP-3540 is. Despite the new instruction being introduced for legacy bytecode (code which is not EOF formatted), there is little chance that a meaningful contract would unintentionally execute 0xed
instruction with formally valid operands and inadvertently cause it to run EOF initcode (which would also require an InitcodeTransaction
to be used, otherwise the initcode lookup will fail).
TXCREATE
instruction introduction into legacy EVM does not affect JUMPDEST
analysis, because instruction has no immediate arguments.
The transactions of the new type are invalid until this change activates.
Contract creation options do not change for legacy bytecode, including how existing transactions with to: nil
behave when encountering code in their calldata that may look like an EOF container.
Needs discussion.
Copyright and related rights waived via CC0.