Deterministic RaptorCast anchors the Raptor encoding to a publicly derivable seed, making it safe to vote directly on the Merkle root upon receiving a single verified chunk without decoding and saving one message delay on the critical path. It also closes two attack surfaces: asymmetric liveness, where a Byzantine leader deprives targeted validators of efficient decoding inputs causing reconstruction delays of several hundred milliseconds, and mixed-commitment equivocation, where a single Merkle root decodes to different payloads at different validators.
Regarding the proposal to vote on the Merkle root after receiving a single verified chunk: How does this impact the guarantee of data availability? While it certainly reduces latency, I’m curious if this change introduces a window where a validator might vote on a root for which the full payload hasn’t yet been fully propagated across the rest of the set
This is intentional pipelining. Dissemination and the first round of consensus voting proceed in parallel rather than sequentially. If QC forms from 2f+1 such votes, it guarantees that at least f+1 correct validators hold valid chunks, which is sufficient for any correct validator to reconstruct the full payload.