Load manifest from state-tree

[Stebalien]

Currently, we load the actor manifest from the bundle (mostly for introspection). However, we should be using the state-tree:

• The bundles should only be used for upgrades.
• The state-tree is the ultimate source of truth.

Unfortunately, this is non-trivial:

• We can easily map the code CID to the actor type by looking at the manifest in the system actor. We should attach a (caching) GetBuiltinActors() map[string]cid.Cid method to the StateManager.
• We cannot easily map this onto a network version. This makes it difficult to, e.g., implement https://github.com/filecoin-project/lotus/blob/93f3b4923511f5ae3b661c234d09231ee56c4034/chain/actors/builtin/power/power.go#L39 correctly.

For now, we'll probably continue importing the bundle.

[jennijuju]

we should just load from the system actor, no?

[jennijuju]

oh nvm that gives you actor cids, not manifest CID. Why would one still want manifest CID if code cids were available ?

[Stebalien]

Ah, no. The issue isn't the actor CIDs or the manifest CIDs. The issue is mapping actor CIDs to actor versions so we can load the state with the correct "introspection" code in:

https://github.com/filecoin-project/lotus/blob/93f3b4923511f5ae3b661c234d09231ee56c4034/chain/actors/builtin/power/power.go#L39-L79

[Stebalien]

So, one solution is to just record the actor-version -> manifest mapping in the binary, which should be fine, honestly.

[Stebalien]

We can easily map the code CID to the actor type by looking at the manifest in the system actor. We should attach a (caching) GetBuiltinActors() map[string]cid.Cid method to the StateManager.

Well... "easily". To do this, we still need to be able to decode the system actor in the first place, which means we need some way to resolve a code CID to an actors version 🙄.