feat: chain: future proof the from & to address protocols

[Stebalien]

This lets us add new address protocols to go-address without implicitly accepting them in messages on the network.

Checklist

Before you mark the PR ready for review, please make sure that:

• Commits have a clear commit message.
• PR title is in the form of of <PR type>: <area>: <change being made>
  • example: fix: mempool: Introduce a cache for valid signatures
  • PR type: fix, feat, build, chore, ci, docs, perf, refactor, revert, style, test
  • area, e.g. api, chain, state, market, mempool, multisig, networking, paych, proving, sealing, wallet, deps
• New features have usage guidelines and / or documentation updates in
  • Lotus Documentation
  • Discussion Tutorials
• Tests exist for new functionality or change in behavior
• CI is green

[Stebalien]

I think I got all the cases we care about here.

[raulk]

Not a fan of this solution; I'd prefer to be more explicit.

How about we keep track of supported protocols per network version in go-address? There are several options, out of which one of these would work best:

• Turn the Protocol alias into a newtype, and add a MinNetworkVersion() uint to it.
• Add a top-level utility function SupportedInNetworkVersion(address.Protocol, version uint)

I'd prefer the first one, but there may be some type breakage.

[Stebalien]

So, go-addresss doesn't understand (and shouldn't understand) network versions. It would be best to add a helper in lotus, but it's unclear where we'd do that.

[raulk]

@Stebalien I was afraid you'd say that. I think it should.

• go-address has no utility beyond interacting with the Filecoin network.
• As the Filecoin network evolves, so does go-address.
• It's best to place change management and versioning logic in a single, colocated place.
• Other dependents of go-address will also benefit from this library having self-awareness and knowledge of when each protocol was introduced.

What are downsides do you see in putting the change management logic here?

[Stebalien]

Well, for one, that would introduce a cyclic module dependency between the state types and the address type. I agree we should manage this kind of information in one place, but that one place is the lotus repo. If we started adding version checks to the go-address repo, we'd need to start making changes in two places.

But yes, the current situation isn't great. We should a small package in lotus where we define the address constraints for an upgrade.

[raulk]

Well, for one, that would introduce a cyclic module dependency between the state types and the address type.

The network version is just a uint. There is no reason to make this module depend on network.Version from go-state-types. The orchestrator of both modules (e.g. Lotus) can trivially cast the type, if needed.

[raulk]

I still think constraints belong in go-address, and enforcement of those constraints obviously on the client of that module (Lotous). That way, an address protocol can declare "I don't make sense before nv18", and the client module would be in charge of enforcing it.

[Stebalien]

This is coming down to a matter of preference and norms, and I'm strongly inclined to stick with the current norms of encoding all network policies in this repo and the builtin actors. All other repos provide functionality and types, but they don't encode decisions with respect to network versions (and, really, don't even care about them).

The final decision is up to @arajasek.

[Stebalien]

Options:

1. Add a ValidForNetworkVersion on the Address type (in the go-address module).
2. Add a new package/function somewhere in lotus for checking per-version address rules.
3. Keep this as-is with ad-hoc checks everywhere (matches current behavior but is, well, ad-hoc).

[arajasek]

I definitely don't want go-address becoming aware of network versions and having the constraints defined there. I'd much rather leave go-address home to the implementations of various address protocols, and let clients use them as they see fit. That makes more sense to me, and fits the pattern better. As an example, our actors don't have any stated constraints about them -- one could deploy v8 code as network version 1 if they wanted to, it's up to clients to enforce that doesn't happen.

I don't like the ad-hoc checks either, because that will grow. I would actually propose adding this ValidForNetworkVersion to go-state-types. It's a bit funky, but that's where "what's appropriate for this network version" logic currently lives (eg. ActorsVersionForNetwork).

I don't feel strongly about that, though, so if you wanna just have the helper here in lotus, that's fine by me (but do have a method, and not just m.To.Protocol() > address.BLS.

[simlecode]

@Stebalien Hello, why not add the same check in https://github.com/filecoin-project/lotus/blob/master/chain/vm/fvm.go#L113