Discussion: State Types refactor

[arajasek]

State Types refactor

This is a design discussion for how to structure the Golang implementations of the various types in the Filecoin protocol. The discussion outlines the current state of things, motivates the need for a change, and then makes some proposals.

Background

The Filecoin protocol has a set of "builtin" actors that run trusted code. These actors are implemented in both Go and Rust today, alongside their state types. With the planned introduction of the FVM, all implementations will start running the builtin-actors (written in Rust) through the FVM. The specs-actors repo, written in Go, will not be used for message execution.

However, it is still important for Go-based implementations like Lotus to be able to de/serialize actor state types and inspect the underlying state. Such implementations also need access to the message parameter types, which live in specs-actors today. At the current state of development, we are doing this by continuing to us. the specs-actors repo for state access and message parameter serialization (but not message execution). This works, so long as any changes made to the state types in builtin-actors are also reflected in specs-actors. Doing so risks introducing bugs in Lotus, however, in places where we continue to use old specs-actors information that is no longer valid (eg the synthetic code CIDs).

Proposal

The proposal is to have Go-based implementations of the state types, de/serialization logic, and message parameters live somewhere else. This will involve extracting these types from the specs-actors repo, without any of the actor logic or deprecated content. This also forces Go-based implementations to refactor away from specs-actors, and fixup any incorrect usage of old logic.

Option 1: Add the state types to go-state-types

The go-state-types repo currently includes some, but not all, of the ABI. Given its name, it makes sense to add these types into go-state-types. This is a major increase in the size of go-state-types, and needs us to introduce versioning to the repo, as it will need to keep up with new versions of builtin actors.

This has already been prototyped: filecoin-project/go-state-types#36

Option 2: Create a new repo for these types

It would be nice to leave go-state-types unchanged, it's good for what it currently does. Some new builtin-states repo could house these types.

Migrations

When builtin actor states change, a migration is needed to convert from the old state type to the new one. Currently, these migrations also live in the specs-actors repo. We could:

• move them to wherever the state types go. It's useful to have them adjacent to the types for testing purposes.
• move them to some new repo.
• implement them in Rust, and invoke them through an FFI call. This is not feasible to do in time for the v16 upgrade.
• leave them in specs-actors for now.

[anorth]

Sentinel is another consumer of this Go state schema (@frrist).

High level I concur with the plan to move (copy) the state schemas somewhere and continue to maintain them. See also filecoin-project/builtin-actors#263

This new schemas repo does not need to follow the same versioning approach as specs-actors did. One probably-viable alternative is to have each actors version be present as a top-level package of the repo, adding a new one for each new actors version. This could remove the chain of dependencies on prior release branches, explicitly flattening it.

The primary reason go-state-types was introduced is to reduce versioning pain for a bunch of simple primitive types that don't change across actor code versions. Consumers like Lotus want to depend on a single, stable repo for these. This need will continue to exist after moving the actor state schemas somewhere else.

It's possible that the combination of the above two paragraphs resolves this issue. A top-level package for the non-versioned types could be depended upon by each actors version package. Any necessary refactors to the non-versioned types would actually become easier to propagate to the historical actor schemas to ensure they are all using a single, most recent definition.

FYI also @ZenGround0 @Stebalien @raulk

[jennijuju]

@arajasek this was fun and now ✅ ! do we need any further discussion or can we close this ticket!