Shelley testing: check ocert replacement #663
Labels
Comments
mrBliss
referenced
this issue
in IntersectMBO/ouroboros-network
Jun 23, 2020
We were hard-coding `maxKESEvolutions` to 100 in the ThreadNet tests, even though the mock KES we use only supports 10 evolutions. When running the tests for a higher number of slots, this was causing failures, as we were trying to evolve keys more times than they support. Use the maximum number of evolutions supported by the KES algorithm (`totalPeriodsKES`) as `maxKESEvolutions`, so this can't happen again. Pick a value for `sgSlotsPerKESPeriod` so that the ThreadNet tests can run without re-issuing OCerts (until #2107 is done). Moreover, assert in `protocolInfoShelley` that the value chosen for `sgMaxKESEvolutions` is supported by the KES algorithm. A proper check (error instead of assert) should be done by the genesis validation in cardano-ledger-specs, see IntersectMBO/cardano-ledger#1516.
mrBliss
referenced
this issue
in IntersectMBO/ouroboros-network
Jun 23, 2020
We were hard-coding `maxKESEvolutions` to 100 in the ThreadNet tests, even though the mock KES we use only supports 10 evolutions. When running the tests for a higher number of slots, this was causing failures, as we were trying to evolve keys more times than they support. Use the maximum number of evolutions supported by the KES algorithm (`totalPeriodsKES`) as `maxKESEvolutions`, so this can't happen again. Pick a value for `sgSlotsPerKESPeriod` so that the ThreadNet tests can run without re-issuing OCerts (until #2107 is done). Moreover, assert in `protocolInfoShelley` that the value chosen for `sgMaxKESEvolutions` is supported by the KES algorithm. A proper check (error instead of assert) should be done by the genesis validation in cardano-ledger-specs, see IntersectMBO/cardano-ledger#1516.
mrBliss
referenced
this issue
in IntersectMBO/ouroboros-network
Jun 24, 2020
We were hard-coding `maxKESEvolutions` to 100 in the ThreadNet tests, even though the mock KES we use only supports 10 evolutions. When running the tests for a higher number of slots, this was causing failures, as we were trying to evolve keys more times than they support. Use the maximum number of evolutions supported by the KES algorithm (`totalPeriodsKES`) as `maxKESEvolutions`, so this can't happen again. Pick a value for `sgSlotsPerKESPeriod` so that the ThreadNet tests can run without re-issuing OCerts (until #2107 is done). Moreover, assert in `protocolInfoShelley` that the value chosen for `sgMaxKESEvolutions` is supported by the KES algorithm. A proper check (error instead of assert) should be done by the genesis validation in cardano-ledger-specs, see IntersectMBO/cardano-ledger#1516.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Expand the Shelley testing to replace operational certificates when necessary.
The text was updated successfully, but these errors were encountered: