Add early RANDAO pre-consensus emission SIP

[shane-moore]

Operators may emit the existing Proposer-duty RANDAO partial signature up to 2 slots before the proposal slot, so clusters can reconstruct randao_reveal before the slot starts instead of inside the post-Gloas ~3s block-production budget.

No new duty, role, message kind, domain, topic, or container is introduced. Protocol changes are limited to target-slot activation, message-validation timing, message-kind-scoped ordering, and complete-schedule duty handling. Receivers MAY additionally retain an otherwise-valid Unknown-duty candidate locally, but retention is optional and does not change the initial IGNORE gossip verdict.

The rules activate from the stamped proposal slot S: they apply when epoch(S) >= GLOAS_FORK_EPOCH, including when the permitted window for the first Gloas slots begins before the fork in wall-clock time. The SSV fork schedule is not an input.

Rationale and design discussion: #100
Addresses: ssvlabs/ssv-spec#373

[iurii-ssv]

LGTM overall, the suggestions below are mostly minor clarifications.

[iurii-ssv]

Just two non-blocking nits.

[iurii-ssv]

LGTM!

[shane-moore]

Pushed some commits tightening the validation contract, from some findings while implementing the receiver rules in anchor:

1. 0affc08 Pin validation ordering and stage authentication checks. The previous text required signatures strictly before the contextual rules. Anchor's pipeline (and, from our reading, go-ssv's) runs the cheap contextual checks first, and reordering would cost the duplicate-count shield in front of RSA verification. Now: structural and canonical-form checks MUST run first and define an "Early RANDAO candidate"; for candidates the signature-vs-contextual order is implementation-defined, short-circuiting only on non-retaining verdicts; any outcome that retains, accepts, forwards, or mutates state MUST first pass operator-signature verification (invalid signature plus Unknown duty is a pinned REJECT, never retained). Staging is explicit: RSA gates retention and forwarding, BLS gates consumption.

2. 60d143e Make duty-view and retention behavior deterministic. Pins points where two conformant receivers could diverge: Known requires the epoch's complete fetched proposer schedule (Anchor's duty tracker holds a locally filtered subset, which must not count as Known); retention is admission-conditioned; a byte-identical occupied-key duplicate keeps the original entry; full-capacity eviction has the incoming candidate compete under an exact total order; promotion is restated via promotion candidates (revalidate, promote only on success).

Test vectors added for each change.

[MatheusFranco99]

Good work @shane-moore !!
First review batch :)

[MatheusFranco99]

up to 2 slots before the proposal slot

Hmm, just by curiosity, why 2 slots, exactly?
Also, is there an edge case, like first epoch slot, in which one can't do 2 slots or even 1 in advance?
And if so how should them behave?
Possibly, clear edge-cases are the 1st and 2nd slots of the fork, right?

[shane-moore]

Good catch. The previous wording compressed three separate points.

EARLY_RANDAO_LEAD = 2 is the maximum earliness receivers must support, not an assertion that gossip needs two slots. The window gives a producer an opportunity during S - 2 and another during S - 1 if the earlier local publication attempt fails. Conforming clients may emit at different points in that window. Receivers accumulate shares asynchronously and reconstruct at 2f+1, so different schedules remain compatible, but the latest share needed for quorum determines when the reveal becomes available. We did not select a longer receiver window because it would increase reveal and stale-duty exposure without an identified need.

S >= EARLY_RANDAO_LEAD is only a genesis underflow guard for calculating S - 2. It excludes absolute slots 0 and 1, not the first two slots of every epoch or the Gloas activation epoch.

Let F be the first slot of a non-genesis GLOAS_FORK_EPOCH. There is intentionally no activation warm-up:

• S = F is eligible, and its producer window opens at slot_start(F - 2).
• S = F + 1 is eligible, and its window opens at slot_start(F - 1).
• Target slots before F remain ineligible.

The separate 500 ms producer delay remains guidance inside those windows. Because receiver timing also includes the clock tolerance, receiver validation and quarantine must be active no later than receiver-local slot_start(F - 2) - EARLY_RANDAO_CLOCK_TOLERANCE.

