Investigate how to enact hardforks in the Voltaire phase

[JaredCorduan]

The way in which the consensus layer checks the ledger state to see if a hard fork should occur will be changing with the conway ledger era. For the full background, see CIP-1694.

The existing check has been unchanged (semantically) since the start of the shelley ledger era:

https://github.com/input-output-hk/ouroboros-network/blob/72863b0fc78abdc2b8e29f0dda96c06da3dd11d0/ouroboros-consensus-shelley/src/Ouroboros/Consensus/Shelley/Ledger/Inspect.hs#L121

In other words, it currently checks that quorum-many votes agree on a protocol parameter change, which implies a hard fork in the case when the major protocol version is changed.

(I had thought that the consensus code re-used the ledger function which does the same thing, namely votedValue, so perhaps the implementation details have changed.)

Starting in the conway ledger era, the new check will also inspect the ledger state, but it will instead look to see if a governance action to change the major protocol version has been staged for enactment. The exact details are still being decided.

[nfrisby]

The current state of CIP 1694 (which is not yet final!) specifies that there will be exactly one full epoch between a hard fork being decided aka ratified and it happening aka enacted.

It also currently lists the following sequence of enactments.

Actions that have been ratified in the current epoch are prioritized as follows for enactment:

• Motion of no-confidence
• New committee/threshold
• Update to the Constitution or proposal policy
• Hard Fork initiation
  ...

Therefore, the singleEraTransition method for ConwayEra should become Just e as soon as the e-1 to e epoch boundary will actually enact the hard fork initiation governance action. The only subtlety is determining whether other governance actions also scheduled for enactment on that same epoch boundary will prevent the hard fork initiation's enactment (eg as a motion of no-confidence would). But the necessary information for that should all be available simultaneously.

Thus, the ratification check at the boundary between e and e+1 fully determines whether the hard fork initiation will be enacted at the boundary between epoch e+1 and e+2.

And so the safe zone is for Conway is technically the duration of one epoch, and actually an exactly tight bound (ie = instead of a lower bound). However, there are two caveats in practice.

• The ratification calculation is relatively expensive. The computer can do it within a few seconds, but that's more time than the ledger rules should take per block. And so this calculation will be incrementalized. Thus the result of ratification will not be available until the incremental calculation is done, which is likely to be the first block after the scheduled end of that incrementalization (which is 4k/f last we heard). Therefore the safe zone could be 6k/f, or "6k/f minus however many slots it takes for the next block to arise").

• Issue Reconsider counting blocks in the HFC #389 et al currently means the transition from Nothing to Just e will actually happen as of the k+1st block of the epoch after the ratification boundary. Thus the safe zone is conservatively reduced to epoch length - two stability windows (ie 4k/f). (Our existing fundamentals only deal in increments of k blocks, sadly, but it's fine here.)

Note that the block counting delay and the incrementalization delay can overlap without complication: the block counting can begin after the "deadline" (ie the ratification epoch boundary) even before the results of ratification are computed.

[nfrisby]

I changed the status to Help needed because this is technically blocked on the final draft of CIP-1694.

We could technically finish this task before then, but only once the relevant details (those underlying my previous comment) are confirmed as final.

cc @dnadales @amesgen @WhatisRT

[dnadales]

@nfrisby could we close this one considering we also have this other issue, which is about integrating the Voltaire HF logic into Consensus, and considering you and Alex have a good understanding of how harforks work?

[dnadales]

The Ledger team confirmed:

This has been discussed a bunch of times with ledger and consensus folks and this schedule is the result of those discussions, so I don't expect any issues that would necessitate a change.

Modulo any issues found in the spec, of course.

[dnadales]

Closing this issue in favour of #920