#dusk $DUSK @Dusk
I used to think Dusk’s Emergency Mode was simply a backup plan for when the network couldn’t produce a block.
But after looking deeper into it, I think there’s a more interesting idea here: how do you keep a blockchain moving when normal consensus starts failing?
Dusk normally moves through iterations where blocks are proposed, validated and ratified. But if too many provisioners go offline, several iterations can fail one after another.
After 16 consecutive failed iterations, Dusk can enter Emergency Mode.
What changes here is pretty interesting. The normal step timeouts stop being the main constraint, and multiple open iterations can keep trying until one gets quorum.
Of course, that creates another problem. Multiple candidates also mean a higher chance of competing blocks.
Dusk handles that by accepting the successful block from the lowest-numbered iteration and closing the remaining open iterations.
But what happens if even the final iteration can’t reach quorum?
That’s where Emergency Block Requests come in.
If a stake-weighted majority of provisioners requests one, Dusk can create a special empty block, signed by Dusk itself, allowing the chain to move forward instead of remaining stuck indefinitely.
The part I find most interesting is the trade-off.
Dusk is adding a controlled centralized fallback to protect network liveness during an extreme failure scenario.
So maybe the real question isn’t whether Emergency Mode is decentralized enough.
It’s whether keeping the network alive during a worst-case situation is worth that small compromise.
That balance between decentralization and liveness is what makes Dusk’s consensus design interesting to me.
I used to think Dusk’s Emergency Mode was simply a backup plan for when the network couldn’t produce a block.
But after looking deeper into it, I think there’s a more interesting idea here: how do you keep a blockchain moving when normal consensus starts failing?
Dusk normally moves through iterations where blocks are proposed, validated and ratified. But if too many provisioners go offline, several iterations can fail one after another.
After 16 consecutive failed iterations, Dusk can enter Emergency Mode.
What changes here is pretty interesting. The normal step timeouts stop being the main constraint, and multiple open iterations can keep trying until one gets quorum.
Of course, that creates another problem. Multiple candidates also mean a higher chance of competing blocks.
Dusk handles that by accepting the successful block from the lowest-numbered iteration and closing the remaining open iterations.
But what happens if even the final iteration can’t reach quorum?
That’s where Emergency Block Requests come in.
If a stake-weighted majority of provisioners requests one, Dusk can create a special empty block, signed by Dusk itself, allowing the chain to move forward instead of remaining stuck indefinitely.
The part I find most interesting is the trade-off.
Dusk is adding a controlled centralized fallback to protect network liveness during an extreme failure scenario.
So maybe the real question isn’t whether Emergency Mode is decentralized enough.
It’s whether keeping the network alive during a worst-case situation is worth that small compromise.
That balance between decentralization and liveness is what makes Dusk’s consensus design interesting to me.