Network level versioning

[pipermerriam]

What is wrong

#371 implements a versioning scheme for the base transport protocol. This does not cover breaking changes to the individual network protocols, such as changes to the content-key/content-id scheme.

How can this be fixed.

I think that we probably want to fix this in a similar manner.

• Sub-Protocols will have their own version number.
• ENR records can be used to transmit version information for the sub-protocol versions.

What gets complex is that Nodes without any version overlap should not communicate... which means that they shouldn't be in each other's routing tables... which also suggests that you shouldn't respond to a FIND_NODES request with a node who has no version overlap...

So this kind of change has somewhat deep effects on the network topology, and in theory could have effects like network partitioning in extreme cases.

Overall I think this scheme works, but I want people to spend a little time thinking about the deeper effects it is likely to have.

[KolbyML]

I am not a fan of this direction.
As we can't store all the subnetworks upgrade keys in the same enr over time, due to a size limit of 300 bytes for the enr. Our Enr's are exchanged at the discv5 level in addition to these it would be needless complexity to handle 3 different versions of the Enr.

We wouldn't be generating the updated Enr's on the fly either as to update an Enr you have to sign the changes.

I think we should use pv for all changes with the idea that protocol version changes will drastically slow down as Portal matures.

[pipermerriam]

Interesting, so still bumping global protocol version for content-key/content-id style changes? This seems viable. The simplicity seems appealing. Curious what others think.

[morph-dev]

I would like to understand what are the common network breaking changing that we are taking into consideration. I can't think of any that requires versioning. Few examples:

• breaking change to the content id/key/value: we should just introduce new content id/key/value
  • clients can handle internal migration from one type to another and/or support both for some time (until all clients migrate)
  • this makes spec less clean (e.g. we would have to keep track of obsolete content-key selectors)
• breaking change in some fundamental level (e.g. distance metrics is changed): just create new network/subprotocol
  • this is a tool that can to be used for any breaking change, but probably too big hammer in most of the cases
  • same as above, clients can migrate data if applicable

[GrapeBaBa]

I agree with @KolbyML , just use pv for simplify. We could encode(protocol version + network type + network version) in pv to avoid frequent changes in a single global version.