#dusk $DUSK @Dusk
Went back to the incentives section of the whitepaper after finishing the consensus part.
Skimmed it the first time, assumed block rewards were just whoever builds the block gets paid. Second pass, that assumption fell apart.
The reward split isn't flat. 80% to the generator, 10% to the voting committee, 10% to Dusk, but the generator's 80% is itself split into a fixed 70% and a variable 10% that depends on how many votes they actually bothered to include in the block certificate.
Skip votes = lose money.
That's not an accident, it's solving a specific problem.
Here's the PROBLEM:
Generators for every iteration in a round are knowable in advance.
Which means a generator scheduled for iteration 4 has a quiet incentive to just not show up for validation on iterations 1 through 3.
Let them fail, and iteration 4 becomes their payday instead of someone else's.
The protocol is essentially bribing its own future block producers not to sabotage the present ones.
The fix isn't one patch, it's FOUR stacked together:
voters get paid regardless of whether their vote wins, so participating beats waiting.
Generators lose reward share if they exclude known votes, so hiding votes costs them too.
Whoever's up next as generator is explicitly barred from voting in the current iteration, closing the most obvious version of the exploit. And the max number of iterations per round is capped, so there are only so many future generators worth sabotaging for.
What clicked for me is that none of these four mechanisms work alone, they're patching different angles of the same incentive gap, not one clean fix.
Selection decides who gets a shot at the reward.
Rewards then have to be shaped so that decision doesn't quietly reward bad behavior.
Still wondering: do these four mechanisms actually close the incentive gap, or just make sabotage less profitable?
Also Is needing four mitigations solid mechanism design—or evidence that the underlying predictability problem is harder to solve?
Went back to the incentives section of the whitepaper after finishing the consensus part.
Skimmed it the first time, assumed block rewards were just whoever builds the block gets paid. Second pass, that assumption fell apart.
The reward split isn't flat. 80% to the generator, 10% to the voting committee, 10% to Dusk, but the generator's 80% is itself split into a fixed 70% and a variable 10% that depends on how many votes they actually bothered to include in the block certificate.
Skip votes = lose money.
That's not an accident, it's solving a specific problem.
Here's the PROBLEM:
Generators for every iteration in a round are knowable in advance.
Which means a generator scheduled for iteration 4 has a quiet incentive to just not show up for validation on iterations 1 through 3.
Let them fail, and iteration 4 becomes their payday instead of someone else's.
The protocol is essentially bribing its own future block producers not to sabotage the present ones.
The fix isn't one patch, it's FOUR stacked together:
voters get paid regardless of whether their vote wins, so participating beats waiting.
Generators lose reward share if they exclude known votes, so hiding votes costs them too.
Whoever's up next as generator is explicitly barred from voting in the current iteration, closing the most obvious version of the exploit. And the max number of iterations per round is capped, so there are only so many future generators worth sabotaging for.
What clicked for me is that none of these four mechanisms work alone, they're patching different angles of the same incentive gap, not one clean fix.
Selection decides who gets a shot at the reward.
Rewards then have to be shaped so that decision doesn't quietly reward bad behavior.
Still wondering: do these four mechanisms actually close the incentive gap, or just make sabotage less profitable?
Also Is needing four mitigations solid mechanism design—or evidence that the underlying predictability problem is harder to solve?
