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 that returns a valid 4 byte magic to indicate approval 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, if Native Account Abstraction is to be implemented in coordination with EIP-3540, relying on the concept of "code sections" it introduces is a superior approach.
Specification
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 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.
Note: do not confuse code execution entrypoint
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:
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 entrypoints_role
marker corresponding to the current step,
and pc
is set to the corresponding target_section_pc_offset
.
If the specified contract does not contain such a section, or is not an EOF contract, the transaction is not valid.
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 SSZ 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 SSZ encoding of the following data:
This step is performed with the role_paymaster_posttx
code section.
Rationale
SSZ 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.
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.
Backwards Compatibility
An EOF contract with kind_entrypoints
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
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.
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,
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.