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[^1]. Recently, investigating https://github.com/input-output-hk/cardano-ledger/issues/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 https://github.com/input-output-hk/ouroboros-consensus/pull/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

• [x] There is now a HWW entry for the status quo of the HFC.
• [ ] https://github.com/IntersectMBO/ouroboros-consensus/issues/921

HFC behavior

• [ ] https://github.com/input-output-hk/ouroboros-consensus/issues/345
• [ ] https://github.com/input-output-hk/ouroboros-consensus/issues/416
• [ ] https://github.com/input-output-hk/ouroboros-consensus/issues/417
• [ ] https://github.com/input-output-hk/ouroboros-consensus/issues/413 (likely part of implementing alternatives to block counting)
• "Block counting" related:
  • [ ] https://github.com/input-output-hk/ouroboros-consensus/issues/385
  • [ ] https://github.com/input-output-hk/ouroboros-consensus/issues/389 (might supersede the previous point)
• [ ] https://github.com/input-output-hk/ouroboros-consensus/issues/419

HFC implementation/testing

• [ ] https://github.com/IntersectMBO/ouroboros-consensus/issues/1336

[^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.