Commit c859af6 now makes this target-slot activation model explicit in the summary, rationale, qualifying-message rules, producer behavior, and cross-client test expectations. We also aligned Anchor's receiver, quarantine, and producer issues so implementations do not accidentally introduce a current-epoch gate.

[shane-moore]

Correction to part of my earlier reply: the activation model described there is unchanged, but the two-slot value is no longer used to prescribe an S - 2 attempt followed by an S - 1 retry.

It remains the maximum receiver window. The recommended producer attempt is now exactly S - 1; the 500 ms offset and coordinated second pre-slot attempt were removed.

Addressed in b29db38.

[MatheusFranco99]

gossip layers deduplicate before validation, so a second copy either never reaches validation or is the receiver's first copy.

Just to add: byzantine duplicates with a different signature for the same (duty, signer) won't be dropped by the naive gossip hash deduplication, but it will be by our app message validation logic that accepts only 1 partial beacon signature per signer per type (pre- or post- consensus) and per duty.

[shane-moore]

Good point. A byte-identical copy shares the original content-derived gossip ID, but changing the inner partial signature and re-signing the envelope normally produces a different gossip ID. That variant reaches application validation, where the existing one-message limit for the (MessageID, signer, slot) key and pre-consensus or post-consensus class stops it.

I narrowed the rationale to distinguish those cases. The duplicate limit itself does not need to change.

Addressed in c13987a.

[MatheusFranco99]

never unmark a seen message

I think they do so, but I also think we are just fine in here since it should be a window of 1 or 2 epochs. We just need to confirm.

[iurii-ssv]

Confirmed — they do expire, but with a wide margin: go-ssv's msgIDCacheTTL is 6.4 min (~32 slots) against this SIP's 24 s window. So "never unmark" is stronger than what implementations do; the conclusion holds, and stating the margin would be more convincing than the absolute.

[shane-moore]

Confirmed, thanks. I replaced both absolute claims, "never unmark" and "a few seconds," with the narrower statement that gossip duplicate-cache lifetimes can exceed the entire useful Early RANDAO window. The recovery wording now says the in-slot copy may be suppressed, since restart and local cache state matter.

Addressed in a939402.

[MatheusFranco99]

I think it could be useful to add a third column for a short description for each so the reading flow provides more intuition, what do you think?
For example EARLY_RANDAO_CLOCK_TOLERANCE appears only after some time in the document.

[shane-moore]

Agreed, addressed in 8a098c9.

[MatheusFranco99]

S >= EARLY_RANDAO_LEAD

Hmm, I got confused here... the slot number should be above 2? Or it was more in the sense:

• First enabled slot ever: $S - \text{[GLOAS FORK EPOCH.first slot]} \geq 2$?
• Or distance to duty slot: $0 \leq S (duty.slot) - now.slot \leq 2$ ?

[shane-moore]

Answered this together with the two-slot and fork-boundary questions here. In short, S >= EARLY_RANDAO_LEAD is only the absolute-slot genesis guard; the allowed distance from the current time is enforced separately by the producer and receiver timing rules.

[MatheusFranco99]

the first EARLY_RANDAO_LEAD slots at genesis

Ah, got it. But does it really make sense to do so? Shouldn't it be the first two of the activation epoch?

[shane-moore]

Covered this in the consolidated response here. We are keeping the genesis guard and not excluding the first two activation-epoch slots: F and F + 1 are eligible target slots, including their pre-fork emission windows.

[MatheusFranco99]

But what about the first slot of the fork?
Is there a warm-up, or, for this case, it would end up just sending on its slot and that's it?

[shane-moore]

Covered this in the consolidated response here. There is no warm-up: target slot F may emit from F - 2, so receiver support must be active before wall-clock Gloas.

[MatheusFranco99]

Wait, so it always also try to emit again once the slot starts?
I think there could be a problem here since re-creating a message and BLS-signing it takes time. Only if we have it cached...
But maybe a flag about the message being published well or not is enough, no? What do you think?

[shane-moore]

Yes, the ordinary in-slot path remains a SHOULD regardless of the recorded early outcome.

