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:
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:
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.
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_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.