I went back through the Dusk documentation last night, specifically the sections on the DS algorithm and how provisioners get selected for consensus.
I started by trying to map the stake eligibility rules. A provisioner’s stake S is treated as eligible only if the amount is at least the minimum (set at 1000 DUSK) and its age/length sits between 0 and M. The DS process then ranks those eligible stakes by a score that mixes the stake’s size with a deterministic function of the previous block hash and the provisioner’s public key. The highest-scoring provisioner becomes the one who can propose the next block.
Reading further, the flow became clearer: the selected provisioner broadcasts a candidate block, a committee of other provisioners runs validation, and if a simple majority (½ + 1) of ValidBk messages appears, the block moves to ratification. Ratification itself needs a stronger threshold ⅔ + 1 before the block is considered finalized and the new set of provisioners is locked in. Attestation and voting committees are formed the same deterministic way, just with different seeds.
What still feels unresolved for me is how sensitive the whole chain is to the exact value of M and to the 1000 DUSK floor. If those parameters shift, does the effective decentralization of the provisioner set change in ways that are hard to see from the outside? And once a block is attested, how much practical recourse exists if a later audit shows the DS ranking was gamed?
Curious how others who’ve dug into the same pages read the security margins around those majority thresholds.
#dusk $DUSK @Dusk
I started by trying to map the stake eligibility rules. A provisioner’s stake S is treated as eligible only if the amount is at least the minimum (set at 1000 DUSK) and its age/length sits between 0 and M. The DS process then ranks those eligible stakes by a score that mixes the stake’s size with a deterministic function of the previous block hash and the provisioner’s public key. The highest-scoring provisioner becomes the one who can propose the next block.
Reading further, the flow became clearer: the selected provisioner broadcasts a candidate block, a committee of other provisioners runs validation, and if a simple majority (½ + 1) of ValidBk messages appears, the block moves to ratification. Ratification itself needs a stronger threshold ⅔ + 1 before the block is considered finalized and the new set of provisioners is locked in. Attestation and voting committees are formed the same deterministic way, just with different seeds.
What still feels unresolved for me is how sensitive the whole chain is to the exact value of M and to the 1000 DUSK floor. If those parameters shift, does the effective decentralization of the provisioner set change in ways that are hard to see from the outside? And once a block is attested, how much practical recourse exists if a later audit shows the DS ranking was gamed?
Curious how others who’ve dug into the same pages read the security margins around those majority thresholds.
#dusk $DUSK @Dusk