We had a load shedding stretch in Islamabad last week where the grid just kept failing over and over, and every time it came back the backup system had to restart from scratch instead of picking up where it left off. I assumed Dusk's emergency mode worked the same way, network stalls, it just keeps retrying the same fixed timeout until something sticks.
That's not what happens. Emergency mode only kicks in after 16 consecutive failed iterations, and once it activates, the whole timeout structure gets removed. Iterations don't expire anymore, they run indefinitely until a candidate block actually gets proposed and reaches quorum in both validation and ratification. NoCandidate and NoQuorum votes get disabled too, so every step has to properly succeed before the next one starts.
What actually reframed this for me is that multiple of these open iterations can run at once. That's not a flaw, it's intentional, it raises the odds that at least one produces a valid block. The tradeoff is more fork risk, which gets resolved by always picking whichever candidate reached consensus at the lowest iteration number.
There's also a last resort inside the last resort. If even the final iteration stalls, provisioners holding the majority of total stake can request an emergency block, a special empty block signed by Dusk with no transactions in it, just to keep the round moving.
What the whitepaper doesn't say is how often this has actually triggered on real Dusk infrastructure so far. I have no data to back a frequency claim.
The real test for DUSK is how rarely emergency mode needs to fire once mainnet runs at real scale.
Has anyone actually witnessed emergency mode trigger on Dusk yet?
@Dusk #dusk $DUSK
That's not what happens. Emergency mode only kicks in after 16 consecutive failed iterations, and once it activates, the whole timeout structure gets removed. Iterations don't expire anymore, they run indefinitely until a candidate block actually gets proposed and reaches quorum in both validation and ratification. NoCandidate and NoQuorum votes get disabled too, so every step has to properly succeed before the next one starts.
What actually reframed this for me is that multiple of these open iterations can run at once. That's not a flaw, it's intentional, it raises the odds that at least one produces a valid block. The tradeoff is more fork risk, which gets resolved by always picking whichever candidate reached consensus at the lowest iteration number.
There's also a last resort inside the last resort. If even the final iteration stalls, provisioners holding the majority of total stake can request an emergency block, a special empty block signed by Dusk with no transactions in it, just to keep the round moving.
What the whitepaper doesn't say is how often this has actually triggered on real Dusk infrastructure so far. I have no data to back a frequency claim.
The real test for DUSK is how rarely emergency mode needs to fire once mainnet runs at real scale.
Has anyone actually witnessed emergency mode trigger on Dusk yet?
@Dusk #dusk $DUSK