A local published flag is not enough to suppress it. Local enqueue, gossip publication, and peer receipt are distinct states, and successful local publication does not prove that the intended peers received the share.

The revised text also makes clear that a completed reconstruction MAY be returned immediately to the in-slot consumer without waiting for repeated signing or publication. Implementations MAY reuse cached valid signing artifacts or schedule emission independently.

Addressed in b29db38.

[MatheusFranco99]

Hmm, sorry I got lost in here. What is the purpose of doing that? Trying to let the receiver accept the msg due to the possibility of it having an earlier clock time and still being in the duty slot - 3? We can align msg validation for that rather than the logic (as we already do if I'm not mistaken)

[shane-moore]

You are right. The 500 ms value was additional producer-side slack, while EARLY_RANDAO_CLOCK_TOLERANCE = 1000 ms already handles the assumed clock disparity at the legal receiver boundary. Once the recommended emission moved to S - 1, the 500 ms offset no longer served a protocol purpose.

I removed it. The producer now SHOULD make its first early attempt at slot_start(S - 1), while the two-slot receiver window and 1000 ms receiver tolerance remain unchanged. I am open to another recommended lead if you think there is a better choice.

Addressed in b29db38.

[iurii-ssv]

Added some potential clarifications to consider

[iurii-ssv]

Confirmed — they do expire, but with a wide margin: go-ssv's msgIDCacheTTL is 6.4 min (~32 slots) against this SIP's 24 s window. So "never unmark" is stronger than what implementations do; the conclusion holds, and stating the margin would be more convincing than the absolute.

[iurii-ssv]

Just a minor followup.

[GalRogozinski]

Looks good! Just a clarity request

[GalRogozinski]

I find this whole section very hard to read. Maybe make a list of new rules and changed rules

[GalRogozinski]

Two conformant receivers can disagree after a refresh race: view replacement has no freshness rule.

Fix: bind installation to fetch recency — e.g. "A receiver MUST NOT replace an installed view with a schedule produced by a request issued before the request that produced the installed view" (or equivalently, key replacement to a newer observed dependent root).

"A newly retained complete schedule replaces the prior view" places no ordering constraint on which complete schedule wins. With overlapping refreshes — or two beacon nodes where one lags a reorg — an older complete response can arrive last and reinstate the pre-reorg schedule after the replacement was already installed. A receiver that suppresses stale responses then answers Known-and-assigned where one installing in completion order answers Known-and-not-assigned → IGNORE, for the same honest share. Distinct from the documented pre-replacement staleness interval: this permits rollback after replacement, and view flapping under multi-BN setups.

[GalRogozinski]

Registry lag is an unnamed permanent-loss class, and retention cannot cover it.

Fix: name it in the residual-loss enumeration: a receiver whose SSV registry has not yet indexed the message's validator drops the share at the existing unknown-validator/committee semantics checks; retention is unavailable by construction (it requires duty assignment to be the only non-passing check), and duplicate suppression can block the byte-identical in-slot copy — bounded by the same round-change fallback as stale-Known.

The SIP carefully enumerates its residual losses (stale-Known reorg, restarts, eviction), but this class is only implicitly inside "candidates that are not retained ... remain residual loss cases." Concrete case: a newly registered validator's first proposal, with the early share arriving before every committee peer has synced the registry. (The same lag also drops the duty's QBFT messages under the legacy proposer check — see the PR-level comment on duty-staleness policies.)

[GalRogozinski]

Design discussion (non-blocking for this PR): we now have three duty-staleness policies — should a follow-up unify them?

With this SIP, the stack answers "my duty view might be stale — what do I do?" three different ways:

1. ePBS SIP roles (7/8/9): skip the assignment check during a detected validator-set/dependent-root change window — fail-open, safe because those roles carry duty-count and distinct-signing-root caps.
2. This SIP (randao candidates): stale complete schedule stays authoritative — fail-closed IGNORE, with optional retention as the rescue. Justified: the proposer role has no per-epoch duty limit, so the assignment check is the only spam bound on the widened early window, and fail-open under an unboundedly long Unknown (BN outage) would remove it.
3. Legacy proposer QBFT/post-consensus (same MessageID as the randao share): unspecified — go-ssv happens to accept under an unfetched epoch.

