It is great to see these challenges being openly considered.
There is the old adage: “Be conservative in what you send and liberal in what you accept.” This may well be relevant to the topic of upgrades. I agree with the consensus expressed in this thread that single-event migrations are not feasible or desirable in a decentralised network.
One possible option would be to consider a sliding window of inter-operable versions such that any peer running a particular version is permitted to fully inter-operate with any other node running a version within the permitted window. Extending this concept to include a wider sliding window that allowed nodes running older versions (up to a point) to continue to be part of the network without losing their identity, but which would only permit them be a receiver and not a transmitter, may facilitate a more graceful upgrade process with less opportunity for the network to become disjointed.
Using the concept of a sliding window would afford the potential that a distant part of the network (in terms of peer hop connectivity) could be running a version that is incompatible with the local (pioneer) neighbourhood - but be bridged by a majority of nodes running versions whose sliding windows overlap both the pioneer and legacy versions.
What will be the motivation for a node to upgrade? Will this be a stick or a carrot or both? It sounds like @Jean-Philippe is suggesting a potential stick of losing identity - so what might be the carrot?
How will upgrade releases be controlled? Can anyone initiate the injection of an upgrade? In a truly decentralised network then the answer probably should be “yes”. Will consensus be used to agree that an upgrade be accepted into the network and for it to be rolled out? Again, this brings my thoughts back to the need for incentives: both for the proposer node (of an accepted upgrade) as well as pioneer nodes whose administrators put in the effort to assess and validate an upgrade’s worth, stability, security etc. As @tfa stated: automatic upgrades are a big NO - and I suspect that this may well be the position of a large proportion of administrators of non-consumer operated nodes - then my thoughts come back to the incentives for testing and validation.
Will there be the concept of roll-back? I can see the desirability for this in more than once reason:
- a proposed upgrade does not gain consensus
- a previously accepted upgrade is found to be less beneficial (stable, performant, secure etc.) than the previous version after it has reached consensus (but who can have the authority to make this decision to roll back? - or should it just roll forwards?)
I guess the network will distribute its own upgrade code. If the network were to test and validate the code automatically and, by consensus, upgrade automatically then it would have the potential to autonomously evolve - that is if nodes were to propose upgrades without human intervention. (Perhaps the incentive for submitting and testing upgrades shouldn’t be financial!) This may even lead to the network evolving in a way that purposefully excludes groups of nodes and culls certain content in a manner that we can not conceive at this time.