Header revalidation

Same as validateHeader but used when the header has been validated before w.r.t. the same exact HeaderState.

Expensive validation checks are skipped (reupdateChainDepState vs. updateChainDepState).

Header validation

Header validation (as opposed to block validation) is done by the chain sync client: as we download headers from other network nodes, we validate those headers before deciding whether or not to download the corresponding blocks.

Before we adopt any blocks we have downloaded, however, we will do a full block validation. As such, the header validation check can omit some checks (provided that we do those checks when we do the full validation); at worst, this would mean we might download some blocks that we will reject as being invalid where we could have detected that sooner.

For this reason, the header validation currently only checks two things:

• It verifies the consensus part of the header.

For example, for Praos this means checking the VRF proofs.

• It verifies the HasHeader part of the header.

By default, we verify that

• Block numbers are consecutive
• The block number of the first block is firstBlockNo
• Slot numbers are strictly increasing
• The slot number of the first block is at least minimumPossibleSlotNo
• Hashes line up

If a particular ledger wants to verify additional fields in the header, it will get the chance to do so in applyBlockLedgerResult, which is passed the entire block (not just the block body).

Annotated information about the tip of the chain

The annotation is the additional information we need to validate the header envelope. Under normal circumstances no additional information is required, but for instance for Byron we need to know if the previous header was an EBB.

State required to validate the header

See validateHeader for details

Tick the ChainDepState inside the HeaderState

Ledger-independent envelope validation (block, slot, hash)

Validate header envelope

Invalid header

Reusable strict data type for TipInfo in case the TipInfo should contain IsEBB in addition to the HeaderHash.

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

A header paired with the time of the slot that it inhabits.

Note that the header's slot was translated to this time (in the ChainSync client) according to the header's chain. This clarification may be helpful, since it's possible that some other chain would translate that same slot to a different time.

Convert Header to HeaderWithTime

PREREQ: The given ledger must be able to translate the slot of the given header.

This is INLINEed since the summary can usually be reused.