Early RANDAO Pre-Consensus Emission

[shane-moore]

Normative text lives in PR #101; this post is rationale only. It covers the design choices reviewers are most likely to question, the gossip-layer findings that shaped them, and the alternatives we rejected. Follows up ssvlabs/ssv-spec#373 and the Discord thread that converged on proposal_slot - 2.

Why not a new duty

ProposerPreferences needed its own duty because its output must leave SSV before the slot and its content is mutable, so collection state has to exist per future slot. RANDAO has neither property: the reveal is a deterministic single root whose only consumer is the Proposer duty itself, at the slot. Early emission just needs the existing partial to travel earlier; the in-slot runner consumes it as usual. A dedicated duty would also still need the in-slot pre-consensus as its failure fallback, so we would ship two mechanisms to do one job, and one proposal's failure story would span two duties.

Why a 2-slot window, and why it is receiver-pinned but producer-free

The gossip wave needs well under a slot, so the window size is not about latency. Two slots buys a retry opportunity (a missed emission at S-2 leaves S-1) and keeps emission away from the epoch boundary. The receiver window is the fork-locked rule; when a producer emits inside it is policy. That split is deliberate: after the fork we can measure and narrow emission guidance freely, but widening the window would need another fork. Pinning the larger window keeps every later choice reversible. This also answers the "keep the timing open until we can test" position: it is open, on the producer side, permanently.

Epoch-start batching looks simpler and is not. It needs a ~32-slot earliness allowance, makes the slot-ordering exemption load-bearing for all proposer traffic instead of an edge case, turns the duty-knowledge race into the common case (emission at the exact moment every node fetches the new epoch's duties), widens reveal exposure ~16x, and lands on the busiest processing moment of the epoch. Same spec, bigger constants, rare paths promoted to hot paths.

What the gossip layer actually does with duplicates (this drove half the spec)

We verified the deduplication behavior in both stacks before writing the rules, and three facts turned out to be load-bearing:

1. Message IDs are content-derived and byte-identical across both clients, and a RANDAO partial has exactly one valid byte encoding (canonical SSZ, deterministic BLS, deterministic RSA PKCS#1 v1.5). One logical partial, one ID, network-wide.
2. The seen-cache is populated on first receipt, before validation, and no validation verdict removes the entry. TTL is ~6.4 minutes in both clients, far beyond the window.
3. A node that publishes bytes it already published has the second publish absorbed locally; it never reaches the wire while the node stays up.

Consequences, in order of how much spec they explain:

• The per-(signer, slot) limit stays 1. A second copy either dies in a seen-cache before validation or arrives at a peer with fresh state, where it is a first copy. Raising the limit to 2 (our own earlier plan) would have changed nothing.
• IGNORE is no longer a harmless drop. An IGNOREd early partial leaves its ID in the seen-cache, the on-time identical copy dies there, and the origin will not resend. One IGNORE = that share is gone for the window. That is why unknown-duty messages are retained locally rather than dropped, why known-unassigned stays IGNORE rather than REJECT, and why the earliness rule gets its own 1s tolerance instead of the generic 50ms (a producer at the window boundary with ordinary clock skew must not get poisoned).
• The in-slot emission stays on unconditionally. A running node's re-publish costs nothing (absorbed locally); a restarted node's re-publish is the only recovery path for peers that missed the early copy. Prohibiting re-emission, which we also originally planned, would have banned the useful case to prevent a case that cannot occur.

The ordering exemption's second direction came out of the same review: randao shares its MessageID with the proposal's consensus and post-consensus traffic, so an early partial for S+1 observed during slot S must not advance the high-water mark, or slot S's remaining messages get rejected as stale. The first direction (not being rejected below the mark) mirrors the ProposerPreferences precedent; the second is new because PP has its own MessageID and randao does not.

Other rejected options

• Same-epoch-only emission (skip duties whose window crosses the epoch boundary): would delete the retention buffer and the next-epoch-duty expectation for ~6.25% less coverage. Rejected because unknown-duty robustness is needed anyway (bootstrap, fetch failures), and the excluded proposals are exactly the ones whose in-slot fallback lands on the epoch-boundary load spike, where early emission helps most.
• A pull/re-request protocol for missed early shares: new wire surface to shave a residual whose cost equals the existing dead-leader round change. The measurement gate in the SIP exists to check that judgment against data before mainnet guidance.
• Bundling with RequestAuth or ProposerPreferences: different signed objects, mutability, and retry behavior; block proposals are rare enough that shared containers buy nothing. A shared early-emission trigger can come later without touching the wire.

Security reasoning beyond the SIP's conclusions

The widened reaction window is the design's real cost. Today an observer can reconstruct a cluster's reveal roughly 2-4s before the block publishes; early emission stretches that to up to 25s. What changes is not the proposer's grinding ability (unchanged in kind, one bit per slot) but third parties' time to act on it: compute the conditional effect of this slot's reveal, then bribe, censor, or DoS the four known operator endpoints if withholding favors them. We judged this acceptable because it is bounded by the existing single-proposal grinding bound, and because the producer-side timing freedom means the window can be operationally narrowed to near-today without a fork if it ever matters in practice.

Two properties worth knowing when reviewing the validation rules: seen-cache poisoning from deliberately mistimed emission is always self-inflicted (only the signer can produce the bytes, so an attacker can only starve its own share), and the retention buffer's worst case requires a committee operator sharing several hundred validators with the victim during a duty-fetch failure, for a payoff bounded at one evicted share and a round change.

Evidence and verification

Mechanics verified 2026-07-23 against go-ssv pr-2901-epbs-gloas @ 90df7fa0 with go-libp2p-pubsub v0.15.0, and Anchor unstable with its pinned rust-libp2p; ssv-spec main @ 5d11f26b confirmed no spec-repo changes are needed (the runner already stamps the duty slot; buffering and validation timing are node-side). The design went through an adversarial cross-model review that produced the ordering exemption's second direction, the retention redesign, and the per-duty fork predicate; the three residual risks it still flags are stated verbatim at the end of the SIP's Security Considerations.

Open questions for this thread

1. Constants sign-off: 1000ms earliness tolerance, 4096 retention cap, 500ms producer delay guidance.
2. The emission-timing measurement plan (what leads to test on testnet, and what incidence of missed early shares we would consider acceptable).