EIP-7727: EVM Transaction Bundles

Enable meta transactions to order other transactions without revert protections.

Metadata

Status: DraftStandards Track: CoreCreated: 2024-06-24

Authors

Lily Johnson (@lilyjjo)

Requires

EIP-2718

Links

GitHub page Discussion on Ethereum Magicians

Abstract

This EIP introduces two new EIP-2718 transaction types and one new opcode, enabling smart contracts and transactions to delegate their local sequencing rights to an off-chain entity. These new transaction types work together to create EVM-native 'bundles', which are similar to but weaker than the Proposer-Builder Separation (PBS) bundles offered by builders to searchers.

One of the EIP-2718 transactions is an extended normal transaction that supports:

Specifying the entity who can place the transaction in a bundle.
An optional block number that the transaction is valid in.

The other EIP-2718 transaction is a 'meta' transaction that does not enter into execution, but rather orders transactions of its own type and the other new type. The 'meta' transaction can also specify an entity allowed to include it in a bundle and a valid block number.

The new opcode reveals to the EVM the entity that placed the transaction in a bundle if the transaction was in a bundle.

Motivation

Currently, a single block builder has unrestricted control over the final sequencing of a block’s transactions. This poses a problem, as sequencing—the choice of who gets to interact with specific pieces of state and in what order—significantly influences value flow. The objective of this EIP is to allow more parties to participate in the construction of single blocks by exposing sequencing concepts inside of the EVM. This change would enable EVM applications to reclaim some of the sequencing value that is currently monopolized by block builders, redirecting it back to the applications themselves.

Specification

Constants

Name	Value
DELEGATED_TX_TYPE	0x05
BUNDLE_TX_TYPE	0x06
BUNDLE_BASE_GAS_COST	TBD
BUNDLE_SIGNER_OPCODE_NUMBER	TBD

New Transaction Payload Types

Two new EIP-2718 transactions with types DELEGATED_TX_TYPE and BUNDLE_TX_TYPE.

For the DELEGATED_TX_TYPE, the transaction payload should be interpreted as:

The signatureYParity, signatureR, signatureS elements of the DELEGATED_TX_TYPE represent a secp256k1 signature over:

For the BUNDLE_TX_TYPE, the transaction payload should be interpreted as:

Where the transactionList element is a list of syntactically valid transactions of either type DELEGATED_TX_TYPE or BUNDLE_TX_TYPE. At least one transaction must be in the list.

An example would of the transactionList would be:

The signatureYParity, signatureR, signatureS elements of the BUNDLE_TX_TYPE represent a secp256k1 signature over:

We’ll refer to address resolved by this signature the bundle transaction’s signer.

`BUNDLE_SIGNER` Opcode

The BUNDLE_SIGNER is a new opcode identified by BUNDLE_SIGNER_OPCODE_NUMBER that requires zero stack arguments.

When the transaction type is DELEGATED_TX_TYPE, this opcode pushes the bundleSigner from the transaction payload onto the stack as an address. If the transaction is of a different type, it returns the zero address.

The gas cost for this opcode is the GAS_VERY_LOW gas constant.

Transaction Validity Rules

For a DELEGATED_TX_TYPE to be valid, the following must be true:

The transaction must be included in a BUNDLE_TX_TYPE's transactionList to be valid.
The transaction’s specified bundleSigner must be equal to the address who signed over the BUNDLE_TX_TYPE that included the transaction in a transactionList.
The payload variable blockNumber, if not zero, must be the block number that the transaction is executed in.

For a BUNDLE_TX_TYPE to be valid, the following MUST be true:

All transactions in the transactionList must specify the signer of the BUNDLE_TX_TYPE as the bundleSigner.
The transaction must be included in a BUNDLE_TX_TYPE's transactionList if the bundleSigner payload variable is not the zero address.
The payload variable blockNumber, if not zero, must be the block number that the transaction is executed in.

Gas Costs

The BUNDLE_TX_TYPE has a new gas cost formula that changes based on whether the transactions in the transactionList are valid at the time of execution.

If a transaction in the transactionList is invalid, the BUNDLE_TX_TYPE transaction is charged as if the invalid transaction's bytes were part of a typical transaction's CALL_DATA. If an inner transaction is valid, there is no cost for its inclusion in the list.

The formula is calculated as follows:

At the start of processing, the BUNDLE_TX_TYPE's signer is charged as if all inner transactions were invalid and is refunded the gas for the valid transactions as each valid transaction finishes execution.

The DELEGATED_TX_TYPE follows typical gas costing rules.

Execution

