Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Warn the protocol version is too low if we have ExperimentalHardForksEnabled #5883

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

palas
Copy link
Contributor

@palas palas commented Jun 25, 2024

Description

This PR makes cardano-node show a warning when the ExperimentalHardForksEnabled flag is set, and the specified version is less than the one specified for Shelley in its genesis file.

Checklist

  • Commit sequence broadly makes sense and commits have useful messages
  • New tests are added if needed and existing tests are updated. These may include:
    • golden tests
    • property tests
    • roundtrip tests
    • integration tests
      See Runnings tests for more details
  • Any changes are noted in the CHANGELOG.md for affected package
  • The version bounds in .cabal files are updated
  • CI passes. See note on CI. The following CI checks are required:
    • Code is linted with hlint. See .github/workflows/check-hlint.yml to get the hlint version
    • Code is formatted with stylish-haskell. See .github/workflows/stylish-haskell.yml to get the stylish-haskell version
    • Code builds on Linux, MacOS and Windows for ghc-8.10.7 and ghc-9.2.7
  • Self-reviewed the diff

@palas palas added the enhancement New feature or request label Jun 25, 2024
@palas palas self-assigned this Jun 25, 2024
@palas palas requested a review from a team as a code owner June 25, 2024 00:08
@palas palas requested a review from Jimbo4350 June 25, 2024 00:09
@@ -7,6 +7,7 @@
{-# LANGUAGE TypeApplications #-}

{-# OPTIONS_GHC -Wno-orphans #-}
{-# LANGUAGE BangPatterns #-}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should go with the other LANGUAGE pragma

(liftIO $ putStrLn $ "Warning: experimental hard fork version " ++ show hfMajor ++
" for " ++ era ++ " is less than the actual protocol version " ++ show actualMajor ++
" specified for Shelley on its genesis file.")
checkHardForkVersion _ _ _ = return () -- No need to check for epoch-based hard forks
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you make the _ on Consensus.TriggerHardFork explicit? So that, if TriggerHardFork receives a new case in the future, we get a non-exhaustive pattern warning?

Copy link
Contributor

@carbolymer carbolymer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I don't understand the change. Could you clarify it a bit? When the warning should be printed? When we're in babbage and experimental hard forks are enabled? Or when we're in bootstrap Conway and the flag is enabled? Or in any case?

-> ExceptT CardanoProtocolInstantiationError IO ()
checkHardForkVersion era (Consensus.TriggerHardForkAtVersion hfMajor) (ProtVer actualMajorVer _) =
let actualMajor = getVersion actualMajorVer in
when (hfMajor < actualMajor)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't that result in printing the warning for each previous era?

-> Consensus.TriggerHardFork
-> ProtVer
-> ExceptT CardanoProtocolInstantiationError IO ()
checkHardForkVersion era (Consensus.TriggerHardForkAtVersion hfMajor) (ProtVer actualMajorVer _) =
Copy link
Contributor

@Jimbo4350 Jimbo4350 Jun 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the problem in the slack thread was hard forking to Conway at epoch 0. So we're actually (at this point) not interested in TriggerHardForkAtVersion but we care about TriggerHardForkAtEpoch. We need two things:

  1. A mapping of Era -> Protocol Version
  2. Functions that check for the presence of the various npcTest${era}HardForkAtEpoch values.
    Then you can compare the defined protocol version in the Shelley genesis vs the expected protocol version.

See if you can use the Era class in cardano-ledger to avoid hard coding protocol versions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Jimbo4350 I am comparing the Eras with the protocol version. I am using the numbers already hardcoded in the function, and those can be overriden, apparently. So having a mapping wouldn't work? But I don't understand how the epochs fit on this. How do we link the epochs to versions? I may be completely wrong.

@palas palas marked this pull request as draft July 17, 2024 18:39
Copy link

github-actions bot commented Sep 1, 2024

This PR is stale because it has been open 45 days with no activity.

@github-actions github-actions bot added the Stale label Sep 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Stale
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants