Slot and corresponding genesis key

PBFT state

For a window size of n, the PBFT chain state is a sequence of signatures over the last n slots

+-------------------------------------------+
|                signatures                 |
+-------------------------------------------+

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                 window of n

We need the last n signatures to verify that no single key has signed more than a certain threshold percentage of the slots.

When near genesis, we will have less than n signatures in the history.

The window size itself is pretty much arbitrary and will be fixed by a particular blockchain specification (e.g., Byron).

" Ticked " piece of state (LedgerState, LedgerView, ChainIndepState)

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 (or forecast).

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.

Window size

See PBftState itself for a detailed discussion on the window size versus the number of signatures.

Append new signature

Drops the oldest signature, provided we have reached the required number.

Empty PBFT chain state

In other words, the PBFT chain state corresponding to genesis.

Number of signatures in the window

This will be equal to the specified window size, unless near genesis

The number of blocks signed by the specified genesis key

This only considers the signatures within the window, not in the pre-window; see PBftState for detailed discussion.

The last (most recent) signed slot in the window

Returns Origin if there are no signatures in the window (this will happen exactly at genesis only).

Unaffected by EBBs, since they're not signed.

Note: we are not checking the invariants because we don't want to require the WindowSize to be in the context, see #2383. When assertions are enabled, we would notice the invariant violation as soon as we append.

PRECONDITION: the slots of the signers are in ascending order.