Proof of concept exported API for Account actor

[anorth]

This is an example mechanism for defining and enforcing an exported API for builtin actors. The existing low-valued method numbers are all restricted to built-in callers only. This means we can, if ever needed, change their parameters or behaviour while preserving compatibility for callers of exported method numbers. But for now exported method numbers map to the same implementation as the internal.

Before merging:

• Decide the right target branch for this work

[ZenGround0]

I like this approach

[Stebalien]

Ok, in general I like the idea of reserving a range for "internal" use. Comments:

• It's strange that off-chain accounts can call "internal" methods. Are we going to change things like ProveCommit to use exported IDs? Or are we going to continue using "internal" methods from off-chain, but "exported" methods on-chain?
• The whole "Exported" naming is kind of annoying, maybe create a separate table and/or enum? Then we can clearly label these as "private" and "exported" (with entirely separate enums).

[Stebalien]

Also note: if we define a separate table, we can use a proc macro to compute the method name automatically:

#[frc42_methods]
pub enum MyMethods {
    Receive,
}

[arajasek]

@Stebalien Thanks for the review!

• It's strange that off-chain accounts can call "internal" methods. Are we going to change things like ProveCommit to use exported IDs? Or are we going to continue using "internal" methods from off-chain, but "exported" methods on-chain?

I think off-chain / on-chain isn't the relevant division here -- builtin vs. not-builtin is what matters. It's fine for off-chain entities to call "internal" methods, so long as the calling entity in question is a builtin actor (eg. the account actor). The current proposal likely won't export things like ProveCommit for now.

• The whole "Exported" naming is kind of annoying, maybe create a separate table and/or enum? Then we can clearly label these as "private" and "exported" (with entirely separate enums).

This seems like a good suggestion, I think.

[anorth]

Eventually, I expect anything that an Account can call will become exported.

I toyed briefly with an alternative Enum, but it makes everything else more complicated and in some cases less transparent. Here the churn is confined to the enum values. Of course we can try other concrete approaches too.

[anorth]

Elsewhere I heard some resistance to merging this to master. Since there probably will be a FIP for this work (following filecoin-project/FIPs#401) I'll merge to a new integration branch integration/builtin-api for now.

[arajasek]

I'm in favour of this approach, let's land this.

[Stebalien]

I think off-chain / on-chain isn't the relevant division here

The "account" actor is basically "the user" so there isn't really anything internal about it.

But we can handle this by:

1. Exporting these methods as suggested by @anorth.
2. Encouraging users to use the "correct" method numbers, hiding the internal ones.

I toyed briefly with an alternative Enum, but it makes everything else more complicated and in some cases less transparent. Here the churn is confined to the enum values. Of course we can try other concrete approaches too.

I think the main win will be when we have to export, document, and import these APIs. But we can always cross that bridge later.