#dusk $DUSK @Dusk
What caught my attention wasn't the zero knowledge side of Dusk that gets most of the attention it was a smaller detail in how a block actually becomes final.
I wanted to check how Succinct Attestation, DuskDS's permissionless, committee Based proof-of-stake consensus protocol actually confirms a transaction since instant settlement gets thrown around loosely in this space.
Each round goes through three steps: a provisioner proposes and broadcasts a candidate block a committee validates it and a second committee ratifies that validation and finalizes the block. Only after both committees agree does the block move forward.
What's interesting is that @Dusk_Foundation doesn't treat finality as one binary event. A block is Accepted once it passes all three steps Confirmed once later blocks build on it Stable once it's sufficiently buried and finally Final deterministic and cryptographically guaranteed meaning it cannot be reversed.
For regulated settlement, that staged distinction matters more than raw speed. A custodian doesn't just need a transaction to be fast it needs a defined point where irreversible is provable not assumed.
What I'd want clarified is behavior under sustained load. Two separate committees agreeing adds a coordination step that single proposer chains skip. As the provisioner set and stake distribution grow, does ratification stay fast or does committee coordination itself become the constraint?
The docs lay out the phases and reward split 70% proposer 5%/5% to validation and ratification committees clearly what they do not spell out is a throughput ceiling under Real network congestion only testnet behavior.
Has anyone seen committee selection or finality Time data from Dusk under actual sustained transaction load rather than idle network numbers?
$DUSK #Dusk
What caught my attention wasn't the zero knowledge side of Dusk that gets most of the attention it was a smaller detail in how a block actually becomes final.
I wanted to check how Succinct Attestation, DuskDS's permissionless, committee Based proof-of-stake consensus protocol actually confirms a transaction since instant settlement gets thrown around loosely in this space.
Each round goes through three steps: a provisioner proposes and broadcasts a candidate block a committee validates it and a second committee ratifies that validation and finalizes the block. Only after both committees agree does the block move forward.
What's interesting is that @Dusk_Foundation doesn't treat finality as one binary event. A block is Accepted once it passes all three steps Confirmed once later blocks build on it Stable once it's sufficiently buried and finally Final deterministic and cryptographically guaranteed meaning it cannot be reversed.
For regulated settlement, that staged distinction matters more than raw speed. A custodian doesn't just need a transaction to be fast it needs a defined point where irreversible is provable not assumed.
What I'd want clarified is behavior under sustained load. Two separate committees agreeing adds a coordination step that single proposer chains skip. As the provisioner set and stake distribution grow, does ratification stay fast or does committee coordination itself become the constraint?
The docs lay out the phases and reward split 70% proposer 5%/5% to validation and ratification committees clearly what they do not spell out is a throughput ceiling under Real network congestion only testnet behavior.
Has anyone seen committee selection or finality Time data from Dusk under actual sustained transaction load rather than idle network numbers?
$DUSK #Dusk