The hash of an endorser block, as ranking blocks announce it.

The hash of a ranking block's header, which votes sign.

Ranking blocks are Praos blocks, whose HeaderHash depends on blk. Use toRankingBlockHash to convert it to this monomorphic type.

Convert a ranking block's HeaderHash. It must be the same length as a RankingBlockHash, ie 32 bytes.

TODO Rule out a HeaderHash of another size at compile time, as Peras does with HashSize blk ~ 32, without requiring it of every RunNode block.

The hash of a transaction an endorser block references. It hashes all of the transaction's bytes, witnesses included, unlike the ledger's TxId and so the mempool's GenTxId, which hash only the transaction's body.

A Leios transaction, as the CBOR bytes of the ledger's transaction.

Its codec wraps those bytes as CBOR-in-CBOR, so receiving a transaction does not decode it.

TODO ChainSel and Leios voting will need a way to actually decode the transaction: a per-block-type decoder that takes the ledger state resulting from the announcing ranking block, whose era is the one the endorser block was announced in.

Uniquely identifies an endorser block in Leios. Could use 'Block SlotNo EndorserBlockHash' eventually, but a dedicated type is better to explore.

A ranking block leadership election: a slot and the pool it elected.

This is unrelated to the ElectionId type family, which identifies an election of a voting committee. We do not anticipate a module using both.

The derived Ord orders by slot first, which pruning relies on.

A vote for a Leios announcement.

An endorser block in the Leios overlay protocol. It endorses transactions by naming a list of TxHash and BytesSize pairs. Construct using mkEndorserBlock.

A compatibility layer over the ledger's EbReferences: consensus sees only this module's functions, never the ledger's representation.

The position of a transaction in its endorser block.

An endorser block naming these transactions, in this order.

The endorser block naming the transactions with these bytes, in this order. It names each by the TxHash and the length of its bytes.

The hash ranking blocks announce for the endorser block: that of its encoding.

The transactions an endorser block names, in order.

Encode an endorser block as the ledger does: a CBOR map from each transaction hash to the size of that transaction.

The mempool charges each transaction sizeEndorserBlockReference, and referencesCapacity subtracts the framing around the references. If the encoding changes, both must change with it.

The inverse of encodeEndorserBlock, given the whole input it decoded from, not just the endorser block's bytes: the ledger's annotator slices them by the byte offsets of this decoder's run. Like the ledger, it rejects an empty map of transaction references and one naming a transaction twice. It also rejects one whose bytes exceed maxEndorserBlockBytesSize. It can tell only after decoding them (if endorser blocks were wrapped as CBOR-in-CBOR, it would know their length before decoding them, even from an indefinite-length byte string), since a CBOR map gives its number of entries rather than of bytes. So the byte limit of the message carrying it must keep small the work it does before then, eg byteLimitsLeiosFetch.

The endorser block keeps its slice of those bytes, so its hash and encoding are of the bytes received.

The bytes one reference occupies for a transaction of the given size: the hash and the size, exactly as encodeEndorserBlock writes them.

Also used on the Dijkstra transaction measure, so the mempool charges a transaction what it will actually cost in the reference list rather than an approximation of it.

The size of encodeEndorserBlock: of the bytes the endorser block was received in, or of the ledger's encoding of one this node built.

The references capacity a maxEndorserBlockReferencesSize parameter yields: the parameter minus the framing encodeEndorserBlock writes ahead of the references. A parameter smaller than the framing exhausts the capacity, so no reference fits, rather than wrapping around to "no limit".

The design ceiling on an endorser block's encoding: what the node will forge, serve and size its buffers for.

TODO Nothing yet keeps the maxEndorserBlockReferencesSize protocol parameter within it, so a larger value would let an honest peer send an endorser block that decodeEndorserBlock rejects. Make it the constitution's guardrail on that parameter, and refuse to run with a parameter above it.

The most transactions an endorser block may name, given maxEndorserBlockBytesSize. Each reference takes at least as many bytes as sizeEndorserBlockReference charges a transaction of size 0, however it is encoded.

It derives from the design ceiling and not from the protocol parameter, since the buffers it sizes are allocated before any ledger state is in reach.

A duration the ledger gives in milliseconds.

The earliest slot at which a block may certify an endorser block announced in the given slot.

The announcement, voting and diffusion periods must all have elapsed. They are wall-clock durations, so the gap rounds up to whole slots: a block is forged at its slot's onset, so the answer is the first slot whose onset is far enough after the announcement.