Remove legacy protocol code from Lotus

[arajasek]

Lotus has various code paths that exist for the purpose of syncing historical chain state. These paths are not exercised by the vast majority of Lotus users today (likely all of them), but are important to maintain for users that do want to validate the entirety of the Filecoin blockchain. Some examples of these paths include:

• The circulating supply calculation, which evolved rapidly pre-liftoff:

  lotus/chain/stmgr/supply.go

  Line 148 in e65fae2

  func (sm *StateManager) setupPostCalicoVesting(ctx context.Context) error {

• Various network version checks in the LegacyVM that fixed minor issues behind network version checks:

  lotus/chain/vm/vm.go

  Line 317 in 05cdeb8

  if vm.networkVersion <= network.Version3 {

• All of the migrations for older network versions:

  lotus/chain/consensus/filcns/upgrades.go

  Lines 55 to 56 in 906463b

  	var us stmgr.UpgradeSchedule

• Accessors for state belonging to old actors versions, eg:

  lotus/chain/actors/builtin/account/v0.go

  Line 14 in e65fae2

  func load0(store adt.Store, root cid.Cid) (State, error) {

I would like to propose removing these code paths from Lotus master. We would effectively say that new releases of Lotus only support accessing & validating the chain from a certain network version and onwards -- I would propose v14, which would give us about a year of historical lookback for now, while still dropping most of the bloat. Given that it is important to access & validate historical state, though, we must preserve that functionality somehow. We could do so by:

1. Simply saying that earlier versions of Lotus (eg v1.16.0) syncs historical state. Easiest option, but means we won't have a single binary capable of validating the entire chain. Would that be okay?
2. Forking lotus today, and maintianing a lotus-archive repo into which we would periodically merge lotus. This would be a lot of work, but we could do it on a quarterly, or as-needed basis.
3. Something else more clever?

One risk from doing this would be to test networks, and calibrationnet in particular, which require all of these old code paths. We likely have users that do sync calibrationnet from scratch. If we go forward with this proposal, it will be important to offer snapshots for calibrationnet similar to those that we offer for mainnet. An alternative could be to reset calibrationnet to start from nv14.

[ZenGround0]

As a purist I would rather not see lotus lose the ability to sync the whole chain.

Another option: we could take that frozen binary and support delegating to it in the case of historical syncs. make lotus archive or something would package lotus with the old binary -- you'd need to explicitly build an old binary to make things work with historical syncing. Dispatching api calls on old state might need design work, though maybe we could disallow any state accesses beyond syncing on things in the historical height.

[whyrusleeping]

Agree with @ZenGround0 , we should absolutely not ever remove the ability for a lotus node to sync the full chain.

[anorth]

Could you expand more on why? With a deeper understanding of the motivations, we might be able to design changes that preserve those goals while also reducing the burden on future development.

[anorth]

This affects all nodes, not just Lotus. For a totally different, pragmatist take: data is forever, right? Especially if we store it on Filecoin.

For use cases that require the full transaction history, what about ideas to store that full history within Filecoin (with massive redundancy)? As well as other places. The chances of humanity ever losing that data altogether are already pretty remote, we can make it way lower than the expected chance of some other catastrophe like crypto being broken. There are many details of course, questions of availability etc, so it's not an immediate fix. But in principle as a direction to aim for?

There may be other reasons to preserve fully sync besides historical data access. What are those reasons? There's almost certainly something around detecting fake chains since the POW is not easily validated. But it would help a lot to get really concrete about the challenge there, and seriously explore alternatives to full sync (which, in practise, does anyone actually ever do?).

These are protocol-level ideas. Even if they turn out to be infeasible, I concur with @arajasek that it's worth some serious effort to pursue simplifying the codebase that determines the future of the Filecoin network. Perhaps something has to be able to sync the full chain, but maybe it's not the binary we call Lotus that everyone runs.

[arajasek]

Thanks for the engagement! I like your phrasing of:

Perhaps something has to be able to sync the full chain, but maybe it's not the binary we call Lotus that everyone runs.

That's roughly the central thesis of my idea.

I also wanna be careful about blurring the lines between the data that is the Filecoin chain (primarily blocks & messages), and the logic that is required to compute state for this data. I think it is important to preserve both somewhere, and this discussion is about where the logic component of that needs to live.

This affects all nodes, not just Lotus.

I don't think that's quite true -- each node is free to decide how much of the chain they wish to support validation.

[jennijuju]

Agree with @ZenGround0 and @whyrusleeping - i also think it's important for filecoin to have at least one client implementation, it can be lotus or forest, that has the ability to sync the full chain. Unless, there is a well maintained, long term commitment service that exists that provides full archival node services / full history snapshots. (summoning @travisperson who may or may not is working on this. )

what about ideas to store that full history within Filecoin (with massive redundancy)

imho, ideal/easy to say - but hard to do.

@arajasek for the binary approach, say I want to build an application, that allows a SP, that joined the network since liftoff, to do bookkeeping stuff for their funds movement & history since they start a business for tax purpose. How will I do it?

[arajasek]

@jennijuju That's a good question that maybe motivates another solution! My immediate answer would be that they should use Lotus as a dependency, and have a wrapper that switches on the version of Lotus used to execute messages. This is somewhat easier with the Eudico refactor from last year -- they could have multiple TipsetExecutors, one from Lotus v1.15.0 for v0-v15, and Lotus v1.16.0 for v16 and up.

Now there's no reason for why we couldn't do that in Lotus ourselves. It would be fairly easy to version the entirety of the core StateCompute logic (https://github.com/filecoin-project/lotus/tree/e65fae28de2a44947dd24af8c7dafcade29af1a4/chain/consensus/filcns). Unfortunately, that doesn't get rid of all of these stray checks -- we'd have to move a lot of the network-versioned logic (eg circ supply, migrations) behind such versioning, which wouldn't be trivial...but definitely doable.