The key used for the given period or a stub Poisoned value.

A key will be poisoned if it failed to evolve by updateKES, and will remain poisoned forever after that.

The HotKey could not be evolved to the given Period.

An uninhabited type representing the Praos protocol.

The chain dependent state, in this case as it is a mock, we just will store a list of BlockInfos that allow us to look into the past.

An association from epoch to stake distributions.

Should be used when checking if someone is the leader of a particular slot. This is sufficiently good for a mock protocol as far as consensus is concerned. It is not strictly necessary that the stake distribution is computed from previous epochs, as we just need to consider that:

1) an attacker cannot influence it. 2) all the nodes agree on the same value for each Slot.

Each pair stores the stake distribution established by the end of the epoch in the first item of the pair. See latestEvolvedStakeDistAsOfEpoch for the intended interface.

If no value is returned, that means we are checking the stake before any changes have happened so we should consult instead the praosInitialStake.

Fields that should be included in the signature

The fields that Praos required in the header

Praos parameters that are node independent

To be used in conjunction with, e.g., modifyMVar.

NOTE: when the key's period is after the target period, we shouldn't use it, but we currently do. In real TPraos we check this in tpraosCheckCanForge.

Create a PraosFields using a proof, a key and the data to be signed.

It is done by signing whatever is extracted from the extra fields by mkToSign and storing the signature and the extra fields on a PraosFields.

A validate view is an association from the (signed) value to the PraosFields that contains the signature that sign it.

In this mock implementation, this could have been simplified to use SignedSimplePraos but from the consensus point of view, it is not relevant which actual value is being signed, that's why we use the existential.

An error that can arise during validation

Convenience constructor for PraosValidateView

Static configuration required to run the consensus protocol

Every method in the ConsensusProtocol class takes the consensus configuration as a parameter, so having this as a data family rather than a type family resolves most ambiguity.

Defined out of the class so that protocols can define this type without having to define the entire protocol at the same time (or indeed in the same module).

" Ticked " piece of state, either LedgerState or ChainDepState

Ticking refers to the passage of time (the ticking of the clock). When a piece of state is marked as ticked, it means that time-related changes have been applied to the state. There are exactly two methods in the interface that do that: tickChainDepState and applyChainTickLedgerResult.

Also note that a successful forecast forecastFor (ledgerViewForecastAt cfg st) slot must equal protocolLedgerView cfg (applyChainTick cfg slot st). Thus a LedgerView can only be projected from a Ticked state, but cannot itself be ticked.

Some examples of time related changes:

• Scheduled delegations might have been applied in Byron
• New leader schedule computed for Shelley
• Transition from Byron to Shelley activated in the hard fork combinator.
• Nonces switched out at the start of a new epoch.