CarlosLopezDeLara commented 6 months ago

What

As an SPO or DREP or CC, after updating my node to the version that supports a specific hardfork, I want to query the node for the maximum protocol version it supports before casting my vote, so that I can confirm it supports the protocol version required by the hardfork.

Why

What if it doesn't? :scream: How do I know?

Acceptance Criteria

When I send a query to the node requesting the maximum protocol version it supports, then:

The node returns the maximum protocol version it currently supports
The response should be received within a reasonable timeframe.
The response is clear about Major and Minor components of the protocol version.

Personas

[x ] SPOs
[x] DReps
[x] CC members
[ ] dApp Devs
[ ] Exchanges
[ ] Wallets
[ ] 3rd party tools
[x] ADA holders

Definition of Done (DoD)

[ ] Acceptance Criteria + User Stories & DoD created and singed-off (by PO, dev & test owners)
[ ] Builds successfully on CI
[ ] Code & Test review (as per Acceptance Criteria)
[ ] There is documentation and/or examples for the new functionality (usage/response)
[ ] Log/record changes on Vnext (or similar depending on what we adopt)
[ ] Ticket number(s) included in PR description
[ ] All Acceptance Criteria met and covered by dev/unit/property/integration tests
[ ] System/E2E automated tests + System Test Engineer Owner Sign-off

NOTE: Ideally, we should merge only fully implemented and tested features into the master branch. So all the above steps are required for the PR to be merged.
In order to avoid the PRs becoming stale and requiring to be rebased on master, these can be merged after a reasonable time (current agreement is 3 days) if the System Test Engineer Owner's sign-off was not provided (last step in the DoD).

IMPORTANT: Any deviation from the plan should be discussed and agreed as a comment in the Feature file.

Sign-off

[ ] Product Owner
[ ] Dev Owner
[ ] System Test Engineer Owner

Related PRs

PR # here

gitmachtl commented 6 months ago

The max. supported Protocol-Version is hardcoded into the cardano-cli and cardano-node right? A function to expose that directly via cardano-cli would be super nice yes. Maybe there should be a general new function that shows cardano-cli internals, like this max supported version, minimal supported node-version, etc? Like the query-tip function, but for internals only, not live data. This should all also work offline.

carbolymer commented 6 months ago

@gitmachtl afaik CLI uses ledger's whatever max version is in the code. It's the node which validates if protocol version used is ok. Relevant PR: https://github.com/IntersectMBO/cardano-node/pull/5820/

gitmachtl commented 6 months ago

@gitmachtl afaik CLI uses ledger's whatever max version is in the code. It's the node which validates if protocol version used is ok. Relevant PR: IntersectMBO/cardano-node#5820

if you try to generate a hardforkcertificate with latest cli, and you try f.e. 12.1, it quits with the following error:

cardano-cli-latest: mkProtocolVersionOrErr: invalid protocol version (12,1)
CallStack (from HasCallStack):
  error, called at src/Cardano/CLI/EraBased/Options/Governance/Actions.hs:246:7 in cardano-cli-8.23.1.0-inplace:Cardano.CLI.EraBased.Options.Governance.Actions

calling it with protocol-version like 11.6 works.

so there is also some limitation (maxProtocol) in the cli itself

carbolymer commented 6 months ago

It uses this value: https://github.com/IntersectMBO/cardano-ledger/blob/master/libs/cardano-ledger-binary/src/Cardano/Ledger/Binary/Version.hs#L54 . I guess we can return this as well.