Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Protocol Versions #197

Open
ZenGround0 opened this issue Mar 18, 2019 · 2 comments
Open

Protocol Versions #197

ZenGround0 opened this issue Mar 18, 2019 · 2 comments

Comments

@ZenGround0
Copy link
Contributor

ZenGround0 commented Mar 18, 2019

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
Copy link
Contributor Author

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
Copy link
Member

anorth commented Sep 12, 2019

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.

@pooja pooja removed P1 labels Sep 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants