IntersectMBO / IntersectMBO/ouroboros-consensus

Reconsider counting blocks in the HFC

Open
#389 0 comments 0 reactions 1 assignee Claimed by @nfrisby View on GitHub
documentation
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.