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.