Atomically switching the execution layer to a non-programmable FVM

[raulk]

Discussion to accompany #294.

Adapted from its abstract:

The idea is that at chain height TBD, the network's execution layer would transition from the intrinsic VM to a non-programmable version of the FVM. By non-programmable we mean that users won't be able to deploy custom code, yet.

The network would continue running the logic of the prevailing built-in actor version, estimated to be v7 (assuming this FIP is scheduled to go live right after nv15: OhSnap).

However, the code and deployment form of built-in actors would now be Wasm bytecode. Actor code will begin to be identified through real content-addressing. The current synthetic actor CodeCIDs will migrate to CIDs that hash over their actual Wasm bytecode.

That FIP also proposes that all implementations migrate to a canonical Wasm actors codebase.

[anorth]

There's a note about running sanity checks, possibly validating tipsets in both VMs at once. That latter idea may well be intractable.

My understanding of our intention is to demonstrate equivalence of the FVM actors prior to committing to the change, though. Perhaps we could note a plan something like:

• run the chain with nv15 for at least X epochs after that network upgrade
• nodes running FVM will demonstrate validation of the chain since nv15 for at least those X epochs, before we commit to the upgrade epoch TBD
• some drop-dead epoch prior to TBD after which the network will (socially) commit to roll forward with the change even if an incompatibility emerges (so long as it doesn't threaten functionality or security)

[Stebalien]

Running the chain at nv15 for a while to gain confidence will be important. However, when the FVM upgrade hits, we'll end up running different code (due to gas changes, actor deployment model, etc.) than the one running alongside nv15.

To address that, I'd propose:

1. Test extensively in a test network.
2. Forward-port test vectors from nv15, ignoring the changes in gas. We expect that the state-trees will be mostly the same, so it should be possible to do this.