Was checking Dusk’s consensus docs again and got stuck on one detail: the thing that makes a block final isn’t really a waiting game.
Succinct Attestation runs in rounds. A provisioner proposes a block, a committee validates it, another committee ratifies it. Once ratified, Dusk describes that block as deterministically final. I still instinctively read blockchains through the “wait a few more blocks” lens, so this took me a moment.
For financial workflows, that distinction is pretty practical. If a state is final, there isn’t supposed to be another accepted history replacing it later. Dusk specifically frames SA around fast, deterministic settlement. But its own transaction lifecycle docs make an important distinction too: blocks can still revert before they reach finality, while finalized blocks become immutable and irreversible.
The part I keep coming back to is what happens when the network itself gets split. I couldn’t find a current official Dusk source that explicitly says a network partition will always make block production stop, so I don’t want to turn that into a fact.
Still, the safety question is hard to avoid. Deterministic finality only works if the consensus process can avoid accepting conflicting histories, even when parts of the network can’t see each other.
What I want to see is the actual SA threshold during a prolonged partition: how much committee disagreement is enough to halt finalization, and what does recovery look like after connectivity returns?
#dusk $DUSK @Dusk $ACE $COW
Succinct Attestation runs in rounds. A provisioner proposes a block, a committee validates it, another committee ratifies it. Once ratified, Dusk describes that block as deterministically final. I still instinctively read blockchains through the “wait a few more blocks” lens, so this took me a moment.
For financial workflows, that distinction is pretty practical. If a state is final, there isn’t supposed to be another accepted history replacing it later. Dusk specifically frames SA around fast, deterministic settlement. But its own transaction lifecycle docs make an important distinction too: blocks can still revert before they reach finality, while finalized blocks become immutable and irreversible.
The part I keep coming back to is what happens when the network itself gets split. I couldn’t find a current official Dusk source that explicitly says a network partition will always make block production stop, so I don’t want to turn that into a fact.
Still, the safety question is hard to avoid. Deterministic finality only works if the consensus process can avoid accepting conflicting histories, even when parts of the network can’t see each other.
What I want to see is the actual SA threshold during a prolonged partition: how much committee disagreement is enough to halt finalization, and what does recovery look like after connectivity returns?
#dusk $DUSK @Dusk $ACE $COW
🛡️ Safety
⚡ Liveness
⚖️ Both
🔍 Need more data
1 дн. осталось