The asymmetry between 2 and 3 is partly principled (one-shot pre-slot shares vs an interactive protocol that self-heals via round changes), but it produces transient disagreements within one proposer flow (e.g. duty-fetch outage: randao share IGNOREd while the same duty's QBFT proposal is accepted; registry lag: the reverse). Nothing breaks — but nothing says the split is intentional either, and an implementer unifying the two checks would silently change wire behavior.

Two asks, both satisfiable outside this PR:

• In this SIP: one sentence at the tri-state stating the split is intentional and why (the message-economics argument above), so it isn't "fixed" by accident.
• As a follow-up (here or in the Early RANDAO Pre-Consensus Emission #100 discussion): should the legacy proposer check adopt the complete-schedule authoritative view? It is the best-specified of the three (defined authority, registry-independence, defined replacement), and would fix the pre-existing registry-lag drop of a just-registered validator's QBFT messages — but a naive copy would import fail-closed Unknown into QBFT, a regression under BN outages, so it needs its own design pass rather than inclusion here.

[momosh-ssv]

Could this lead to unbounded, unpenalized distinct-byte injection? Duplicate counts mutate only on acceptance, and under an Unknown/not-assigned view every copy is IGNOREd — so a committee operator can re-sign the envelope over arbitrarily many distinct BLS fields (unchecked at validation) for one (signer, slot). Each copy costs an RSA verification, gives no scoring feedback, and is retention-eligible with store dedup left to implementations — contradicting line 23's "bounded by the existing one-message limit". Fix: count authenticated distinct containers seen (REJECT the second), cap retention at one entry per key, and add a candidate-path duplicate vector (none exists).

[momosh-ssv]

What happens to relay when the duty view is Unknown? In-slot copies are now candidates, so an Unknown-view receiver IGNOREs — and stops forwarding — in-slot randao it forwards today: one node's BN gap becomes a mesh propagation hole. That makes "falls back to today's in-slot exchange" circular (the fallback hits the same tri-state that failed the early copy) and regresses never-early operators (line 64), whose shares Unknown-view peers no longer relay. Either make Unknown forward-but-don't-consume (unlike Known-not-assigned, where IGNORE is justified), or state the relay consequence, stratify the testnet measurement by duty-view state, and pin it with a vector.

[momosh-ssv]

Do we need a per-signer dedup rule? In this duty-move case receivers hold two accepted shares from one signer for the epoch (X- and Y-stamped, identical inner signature and root). A root-keyed collector counting entries toward 2f+1 hits false quorum — 4 ops, f=1: 2 signers × 2 stamps = 4 entries vs threshold 3 — and reconstructs an invalid reveal that fails only at the BN. One sentence fixes it: a reconstruction counts at most one share per signer per signing root (a second replaces, never accumulates); the duty-move vector can then assert 2f+1 distinct signers over a mixed X/Y set.

[momosh-ssv]

Should we consider bounding only the early side? "MUST accept a candidate's timing iff" holds for any already-started slot — even ten epochs late — so one conformant reading has the formula override the lateness TTL and accept/forward arbitrarily late randao, leaving the past-slot half of the ordering exemption unbounded. "MUST NOT reject as too early iff …", with lateness applying independently, removes the ambiguity; the vectors cover only the early boundary, so add a late one.

[momosh-ssv]

Any reason "slot high-water marks" is still in line 68's mutate-on-acceptance list? I

t contradicts the MUST NOT here: an early candidate for slot 11 accepted during slot 9 either advances the mark, rejecting still-live slot-10 consensus/post-consensus traffic on the same MessageID under the unchanged rule, or it doesn't, and implementations diverge.

State that candidates neither read nor write any high-water mark (scope line 68's list to non-candidates). The consecutive-slots vector is randao-vs-randao only; this cross-class case is what the MUST NOT actually regulates.

[momosh-ssv]

Do we need to handle a validator that can't be resolved to an index?

Schedules key by validator_index, the MessageID by pubkey, so even with an authoritative view a just-registered validator is neither assigned nor provably not-assigned, and no branch is specified. I
It matters: pre-existing unknown-validator checks may REJECT (penalizing an honest share) where the tri-state says IGNORE, and retention eligibility differs (duty assignment must be the only failing check).

State precedence where existing rules resolve first with IGNORE not REJECT for candidates, or classify as Unknown, and narrow line 94's registry-independence claim to schedule authority.

[momosh-ssv]

Worth considering an intra-slot offset?

slot_start(S - 1) makes every early emitter fire at a slot boundary, competing with S-1 block propagation and the compressed post-Gloas attestation deadline. slot_start(S - 1) + SLOT_DURATION/2 still leaves ~6 s for gossip and reconstruction, halves the reveal-exposure window, and avoids the burst; at minimum add intra-slot offset to the mandatory lead comparison.

[momosh-ssv]

Should the tolerance match how the bound is stated?

"1 s pairwise" is exactly covered by 1000 ms, but clock bounds are usually per node vs true time, and ±1 s per node gives up to 2 s producer-receiver skew, IGNOREing honest boundary emissions.

Pin one: ±500 ms per node, or tolerance = twice the per-node bound. Only boundary emitters are exposed (recommended-lead producers have a full slot of slack).

[momosh-ssv]

Any reason "the post-Gloas useful-block deadline" isn't pinned to a definition?

It sits inside a MUST that gates mainnet activation guidance, so it needs a citable value or a cross-reference into the ePBS SIP (#94) — the same treatment GLOAS_FORK_EPOCH got.

[momosh-ssv]

Might be worth softening "a re-org can never invalidate it"?

A reorg can move the validator's assignment out of the epoch entirely, which is exactly why the reuse allowance in Reconstruction and consumption is epoch-scoped. "A re-org within the epoch can never invalidate it" matches the Specification.

[MatheusFranco99]

Following up on the message validation duty-staleness design.

I initially thought accepting a message under a missing duty view made no sense — without the duty you can't process it. But that reasoning has two issues: most nodes validating a message are relays that don't actually process it (non-committee), and on a committee node an accepted message just waits in the queue until the duty fetch lands. We already do exactly this on purpose btw in ssv node: the first-slot-of-epoch carve-out for RANDAO messages accepts while duties "are still being fetched." Meanwhile IGNORE is not as harmless as gossipsub's redundancy suggests, because the staleness causes here may be correlated (e.g. a common BN that impacts two operators).

On the other hand, accepting cannot be as simple to prevent spamming.
So my proposal for the proposer role is a tri-state:

• Known beacon state and assigned → pass.
• Known and not assigned → IGNORE (you have real evidence; receiver views can be stale, so never REJECT).
• Unknown → accept, backstopped by a new per-epoch duty cap for the proposer role (it's the one role missing from dutyLimit today).

Two honest caveats. First, unlike the registration/aggregator caps, a proposer cap is probabilistic rather than structural — a validator can draw more than 2 proposals in an epoch, it's just vanishingly rare — so the rule should state that, and the value (2, or 4 to be generous) is a judgment call (I think it's fine increasing up to the max possible, only for the proposer role ofc). Also, the cap fallback only ever binds while the view is Unknown (and soon we will have EIP-7917). Second, forwarding under Unknown is safe reputation-wise: duty-assignment failures are IGNORE-class everywhere, and every REJECT-class check (signatures, structure, counts) needs no duty view, so we never relay something a peer would penalize us for.

One consequence worth making explicit: this cap removes the stated justification for the early-RANDAO rule's fail-closed Unknown ("the assignment check is the only spam bound"). With the cap in place, the same tri-state can govern the RANDAO share and the legacy QBFT/post-consensus path — resolving the asymmetry between the two within one proposer flow, rather than documenting it as intentional. And EIP-7917's in-state proposer lookahead makes the Known side stronger over time: a complete schedule two epochs ahead, pinned by a dependent root, shrinks Unknown to deep-reorg and outage windows.