EIP-7701: Native Account Abstraction with EOF
A variant of RIP-7560 transactions relying on EOF Smart Contract Accounts
Abstract
This proposal describes a slight variation of the Native Account Abstraction design fully described in RIP-7560. This version's difference compared to the original proposal is in relying on features of "EVM Object Format" to distinguish between validation and execution code sections.
Motivation
Talking about Full Native Account Abstraction, the fundamental idea any solution has to address is a mechanism for a Smart Contract Account to separate its validation and execution code sections.
RIP-7560 is build on the current Ethereum contract structure, and therefore has little choice but to rely on using some higher-level abstraction.
In its current form, RIP-7560 transactions use Solidity method selectors in order to achieve this separation.
This, however, is far from ideal as this approach "leaks" the concept from a programming language widely used in the EVM into the core design of the Ethereum protocol.
While there is no purely technical reason to disallow it and there are already instances of Solidity code being "enshrined" in the Ethereum protocol, e.g. the validator deposit contract, such violation of abstraction levels 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 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.
As an alternative, Native Account Abstraction can be implemented in coordination with 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 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:
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 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 entry_point with the EntryPoint contract defined in ERC-4337.
Validation and PostTransaction code entry points
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:
This section is equivalent to a code section.
Its code can be executed during a regular transaction execution and has no special effects. If it is the first code section of a contract, it can act as an entry point during regular transaction execution.
Only a single section per role is allowed in a contract. This rule is validated during contract creation.
Execution entry point for Account Abstraction transaction type participant entity (Sender, Paymaster and Deployer)
During a regular contract code execution, its behaviour is defined as follows by EIP-3540:
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
Inputs to the deployer contract are not defined by the protocol and are controlled by the deployerData parameter.
The sender deployment frame MUST result in the sender address becoming initialized with contract code.
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 ABI encoding of the transaction data,
excluding the chainId and accessList fields and with an extra field of the txHash:
This step is performed with the role_sender_deployment code section.
In order for the transaction to be considered valid the sender validation frame MUST return two 64-bit values:
Paymaster Validation
Inputs to the Paymaster validation section are same as the ones in the Sender Validation step.
This step is performed with the role_paymaster_validation code section.
In order for the transaction to be considered valid the paymaster validation frame MUST return the following values:
Sender Execution
This step is performed with the role_sender_execution code section.
Inputs to the Sender contract are not defined by the protocol and are controlled by the callData parameter.
Paymaster post-transaction frame
Inputs to the Paymaster post-transaction are defined by the protocol as an ABI encoding of the following data:
This step is performed with the role_paymaster_post_tx code section.
Rationale
ABI encoding for system frames' input and output data
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.
A small subset of this data is available with the existing opcodes, however creating an opcode for every transaction 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_entry_points section is not valid according to EIP-3540 and cannot exist on-chain
before this proposal is implemented.
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_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_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.
Copyright
Copyright and related rights waived via CC0.