CPS-???? | Automated Stake Pool Node Version Reporting

[ubani]

About this PR

I was seeing a provider that offered its service using an outdated node version.
Talking with different community members, I learned that - extrapolated over multiple years - outdated nodes could become an issue regarding network security, especially in combination with abandoned ADA that is still delegated to unmaintained or retired stakepools.

Thus - based on the novel Odysee in Space - I'd like to add the number 2001 or 2010 to this CIP.

My thought was, and this is the proposal, that there should be an easy automated way for delegators to spot the node version of a stakepool. Best place to display/track the node version would be from the wallets. Currently there is no automated process in place to achieve this result for all stakepools. The node version is only delivered when minting a block.

I am grateful that, among those members who participated in the discussion in Discord and shared their views and ideas were Tommy Kammerer, George [APEX], Danny Tuppeny [WEN_K], Homer [AAA], Vahid [A4G], Rick [RCADA], Sean [ENVY], Rich [ECP].

With one exception, the discussion participants did overall reflect very positively on the idea and added more value propositions to it. The exception wanted to keep a manual process in order to prove that the SPO knows what (s)he is doing.

[rphair]

@ubani the assignment of numbers to either CIPs or CPSs is not as arbitrary as people would think fromthe notable proposals that were based on a birth years of honorary figures in Cardano's timeline. If the community settles on a way of doing this I am sure whatever sequential number is finally chosen will become very well known regardless. 🤓

More importantly: the document you've submitted isn't suitable as a CIP. First, it's not in the format we've been using for the last several months:

• the preamble data at the top needs to follow this form: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001#header-preamble
• the outline follows older CIPs and the old template; the latest form is here: https://github.com/cardano-foundation/CIPs/blob/master/.github/CIP-TEMPLATE.md

I haven't suggested particular changes or edited the form outright because it really looks like this should be a CPS rather than a CIP (https://github.com/cardano-foundation/CIPs/tree/master/CIP-9999):

• The desired capabilities you've suggested in the Specification contain no specification about how these things would be done; they're actually Goals as described here: https://github.com/cardano-foundation/CIPs/tree/master/CIP-9999#goals
• These goals actually affect more than one of Cardano's subsystems (at least wallet and metadata) which would be two separate categories for CIPs: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001#categories ... but would be fine for a CPS because separate CIPs would handle these goals.

Since this can't move forward as a CIP unless narrowing its focus to a single achievable area with a much more detailed specification for it, and would need a substantial rewrite to be re-posted as a CPS, I'm re-classifying this as a Draft and tentatively titling it as a CPS. Please invite your previous contributors to discuss this process here (e.g. @katomm) and I'll be happy to help if there are questions during the transition. 😎

➡️ Once your CIP vs. CPS type is confirmed then please retitle the project folder (currently CIP-2001) to a folder without a number in it (e.g. CPS-????, CIP-node-version-metadata, CPS-node-version-reporting).

[ubani]

@rphair thank you, I'll follow up with your suggestions.

[AndrewWestberg]

This seems pretty fragile given that it relies on the honesty of the reporting pool. In general, I think the protocol version reported in made blocks is probably sufficient. You can also query a node's on-chain relays and check if they are supporting the latest network-protocol versions. This is a good way to detect old infrastructure without requiring ledger changes.

[ubani]

You can also query a node's on-chain relays and check if they are supporting the latest network-protocol versions.

I didn't know about this query option. So could this information already be implemented by wallet providers or explorers?
If the query returns the version, too, then relays could provide an indication of probability for the node version for PBs that haven't produced blocks yet, while block-producing PBs do report anyway.

[rphair]

@ubani we haven't seen you post anything since April on this pending work. Can you please indicate here if, when & how you intend to move this forward? 🙏

[ubani]

I have checked in with ETERNL they might add it to their features.
If they decide to add this option to their list, then we might have solved the issue.
In which case we would not have to proceed further, correct?

[rphair]

@ubani if you are suggesting that an Eternl implementation of stake pool node version verification would make this CPS unnecessary, I would be inclined to agree. In general the CPS is intended for problems that have no solution yet. Please report here on what you can find about this issue. 🙏