#dusk $DUSK @Dusk
originally thought a block was either final or it wasnt, one clean line.
rolling finality made me rethink that.
the actual mechanism traces backward from the chain tip to the last finalized block, counting stakes of provisioners behind timeout and winning certificates along the way. once that running total hits 67% of total stake at some intermediate block H, H gets marked final, retroactively.
thats not a single vote deciding anything. its a cumulative-stake threshold, checked across a range of blocks, not one moment.
i traced why a single-vote system cant offer the same guarantee. one vote, even a decisive one, only proves what a subset of the network thought at that moment. it doesnt account for what happens if the tip itself never finalizes, or if lower-iteration candidates still have unresolved claims sitting behind it.
Dusk's own engineering notes confirm this changed recently too, from a fixed successor-count to a variable one, depending on how many non-attested lower-iteration candidates existed in the same round. the threshold isnt static, it adapts to how messy that specific round actually was.
so rolling finality isnt protecting against one bad vote. its protecting against the gap between looking settled and actually accumulating enough weighted confirmation to be irreversible.
does a 67%-stake retroactive-threshold feel like a stronger guarantee than a single decisive vote, or does the complexity just relocate where uncertainty hides??
$RE
$HEMI
originally thought a block was either final or it wasnt, one clean line.
rolling finality made me rethink that.
the actual mechanism traces backward from the chain tip to the last finalized block, counting stakes of provisioners behind timeout and winning certificates along the way. once that running total hits 67% of total stake at some intermediate block H, H gets marked final, retroactively.
thats not a single vote deciding anything. its a cumulative-stake threshold, checked across a range of blocks, not one moment.
i traced why a single-vote system cant offer the same guarantee. one vote, even a decisive one, only proves what a subset of the network thought at that moment. it doesnt account for what happens if the tip itself never finalizes, or if lower-iteration candidates still have unresolved claims sitting behind it.
Dusk's own engineering notes confirm this changed recently too, from a fixed successor-count to a variable one, depending on how many non-attested lower-iteration candidates existed in the same round. the threshold isnt static, it adapts to how messy that specific round actually was.
so rolling finality isnt protecting against one bad vote. its protecting against the gap between looking settled and actually accumulating enough weighted confirmation to be irreversible.
does a 67%-stake retroactive-threshold feel like a stronger guarantee than a single decisive vote, or does the complexity just relocate where uncertainty hides??
$RE
$HEMI