MVP Account Abstraction Proposal

[Stebalien]

The current account abstraction proposal (#388) is a large departure from how accounts currently work and therefore raises quite a few security and usability questions:

• Do we restrict abstract accounts to one message per block?
• If and when can abstract accounts mutate their state?
• If/when can abstracts spend funds? How does this affect message packing?

Instead of trying to come up with a complete solution up front, I'm proposing an MVP version that makes abstract accounts look almost identical to current accounts, except that they can chose how they validate messages. My goal is to enable FEVM (FVM M2.1) right now, while setting ourselves up for more generally abstract accounts in the future (FVM M2.2).

Specifically:

• As with Account abstraction #388, introduce a new validate endpoint to validate off-chain messages (with the modification I proposed in Account abstraction #388 (comment)).
• Unlike Account abstraction #388, allow any number of messages to be packed into a single block.
• Unlike Account abstraction #388, automatically enter "read-only" mode when the abstract account is invoked (except on construction). This is like my proposal in Account abstraction #388 (comment) but:
  • Even more restrictive. Not only are state changes forbidden, but transfers and transitive state-changes are forbidden as well.
  • Temporary. We should relax this restriction in the future.

This is sufficient for:

• FEVM.
• New signature schemes.
• Multisigs with a static set of signers.

But that's about it.

[anorth]

Firstly thanks, I support the idea to look for simplifications that will make AA easier to ship, but that are on the path to a more powerful version.

I take issue with the phrasing that #388 disallows packing multiple messages from one actor in a block. It's allowed, just not advisable naively. I would prefer to say that the proposed always-read-only restriction gives an easy heuristic for validation results that are entirely static, and hence multiple messages are safe.

We should think about how to make that restriction easy to relax in the future. E.g. we could make it an explicit property of actors rather than something the VM always does. I.e. an actor specifies a static "always readonly" property which the VM inspects (and for now refuses to call validate() if false). Then in the future when the VM will permit false, existing actors still behave the same way. If we make the restriction a property of the VM only, when we lift it in the future mempools won't be able to distinguish that some actors are still safe, and/or the environment assumptions in which the actor was developed will change.

I note we could reach the same set of use cases with other heuristics about the account code being known to never alter its state nor be upgradeable, i.e. an allow-list, (assuming this is true of FEVM entry point actor), plus other cases could be supported but might expect to be limited to one message per epoch. The protocol itself would be simpler, but those heuristics would be added complexity for implementations.

I would prefer a path to make this read-only property more dynamic, like a no-self-mutation bit for top level messages that you suggested here. This is a bit different to #487, since transitive calls from the actor could still mutate other actors (but those others can't be consulted during validation).

[Stebalien]

I take issue with the phrasing that #388 disallows packing multiple messages from one actor in a block. It's allowed, just not advisable naively. I would prefer to say that the proposed always-read-only restriction gives an easy heuristic for validation results that are entirely static, and hence multiple messages are safe.

It may not disallow it, but there's no incentive for miners to take a risk here so it effectively rate-limits messages from such accounts. Maybe storage providers could whitelist specific account types? But I'd prefer a solution that "just works" predictably.

We should think about how to make that restriction easy to relax in the future.

I agree. A flag seems like a reasonable approach. We'll probably want several flags like this. Also note, we don't have to make a decision until FVM M2.2.

I would prefer a path to make this read-only property more dynamic, like a no-self-mutation bit for top level messages that you suggested #388 (comment). This is a bit different to #487, since transitive calls from the actor could still mutate other actors (but those others can't be consulted during validation).

In general I agree. However, that would require modifying the message format (which is why I'd like to punt that if possible, at least for the first version). On the other hand, that's one way to address your previous concern:

1. By default forbid all mutations (where a value transfer is considered a mutation).
2. If this special bit is set, allow mutations, but only allow one message.

[anorth]

I infer the target here is FEVM, and I'm down with doing something simple for that. But I would urge doing something like changing the message format should come with FVM M2.2, lest the motivation to make any change get lost after that.

[Stebalien]

I completely agree.

[anorth]

In the FIP-0054 draft there's a whole section I don't understand: "Inability to stably address some actors from EVM smart contracts"

I think this section is relying on knowledge of some EVM actor implementation details that are not specified here. Does it also apply to EthAccount? If so, what's the logic in EthAccount that has this effect? Why can't an EVM contract send to an f2 address? Why can't an EthAccount send to and f2 address (if it can't)? What's this masked address thing?

[raulk]

This section indeed is misplaced in this FIP, and better placed in FIP-0054.

[raulk]

FIP-0054 covers the masked ID address form and the CALL mechanics, so makes more sense there.