Skip to content

Commit

Permalink
EraTransitionGovernance.md: also explain the `TestXxxHardForkAtEpoch:…
Browse files Browse the repository at this point in the history
… 0` exception
  • Loading branch information
nfrisby committed Mar 4, 2025
1 parent 146c8db commit c556ca2
Showing 1 changed file with 45 additions and 3 deletions.
48 changes: 45 additions & 3 deletions docs/website/contents/for-developers/EraTransitionGovernance.md
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,7 @@ All eras forbid proposals to increase the major protocol version by more than on
Thus the governance process within those eras (Byron, Alonzo, Babbage, and Conway, so far) that contain multiple major protocol versions must take place multiple times.
In turn, for example, at least the first two epochs of any Cardano chain will be in the Byron era.

## Byron
## Byron Era

The relevant Byron update proposal [increments the major component of the protocol version](https://github.com/IntersectMBO/cardano-ledger/blob/f5b35692b4d92d664187781a98b7af3fab445bad/eras/byron/ledger/impl/src/Cardano/Chain/Update/Proposal.hs#L219).
As with all Byron governance, it's a six stage process on-chain.
Expand All @@ -37,7 +37,7 @@ As with all Byron governance, it's a six stage process on-chain.
The proposal and all of the votes for one increment can be introduced in a single transaction.
Testnets when possible should introduce that transaction in the first slot of whichever epoch is intended to be the last with that protocol version, to maximize the probability that it enters the mempools and is included in a block soon enough, for example.

## Shelley, Allegra, Mary, Alonzo, and Babbage
## Shelley, Allegra, Mary, Alonzo, and Babbage Eras

These eras all use [an update proposal the increments the major component of the protocol version](https://github.com/IntersectMBO/cardano-ledger/blob/f5b35692b4d92d664187781a98b7af3fab445bad/libs/cardano-ledger-core/src/Cardano/Ledger/Core/PParams.hs#L355).
The stages on-chain are simpler than for Byron.
Expand All @@ -51,8 +51,50 @@ The stages on-chain are simpler than for Byron.
All of the proposals for one increment can be introduced in a single transaction.
Testnets when possible should introduce that transaction in the first slot of whichever epoch is intended to be the last with that protocol version, to maximize the probability that it enters the mempools and is included in a block soon enough, for example.

# Conway
*Remark*.
The function that constructs the initial Shelley ledger state from the final Byron ledger state actually ignores the incoming state's protocol version.
This function has other inputs, principally the given Shelley Genesis file, which includes a protocol version.
Note that the Byron Genesis file does _not_ include a protocol version (no one has ever needed Byron to start from a protocol version other than 0).

## Conway Era

The Conway era uses a dedicated [`Hard Fork Initiation` governance action](https://github.com/IntersectMBO/cardano-ledger/blob/f5b35692b4d92d664187781a98b7af3fab445bad/eras/conway/impl/src/Cardano/Ledger/Conway/Governance/Procedures.hs#L805-L810) to increment the major protocol version.

See [CIP-1694](https://cips.cardano.org/cip/CIP-1694) for the stages of the governance process, specifically the dynamics (eg dedicated quorum threshold) of "Hard Fork Initiations".

## Initializing the Chain with a Later Protocol Version

It is often convenient for testnet chains to entirely skip some initial protocol versions.
The node currently supports that for testing purposes via the following steps.

- Choose X, the desired protocol version for the testnet's chain to start with.
As a running example, suppose it is 6.0.
- Declare the `protocolVersion` field to be X (eg `{major: 6, minor: 0}`) within the `protocolParams` field within top-level JSON object of the Shelley Genesis file.
- In the node configuration file, include a `Test<Era>HardForkAtEpoch: 0` declaration for each Cardano era up to and including the era that contains X.
In the running example, protocol version X=6.0 is in Alonzo (refer to the table in the Introduction above), so the following declarations need to be present within the node configuration file.

```
...
TestShelleyHardForkAtEpoch: 0,
TestAllegraHardForkAtEpoch: 0,
TestMaryHardForkAtEpoch: 0,
TestAlonzoHardForkAtEpoch: 0,
...
```

*Warning*.
Values other than `0` should not be used with these settings.
Instead, use the necessary governance transactions to increment the protocol version as explained in the sections above.

With settings like those, today's node still starts from a Byron ledger state corresponding to the given Byron Genesis file (and with a protocol version of 0), but [it immediately](https://github.com/IntersectMBO/ouroboros-consensus/blob/a9a5f3aaf3ddd45b3dd58a132d65b657bbf285e5/ouroboros-consensus/src/ouroboros-consensus/Ouroboros/Consensus/HardFork/Combinator/Embed/Nary.hs#L268-L276) applies the ledger's translation functions to reach the appropriate era for X by the onset of slot 0.

- The translation from Byron to Shelley uses the protocol version specified in the Shelley Genesis file, regardless of the protocol version of the final Byron ledger state.
Some pointers into the code:
- The Consensus Layer translates the last Byron ledger state to the first Shelley ledger state with [this function](https://github.com/IntersectMBO/ouroboros-consensus/blob/a9a5f3aaf3ddd45b3dd58a132d65b657bbf285e5/ouroboros-consensus-cardano/src/ouroboros-consensus-cardano/Ouroboros/Consensus/Cardano/CanHardFork.hs#L265-L269).
- That function mostly delegates to [this function](https://github.com/IntersectMBO/cardano-ledger/blob/f5b35692b4d92d664187781a98b7af3fab445bad/eras/shelley/impl/src/Cardano/Ledger/Shelley/API/ByronTranslation.hs#L92-L100) in the Ledger Layer.
- That function sets the first Shelley ledger state's protocol parameters according to the translation context, which is built from the Shelley Genesis file by [this function](https://github.com/IntersectMBO/cardano-ledger/blob/f5b35692b4d92d664187781a98b7af3fab445bad/eras/shelley/impl/src/Cardano/Ledger/Shelley/Translation.hs#L77-L85).
- No subsequent translation (from each "Shelley-based era" to the next) alters the protocol version.

This interface is the result of historical choices.
It's not ideal, but it seems sufficient for the testnet use case.
In particular, the whole thing could be replaced by simply determining which initial eras to skip based on the protocol version given in the Shelley Genesis file and a flag indicating whether to skip Byron.

0 comments on commit c556ca2

Please sign in to comment.