-
Notifications
You must be signed in to change notification settings - Fork 170
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
Comments
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. |
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. |
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.
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 to1.1.2.1
(a hypothetical upgrade modifying the tipset inclusion rule to allow all blocks with the same grandparents into a tipset) and1.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.
The text was updated successfully, but these errors were encountered: