-
Notifications
You must be signed in to change notification settings - Fork 155
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
Fix epoch rule and tests #3801
Fix epoch rule and tests #3801
Conversation
libs/cardano-ledger-test/src/Test/Cardano/Ledger/Examples/ConwayFeatures.hs
Show resolved
Hide resolved
0599fc8
to
3789175
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The hardest thing to follow is what is the state of the pulser at the beginning of time. Do we start in the epoch rule? or just after the the epoch rule has run. The state of the pulser will have to be different, if we choose one or the other.
libs/cardano-ledger-test/src/Test/Cardano/Ledger/Examples/ConwayFeatures.hs
Show resolved
Hide resolved
libs/cardano-ledger-test/src/Test/Cardano/Ledger/Examples/ConwayFeatures.hs
Show resolved
Hide resolved
The state of the pulser at the beginning of time is in complete state with everything empty and the EnactState matches the EnactState in the GovState
Putting initialization of pulser at the beginning of the EPOCH rule will not make it any simpler, since no matter how you set it up, the very first thing we must do is actually extract the result of the previous pulser, because that is what we need to enact in the EPOCH rule. So, you still have the same problem of what is your initial state of the pulser |
3789175
to
a237b92
Compare
a237b92
to
7d4685c
Compare
* Redo how we construct DRepPulser * PParams are now properly updated and rotation of enact state is correct * `totalObligation` for the `utxosDeposited` field was computed before proposal deposits were returned * `DRepPulser` was started with a state that was not fully updated. Creating of the pulser must be the last step in the EPOCH rule * `DRepPulser` was started with an epoch number value that was one into the future, which resulted in proposals expiring one epoch too soon and theoretically, although very unlikely, could have affect DRep expiry as well. * When `NewEpochState` was translated from Babbage to Conway, only the pparams in the `EnactState` were updated, but not the state of the Pulser. Which normally would result in `PParams` to be reset at the very first Epoch in Conway, however, together with a bug in the EPOCH rule this resulted in alternation of `emptyPParams` with actual `PParams`
* Prior to Conway eras where also changing the previous params, which is not needed. * Conway ImpTest did not chnage the future PParams * Also change a misleading name of a test helper `isGovActionAccepted` to `canGovActionBeDRepAccepted`
* Also add ratification info to logging in imp testing
7d4685c
to
aafef22
Compare
aafef22
to
baac6be
Compare
Description
A whole collection of bug is fixed in this PR:
In the EPOCH Rule
totalObligation
for theutxosDeposited
field was computed before proposal deposits were returnedIn the translation
When NewEpochState was translated from Babbage to Conway, only the pparams in the EnactState were updated, but not the state of the Pulser. Which normally would result in PParams to be reset at the very first Epoch in Conway, however, together with a bug in the EPOCH rule this resulted in alternation of
emptyPParams
with actualPParams
In testing
modifyPParams
function and in theemptyImpNES
Checklist
.cabal
andCHANGELOG.md
files according to theversioning process.
.cabal
files for all affected packages are updated. If you change the bounds in a cabal file, that package itself must have a version increase. (See RELEASING.md)CHANGELOG.md
for the affected packages. New section is never added with the code changes. (See RELEASING.md)fourmolu
(usescripts/fourmolize.sh
)scripts/cabal-format.sh
)hie.yaml
has been updated (usescripts/gen-hie.sh
)