-
Notifications
You must be signed in to change notification settings - Fork 22
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
sketch for auto suspension #1258
Conversation
267725c
to
279a226
Compare
putBool finalizationAwake | ||
mapM_ putWord64be missedRounds | ||
putBool suspensionPrimed |
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.
Could combine the boolean flags with a bitmap.
6f62054
to
fc68e0c
Compare
15db203
to
ca98f6d
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.
This is looking good. I think it would be helpful to refine what the missed block count and primed for suspension actually mean.
- Missed block count: rounds that a validator won but failed to bake a block since the last round that a validator contributed to as a baker or finalizer, since it most recently became a (non-suspended) member of the validator committee.
- Primed for suspension: should be set on a payday when the missed block count exceeds the threshold. Should be cleared when the validator contributes again. At the snapshot epoch, validators that are primed will not be included in the next committee and will be set as suspended (if still an active validator).
If the payday length is 1 epoch, then each payday transition is also the snapshot for the next payday. For this to make sense, we need to determine the set of validators that should get suspended (i.e. the ones that are already marked as primed) before marking any validators as primed. I think this is consistent with the order of operations discussed elsewhere in this review.
(theState9, isSnapshot) <- | ||
if newEpoch + 1 == newNextPayday |
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.
(theState9, isSnapshot) <- | |
if newEpoch + 1 == newNextPayday | |
let isSnapshot = newEpoch + 1 == newNextPayday | |
theState9 <- | |
if isSnapshot |
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.
Here, we're calculating the the validators for the next payday, so we should take into account which validators are going to be suspended here and exclude them. (Not just the ones that are already suspended.) I would suggest we should calculate the validators that are going to be suspended (i.e. check which ones are primed) here, exclude them from the calculation in computeBakerStakesAndCapital
, and then return this set which is then passed on to processSuspensions
to actually suspend them in the epilogue.
41edd01
to
69ff933
Compare
69ff933
to
d4d31bf
Compare
This has been fully implemented now. I'll open two separate PR to bring the changes in. First one is #1264. This are only the new data structures. The second one will contain the implementation. |
Purpose
Discuss how to trigger suspension at snapshot. I filled in most of the missing pieces, but would like to be sure, that
processSuspensions
is doing the right thing.Changes
_Describe the changes that were needed.
Checklist
hard-to-understand areas.
CLA acceptance
_Remove if not applicable.
By submitting the contribution I accept the terms and conditions of the
Contributor License Agreement v1.0
link: https://developers.concordium.com/CLAs/Contributor-License-Agreement-v1.0.pdf
I accept the above linked CLA.