What a protocol needs of its crypto: the Praos essentials, plus signing whichever header body it is the protocol for.

Praos consensus state.

We track the last slot and the counters for operational certificates, as well as a series of nonces which get updated in different ways over the course of an epoch.

Errors which we might encounter

Expresses that, whilst we believe ourselves to be a leader for this slot, we are nonetheless unable to forge a block.

Assembled proof that the issuer has the right to issue a block in the selected slot.

Praos parameters that are node independent

Fields arising from praos execution which must be included in the block signature.

What encoding PolyPraosState needs of its protocol.

LeiosOnly decides which fields are written. There is no inner version: the snapshot version covers it, and the HFC's era index precedes it, so the codec is already chosen when it is read.

" 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.

Ticked is used mainly in two ways:

• Ticked (Ext)LedgerState where its kind gets concretized to StateKind -> StateKind
• Ticked (HeaderState blk) where its kind gets concretized to Type -> Type

checkIsLeader for every Praos.

getOpCertCounters for every Praos.

getPraosNonces for every Praos.

The Leios header checks that read only the header and the ledger view.

Sound out of context: the bound they check is forecast for the header's own slot, so any path that validates the header reads the same value.

They run only for protocols with Leios, which are the ones that fill typeSwitchR.

What the next header may certify after crossing a boundary that rules out certifying the pending announcement, for this reason.

reupdateChainDepState for every Praos.

Re-update the chain dependent state as a result of processing a header.

This consists of: - Update the last applied block hash. - Update the evolving and (potentially) candidate nonces based on the position in the epoch. - Update the operational certificate counter. - Record the header's announcement, if any, replacing the previous one.

updateChainDepState for every Praos.

Validate and update the chain dependent state as a result of processing a new header.

This consists of: - Validate the VRF checks - Validate the KES checks - Call reupdateChainDepState

tickChainDepState for every Praos.

Updating the chain dependent state for Praos.

If we are not in a new epoch, then nothing happens. If we are in a new epoch, we do four things: - Store the existing current epoch nonce as the "previous epoch" nonce. This is needed to validate Peras certificates when they appear in blocks. - Update the epoch nonce to the combination of the candidate nonce and the nonce derived from the last block of the previous epoch. - Update the "last block of previous epoch" nonce to the nonce derived from the last applied block. - Mark the pending announcement as no longer certifiable, since an endorser block may not be certified across an epoch boundary.

doValidateKESSignature, parameterized by whether to enforce the OCERT counter's upper bound (see WhetherToUpperBoundOCERT).

getLeiosAnnouncement for every Praos.

getLeiosLedgerView for every Praos.

validateLeiosAnnouncement for every Praos.

The election proof (VRF) and the signature (KES and operational certificate) are checked in full. The operational certificate counter is not upper bounded, since a counter ahead of our immutable tip's record is honest lag. A counter below that record, or no record at all, yields StaleOCIN rather than a rejection, since that lag can explain either too. The certification gap check is skipped: it needs the header's predecessor, and an announcement is checked without one.

Whether doValidateKESSignature' enforces the OCERT counter's upper bound, i.e. rejects (with CounterOverIncrementedOCERT) a counter more than one greater than the one we have recorded for this issuer.

Normal header validation enforces it (UpperBoundOCERT). Validating a relayed Leios announcement out-of-context against a (possibly lagging) immutable tip legitimately sees counters that have run ahead of our recorded view, so that path skips it (DoNotUpperBoundOCERT). The counter's lower bound (CounterTooSmallOCERT, a revoked key) is enforced either way.

Why the next header may certify no announcement.