Creates a new transaction type which executes a package of one or more transactions, while passing status information to subsequent transactions.
FORK_BLOCK, a new EIP-2718
transaction of type
N is recognized. Transactions of type
N will define a
list of transactions, which must be executed serially by clients. Execution
gas_used, etc.) will be propagated forward to
the next transaction.
Meta-transaction relay contracts have historically been designed to catch reversions in their inner transactions by only passing a portion of the available gas to the subcall. This has been considered bad practice for a long time, but in the case of untrusted subcalls, like the ones relay contracts make, it is the only available solution. Transaction packages are an alternative that allow multiple transactions to be bundled into one package and executed atomically, similarly to how relay contracts operate. Transactions are able to pass their result to subsequent transactions. This allows for conditional workflows based on the outcome of previous transactions. Although this functionality is already possible as described above, workflows using transaction packages are more robust, because they are protected from future changes to the gas schedule.
N = TBD transaction type number INTRINSIC_COST = TBD TOTAL_COST = INTRINSIC_COST + inner_txs.reduce(|itx, acc| acc += itx.value + tx.gas_price * itx.gas_limit) TOTAL_GAS_LIMIT = inner_txs.reduce(|itx, acc| acc += itx.gas_limit) TX_HASH = hash of transaction as defined below SENDER = ecrecover(hash, v, r, s) RESULT = result as defined below for the previous transaction, empty if its the first tx in a package
FORK_BLOCK, a new EIP-2718
N will be interpreted as follows:
rlp([N, [v, r, s, chain_id, nonce, gas_price, [inner_tx_0, ..., inner_tx_n]])
inner_tx_n is defined as:
[to, value, data, gas_limit]
The hash of transaction type
N is defined to be the Keccak-256 hash of the
rlp encoding of the entire transaction with
s values set to
Subsequent transactions will be able to receive the result of the previous
RETURNDATACOPY (0x3E) in first frame of exeuction, before
making any subcalls. Each element, except the last, will be
0-padded left to
||bool||Status of the previous transaction|
||uint256||Total gas used by the previous transaction|
||uint256||Cumulative gas used by previous transactions|
||uint256||The size of the return value|
||bytes||The return value of the previous transaction|
- (v, r, s) are a valid signature of the hash of the transaction
- The nonce is one greater than recovered address’ current nonce
- The recovered address has a balance of at least
TOTAL_GAS_LIMITis less than the current block’s
Transaction packages should be executed as follows:
- Execute the first inner transaction in the list
- Refund any unused
- Record all state changes, logs, and the receipt
- If there are no more transaction, stop
RESULTfor the previously executed transaction
RESULTto be available via return opcodes in the next transaction’s first frame
- Execute the next transaction
Non-recursive inner transactions
For simplicity, inner transactions are fully defined within this EIP. However, there is value in supporting recursive transaction definitions. For example, suppose there is a transaction type which can become invalid after a certain block number. It would be beneficial to support those types of transactions within a package, but the complexity of this EIP would dramatically increase.
Appending result data to transaction input data
An alternative to using return opcodes to propagate
RESULT would be to append
RESULT to the subsequent transaction’s
data field. Unfortunately, in
many cases contracts generated using Solidity will
to resolve the intended function if additional data is present.
Contracts which rely on
ORIGIN (0x32) == CALLER (0x33) && RETURNDATASIZE
(0x3D) == 0x00 will now always fail in transaction packages, unless they are
the first executed transaction. It’s unknown if any contracts conduct this
Copyright and related rights waived via CC0.
Please cite this document as:
Matt Garnett, "EIP-2733: Transaction package [DRAFT]," Ethereum Improvement Proposals, no. 2733, June 2020. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-2733.