Protocol Versions

[ZenGround0]

Why?

In order to support live upgrades of the filecoin protocol, the protocol needs to have and be aware of a protocol versioning scheme. Every point along the chain where the consensus rules or the bits that they agree to change must be indicated by a new version. A complete spec will maintain a mapping from block heights (rounds?) to a protocol version.

Simple idea for representing the version

The simplest thing is to just use an integer or version name for each change. Each new version corresponds to a binary written w.r.t. a set of changes documented in spec.

More random ideas

There are a few high level categories of protocol changes. It might make sense to separate our version representation into 2-4 semantic pieces so that we can bump these changes in a finer-tuned way and allow implementers to deduplicate implementation changes.

1. Changes to the block format
2. Changes to the message format
3. Changes to the consensus validation rules (apart from trivial block + message format changes and state machine validation)
4. Changes to the state machine validation rules (apart from trivial message format changes)

If a version number looked like A.B.C.D with each part corresponding to one of the above types of changes, then implementations would know immediately they could use still use block format 1 when upgrading to 1.1.2.1 (a hypothetical upgrade modifying the tipset inclusion rule to allow all blocks with the same grandparents into a tipset) and 1.2.3.2 (a hypothetical upgrade introducing a multisig account actor into the state machine and changing the lookback parameter for leader election).

Maybe this is all overkill for the spec and this is something we should just let implementers figure out on their own. ¯ _(ツ)_/¯

Out of scope

We probably want to consider other network protocol interoperability questions separately. For example when nodes update their DHT, pubsub, autorelay or hello protocols they do need to take interoperability into account, but these concerns should be separate from blockchain validation rules and can potentially be treated with less care.

[ZenGround0]

Meta note: we need to archive older versions of the spec that specify protocol versions run on mainnet so that implementations can be built to sync the chain from genesis after upgrades.

[anorth]

I note that this issue is quite old. It's possible to implement upgrades without an explicit version number appearing in the bytes exchanged by nodes, and go-filecoin is implementing it that way. It could be helpful to add the protocol version to the hello message.