You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(This is labeled as a bug, but it's only in a corner case that is already well outside the Ouroboros spec's "nominal".)
The HFC counts blocks after the voting deadline so that it can veto the era transition if there were not yet k+1 blocks after the deadline. This is the only way to ensure that (normal) rollbacks (max of <=k) cannot change the votes (if you question that motivation, see Issue #389, but take it for granted as desired for the scope of the current Issue).
The voting deadline is intentionally set to the 10k/f - two stability window mark, ie 4k/f. This ensures that---in the absence of a Chain Growth violation---the k necessary blocks (off-by-one?) will arise before the 7k/f mark, and so the next epoch's era will be determined at least one stability window before it starts (which is at least currently when the nonce is snapshot, which finally determines the next epoch's leader schedule).
Note that this implies the block counting will not veto the ledger's votes unless there is a Chain Growth violation.
We recently realized that the HFC counts blocks all the way up to the epoch transition. Thus, in a particularly severe Chain Growth violation, the k+1st block might arise just a few slots before the end of the epoch. In this case, the HFC will switch to the next era, which is a directly violation of the HFC's "safe zone" concept.
This Issue is to prevent that safe zone violation (which is also a ledger-stability violation) by changing the HFC to only count blocks between the 4k/f and 7k/f marks.
The text was updated successfully, but these errors were encountered:
nfrisby
changed the title
HFC should stop counting blocks after the nonce is snapshot
HFC should stop counting blocks after the nonce snapshot
Oct 2, 2023
nfrisby
changed the title
HFC should stop counting blocks after the nonce snapshot
Cardano SingleEraBlock instances should stop counting blocks after the nonce snapshot
Oct 4, 2023
I'm assuming (in the Issue title eg) that the next era should be known at least as soon as the next leader schedule should be known. I asked Christian B, Peter G, and Alexander R on Slack to confirm.
(This is labeled as a bug, but it's only in a corner case that is already well outside the Ouroboros spec's "nominal".)
The HFC counts blocks after the voting deadline so that it can veto the era transition if there were not yet k+1 blocks after the deadline. This is the only way to ensure that (normal) rollbacks (max of <=k) cannot change the votes (if you question that motivation, see Issue #389, but take it for granted as desired for the scope of the current Issue).
The voting deadline is intentionally set to the 10k/f - two stability window mark, ie 4k/f. This ensures that---in the absence of a Chain Growth violation---the k necessary blocks (off-by-one?) will arise before the 7k/f mark, and so the next epoch's era will be determined at least one stability window before it starts (which is at least currently when the nonce is snapshot, which finally determines the next epoch's leader schedule).
Note that this implies the block counting will not veto the ledger's votes unless there is a Chain Growth violation.
We recently realized that the HFC counts blocks all the way up to the epoch transition. Thus, in a particularly severe Chain Growth violation, the k+1st block might arise just a few slots before the end of the epoch. In this case, the HFC will switch to the next era, which is a directly violation of the HFC's "safe zone" concept.
This Issue is to prevent that safe zone violation (which is also a ledger-stability violation) by changing the HFC to only count blocks between the 4k/f and 7k/f marks.
The text was updated successfully, but these errors were encountered: