FEVM: Expose the "call actor" precompile to the EthAccount actor

[Stebalien]

At the moment, there's no way to call a "native" Filecoin method from an EthAccount (an f410f... account managed, e.g., by metamask). These accounts can only invoke "EVM" methods.

However, we could allow EthAccount actors to call the the "call actor" precompile, calling native actors "by proxy" (kind of).

• In metamask, the user would see a call to 0xfe00...03, the call actor precompile. It would look like they're calling the target actor via the call-actor precompile.
• The Filecoin client would convert the ethereum transaction to a native filecoin message directly from the user's account to the target actor (removing all mentions of the precompile).

That's why I say "kind of". We're using the call actor precompile to signal "hey, this is a native message". But we won't actually use it on-chain. This has the added benefit of working well with native chain explorers: they'll see a message directly from the account to the target actor and won't have to reason about forwarding/precompiles.

The downside of this approach is that the UX isn't great. The end-user will still see the funky precompile address in the transaction's recipient field.

[Schwartz10]

I'm reviewing this post in the context of a very specific use case we have at GLIF - we'd like our users to be able to use MetaMask (not Filsnap) as signers on the built-in multisig actor.

In the context of "allowing an EthAccount to be a built-in multisig actor signer", I think the UX problems really matter here. Multisigs are confusing even with native Filecoin addresses. EthAccount support on top of Filecoin is another confusing point. Introducing unfamiliar and potentially insecure behavior to the process of signing multisig transactions on top of the existing confusions (I think) wouldn't be ideal. We shouldn't instruct users to sign blind transactions to the call actor precompile address 0xfe00...03

I wonder, if in the context of the built-in multisig actor, if there is support we could build into the multisig actor itself to allow EthAccounts to act as signers. This is obviously specifically only handling the use case I'm thinking of, and I'm sure there are plenty of other use cases that would be "unlocked" by implementing this FIP, but I'm not sure where they occur and how important they are. As a result, it's tough for me to gauge how costly the unfavorable UX trade off would be.

--
One other question - would implementing this FIP then also allow a FEVM smart contract to call non-exported methods (like terminating sectors on a miner actor)? Or does this FIP necessarily deal with EthAccount actors only?

[Stebalien]

I wonder, if in the context of the built-in multisig actor, if there is support we could build into the multisig actor itself to allow EthAccounts to act as signers.

This is possible however, there are two reasons it's less likely to happen:

1. We'd like to eventually deprecate the built-in multisig in favor of user-deployed multisig, so the FVM team is reluctant to add any additional features to it. On the other hand, this seems like a totally reasonable FIP as long as you're willing to write/implement it.
2. Metamasks users will likely need some way to interact with native contracts that don't understand the EVM anyways.

Basically, I'm trying to propose a solution that doesn't just fix a hole in the existing Multisig.

One other question - would implementing this FIP then also allow a FEVM smart contract to call non-exported methods (like terminating sectors on a miner actor)? Or does this FIP necessarily deal with EthAccount actors only?

No, that was very much an intentional decision. If there are any specific APIs you need to call, start a FIP discussion to get them exported. The point of restricting the exported APIs was to be intentional about which exact APIs we expose and their definitions.

With respect to the sector termination APIs... those interact with cron in weird ways so they likely won't be unrestricted until we can remove those cron interactions, but it looks like that might be possible in the next upgrade. I believe it was previously blocked on filecoin-project/builtin-actors#1377, see filecoin-project/builtin-actors#1388.

[Schwartz10]

All makes sense to me.

Basically, I'm trying to propose a solution that doesn't just fix a hole in the existing Multisig.

100% agree this is the preferable approach. My main point is that the hole in the existing Multisig is the only instance of the underlying problem that i've actually run into. I'd just make sure solving this problem in a generic way (considering the UX trade offs) unblocks enough downstream functionality / improved UX that it's worth the effort and/or additional complexity

[Stebalien]

Yeah, makes sense. I'll think if there's a good way to keep the address in the address field. It won't be quite as generic (won't work with f1/f2, etc.) but there might be a way to do it.