Generic hard fork state

This is used both for the consensus state and the ledger state.

By using a telescope with f ~ LedgerState, we will keep track of Past information for eras before the current one:

TZ currentByronState
TZ pastByronState $ TZ currentShelleyState
TZ pastByronState $ TS pastShelleyState $ TZ currentAllegraState
...

These are some intuitions on how the Telescope operations behave for this type:

extend

Suppose we have a telescope containing the ledger state. The "how to extend" argument would take, say, the final Byron state to the initial Shelley state; and "where to extend from" argument would indicate when we want to extend: when the current slot number has gone past the end of the Byron era.

retract

Suppose we have a telescope containing the consensus state. When we rewind the consensus state, we might cross a hard fork transition point. So we first retract the telescope to the era containing the slot number that we want to rewind to, and only then call rewindChainDepState on that era. Of course, retraction may fail (we might not have past consensus state to rewind to anymore); this failure would require a choice for a particular monad m.

align

Suppose we have one telescope containing the already-ticked ledger state, and another telescope containing the consensus state. Since the ledger state has already been ticked, it might have been advanced to the next era. If this happens, we should then align the consensus state with the ledger state, moving it also to the next era, before we can do the consensus header validation check. Note that in this particular example, the ledger state will always be ahead of the consensus state, never behind; alignExtend can be used in this case.

Information about the current era

Information about a past era

A h situated in time

Translate f x to f y across an era transition

Typically f will be LedgerState or WrapChainDepState.

Forecast a view y from a state x across an era transition.

In addition to the Bound of the transition, this is also told the SlotNo we're constructing a forecast for. This enables the translation function to take into account any scheduled changes that the final ledger view in the preceding era might have.

Knowledge in a particular era of the transition to the next era

Thin wrapper around sequence

Recover HardForkState from partial information

The primary goal of this is to make sure that for the current state we really only need to store the underlying f. It is not strictly essential that this is possible but it helps with the unary hardfork case, and it may in general help with binary compatibility.

Construct EpochInfo from the ledger state

NOTE: The resulting EpochInfo is a snapshot only, with a limited range. It should not be stored.

Construct EpochInfo given precomputed TransitionInfo

The transition and state arguments are acquired either from a ticked ledger state or a ledger view.

Extend the telescope until the specified slot is within the era at the tip