Documentation

Thrown when a peer's MsgLeiosBlockAnnouncement is one an honest peer would not send; the ensuing thread death disconnects it.

Thrown when a peer's MsgLeiosVotes holds a vote an honest peer would not send; the ensuing thread death disconnects it.

Why a vote is invalid.

A vote a client accepted from its peer, with what the node's VoteState needs to judge and relay it.

Accept a peer's MsgLeiosVotes, or say why the peer must go; see ExnLeiosNotifyInvalidVotes.

This does not check a vote's seat or signature. The node's VoteState will, once per vote, unless copies arrive simultaneously, so a badly signed copy of a vote the node already has costs it only the bytes; see ExnLeiosInvalidVote.

When a vote should be cast and relayed.

When a vote is worth relaying, given its election's ledger view and when its election slot began: from 3 L_hdr after until 3 L_hdr + L_vote + L_diff after, or until its announcement is no longer relayed, if sooner.

How much later than its deadline a vote may arrive without the node disconnecting the peer: enough for transmission, clock skew, and votes queued behind other traffic. Such a vote is too late to use, and the node's VoteState traces it.

TODO magic number; measure buffer bloat on a loaded network.

Thrown when a peer's offer over LeiosNotify is one an honest peer would not send; the ensuing thread death disconnects it.

Without these checks, peers could send bogus offers, and there are infinitely many of those.

Accept a peer's MsgLeiosBlockOffer, or say why the peer must go.

A peer may offer only an endorser block it has itself announced. That is what stops an offer from being an independent way to make us track an endorser block, outside the two-per-election cap on announcements.

Only the point is held to the announcements; the size is free, within the ledger's bound. An offer claims to hold a body, and whoever holds a body knows its size, so a peer may well state a size that no announcement we received claimed.

Accept a peer's MsgLeiosBlockTxsOffer, or say why the peer must go.

Held to the same announcement as the body offer and otherwise independent of it: either may arrive first, or alone. So a LeiosNotify server never has to track what it has already offered a peer in order to synthesise a body offer ahead of a closure offer.

What one LeiosNotify client remembers about its upstream peer.

Only an announcement adds to it, and every entry is for an election at or after lnpsPruneSlot; the node prunes it as its immutable tip advances.

Accept a peer's MsgLeiosBlockAnnouncement, or say why the peer must go.

An accepted announcement goes on to the node's AnnounceState.

Forget everything about elections before the given slot, which is the immutable tip's.