#dusk $DUSK
The phrase "emergency mode" kept appearing in Dusk's whitepaper and I kept moving past it. When I actually read the section, the mechanism is more specific than the name suggests.
Normal Dusk consensus: each round runs up to a maximum of 50 iterations. Each step, Proposal, Validation, Ratification, has a timeout. If no quorum forms before the timeout, the step moves on and eventually a new iteration starts. Sequential, bounded, predictable.
Emergency mode is different. It triggers after 16 consecutive failed iterations — where failed means no quorum was reached, typically because validators are offline or isolated. Once triggered: step timeouts are disabled. New iterations are initiated, but each ongoing iteration stays active instead of closing. Multiple open iterations run concurrently. This raises the chance of producing a block. It also raises the chance of forks.
Forks in emergency mode get resolved by selecting the block from the lowest iteration number. If the network still can't form a block, the last resort is an emergency block: an empty block, no transactions, signed by Dusk the entity using its global public key. Provisioners holding a majority of stake request it.
So why doesn't the network just run emergency mode whenever it wants to be faster.
Normal mode trades some speed for cleaner finality. Concurrent open iterations increase liveness under stress but introduce complexity that The empty block fallback is a centralized intervention — the chain keeps moving, but Dusk the entity is the one moving it.
I actually find the emergency block the more interesting design question — because it means the liveness guarantee ultimately depends on the Dusk entity's availability and willingness to sign. Protocol safety and decentralization pull in slightly different directions there.
What I haven't seen explained is what happens to transactions that were in flight when an emergency block replaces a normal block — whether they get re-included in the next round or whether they're dropped. @Dusk
$DUSK #dusk
The phrase "emergency mode" kept appearing in Dusk's whitepaper and I kept moving past it. When I actually read the section, the mechanism is more specific than the name suggests.
Normal Dusk consensus: each round runs up to a maximum of 50 iterations. Each step, Proposal, Validation, Ratification, has a timeout. If no quorum forms before the timeout, the step moves on and eventually a new iteration starts. Sequential, bounded, predictable.
Emergency mode is different. It triggers after 16 consecutive failed iterations — where failed means no quorum was reached, typically because validators are offline or isolated. Once triggered: step timeouts are disabled. New iterations are initiated, but each ongoing iteration stays active instead of closing. Multiple open iterations run concurrently. This raises the chance of producing a block. It also raises the chance of forks.
Forks in emergency mode get resolved by selecting the block from the lowest iteration number. If the network still can't form a block, the last resort is an emergency block: an empty block, no transactions, signed by Dusk the entity using its global public key. Provisioners holding a majority of stake request it.
So why doesn't the network just run emergency mode whenever it wants to be faster.
Normal mode trades some speed for cleaner finality. Concurrent open iterations increase liveness under stress but introduce complexity that The empty block fallback is a centralized intervention — the chain keeps moving, but Dusk the entity is the one moving it.
I actually find the emergency block the more interesting design question — because it means the liveness guarantee ultimately depends on the Dusk entity's availability and willingness to sign. Protocol safety and decentralization pull in slightly different directions there.
What I haven't seen explained is what happens to transactions that were in flight when an emergency block replaces a normal block — whether they get re-included in the next round or whether they're dropped. @Dusk
$DUSK #dusk
