Prototype account abstraction for Ethereum native transaction support

[raulk]

Proposal

https://github.com/filecoin-project/FIPs/discussions/388 by @anorth

Goal

The goal of this issue is to conduct a prototype to validate the ideas therein and their applicability to native EVM transaction support. Concretely, https://github.com/filecoin-project/fvm-specs/issues/92 talks about how such an abstraction would be applied to this particular problem. This prototype shall act as the base for an eventual mature feature.

High-level tasks

Level of technical detail/accuracy here is low, just enough to structure the work.

1. Implement the actor code update flow.
   • Implement an sself::update_code_cid(Cid) -> Result<!> syscall. Takes the target CodeCID to which to switch this calling actor to.
   • Handle such syscalls by delegating to an update_to(addr: Address, curr_code_cid: Cid) (or similarly named) actor entrypoint to evaluate the intake on the target side, i.e. exported FFI Wasm function.
   • Implement the FVM mechanics to manage this, including a delegatecall like facility (target actor update intake method should execute in the same context as the caller).
2. Create a built-in Ethereum account actor (e.g. eaccount).
   • Offers an update_to entrypoint to allow standard actors to upgrade to it.
   • Offers a validate entrypoint that validates the signature on native Ethereum messages, fulfilling the contract specified in https://github.com/filecoin-project/FIPs/discussions/388.
3. Extend the standard account actor to enable upgrading f1 addresses (backed by secp256k1 keys) to eaccount by invoking sself::update_code_cid.
4. Extend the FVM to validate messages using the validate entrypoint. (New protocol-level signature type needed to indicate "delegate to sender actor"?)
5. (Eventually) Implement JSON-RPC eth_sendSignedTransaction on Lotus utilizing this mechanism.

Not covered by this prototype

Will need separate issues.

• Security model of code updates.
• Security model of validation entrypoint (for now we assume that the container has all syscalls available to it -- this will need to be restricted for no side effects).
• Returning gas spec as per https://github.com/filecoin-project/FIPs/discussions/388.
• Gas charges.

[anorth]

I'm very happy to see this prototyped. IMO we can separate the account abstraction prototype from code updates, though. Code updating is a whole can of worms on its own (#15) and I don't see a robust design for this yet. Cramming something in en route to a different goal could get us stuck with a mediocre solution. Account abstraction is still useful without upgrades (via CREATE2 addresses, for example). For prototype purposes, can we skip straight to your step 4?

1. Add validate entry point to built-in Account actor which validates SECP key
2. Extend FVM to use the validate entry point (now we can test all the performance cost)
3. Make an eaccount actor and just install one at genesis for prototyping. Implement ethereum message validation.

I get that EVM embedding needs upgrades and account abstraction, but let's think about the upgrade story first. It needn't block this.

New protocol-level signature type needed to indicate "delegate to sender actor"?

I don't think so. I think the decision to delegate should be either (1) always, or (2) based on whether the actor implements validate. Then a standard secp signature should be usable by any actor that's using that under the hood.

We will need a new signature type for "opaque" though, so actors can use alternative crypto or other esoteric validation.

[raulk]

@anorth I see your point, and indeed this is an umbrella issue that we plan to split off in multiple pieces (we already talked about this yesterday, and in fact @mriise will be owning the account abstraction part with @vyzo driving the update part).

For purely prototyping account abstraction, the code update path is not needed, correct. However, our goal is to prototype the entire Ethereum native transaction support end to end, and that is dependent on the code upgrade flow, at least in the current solution model.

That's why it's important to prototype it too to our satisfaction, because impediments/complexities may motivate us to seek othe solution paths (e.g. just enhancing the existing account actor with an entrypoint, thus obviating the update flow for now).

[raulk]

We will need a new signature type for "opaque" though, so actors can use alternative crypto or other esoteric validation.

Yes, that was covered here:

Extend the FVM to validate messages using the validate entrypoint. (New protocol-level signature type needed to indicate "delegate to sender actor"?)

[mriise]

#654