Information about the current era

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 a past era

Thin wrapper around sequence

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

Translate f x to f y across an era transition

Typically f will be LedgerState or WrapChainDepState.

Translate a LedgerState across an era transition.

Transate a LedgerTables across an era transition.

Translate a LedgerTables across an era transition.

To translate LedgerTables, it's sufficient to know how to translate TxIns and TxOuts. Use translateLedgerTablesWith to translate LedgerTables using translateTxInWith and translateTxOutWith.

This is a rather technical subtlety. When performing a ledger state translation, the provided input ledger state will be initially populated with a emptyLedgerTables. This step is required so that the operation provided to extend is an automorphism.

If we only extend by one era, this function is a no-op, as the input will be empty ledger states. However, if we extend across multiple eras, previous eras might populate tables thus creating values that now need to be translated to newer eras. This function fills that hole and allows us to promote tables from one era into tables from the next era.

NOTE: If either translateTxInWith or translateTxOutWith is a no-op (id), mapping over the diff with those functions is also equivalent to a no-op. However, we are still traversing the map in both cases.

NOTE: This function is only used on ticking, to prepend differences from previous eras, so it will be called only when crossing era boundaries, therefore the translation won't be equivalent to id.