From dc6bf95768393f8910a8d7a5b0efc05db0c1d466 Mon Sep 17 00:00:00 2001 From: Lily Johnson Date: Mon, 24 Jun 2024 09:04:56 +0200 Subject: [PATCH 01/13] First commit --- EIPS/eip-transaction-bundles.md | 229 ++++++++++++++++++++++++++++++++ 1 file changed, 229 insertions(+) create mode 100644 EIPS/eip-transaction-bundles.md diff --git a/EIPS/eip-transaction-bundles.md b/EIPS/eip-transaction-bundles.md new file mode 100644 index 0000000000000..35b4d19144724 --- /dev/null +++ b/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 From f4c71644ad94dcd574562bfcd5e6fed051602265 Mon Sep 17 00:00:00 2001 From: Lily Johnson Date: Mon, 24 Jun 2024 09:13:12 +0200 Subject: [PATCH 02/13] lints --- EIPS/eip-transaction-bundles.md | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/EIPS/eip-transaction-bundles.md b/EIPS/eip-transaction-bundles.md index 35b4d19144724..ac99fdf847918 100644 --- a/EIPS/eip-transaction-bundles.md +++ b/EIPS/eip-transaction-bundles.md @@ -2,16 +2,17 @@ title: EVM Transaction Bundles description: Enable EVM support for transaction bundles without revert protections. author: Lily Johnson (@lilyjjo) +discussions-to: https://ethereum-magicians.org/t/eip-for-evm-native-bundles/20322 status: Draft -type: Standards +type: Standards Track category: Core created: 2024-06-24 -requires: EIP-2781 +requires: 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. +This EIP introduces two new [EIP-2718](./eip-2718.md) 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: @@ -41,7 +42,7 @@ Currently, a single block builder has unrestricted control over the final sequen ### 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`. +Two new [EIP-2718](./eip-2718.md) 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: @@ -151,7 +152,7 @@ The `DELEGATED_TX_TYPE` follows typical gas costing rules. ### 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: +For `DELEGATED_TX_TYPE` transaction that are able to begin execution, their [EIP-2718](./eip-2718.md) receipt payload should be interpreted as: ```go rlp([status, cumulativeGasUsed, logsBloom, logs]) @@ -159,7 +160,7 @@ 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: +The `BUNDLE_TX_TYPE` transaction’s [EIP-2718](./eip-2718.md) receipt payload should be interpreted as: ```go rlp([statusArray, cumulativeGasUsed]) @@ -224,6 +225,4 @@ Similarly, smart contracts that restrict functionality to transactions signed by Copyright and related rights waived via CC0. -## Citation -TBD From 515eeb1fd8b4727d3695921c8f689cb0c82b1bad Mon Sep 17 00:00:00 2001 From: Lily Johnson Date: Mon, 24 Jun 2024 09:16:46 +0200 Subject: [PATCH 03/13] lints --- EIPS/eip-transaction-bundles.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-transaction-bundles.md b/EIPS/eip-transaction-bundles.md index ac99fdf847918..c155eb809da0a 100644 --- a/EIPS/eip-transaction-bundles.md +++ b/EIPS/eip-transaction-bundles.md @@ -1,13 +1,14 @@ --- +eip: title: EVM Transaction Bundles description: Enable EVM support for transaction bundles without revert protections. author: Lily Johnson (@lilyjjo) -discussions-to: https://ethereum-magicians.org/t/eip-for-evm-native-bundles/20322 +discussions-to: https://ethereum-magicians.org/t/eip-for-evm-native-bundles/20322 status: Draft type: Standards Track category: Core created: 2024-06-24 -requires: 2781 +requires: 2718 --- ## Abstract From 56818da60db7fd0392566fe51c15c13f4d77445b Mon Sep 17 00:00:00 2001 From: Lily Johnson Date: Tue, 25 Jun 2024 14:28:50 +0200 Subject: [PATCH 04/13] add eip number and update discussion link --- EIPS/eip-transaction-bundles.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-transaction-bundles.md b/EIPS/eip-transaction-bundles.md index c155eb809da0a..325656ddef1a7 100644 --- a/EIPS/eip-transaction-bundles.md +++ b/EIPS/eip-transaction-bundles.md @@ -1,9 +1,9 @@ --- -eip: +eip: 7727 title: EVM Transaction Bundles description: Enable EVM support for transaction bundles without revert protections. author: Lily Johnson (@lilyjjo) -discussions-to: https://ethereum-magicians.org/t/eip-for-evm-native-bundles/20322 +discussions-to: https://ethereum-magicians.org/t/eip-7727-evm-transaction-bundles/20322 status: Draft type: Standards Track category: Core From cd3c9e3f2f385e66fa531c84a878a1bb7766d700 Mon Sep 17 00:00:00 2001 From: Lily Johnson Date: Tue, 25 Jun 2024 14:30:07 +0200 Subject: [PATCH 05/13] remove unnecessary field from BUNDLE_TX_TYPE payload --- EIPS/eip-transaction-bundles.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/EIPS/eip-transaction-bundles.md b/EIPS/eip-transaction-bundles.md index 325656ddef1a7..f2c4882e69e27 100644 --- a/EIPS/eip-transaction-bundles.md +++ b/EIPS/eip-transaction-bundles.md @@ -79,7 +79,6 @@ For the `BUNDLE_TX_TYPE`, the transaction payload should be interpreted as: chainId, nonce, gasPrice, - gasLimit, transactionList signatureYParity, signatureR, @@ -102,7 +101,7 @@ An example would of the `transactionList` would be: 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])) +keccak256(0x06 || rlp([bundleSigner, blockNumber, chainId, nonce, gasPrice, transactionList])) ``` We’ll refer to address resolved by this signature the bundle transaction’s signer. From 52c463e333bee319c85aa0e88776d747abe0ab87 Mon Sep 17 00:00:00 2001 From: Lily Johnson Date: Tue, 25 Jun 2024 14:35:47 +0200 Subject: [PATCH 06/13] rename file --- EIPS/{eip-transaction-bundles.md => eip-7727.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename EIPS/{eip-transaction-bundles.md => eip-7727.md} (100%) diff --git a/EIPS/eip-transaction-bundles.md b/EIPS/eip-7727.md similarity index 100% rename from EIPS/eip-transaction-bundles.md rename to EIPS/eip-7727.md From c8bb2b308899a78ef1f44504d926ad1b9d72ccda Mon Sep 17 00:00:00 2001 From: Lily Johnson Date: Tue, 25 Jun 2024 14:38:50 +0200 Subject: [PATCH 07/13] fix spacing --- EIPS/eip-7727.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7727.md b/EIPS/eip-7727.md index f2c4882e69e27..644f58cf67e8b 100644 --- a/EIPS/eip-7727.md +++ b/EIPS/eip-7727.md @@ -132,7 +132,7 @@ For a `BUNDLE_TX_TYPE` to be valid, the following MUST be true: 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`. +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: From aa6065c162c48227fc52b314921da993d704a6c6 Mon Sep 17 00:00:00 2001 From: Lily Johnson Date: Thu, 27 Jun 2024 09:11:28 +0200 Subject: [PATCH 08/13] addressed comments from @SamWilsn --- EIPS/eip-7727.md | 21 +++++---------------- 1 file changed, 5 insertions(+), 16 deletions(-) diff --git a/EIPS/eip-7727.md b/EIPS/eip-7727.md index 644f58cf67e8b..7e55a109d52a8 100644 --- a/EIPS/eip-7727.md +++ b/EIPS/eip-7727.md @@ -1,7 +1,7 @@ --- eip: 7727 title: EVM Transaction Bundles -description: Enable EVM support for transaction bundles without revert protections. +description: Enable meta transactions to order other transactions without revert protections. author: Lily Johnson (@lilyjjo) discussions-to: https://ethereum-magicians.org/t/eip-7727-evm-transaction-bundles/20322 status: Draft @@ -13,14 +13,14 @@ requires: 2718 ## Abstract -This EIP introduces two new [EIP-2718](./eip-2718.md) 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. +This EIP introduces two new [EIP-2718](./eip-2718.md) 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 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 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. @@ -38,7 +38,6 @@ Currently, a single block builder has unrestricted control over the final sequen | 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 @@ -112,7 +111,7 @@ The `BUNDLE_SIGNER` is a new opcode, added in `FORK_BLOCK`, identified by `BUNDL 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`. +The gas cost for this opcode is `GAS_VERY_LOW` gas constant. ### Transaction Validity Rules @@ -207,14 +206,6 @@ These choices were made to prevent DoS attacks on builders and to be compatible 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. @@ -223,6 +214,4 @@ Similarly, smart contracts that restrict functionality to transactions signed by ## Copyright -Copyright and related rights waived via CC0. - - +Copyright and related rights waived via [CC0](../LICENSE.md). From 6954e774dfdbc973d9f5f254e44e6666f26f326a Mon Sep 17 00:00:00 2001 From: Lily Johnson Date: Thu, 27 Jun 2024 09:12:55 +0200 Subject: [PATCH 09/13] nit --- EIPS/eip-7727.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7727.md b/EIPS/eip-7727.md index 7e55a109d52a8..c4142fd954795 100644 --- a/EIPS/eip-7727.md +++ b/EIPS/eip-7727.md @@ -13,7 +13,7 @@ requires: 2718 ## Abstract -This EIP introduces two new [EIP-2718](./eip-2718.md) 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 Proposer-Builder Separation (PBS) bundles offered by builders to searchers. +This EIP introduces two new [EIP-2718](./eip-2718.md) 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: From 8b32a004fcf978d121da1398deca2c7392b2211a Mon Sep 17 00:00:00 2001 From: Lily Johnson Date: Mon, 8 Jul 2024 14:27:37 +0200 Subject: [PATCH 10/13] addressed more comments --- EIPS/eip-7727.md | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/EIPS/eip-7727.md b/EIPS/eip-7727.md index c4142fd954795..210eb99965830 100644 --- a/EIPS/eip-7727.md +++ b/EIPS/eip-7727.md @@ -34,7 +34,6 @@ Currently, a single block builder has unrestricted control over the final sequen | Name | Value | | --- | --- | -| FORK_BLOCK | TBD | | DELEGATED_TX_TYPE | 0x05 | | BUNDLE_TX_TYPE | 0x06 | | BUNDLE_BASE_GAS_COST | TBD | @@ -48,8 +47,8 @@ For the `DELEGATED_TX_TYPE`, the transaction payload should be interpreted as: ```go 0x05 || rlp([ - bundleSigner, - blockNumber, + bundleSigner, + blockNumber, chainId, nonce, gasPrice, @@ -73,8 +72,8 @@ For the `BUNDLE_TX_TYPE`, the transaction payload should be interpreted as: ```go 0x06 || rlp([ - bundleSigner, - blockNumber, + bundleSigner, + blockNumber, chainId, nonce, gasPrice, @@ -129,17 +128,19 @@ For a `BUNDLE_TX_TYPE` to be valid, the following MUST be true: ### 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: +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. -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`. +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 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: +The formula is calculated as follows: -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`. +```go +BUNDLE_BASE_GAS_COST + + (CALL_DATA_TOKEN_COST * transaction_list_invalid_tx_byte_length) + +``` -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. +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. From 424af9e03b3f5f42bdf618b3b9151571bb63f782 Mon Sep 17 00:00:00 2001 From: Lily Johnson Date: Mon, 8 Jul 2024 15:42:46 +0200 Subject: [PATCH 11/13] nits --- EIPS/eip-7727.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-7727.md b/EIPS/eip-7727.md index 210eb99965830..99b516bd83926 100644 --- a/EIPS/eip-7727.md +++ b/EIPS/eip-7727.md @@ -41,7 +41,7 @@ Currently, a single block builder has unrestricted control over the final sequen ### New Transaction Payload Types -Two new [EIP-2718](./eip-2718.md) transactions with types `DELEGATED_TX_TYPE` and `BUNDLE_TX_TYPE` are introduced at `FORK_BLOCK`. +Two new [EIP-2718](./eip-2718.md) transactions with types `DELEGATED_TX_TYPE` and `BUNDLE_TX_TYPE`. For the `DELEGATED_TX_TYPE`, the transaction payload should be interpreted as: @@ -106,7 +106,7 @@ We’ll refer to address resolved by this signature the bundle transaction’s s ### `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. +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. From cbc3357b5b2b4ebc2bfb24d2dbf79654d0f9f528 Mon Sep 17 00:00:00 2001 From: Lily Johnson Date: Mon, 8 Jul 2024 15:51:01 +0200 Subject: [PATCH 12/13] nits --- EIPS/eip-7727.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-7727.md b/EIPS/eip-7727.md index 99b516bd83926..af68a09d7e1f6 100644 --- a/EIPS/eip-7727.md +++ b/EIPS/eip-7727.md @@ -110,7 +110,7 @@ The `BUNDLE_SIGNER` is a new opcode identified by `BUNDLE_SIGNER_OPCODE_NUMBER` 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 `GAS_VERY_LOW` gas constant. +The gas cost for this opcode is the `GAS_VERY_LOW` gas constant. ### Transaction Validity Rules @@ -174,7 +174,7 @@ The `cumulateGasUsed` is the amount of gas spent by the `BUNDLE_TX_TYPE`'s signe ### 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. +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 From 89f54114a56f8d23e238344e5a919e575e01a539 Mon Sep 17 00:00:00 2001 From: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> Date: Tue, 9 Jul 2024 10:37:58 -0400 Subject: [PATCH 13/13] Update eip-7727.md --- EIPS/eip-7727.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-7727.md b/EIPS/eip-7727.md index af68a09d7e1f6..43c8d0ec291e5 100644 --- a/EIPS/eip-7727.md +++ b/EIPS/eip-7727.md @@ -36,8 +36,8 @@ Currently, a single block builder has unrestricted control over the final sequen | --- | --- | | DELEGATED_TX_TYPE | 0x05 | | BUNDLE_TX_TYPE | 0x06 | -| BUNDLE_BASE_GAS_COST | TBD | -| BUNDLE_SIGNER_OPCODE_NUMBER | TBD | +| BUNDLE_BASE_GAS_COST | TBD | +| BUNDLE_SIGNER_OPCODE_NUMBER | TBD | ### New Transaction Payload Types