DELEGATED_TX_TYPE execute normally with the BUNDLE_SIGNER opcode returning the bundleSigner payload variable.

BUNDLE_TX_TYPE do not start execution contexts. TheBUNDLE_TX_TYPE's NONCE must be incremented before the start of any transactionList execution.

ReceiptPayload Definitions

For DELEGATED_TX_TYPE transaction that are able to begin execution, their EIP-2718 receipt payload should be interpreted as:

DELEGATED_TX_TYPE transactions that are invalid do not get transaction receipts.

The BUNDLE_TX_TYPE transaction’s EIP-2718 receipt payload should be interpreted as:

Where the statusArray is a list of status results for the inner transactionList's transactions. The list must be the same length as the transactionList and report the statuses in the same order. The status type 0x3 should be used to report invalid transactions.

The cumulateGasUsed is the amount of gas spent by the BUNDLE_TX_TYPE's signer on the BUNDLE_TX_TYPE transaction costs post CALLDATA refund.

Rationale

Allowing invalid transactions to be included in a `BUNDLE_TX_TYPE`'s `transactionList`

Knowing how a transaction will execute is challenging without knowing the state root to which the transaction is applied. Creators of BUNDLE_TX_TYPE transactions can only access the previous block’s state root and cannot predict which transactions will precede the BUNDLE_TX_TYPE transaction in the upcoming block's total order. If only valid transactions were permitted, BUNDLE_TX_TYPE transaction lists could be easily invalidated by a single inner transaction attempting to grief the bundle through nonce or gas invalidations.

Charging the `BUNDLE_TX_TYPE`'s signer `CALLDATA` gas costs for invalid transactions

Blockchains must charge for the work that nodes perform to prevent DoS attacks. Even though invalid transactions in BUNDLE_TX_TYPE transaction lists do not execute, they still occupy block space as bytes and must be paid for by some entity. It is assumed that BUNDLE_TX_TYPE creators will be sophisticated entities capable of simulating the previous block’s state with relative accuracy and able to generate enough profit to offset any invalidation costs incurred.

The BUNDLE_BASE_GAS_COST should be set to make the cost of attempting to grief the BUNDLE_TX_TYPE signer more expensive than the cost of the bytes to cover the invalid transaction.

Requiring `DELEGATED_TX_TYPE` typed transactions to be included in a `BUNDLE_TX_TYPE`'s `transactionList`

If DELEGATED_TX_TYPE transactions were able to be executed outside of a BUNDLE_TX_TYPE transaction list, then there would be competition between the BUNDLE_TX_TYPE signer and the total block builder for the right to choose how to locally sequence the transaction. If the DELEGATED_TX_TYPE transaction signer wished to allow the total block builder to choose the local ordering, then the DELEGATED_TX_TYPE transaction type should not be used.

The same principle applies to BUNDLE_TX_TYPE transactions. Those that specify a bundleSigner must only be included in a BUNDLE_TX_TYPE list, while those that do not specify a bundleSigner must not be included in such a list.

Not allowing other transactions types to be included in a `BUNDLE_TX_TYPE`'s `transactionList`

This restriction was implemented as a precautionary measure and could be reconsidered in the future. Allowing the inclusion of other transaction types that do not specify a bundleSigner into the transactionList could result in multiple searchers attempting to include the same transaction in a bundle. This could potentially create spam within a block.

Differences from PBS Searcher Bundles

PBS block builders currently offer 'bundles' as a service to searchers in the form of transaction lists that either all execute without reversion or are not included in a block. Searchers typically use these bundles to bid for the right to be the first to interact with a piece of state or to place logic before or after transactions created by non-searcher entities, with back-running and sandwiching being examples. PBS block builders provide this service as a way to gain order flow and increase their block's value.

The BUNDLE_TX_TYPE transaction differ in two key ways:

There is no revert protection.
Only transactions explicitly delegating to a bundleSigner can be bundled.

These choices were made to prevent DoS attacks on builders and to be compatible with non-PBS block builders running other algorithms.

Backwards Compatibility

No backward compatibility issues found.

Security Considerations

Block builders are problematic today partly due to their ability to perform censorship and enforce malicious orderings. These concerns persist even when sequencing rights are delegated to a specific entity. The code that generates the off-chain ordering should be public and executed in a trust-minimized manner, such as in a TEE (Trusted Execution Environment) or on a blockchain with faster block times.

Similarly, smart contracts that restrict functionality to transactions signed by a specific BUNDLE_SIGNER should provide mechanisms for users to withdraw funds without relying on the delegated sequencing entity to be online or non-malicious. A two-step fund removal process could be implemented to allow safe interaction with bundle construction and simulation logic.