The Leios node must relay EbAnnouncements promptly. CIP-0164 is designed around the idea that an EbAnnouncement at an honest stake pool will have propagated to all other honest stake pools within L_hdr, and suggests a value of 1 second. On a network that spans the globe, that's a very tight window. But each EbAnnouncement is slightly less than 1 kB, so it does seem plausible.

In the current design of CIP-0164, the existing Praos header (aka RbHeader) was extended with new fields. One of those fields is an optional tuple: EbBody hash and EbBody size. That's the announcement. As part of the RbHeader, it is adjacent to the election proof that justifies the EbAnnouncement and it is signed by the electee. Because that election proof necessarily includes the slot of the election, every EbAnnouncement has an age. In particular, that age is used to evict too-old announcements so that the existing stochastic bound on the number of elections younger than some age also bounds the number of in-memory EbAnnouncements: zero (no announcement), one (unequivocal announcement), or two (equivocal announcements) per sufficiently-young election.

The LeiosNotify mini protocol in CIP-0164 already includes a notification MsgLeiosAnnouncement, whose payload is the RbHeader. It is sent as one of the possible responses to the generic MsgLeiosNotificationRequestNext message. The healthy honest node tries to maintain ~hundreds of those requests outstanding at all times, so that the upstream peer can always enqueue a notification immediately. The intended timeline one a single connection from an honest node X to an honest node Y is as follows.

• X either receives or itself issues a new valid EbAnnouncement.
• If that's the first or second announcement X has seen for that election, then X tries to relay that announcement to its downstream peers, including Y.
• X will be able to send to Y, because X should have received at least one more MsgLeiosNotificationRequestNext message from Y than X has already replied to.

TO BE IMPORTED QUALIFIED