Guys Most blockchains assume consensus keeps moving. $DUSK actually has a plan for when it doesn’t.
In its SA consensus, each block carries a seed derived from the previous block generator’s signature. That constantly changes the randomness, making future block generators and committees difficult to predict in advance.
But the more interesting part is what happens when things go badly.
If enough provisioners go offline and 16 consecutive iterations fail, Dusk enters emergency mode. Instead of simply giving up, the network keeps trying until a candidate block reaches quorum.
Multiple iterations can even remain open at the same time, increasing the chance that one succeeds. The trade-off? More concurrent attempts can also create forks, which Dusk resolves by selecting the candidate from the lowest iteration.
And if the network reaches the final iteration without progress, provisioners holding a majority of stake can request an emergency block. That block contains no transactions, but gives the network a new seed so it can move into the next round.
I actually find this more interesting than the usual “fast consensus” claim. It shows what the protocol does when the network behaves badly, not just when everything works perfectly.
But I keep wondering: does having an elaborate emergency path make Dusk more resilient, or does the added complexity introduce new edge cases?
Would you rather use a blockchain with a detailed failure-recovery mechanism, or one with a simpler consensus design?
#dusk $DUSK @Dusk
In its SA consensus, each block carries a seed derived from the previous block generator’s signature. That constantly changes the randomness, making future block generators and committees difficult to predict in advance.
But the more interesting part is what happens when things go badly.
If enough provisioners go offline and 16 consecutive iterations fail, Dusk enters emergency mode. Instead of simply giving up, the network keeps trying until a candidate block reaches quorum.
Multiple iterations can even remain open at the same time, increasing the chance that one succeeds. The trade-off? More concurrent attempts can also create forks, which Dusk resolves by selecting the candidate from the lowest iteration.
And if the network reaches the final iteration without progress, provisioners holding a majority of stake can request an emergency block. That block contains no transactions, but gives the network a new seed so it can move into the next round.
I actually find this more interesting than the usual “fast consensus” claim. It shows what the protocol does when the network behaves badly, not just when everything works perfectly.
But I keep wondering: does having an elaborate emergency path make Dusk more resilient, or does the added complexity introduce new edge cases?
Would you rather use a blockchain with a detailed failure-recovery mechanism, or one with a simpler consensus design?
#dusk $DUSK @Dusk