Update RIP-7711: Remove the no-op header transaction type (#42)

* Simplify RIP-7711 by removing the no-op header type

* Change title and description

Author: forshtat

RIPS/rip-7711.md

@@ -1,7 +1,7 @@
 ---
 rip: 7711
-title: An RIP-7560 transactions bundle transaction type
-description: An RIP-7560 compatible transaction type that allows specifying a set of AA transactions that can be atomically validated together
+title: Validation-Execution Separation in Native Account Abstraction
+description: A change in the order of execution of frames of RIP-7560 transactions inside a block that enables efficient block building
 author: Vitalik Buterin (@vbuterin), Yoav Weiss (@yoavw), Alex Forshtat (@forshtat), Dror Tirosh (@drortirosh), Shahaf Nacson (@shahafn)
 discussions-to: https://ethereum-magicians.org/t/rip-7711-an-rip-7560-compatible-transactions-bundle-transaction-type/20093
 status: Draft
@@ -17,7 +17,7 @@ requires: 7560
 This proposal provides block builders with a mechanism to isolate validation from execution for
 a set of RIP-7560 transactions.
 By doing so we simplify the task of filling a block gas space with RIP-7560 transactions and prevent potential
-denial of service attacks against block builders.
+denial-of-service attacks against block builders.
 
 On "single sequencer" Layer 2 chains that do not have a "transaction mempool" in a traditional sense,
 this proposal provides no benefit compared to the original RIP-7560.
@@ -43,61 +43,40 @@ before their respective execution frames.
 
 ## Specification
 
-### Bundle header RIP-7560 transaction type
-
-```
-BUNDLE_HEADER_TYPE = x
-```
-
-Instead, we propose to introduce an explicit "counter" transaction type.
-
-The payload should be interpreted as:
-
-```
-0x04 || 0x01 || rlp([chainId, transactionCount])
-```
-
-Header transactions have a unique hash calculated as follows:
-
-```
-keccak256(AA_TX_TYPE || 0x01 || rlp(chainId, transactionCount, blockNumber, txIndex))
-```
-
-The `transactionCount` is required to be strictly larger than `1`.
-
-The `blockNumber` and `txIndex` parameters are added to the hash to achieve unique header transaction IDs.
-
-The header transactions are only used to help execution clients determine how many of the `AA_TX_TYPE` transactions
-belong to each individual bundle.
-
-The block is not valid if a header transaction is located anywhere except before a set of `AA_TX_TYPE` transactions.
-
-Header transactions do not affect blockchain state and do not cost any gas.
-
 ### Non-atomic validation and execution transaction type
 
 ```
 BUNDLE_TRANSACTION_TYPE = x
 ```
 
 These transactions are completely identical to regular RIP-7560 transactions with the exceptions of being
-composable into bundles.
+composed into "AA transaction bundles".
 
 It is important for the wallets to explicitly opt into this feature by accepting the `BUNDLE_TRANSACTION_TYPE`,
 as some Smart Contract Accounts
 may be created in a way that relies on atomicity between validation and execution phases.
 
-### All validation state changes apply before all execution ones
+### AA transaction bundles
+
+In AA transaction bundles, all validation state changes apply before all execution ones.
 
 Filling a block with AA transactions must not be a challenge for the block builder.
 However, if each transaction during its execution can alter any state that affects the validity of another transaction
 in the mempool, the block builder will be forced to revalidate all transactions in the mempool after each inclusion.
+Transactions of `BUNDLE_TRANSACTION_TYPE` type mitigate the inherent computational complexity of building a block that
+contains `AA_TX_TYPE` transactions.
+
+With `BUNDLE_TRANSACTION_TYPE` transactions, **all** the validation frames
+of an uninterrupted sequence of AA transactions are run first,
+and **all** the execution frames are run immediately after that.
 
-We mitigate that by applying all changes in all the validation frames of a sequence of AA transactions first
-and all execution frames apply immediately after that.
+### Validation code sandboxing
 
-In theory, the validation frames can also invalidate each other, but we define ways to prevent that by applying
-certain rules for the mempool transactions in ERC-7562.
+Even with RIP-7711, validation frames of a `BUNDLE_TRANSACTION_TYPE` transactions bundle can invalidate
+other transactions in the same bundle.
+We define a mechanism to prevent cross-validation dependencies by applying
+certain rules for the mempool transactions which is fully described in [ERC-7562](../eip-7562).
+This is equivalent to the mechanism used by the ERC-4337 UserOperations mempool.
 
 A builder that chooses not to enforce the rules from ERC-7562 **must** take care to re-validate each transaction
 against the mid-block state at the position where it is being included into a block.
@@ -109,8 +88,13 @@ Here is a visual representation of a block that contains multiple Account Abstra
 The validation parts of AA transactions are executed as separate transactions,
 but are not represented as separate transactions in the block data.
 
-![](../assets/rip-7560/block_overview.png)
-*The structure of a block containing multiple Native Account Abstraction Transactions*
+![](../assets/rip-7711/rip_7711_block_overview.png)
+*The structure of a block containing multiple RIP-7711 Native Account Abstraction Transactions*
+
+For comparison, this is the diagram of a similar block using RIP-7560 transactions:
+
+![](../assets/rip-7711/rip_7560_block_overview.png)
+*The structure of a block containing multiple RIP-7560 Transactions*
 
 ### Transaction execution context
 
@@ -169,19 +153,6 @@ many times until a fully utilized block is discovered.
 The effects of allowing transactions to specify unrestricted gas limits is shown on this diagram:
 ![](../assets/rip-7560/unused_gas_attack_overview.png)
 
-### Using a header transaction to carry metadata instead of adding a field to the block payload
-
-While in this particular case there is no execution frame that needs to happen for
-a `BUNDLE_HEADER_TYPE` transaction, in other similar scenarios it is possible we
-will require some execution for a header transaction.
-
-For example, in the upcoming Signature Aggregation RIP, the header transaction contains
-the execution of the aggregated signature verification code.
-
-For consistency with potential future extensions to the RIP-7560 it seems reasonable to
-introduce a transaction type that has zero execution frames.
-In addition, it couldn't be efficiently represented as one field because a block may contain any number of such bundles.
-
 ### Breaking up a transaction flow into non-atomic pieces
 
 While changing the transaction flow is a departure from the norm for Ethereum transactions,
@@ -197,6 +168,11 @@ so there are no expected difficulties with implementing this proposal.
 
 ## Backwards Compatibility
 
+The non-atomic flow of an RIP-7711 transaction requires attention from the Smart Contract Account developers
+to ensure the accounts cannot be left in a broken state between the validation and execution frames.
+
+However, as ERC-4337 has a very similar execution flow for UserOperations, it is a known property of
+Account Abstractions and all existing code is likely to be compatible with RIP-7711 with only some minor modifications.
 
 ## Security Considerations
 
@@ -208,7 +184,7 @@ between validation and execution phases, which is wrong.
 
 The state that exists at the end of the validation frame may be observed or modified by unrelated contracts before
 the execution frame begins.
-`Sender` contracts must take great care in making sure their code does not make any false assumptions.
+Smart Contract Account developers contracts must ensure that their code does not make any false assumptions.
 
 ## Copyright