Proposals for second iteration of the HFC

[amesgen]

The most intricate parts of the HFC related to how time/era transitions are performed have been largely unmodified since they were first introduced¹. Recently, investigating IntersectMBO/cardano-ledger#3491 lead us to scrutinize these aspects, resulting in improving our understanding of the status quo and giving rise to potential improvements.

As the aforementioned issue has been resolved in #366 (albeit in a relatively ad-hoc fashion), there is no immediate need to make any large HFC changes. Instead, the purpose of this issue is to give an overview over the HFC-related changes that came out of this effort.

Documentation

• There is now a HWW entry for the status quo of the HFC.
• Document HFC #921

HFC behavior

• [FEAT] - Generalize how the HFC handles era transitions #345
• Remove TriggerHardForkAtEpoch #416
• HFC: require that every era contains at least one safe zone worth of slots #417
• Reconsider HFC requirement that ticking cannot make a transition become known #413 (likely part of implementing alternatives to block counting)
• "Block counting" related:
  • Cardano SingleEraBlock instances should stop counting blocks after the nonce snapshot #385
  • Reconsider counting blocks in the HFC #389 (might supersede the previous point)
• Reconsider requiring era transition knowledge to not be subject to rollback ("double stability") #419

HFC implementation/testing

• HFC: share implementation of reconstructSummary and summarize #1336

Footnotes

1. This is largely due to the fact that they did their job well, with one notable exception: https://github.com/input-output-hk/ouroboros-network/pull/3754 ↩

[nfrisby]

Alexey and I just had a nice chat, which included the potential of upstreaming the HFC's block counting into the Ledger's governance (only regarding HardFork initiation). He agreed it seems plausible and relatively straight-forward to implement --- and preferable to the HFC ever overriding the Ledger's governance.

In Conway, as it happens, it wouldn't even require any extra data: the difference between the BlocksMade maps' sizes is the count of blocks since the previous epoch boundary, which is the appropriate voting deadline. Moreover, the decision is made a stability window before the enacting epoch boundary, so we get the block count one stability window before enactment for free.

It also finally explicitly occurred to me that today's HFC prevents a hard fork from being the mechanism by which the community chooses to escape a low participation disaster. Which seems fine: I highly doubt a "proper" hard fork is how the community would prefer to end some disaster --- it's more likely to be a hotfix, with or without an intra-era hard fork.