First tick across the era boundary when translating the ledger/chain-dep state #340

This adds an extremely simple mechanism that increments protocol versions on era boundaries. The motivation is to showcase that due to how HFC ticking is implemented, this does not do what one would expect. See #340 for a concrete scenario where this behavior is problematic.

Trivial generalization that will be used in subsequent commits

In a subsequent commit, we will use this extra information when invoking `State.align`.

Initial motivation for this is the need (in a later commit) to implement the translation of the last *ticked* Byron ledger state to the first Shelley state, which becomes possible as `ByronTransition` is part of the ticked Byron ledger state. Apart from the translation to Shelley, this tip block number is only used to check whether an update proposal became stable, so it makes sense to make it part of `ByronTransition` in any case.

This doesn't actually change any code, and is mostly done to highlight the changes to this function in the next commit.

See #339 for explanation/motivation.

In a single-era context, this change makes no difference for the slot field in the unticked `ChainDepState (T)Praos`, as the slot we last ticked to will always be the slot of the last applied block. However, in a later commit, we will change how the HFC does cross-era ticking, namely by first ticking just across the epoch boundary using the old era's logic, then translating, and then ticking to the target slot using the new era's logic. - Without this change, as the slot in the unticked `ChainDepState` is not update by ticking, we would conclude twice that we are ticking across an epoch, which is incorrect. - With this change, only the first tick considers itself to cross an epoch boundary. Hence, after the translation step, the slot in the unticked `ChainDepState` will *not* contain the slot of the last applied block, but rather the slot just after the era boundary (as we ticked to that slot in the first tick). Note that this is purely an intermediary state in the HFC.

Context: This commit enables changing the HFC protocol logic for ticking. This change is based on the observation that all single-era `ConsensusProtocol`s except TPraos do not actually need the `LedgerView` when ticking at all; they just store it in the `Ticked ChainDepState` such that it can be used by other functions from `ConsensusProtocol`, such as `updateChainDepState` and `checkIsLeader`. Hence, we can introduce a new type family `HorizonView` (that will be set to `()` for all single-era protocols except TPraos), and decompose `tickChainDepState` into `tickChainDepState_` (which now only takes a horizon view instead of a ledger view) and `projectHorizonView` (which allows one to always get a horizon view from a ledger view). TPraos and the HardForkProtocol are just minimally modified to make them compile; they will be adapted in subsequent commits. Co-authored-by: Nicolas Frisby <[email protected]>

This commit minimizes the `HorizonView` for TPraos from the full `LedgerView` to just the extra entropy nonce (a ledger protocol parameter), which is the only part of the `LedgerView` needed for ticking. Co-authored-by: Nicolas Frisby <[email protected]>

Sole motivation is to make HFC protocol ticking analogous to HFC ledger ticking which was already changed in an earlier commit. Co-authored-by: Nicolas Frisby <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

First tick across the era boundary when translating the ledger/chain-dep state #340

First tick across the era boundary when translating the ledger/chain-dep state #340

Commits on Sep 21, 2023