I was digging into Dusk's Succinct Attestation consensus, trying to understand what actually happens when a committee fails to produce a block in a given iteration. My assumption going in: a failed iteration means something went wrong — a fault, a missed slot, a problem to route around.
That's not quite it.
Dusk's consensus runs in iterations, each with its own randomly selected committee for proposal, validation, and ratification. If a committee doesn't reach quorum — maybe not enough validators responded in time, maybe network latency, nothing dramatic — the system doesn't treat that as a failure to patch. It just moves to the next iteration with a freshly selected committee. No block is lost, no chain forks, no rollback. The attempt simply expires and consensus tries again with different validators holding the responsibility.
What struck me is that this isn't a fallback bolted onto the design. It's the default expectation. The protocol assumes some iterations won't finalize, and builds the committee rotation around that assumption rather than around the hope that every iteration succeeds.
That changes how I read "block time" for Dusk. It's not one attempt with a timeout — it's a sequence of attempts where failure is routine, not exceptional, and finality just waits for whichever iteration actually converges.
I'm still not sure how this behaves under sustained network stress rather than isolated missed quorums. @Dusk_Foundation #dusk $DUSK
That's not quite it.
Dusk's consensus runs in iterations, each with its own randomly selected committee for proposal, validation, and ratification. If a committee doesn't reach quorum — maybe not enough validators responded in time, maybe network latency, nothing dramatic — the system doesn't treat that as a failure to patch. It just moves to the next iteration with a freshly selected committee. No block is lost, no chain forks, no rollback. The attempt simply expires and consensus tries again with different validators holding the responsibility.
What struck me is that this isn't a fallback bolted onto the design. It's the default expectation. The protocol assumes some iterations won't finalize, and builds the committee rotation around that assumption rather than around the hope that every iteration succeeds.
That changes how I read "block time" for Dusk. It's not one attempt with a timeout — it's a sequence of attempts where failure is routine, not exceptional, and finality just waits for whichever iteration actually converges.
I'm still not sure how this behaves under sustained network stress rather than isolated missed quorums. @Dusk_Foundation #dusk $DUSK