EIP-7701: Native Account Abstraction with EOF

EIPs EIPs core
, ,
1

One of the issues that arises from enshrining an ERC-4337: Account Abstraction Using Alt Mempool design in Ethereum is its reliance on Solidity method signatures and ABI-encoding that is not a native part of the EVM.

This EIP is a variant of RIP-7560: Native Account Abstraction that solves these issues by the means of extending the EOF format.

3 Likes
2

A bit late reviewing this, but itā€™s been because EOF v1 has been solidifying. With that in mind I have some comments and suggestions with the EOF portions of the PR.

  • Remove target_section_pc_offset and require all sections to start at PC=0 within the code section

My reasoning for this relates to the code validaiton within EOF, itā€™s only intended to start with a single entry point at zero. If code can enter at multiple entry points significant portions of stack validation need to be reconsidered, and that feels like too much for this EIP, in addition to needing a separate skill set to evaluate.

  • Reconsider specifying ssz encoding of data

Clients are not yet mandated to implement, but more importantly robust solidity libraries handling SSZ do not exist yet, and the efficiency of SSZ in the EVM is an open question. This is an issue that may be overcome in time, but I donā€™t think Native AA is the correct place to find out. Right now the Solidity ABI is much better ingrained in the ecosystem and will result in less friction when it comes to adoption.

The following 2 suggestions are to allow Native AA to use the EOF features without embedding the AA aspects into the EOF spec, and provide a generic reusable facility for other uses.

  • Consider 4 bytes for entrypoint_role, and assign names based on ABI selectors

Expanding this to 4 bytes makes arbitrary mappings a bit less arbitrary, and preserves two future design spaces: multiple possible signatures for entry point actions, and secondarily possibly expanding it to a general case ā€œselectorā€ mode that EOF can deploy, where solidity can dispense with the occasionally large switching logic for function dispatch. This also helps decouple AA logic from the EVM.

  • Consider adding a ā€œflagsā€ field in entrypoints_section entries.

Some drafts of various AA proposals have imposed more restrictions on the kinds of operations that a function may perform, such as prohibiting all block info access in sender validation calls. An extra flags field will provide signaling into the EVM so that EOF can perform that validation as part of EOF validation. This further decouples AA logic from the EVM otherwise specific validations would be tied to specific types which would then require EVM updates when new or different validations are requested.

1 Like
3

Thank you for your review! Sorry on my part for a late response. We have made significant progress implementing RIP-7560 and, hopefully, it will have some production use by the time EOF is merged and EIP-7701 becomes our main focus.

I have made changes to EIP-7701, mostly implementing your suggestions.
You can see the PR with the recent changes here:

However, I do have a couple of questions about them:

  1. You have mentioned the ā€œselectorā€ mode for EOF.
    Is this something that is currently on a roadmap for EOF? I could not find this feature described anywhere, and native AA could greatly benefit from using a standard EVM-level dispatch.
    I assume EIP-7701 would have little chance of getting accepted with its own dispatch logic when there are plans to introduce a system-wide solution. Do you think it makes sense for us to propose a general EVM ā€œselectorā€, for instance, as a separate EIP that is a prerequisite to EIP-7701?

  2. Regarding the flags field for entrypoints_section entries, would we have to define the full set of possible flags as part of this EIP? Currently, I am not sure I know what are the flags we may need in the future, so I assumed we would need a new EIP for each new flag, right?

  3. Regarding the ABI encoding for the data necessary during the transaction validation, one alternative we discussed and are still considering is creating one or a small number of ā€œtransaction getterā€ opcodes that would provide the missing EIP-7701 transaction fields. Would you consider such a direction to be more or less consistent with the direction of the EOF?

1 Like
4
  1. Selector mode. I havenā€™t published any of my ideas for post EOF right now to keep focus on 1.0. I have a talk at devcon where I will disuss some of my ideas. It would be a general EVM selector. It would basically switch out what the entry code section is.
    If the section is presentā€¦
  • Input data less than 4 bytes enters at section zero
  • if there is an entry in the table matching the first 4 bytes of input data, that index + 1 is the entry section
  • If non match, section zero is the entry
  • the table must be sorted, so you can do a binary search.
  • 4 byte selectors are meant to match solidity function selectors.

  1. Iā€™m not sure if we need flags. There are bytes we can use in the type section if needed. A new EIP for each flag.

  2. I would prefer system contracts (precompiles) to peek data out from the transaciton. Opcode space is getting crowded with opcodes that sometimes lose meaning in rollups and other applications such as off-chain compute.