Limits/authentication by actor "type"

[Stebalien]

In nv16 (M1), the FVM itself has a list of all builtin actors, allowing actors to resolve code CIDs to actor "type" (see #342). However, this isn't sustainable:

1. It's "off-chain" information that should really live on-chain.
2. It doesn't work for user programmable actors.

From #342:

1. the init actor holds an allowlist of actors it is allowed to construct (multisig, paych)
2. the market and miner actors validate that only "signable" actors (account, multisig) can perform certain duties
3. the market actor validate that only the miner actor can perform deal management operations
4. the power actor validates that only the miner actor can perform privileged operations

Initialization Restrictions (1)

Initialization restrictions (restrictions on who can "create" an actor of a given type) can allow actor programmers to make assumptions like "any caller with code X is 'safe'".

Today, the init actor itself decides what can and cannot be constructed. But that won't work for user programmable actors.

Proposal 1: Call the actor constructor with Constructor(caller_id, params) where caller_id is the actor that originally called the init actor. That way the actor under-construction can decide whether it wants to abort.

Proposal 2: Let users construct miner actors directly instead of having to call the power actor.

Limiting to "Signable" Actors (2)

We mostly do this as a safety check, but it makes no sense in a system with user programmable actors.

Proposal: We should just remove this check.

Privileged Operations (3 & 4)

We're currently using #342 to determine if an actor is in the "privileged" set. However:

1. This only works for system actors.
2. This requires all actors to be upgraded in lock-step. One can ask the system "is X the current miner code", but there's no way of asking "is X some valid version of the miner code".

Proposal: Implement a name system (filecoin-project/FIPs#297) that can "name" actor code.

[anorth]

Initialization Restrictions

Thanks, I never liked this. We can't gate what can be constructed at all. Your proposal 1 sounds good, and may be useful for user actors too. I don't think we need to go to proposal 2 (I don't actively oppose it, just think we don't need it).

After this, someone will be able to instantiate something that's just like, say, the RewardActor or CronActor, but without a "fail if not called by the system actor" and we just have to be ok with that.

Limiting to signable actors.

Agree.

Priviledged operations

We certainly still need this for the built-in actors, but I think it's ok, for now, that it only works for them. It's ok that it requires all built-in actors to be upgraded in lock-step. While a name system would be a good asset long term, I don't think we need to build it now. All we need is a library or actor to call that can answer "is X the current miner code" for the built-in types. We could add that to the InitActor, for example. Or to a library, if the dispatch (from user contracts too) is dynamic. Or even a syscall wouldn't be all that bad.