I went back through the Dusk documentation last night, and the emergency mode section made me look at consensus a little differently.
At first, I thought an emergency mechanism was simply a backup for when validators go offline. But the details are more interesting.
Dusk uses validation and ratification committees, with randomly selected provisioners voting on whether a proposed block is valid and whether that result should be accepted. A quorum requires different thresholds depending on the vote, including a 2/3 supermajority for Valid votes.
What happens when the network cannot get that quorum?
After 16 failed iterations, according to the documentation, the protocol enters emergency mode. Instead of timing out and giving up, iterations can remain open until a candidate gets enough support. Multiple iterations may run at the same time, which increases the chance of producing a block but also creates a possibility of forks.
I found the trade-off interesting.
If multiple candidate blocks reach consensus, the protocol resolves the fork by choosing the candidate from the lowest iteration. I’m curious about how this behaves under prolonged network congestion or partial isolation, especially when different parts of the network see messages at different times.
The final fallback is even more unusual. If the last iteration fails, provisioners holding a majority of total stake can request an emergency block. That block contains no transactions and allows the network to move into the next round.
This raises questions for me around governance and decentralization.
Does requiring majority stake for an emergency block create a useful safety mechanism, or could it become a point of influence during a serious network failure?
And how robust is the system when communication is heavily disrupted but different committees continue operating?
I’m still digging into the edge cases, but these are the parts of consensus design I find most worth understanding.
@Dusk $DUSK #dusk
#dusk $DUSK @Dusk
At first, I thought an emergency mechanism was simply a backup for when validators go offline. But the details are more interesting.
Dusk uses validation and ratification committees, with randomly selected provisioners voting on whether a proposed block is valid and whether that result should be accepted. A quorum requires different thresholds depending on the vote, including a 2/3 supermajority for Valid votes.
What happens when the network cannot get that quorum?
After 16 failed iterations, according to the documentation, the protocol enters emergency mode. Instead of timing out and giving up, iterations can remain open until a candidate gets enough support. Multiple iterations may run at the same time, which increases the chance of producing a block but also creates a possibility of forks.
I found the trade-off interesting.
If multiple candidate blocks reach consensus, the protocol resolves the fork by choosing the candidate from the lowest iteration. I’m curious about how this behaves under prolonged network congestion or partial isolation, especially when different parts of the network see messages at different times.
The final fallback is even more unusual. If the last iteration fails, provisioners holding a majority of total stake can request an emergency block. That block contains no transactions and allows the network to move into the next round.
This raises questions for me around governance and decentralization.
Does requiring majority stake for an emergency block create a useful safety mechanism, or could it become a point of influence during a serious network failure?
And how robust is the system when communication is heavily disrupted but different committees continue operating?
I’m still digging into the edge cases, but these are the parts of consensus design I find most worth understanding.
@Dusk $DUSK #dusk
#dusk $DUSK @Dusk
