ouroboros-consensus

ouroboros-consensus copied to clipboard

Motivating example: suppose we add a new constructor LocalStateQuery protocol. The question is: should this give rise to a new NodeToClient version? When we previously discussed this (starting at the end of https://github.com/input-output-hk/ouroboros-network/issues/2309#issuecomment-653392881, and continuing below), we concluded that there would not be too much point, since client code cannot actually take advantage of this new version. However, if client code can tell the network layer, I want at least version such-and-such, then incrementing the version makes perfect sense, and now the client can say "I need version x, because I need query A".

For tooling such as the CLI, the version required would then depend on which query it needs to submit, which depends on the command given by the user. Again, allowing the CLI to specify a minimum bound here, and have this be included in the version negotiation, makes a lot of sense: the CLI would then be able to report to a user "the node you're submitting this particular query to does not support it" rather than just getting some kind of serialization/deserialization failure.

Talking of serialisation/deserialisation, consensus side we would then take the following approach:

• Encoders for "extensible" types such as the local state query (but also, say, all of the HFC types) don't do anything special. They don't check version numbers at all, and just encode.
• The corresponding decoders all use a tag to distinguish between the different queries/eras/..., and so can report a sensible error when they get an unexpected one: "Unexpected query tag such-and-such, probably you need to adjust your version bounds or upgrade your software" or something along those lines.

Perhaps this should then be part of peer selection also, so that we select peers that support the versions we want. See https://github.com/input-output-hk/ouroboros-consensus/issues/386 .

@coot @dcoutts Ideally we have this by the time somebody needs another kind of query. A lower bound check + disconnect is not enough, peer selection should take it into account.

Peer selection? Isn't this about local clients?

Can't we just make the client side of the LocalStateQuery aware of the negotiated version and error if it tries to use a command when the version is too low? The user will get a nice error, and the version check is isolated in the client code.

No, we should also have a lower bound on the node to node protocol.

(Closed by mistake)

@nfrisby has a new proposal which is related, see IntersectMBO/ouroboros-network#4770