#dusk $DUSK @Dusk
Went through how a Dusk block actually gets certified this week because I wanted to understand what an "attestation" actually contains — not just that quorum was reached, but what the proof looks like structurally.
The consensus design has a two-step confirmation after a block candidate is proposed: Validation, where committee members vote Valid or Invalid, and Ratification, where a second committee confirms the Validation result. If both steps reach quorum, a success attestation is produced.
What's in an attestation: the quorum-reaching vote type (Valid, Invalid, NoCandidate, or NoQuorum), plus aggregated BLS signatures from both the validation and ratification steps. And a bitset. The bitset is the part I hadn't seen explained anywhere in summaries.
The bitset indicates which committee members' signatures are included in the aggregation. If the committee is [P0, P1, P2, P3] and the bitset is [0, 1, 0, 1], that means P1 and P3 signed.
That part is solid. One compact attestation carries everything needed to verify quorum — the vote, the aggregated proof, and the membership record — without the size scaling linearly with committee size.
What's harder to think through is what happens when attestations accumulate. A block that's "confirmed" needs sufficient successor blocks with their own attestations. If attestations are large in practice, or if nodes need to store full attestation histories for sync, there's a storage and bandwidth cost that doesn't show up in the quorum description alone.
I actually think the bitset is the genuinely clever part — it's what makes BLS aggregation practical when you need to later verify exactly who signed, not just that a threshold was met.
What I haven't figured out is whether fail attestations carry the same two-step aggregated structure as success attestations — or whether a fail result from just one step is sufficient to close the iteration without requiring both steps to complete. @Dusk
$DUSK #dusk
Went through how a Dusk block actually gets certified this week because I wanted to understand what an "attestation" actually contains — not just that quorum was reached, but what the proof looks like structurally.
The consensus design has a two-step confirmation after a block candidate is proposed: Validation, where committee members vote Valid or Invalid, and Ratification, where a second committee confirms the Validation result. If both steps reach quorum, a success attestation is produced.
What's in an attestation: the quorum-reaching vote type (Valid, Invalid, NoCandidate, or NoQuorum), plus aggregated BLS signatures from both the validation and ratification steps. And a bitset. The bitset is the part I hadn't seen explained anywhere in summaries.
The bitset indicates which committee members' signatures are included in the aggregation. If the committee is [P0, P1, P2, P3] and the bitset is [0, 1, 0, 1], that means P1 and P3 signed.
That part is solid. One compact attestation carries everything needed to verify quorum — the vote, the aggregated proof, and the membership record — without the size scaling linearly with committee size.
What's harder to think through is what happens when attestations accumulate. A block that's "confirmed" needs sufficient successor blocks with their own attestations. If attestations are large in practice, or if nodes need to store full attestation histories for sync, there's a storage and bandwidth cost that doesn't show up in the quorum description alone.
I actually think the bitset is the genuinely clever part — it's what makes BLS aggregation practical when you need to later verify exactly who signed, not just that a threshold was met.
What I haven't figured out is whether fail attestations carry the same two-step aggregated structure as success attestations — or whether a fail result from just one step is sufficient to close the iteration without requiring both steps to complete. @Dusk
$DUSK #dusk
