Update EIP-7701: EIP-7701 update

Merged by EIP-Bot.

EIPS/eip-7701.md

@@ -37,16 +37,30 @@ often lead to unnecessary technical debt and are worth avoiding if possible.
 Additionally, method selectors provide very weak indication of the contract developer's decision to become a
 participant in Native Account Abstraction transaction flow.
 The chance of accidentally exposing a function with a colliding 4 byte
-method identifier that returns a valid 4 byte magic to indicate approval is pretty low, but a malicious developer
+method identifier is pretty low, but a malicious developer
 can easily hide such a function giving it an innocent name, making it hard to spot a Native Account Abstraction entity.
 
 This issue to some extent is also present in [ERC-4337](./eip-4337.md).
 
-As an alternative, if Native Account Abstraction is to be implemented in coordination with [EIP-3540](./eip-3540),
-relying on the concept of "code sections" it introduces is a superior approach.
+As an alternative, Native Account Abstraction can be implemented in coordination with [EIP-3540](./eip-3540).
+Relying on the concept of "code sections" introduced with EIP-3540 appears to be a superior approach.
 
 ## Specification
 
+### Constants
+
+| Name       | Value |
+|------------|-------|
+| AA_TX_TYPE | TBD   |
+
+### New Transaction Type
+
+A new [EIP-2718](./eip-2718) transaction with type `AA_TX_TYPE` is introduced.
+Transactions of this type are referred to as
+"AA transactions".
+
+The contents of such transactions are fully described in RIP-7560.
+
 ### System-level code entry points
 
 Modify the EOF container format to consist of the following sections:
@@ -56,34 +70,35 @@ container := header, body
 header :=
     magic, version,
     kind_types, types_size,
-    kind_entrypoints, entrypoints_size,
+    kind_entry_points, entry_points_size,
     kind_code, num_code_sections, code_size+,
     [kind_container, num_container_sections, container_size+,]
     kind_data, data_size,
     terminator
-body := types_section, entrypoints_section, code_section+, container_section*, data_section
+body := types_section, entry_points_section, code_section+, container_section*, data_section
 types_section := (inputs, outputs, max_stack_height)+
-entrypoints_section := (entrypoints_role, target_section_index, target_section_pc_offset)+
+entry_points_section := (entry_point_role, target_section_index, target_section_flags)+
 ```
 
-For regular calls to the contract, the execution always starts at the first byte of code section 0, and pc is set to 0.
+For regular calls to the contract, the execution always starts at the first byte of code section 0, and `pc` is set to
+0.
 
-Here the `entrypoints_section` defines alternative indexes of code sections to start the execution for system calls.
-This is reserved for execution of special roles in the `entrypoints_role` range.
+Here the `entry_points_section` defines alternative indexes of code sections to start the execution for system calls.
+This is reserved for execution of special roles in the `entry_point_role` range.
 
-Note: do not confuse code execution `entrypoint` with the `EntryPoint` contract defined in ERC-4337.
+Note: do not confuse code execution `entry_point` with the `EntryPoint` contract defined in ERC-4337.
 
 ### Validation and PostTransaction code entry points
 
-The contract that may have a role in an Account Abstraction transaction, either as a Sender, a Paymaster or a Deployer,
-has to contain a section marked with one of the following `entrypoints_role` marker:
+The contract that has a role in an Account Abstraction transaction, either as a `Sender`, a `Paymaster` or a `Deployer`,
+has to contain all necessary sections marked with one of the following `entry_point_role` markers:
 
 ```
-role_sender_execution = 0x0000
-role_sender_deployment = 0x0001
-role_sender_validation = 0x0002
-role_paymaster_validation = 0x0003
-role_paymaster_posttx = 0x0004
+role_sender_execution = 0x00000000
+role_sender_deployment = 0x00000001
+role_sender_validation = 0x00000002
+role_paymaster_validation = 0x00000003
+role_paymaster_post_tx = 0x00000004
 ```
 
 This section is equivalent to a code section.
@@ -102,12 +117,16 @@ During a regular contract code execution, its behaviour is defined as follows by
 Execution starts at the first byte of code section 0, and pc is set to 0
 ```
 
-However, if a contract is referenced in an `AA_TX_TYPE` transaction as a Sender, Paymaster or a Deployer,
-execution starts at the first byte of code section with the `entrypoints_role` marker corresponding to the current step,
-and `pc` is set to the corresponding `target_section_pc_offset`.
+However, if a contract is referenced in an `AA_TX_TYPE` transaction as a `Sender`, `Paymaster` or a `Deployer`,
+execution starts at the first byte of code section with the `entry_point_role` marker corresponding to the current step,
+and `pc` is set to `0`.
 
 If the specified contract does not contain such a section, or is not an EOF contract, the transaction is not valid.
 
