First commit

EIPS/eip-transaction-bundles.md

@@ -0,0 +1,229 @@
+---
+title: EVM Transaction Bundles
+description: Enable EVM support for transaction bundles without revert protections.
+author: Lily Johnson (@lilyjjo)
+status: Draft
+type: Standards
+category: Core
+created: 2024-06-24
+requires: EIP-2781
+---
+
+## Abstract
+
+This EIP introduces two new [EIP-2718](https://eips.ethereum.org/EIPS/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 but weaker than the 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 |
+| --- | --- |
+| FORK_BLOCK | TBD |
+| DELEGATED_TX_TYPE | 0x05 |
+| BUNDLE_TX_TYPE | 0x06 |
+| BUNDLE_BASE_GAS_COST | TBD |
+| BUNDLE_SIGNER_OPCODE_COST | TBD |
+| BUNDLE_SIGNER_OPCODE_NUMBER | TBD |
+
+### New Transaction Payload Types
+
+Two new [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) transactions with types `DELEGATED_TX_TYPE` and `BUNDLE_TX_TYPE` are introduced at `FORK_BLOCK`.
+
+For the `DELEGATED_TX_TYPE`, the transaction payload should be interpreted as:
+
+```go
+0x05 || rlp([
+  bundleSigner,
+  blockNumber,
+	chainId, 
+	nonce, 
+	gasPrice, 
+	gasLimit, 
+	to, 
+	value, 
+	data, 
+	signatureYParity, 
+	signatureR, 
+	signatureS
+])
+```
+
+The `signatureYParity`, `signatureR`, `signatureS` elements of the `DELEGATED_TX_TYPE` represent a secp256k1 signature over:
+
+```go
+keccak256(0x05 || rlp([bundleSigner, blockNumber, chain_id, nonce, gasPrice, gasLimit, to, value, data]))
+```
+
+For the `BUNDLE_TX_TYPE`, the transaction payload should be interpreted as:
+
+```go
+0x06 || rlp([
+  bundleSigner,
+  blockNumber,
+	chainId, 
+	nonce, 
+	gasPrice, 
+	gasLimit, 
+	transactionList
+	signatureYParity, 
+	signatureR, 
+	signatureS
+])
+```
+
+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:
+
+```go
+[
+	DELEGATED_TX_TYPE.payload, 
+	BUNDLE_TX_TYPE.payload, 
+	DELEGATED_TX_TYPE.payload
+]
+```
+
+The `signatureYParity`, `signatureR`, `signatureS` elements of the `BUNDLE_TX_TYPE` represent a secp256k1 signature over:
+
+```go
+keccak256(0x06 || rlp([bundleSigner, blockNumber, chainId, nonce, gasPrice, gasLimit, transactionList]))
+```
+
+We’ll refer to address resolved by this signature the bundle transaction’s signer. 
+
+### `BUNDLE_SIGNER` Opcode
+
+The `BUNDLE_SIGNER` is a new opcode, added in `FORK_BLOCK`, identified by `BUNDLE_SIGNER_OPCODE_NUMBER` and 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 `BUNDLE_SIGNER_OPCODE_COST`.
+
+### 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. For the `BUNDLE_TX_TYPE` to be valid, it must have enough gas to cover:
+
+1.  The `BUNDLE_TX_TYPE` transaction base cost of `BUNDLE_BASE_GAS_COST`.
+2. All bytes of the `transactionList` elements as if their bytes were part of a typical transaction’s `CALL_DATA`.
+
+The final gas cost of the `BUNDLE_TX_TYPE` depends on if the `transactionList`'s elements are valid transactions or not. The following logic is used on the `transactionList` elements:
+
+1. If an element is valid and can begin execution, the `BUNDLE_TX_TYPE` signer is not charged for that element’s bytes.
+2. If the element is not valid and cannot being execution, the `BUNDLE_TX_TYPE` is charged as if that element’s bytes were just `CALL_DATA`.
+
+At the start of processing, the `BUNDLE_TX_TYPE`'s signer must be charged as if all inner transactions were invalid and 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. The`BUNDLE_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](https://eips.ethereum.org/EIPS/eip-2718) receipt payload should be interpreted as:
+
+```go
+rlp([status, cumulativeGasUsed, logsBloom, logs])
+```
+
+`DELEGATED_TX_TYPE` transactions that are invalid do not get transaction receipts.
+
+The `BUNDLE_TX_TYPE` transaction’s  [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) receipt payload should be interpreted as:
+
+```go
+rlp([statusArray, cumulativeGasUsed])
+```
+
+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`
+
+Understanding 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:
+
+1. There is no revert protection. 
+2. 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.
+
+## Test Cases
+
+TBD
+
+## Reference Implementation
+
+TBD
+
+## 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.
+
+## Copyright
+
+Copyright and related rights waived via CC0.
+
+## Citation
+
+TBD