#dusk @Dusk
I was looking for the randomness source behind Dusk's deterministic sortition.
I expected a separate mechanism entirely. An external randomness beacon. Some value generated independently of the chain.
There isn't one.
The seed used to select the next block generator and voting committees comes from the current block generator's signature over the previous block's seed.
Each block produces the input the next selection needs.
That's the part that stopped me.
The seed isn't simply carried forward from block to block. It's produced fresh each time, by the current block generator. A generator that could predict future selection would have a reason to exploit that knowledge.
The whitepaper is direct about why this matters. Because each seed only exists once its generator signs it, future generators and committee members can't be calculated in advance.
Not because the information is hidden somewhere.
Because it doesn't exist yet.
I'd been picturing unpredictability as something a consensus system needs to import from somewhere else.
@Dusk_Foundation treats it as something the chain produces one step at a time.
That changes what I think the security boundary is. The important property isn't that the seed stays secret. It's that the information needed for the next selection doesn't exist until the current block has been produced.
What I still want to understand is what happens when the same small set of generators happens to produce several consecutive blocks. Does the chained signature construction preserve the same unpredictability across that stretch, or does repeated control of block production change any of the security assumptions?
$DUSK only becomes more interesting to me if that dependency chain holds up under a real stretch of consecutive generators, not just in the model.
I was looking for the randomness source behind Dusk's deterministic sortition.
I expected a separate mechanism entirely. An external randomness beacon. Some value generated independently of the chain.
There isn't one.
The seed used to select the next block generator and voting committees comes from the current block generator's signature over the previous block's seed.
Each block produces the input the next selection needs.
That's the part that stopped me.
The seed isn't simply carried forward from block to block. It's produced fresh each time, by the current block generator. A generator that could predict future selection would have a reason to exploit that knowledge.
The whitepaper is direct about why this matters. Because each seed only exists once its generator signs it, future generators and committee members can't be calculated in advance.
Not because the information is hidden somewhere.
Because it doesn't exist yet.
I'd been picturing unpredictability as something a consensus system needs to import from somewhere else.
@Dusk_Foundation treats it as something the chain produces one step at a time.
That changes what I think the security boundary is. The important property isn't that the seed stays secret. It's that the information needed for the next selection doesn't exist until the current block has been produced.
What I still want to understand is what happens when the same small set of generators happens to produce several consecutive blocks. Does the chained signature construction preserve the same unpredictability across that stretch, or does repeated control of block production change any of the security assumptions?
$DUSK only becomes more interesting to me if that dependency chain holds up under a real stretch of consecutive generators, not just in the model.