IntersectMBO / IntersectMBO/ouroboros-consensus
Reconsider counting blocks in the HFC
- Dominant language
- Haskell
- Stars
- 67
- Forks
- 43
- Avg merge
- 5d 13h
- Merged PRs (30d)
- 43
Description
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.
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.
Note that this implies the block counting will not veto the ledger's votes unless there is a Chain Growth violation.
This behavior is not strictly necessary. In particular, it is unclear whether it's worthwhile for the HFC to _ever_ disagree with the ledger.
This Issue is to summarize the relevant concerns and discuss with the appropriate architecture stakeholders. If the outcome requires a change to the implementation, that'll be a separate Issue.
Contributor guide
Assessment
This issue has not been assessed yet.