Open raulk opened 2 years ago
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?
validate
entry point to built-in Account actor which validates SECP keyvalidate
entry point (now we can test all the performance cost)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.
@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).
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"?)
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/ref-fvm/issues/721 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
sself::update_code_cid(Cid) -> Result<!>
syscall. Takes the target CodeCID to which to switch this calling actor to.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.delegatecall
like facility (target actor update intake method should execute in the same context as the caller).eaccount
).update_to
entrypoint to allow standard actors to upgrade to it.validate
entrypoint that validates the signature on native Ethereum messages, fulfilling the contract specified in https://github.com/filecoin-project/FIPs/discussions/388.account
actor to enable upgrading f1 addresses (backed by secp256k1 keys) toeaccount
by invokingsself::update_code_cid
.validate
entrypoint. (New protocol-level signature type needed to indicate "delegate to sender actor"?)eth_sendSignedTransaction
on Lotus utilizing this mechanism.Not covered by this prototype