IntersectMBO / IntersectMBO/ouroboros-consensus
Remove ShelleyGenesis from ShelleyLedgerConfig
- Dominant language
- Haskell
- Stars
- 67
- Forks
- 43
- Avg merge
- 5d 13h
- Merged PRs (30d)
- 43
Description
The difference between Babbage and Conway was intentionally as minimal as possible. This has a couple benefits.
- Clarke had orchestrated the integration of new eras. So it's nice that the first one we did without him is so minimal.
- The minimality helped us (especially in Clarke's absence) notice the aspects that we found confusing.
This Issue is about one such aspect: I don't think `ShelleyGenesis` (as `CompactGenesis`) should be in the `ShelleyLedgerConfig`. In other words, I'm proposing removing the following function.
```
Ouroboros.Consensus.Shelley.Ledger.Ledger.shelleyLedgerGenesis :: ShelleyLedgerConfig era -> SL.ShelleyGenesis era
```
I've catalogued its uses as follows:
- It's used in `Ouroboros.Consensus.Cardano.CanHardFork` for translating/forecasting from Byron to the first Shelley era. This is a necessary use.
- It's used in `Ouroboros.Consensus.Shelley.Ledger.Inspect`, `Ouroboros.Consensus.Shelley.Ledger.Ledger`, and `Ouroboros.Consensus.Shelley.ShelleyHFC` to get the value of `k`, `f` (only used to compute the stability window), `quorum`, `slotLength`, and `epochLength`. I think all of these could and should instead use the (already-existing!) `shelleyLedgerGlobals :: SL.Globals` field.
The second bullet point is for enabling the hard fork combinator, which every era needs to do. The first bullet point is instead for translating from Byron to Shelley, which only the first Shelley-based era needs to do. Moreover, I don't think we want to require that _any_ Shelley-based era could be the successor Byron, do we? So I propose:
```
data ShelleyLedgerConfig era = ShelleyLedgerConfig {
shelleyLedgerGlobals :: !SL.Globals
, shelleyLedgerTranslationContext :: !(Core.TranslationContext era)
, shelleyLedgerTranslationContextFromByron :: !(StaticMaybe (SL.ByronTranslationContext era))
}
data StaticMaybe :: Maybe Type -> Type where
StaticJust :: !a -> StaticMaybe (Just a)
StaticNothing :: StaticMaybe Nothing
```
(see https://github.com/input-output-hk/cardano-ledger/pull/3053#discussion_r1015751613 for motivating the `StaticMaybe` layer)
where in the ledger we have:
```
type family ByronTranslationContext era
type instance ByronTranslationContext ShelleyEra = SL.ParedDownShelleyGenesis
type instance ByronTranslationContext AllegraEra = Void -- or TypeError? (I originally wrote () here but then I objected to it on one of Bart's PRs :face_palm)
type instance ByronTranslationContext MaryEra = Void -- or TypeError?
type instance ByronTranslationContext AlonzoEra = Void -- or TypeError?
type instance ByronTranslationContext BabbageEra = Void -- or TypeError?
type instance ByronTranslationContext ConwayEra = Void -- or TypeError?
```
As a result of this, we should be able to remove all of the oxymoronic `TranslateEra ShelleyGenesis` instances. We'll have to replace them with `TranslateEra Globals` instances (or some translate-able data that determines the `Globals`). For example, these new translation instances won't even have a "genesis delegates" field, and so it'll avoid the existing confusing fact that the `TranslateEra ShelleyGenesis ConwayEra` instance does _not_ need to update the `sgGenDelegs` field!
Contributor guide
Assessment
This issue has not been assessed yet.