@Dusk_Foundation
16 consecutive failed iterations is enough to make Dusk stop behaving normally.
I read that number a few times before it landed.
Under normal conditions, consensus steps run against a timeout. If a step doesn't produce a result in time, it outputs nothing and the round tries again.
Try. Timeout. Try again.
I assumed that failure path stayed in place no matter how bad things got.
It doesn't.
After 16 consecutive failures, Dusk disables those timeouts. Steps can no longer return NoCandidate or NoQuorum. Iterations keep running until a candidate actually reaches quorum for validation and ratification.
That creates a second failure mode I hadn't separated before.
Normal failure is bounded by the clock. Emergency mode removes that boundary.
And that introduces another problem: multiple open-ended iterations can run at the same time, creating the possibility of competing candidates reaching quorum in the same round.
Dusk already has a rule for that case: the candidate that reaches quorum at the lowest iteration wins.
What I still don't know is what 16 consecutive failures actually looks like on a live network.
What kind of sustained network condition gets you there, and how often would the fork-resolution rule actually be exercised rather than remaining a theoretical path?
$DUSK becomes more interesting to me if this emergency path proves reliable when the network actually needs it.
#dusk
16 consecutive failed iterations is enough to make Dusk stop behaving normally.
I read that number a few times before it landed.
Under normal conditions, consensus steps run against a timeout. If a step doesn't produce a result in time, it outputs nothing and the round tries again.
Try. Timeout. Try again.
I assumed that failure path stayed in place no matter how bad things got.
It doesn't.
After 16 consecutive failures, Dusk disables those timeouts. Steps can no longer return NoCandidate or NoQuorum. Iterations keep running until a candidate actually reaches quorum for validation and ratification.
That creates a second failure mode I hadn't separated before.
Normal failure is bounded by the clock. Emergency mode removes that boundary.
And that introduces another problem: multiple open-ended iterations can run at the same time, creating the possibility of competing candidates reaching quorum in the same round.
Dusk already has a rule for that case: the candidate that reaches quorum at the lowest iteration wins.
What I still don't know is what 16 consecutive failures actually looks like on a live network.
What kind of sustained network condition gets you there, and how often would the fork-resolution rule actually be exercised rather than remaining a theoretical path?
$DUSK becomes more interesting to me if this emergency path proves reliable when the network actually needs it.
#dusk