+The `target_section_flags` parameter is added to provide signaling into the EVM so that EOF can perform some additional
+validations as part of EOF code validation.
+The description of specific flags and their impact on EOF validation shall be added as a separate EIP.
+
 ### Encoding inputs for different execution frames
 
 #### Sender Deployment
@@ -120,11 +139,11 @@ This step is performed with the `role_sender_validation` code section.
 
 #### Sender Validation
 
-Inputs to the `Sender` validation section are defined by the protocol as an SSZ encoding of the transaction data,
+Inputs to the `Sender` validation section are defined by the protocol as an ABI encoding of the transaction data,
 excluding the `chainId` and `accessList` fields and with an extra field of the `txHash`:
 
 ```
-ssz([
+abi.encode(
   subtype,
   sender, nonce, builderFee,
   callData,
@@ -134,7 +153,7 @@ ssz([
   validationGasLimit, paymasterValidationGasLimit,
   callGasLimit, paymasterPostOpGasLimit
   signature, txHash
-]
+)
 ```
 
 This step is performed with the `role_sender_deployment` code section.
@@ -143,7 +162,7 @@ In order for the transaction to be considered valid the
 sender validation frame MUST return two 64-bit values:
 
 ```
-ssz(bool success, uint64 validUntil, uint64 validAfter)
+abi.encode(bool success, uint64 validUntil, uint64 validAfter)
 ```
 
 #### Paymaster Validation
@@ -156,7 +175,7 @@ In order for the transaction to be considered valid the
 paymaster validation frame MUST return the following values:
 
 ```
-ssz(uint64 validUntil, uint64 validAfter, bytes context)
+abi.encode(bool success, uint64 validUntil, uint64 validAfter, bytes context)
 ```
 
 #### Sender Execution
@@ -167,20 +186,20 @@ Inputs to the `Sender` contract are not defined by the protocol and are controll
 
 #### Paymaster post-transaction frame
 
-Inputs to the `Paymaster` post-transaction are defined by the protocol as an SSZ encoding of the following data:
+Inputs to the `Paymaster` post-transaction are defined by the protocol as an ABI encoding of the following data:
 
 ```
-ssz([uint256 actualGasCost, bool success, bytes context])
+abi.encode(uint256 actualGasCost, bool success, bytes context)
 ```
 
-This step is performed with the `role_paymaster_posttx` code section.
+This step is performed with the `role_paymaster_post_tx` code section.
 
 ## Rationale
 
-### SSZ encoding for system frames' input and output data
+### ABI encoding for system frames' input and output data
 
-Using an SSZ encoding format for data provided by the protocol itself does represent an abstraction levels violation,
-however it is a relatively safe and any alternative solution would require some trade-offs.
+Using an ABI encoding format for data provided by the protocol itself does represent an abstraction levels violation,
+however it is a relatively safe one and any alternative solution would require some trade-offs.
 
 The validation section of a Smart Contract Account code needs to have full access to the majority of transaction
 details in order to be able to make an informed decision about either accepting or rejecting the transaction.
@@ -191,20 +210,24 @@ parameter is not feasible.
 Allowing wallets to specify their own encoding for this data is also not feasible as Smart Contract Accounts must
 avoid any ambiguity about the meaning of the received data.
 
+The main benefit of using the ABI encoding lies in its currently ubiquitous use in smart contracts.
+There exist multiple high-quality production-tested libraries implementing ABI encoding and decoding in
+multiple programming languages.
+
 ## Backwards Compatibility
 
-An EOF contract with `kind_entrypoints` section is not valid according to EIP-3540 and cannot exist on-chain
+An EOF contract with `kind_entry_points` section is not valid according to EIP-3540 and cannot exist on-chain
 before this proposal is implemented.
 
-The introduction of `kind_entrypoints` will break an assumption that a contract code can only have a single
+The introduction of `kind_entry_points` will break an assumption that a contract code can only have a single
 execution starting point, which might confuse some developer tooling that relies on this assumption.
 
 ## Security Considerations
 
-A contract with a `kind_entrypoints` section explicitly indicates its role as a Native Account Abstraction entity.
+A contract with a `kind_entry_points` section explicitly indicates its role as a Native Account Abstraction entity.
 This is a significant improvement over ERC-4337 and RIP-7560 where entities are not explicitly marked.
 
-As the `kind_entrypoints` code sections represent a generic way to authorize any action on behalf of the contract,
+As the `kind_entry_points` code sections represent a generic way to authorize any action on behalf of the contract,
 correct and secure implementation of this code is critical.
 We expect compilers targeting EVM will play a major role in enabling and ensuring Smart Contract Accounts' security.