Creates a new transaction type which executes a package of one or more transactions, while passing status information to subsequent transactions.
Introduce a new transaction type which includes a list of transactions that must be executed serially by clients. Execution information (e.g. success, gas_used, etc.) will be propagated forward to the next transaction.
Onboarding new users to Ethereum has been notoriously difficult due to the need for new users to acquire enough ether to pay for their transactions. This hurdle has seen a significant allocation of resources over the years to solve. Today, that solution is meta-transactions. This is, unfortunately, a brittle solution that requires signatures to be recovered within a smart contract to authenticate the message. This EIP aims to provide a flexible framework for relayers to "sponsor" many transactions at once, trustlessly.
Meta-transactions often use relay contracts to maintain nonces and allow users to pay for gas using alternative assets. They have historically been designed to catch reversions in their inner transactions by only passing a portion of the available gas to the subcall. This allows them to be certain the outer call will have enough gas to complete any required account, like processing a gas payment. This type of subcall has been considered bad practice for a long time, but in the case of where you don't trust the subcalls, 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.
An important byproduct of this EIP is that it also facilitates bundling transactions for single users.
Introduce a new EIP-2718 transaction type where id = 2.
keccak256(rlp([2, chain_id, children, nonce, gas_price, v, r, s])
keccak256(rlp([2, chain_id, children, nonce, gas_price])
Each ChildTransaction transaction will generate a ChildReceipt after execution. Each
of these receipts will be aggregated into a Receipt.
Let ChildPackage be interpreted as follows.
The type field is used to denote whether the Child signer wishes to
delegate the max_gas_price and gas_limit choice to the TransactionPackage
signer.
| type | signature hash |
|---|---|
0x00 | keccak256(rlp([0, nonce, transactions, max_gas_price]) |
0x01 | keccak256(rlp([1, nonce, transactions_without_gas_limit]) |
A TransactionPackage can be deemed valid or invalid as follows.
Subsequent ChildTransactions will be able to receive the result of the
previous ChildTransaction via RETURNDATACOPY (0x3E) in first frame of
execution, before making any subcalls. Each element, except the last, will be
0-padded left to 32 bytes.
Let the intrinsic cost of the transaction package be defined as follows:
Transaction packages should be executed as follows:
8.Result for the previously executed transaction.Result to be available via return opcodes in the next
transaction's first frame.3.7.Child has its own signatureFor simplicity, the author has chosen to require each child package to specify its own signature, even if the signer is the same as the package signer. This choice is made to allow for maximum flexibility, with minimal client changes. This transaction can still be used by a single user at the cost of only one additional signature recovery.
ChildPackage specifies max_gas_price instead of gas_priceAllowing child packages to specify a range of acceptable gas prices is strictly more versatile than a static price. It gives relayers more flexibility in terms of building transaction bundles, and it makes it possible for relayers to try and achieve the best price for the transaction sender. With a fixed price, the relayer may require the user to sign multiple different transactions, with varying prices. This can be avoided by specifying a max price, and communicating out-of-band how the urgency of the transaction (e.g. the relayer should package it with the max price immediately vs. slowly increasing the gas price). A future transaction type can be specified with only a single signature, if such an optimization is desired.
ChildPackage is also typedThe type element serves a modest role in the transaction type, denoting whether the transaction signer wishes to delegate control of the gas price and gas limit to the outer signer. This is a useful UX improvement when interacting with a trusted relayer, as once the user decides to make a transaction the relayer can ensure it is included on chain by choosing the best gas price and limit.
flags and extra fields aren't usedThese fields are included to better support future changes to the transaction
type. This would likely be used in conjunction with the flags and type
fields. A benefit of explicitly defining them is that specialized serialization
of RLP can be avoided, simplifying clients and downstream infrastructure. The
author believe the cost of 2 bytes per transaction is acceptable for smoother
integration of future features.
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
check.
TBD
TBD
The introduction of a new transaction type brings along new concerns regarding the mempool. Done naively, it could turn into a DDoS vector for clients. This EIP has been written to reduce as much validation complexity as possible.
An existing invariant in the mempool that is desirable for new transactions to maintain, is that transactions can be validated in constant time. This is also possible for packaged transactions. There is an inherent 10Mb limit for RLPx frames, so that would be the upper bound on transactions that could be included in a package. On the other hand, clients can also just configure their own bound locally (e.g. packages must be less than 1Mb). Validity can then be determined by using the function above.
Once a package has been validated, it must continuously be monitored for nonce invalidations within its package. One potential way to achieve this efficiently is to modify the mempool to operate on thin pointers to the underlying transaction. This will allow packages to ingest as many "single" transactions, simplifying the facilities for monitoring changes. These "parts" of the package can maintain a pointer to a structure with pointers to all the parts of the package. This way, as soon as one part becomes invalid, it can request the parent to invalidate all outstanding parts of the package.
Copyright and related rights waived via CC0.