the Dusk detail I kept coming back to is that a block can have a success attestation and still not be final.
my first read of Succinct Attestation was simpler.
proposal lands.
validation reaches a supermajority of Valid votes.
ratification confirms it.
aggregated BLS signatures prove the quorum.
done, right?
not quite.
Dusk’s rolling finality section splits a block into accepted, attested, confirmed, and final.
if a block is produced at iteration I > 0 while an earlier iteration still has no fail attestation, it can carry a success attestation and only be marked accepted.
because “the committee reached quorum” sounds very close to “this block cannot disappear.”
on Dusk those are different claims.
the unresolved earlier iteration still matters. if a lower-iteration block later reaches consensus, fallback can replace the accepted block and discard its successors.
so the success attestation proves agreement happened.
it does not always prove the chain has finished choosing.
an attested block either landed at iteration 0 or has fail attestations covering every earlier iteration, so no lower-iteration block can replace it directly. confirmed depends on later blocks. final arrives only when the block is confirmed and its parent is already final.
that made “finality in seconds” feel less like one event and more like a boundary an application has to read correctly.
an application on Dusk is not only asking whether consensus signed something.
release collateral?
recognize a security transfer?
let another contract treat the state as irreversible?
those may not deserve the same threshold.
most of the time this probably moves quickly. fine
the edge case is what interests me: a block looks successful, an application reacts to it, and a lower iteration is still alive.
Dusk does not hide that gap. it names it.
accepted is not final.
and once I noticed that, my integration question changed.
not “did consensus succeed?”
how irreversible does this application need Dusk to be before it acts?
@Dusk_Foundation $DUSK #Dusk $ACE $APR
my first read of Succinct Attestation was simpler.
proposal lands.
validation reaches a supermajority of Valid votes.
ratification confirms it.
aggregated BLS signatures prove the quorum.
done, right?
not quite.
Dusk’s rolling finality section splits a block into accepted, attested, confirmed, and final.
if a block is produced at iteration I > 0 while an earlier iteration still has no fail attestation, it can carry a success attestation and only be marked accepted.
because “the committee reached quorum” sounds very close to “this block cannot disappear.”
on Dusk those are different claims.
the unresolved earlier iteration still matters. if a lower-iteration block later reaches consensus, fallback can replace the accepted block and discard its successors.
so the success attestation proves agreement happened.
it does not always prove the chain has finished choosing.
an attested block either landed at iteration 0 or has fail attestations covering every earlier iteration, so no lower-iteration block can replace it directly. confirmed depends on later blocks. final arrives only when the block is confirmed and its parent is already final.
that made “finality in seconds” feel less like one event and more like a boundary an application has to read correctly.
an application on Dusk is not only asking whether consensus signed something.
release collateral?
recognize a security transfer?
let another contract treat the state as irreversible?
those may not deserve the same threshold.
most of the time this probably moves quickly. fine
the edge case is what interests me: a block looks successful, an application reacts to it, and a lower iteration is still alive.
Dusk does not hide that gap. it names it.
accepted is not final.
and once I noticed that, my integration question changed.
not “did consensus succeed?”
how irreversible does this application need Dusk to be before it acts?
@Dusk_Foundation $DUSK #Dusk $ACE $APR
SELECTIVE DISCLOSURE
0%
DUSKVM
0%
DUSK'S MOONLIGHT
100%
DUSK'S PHOENIX
0%
1 الأصوات • تمّ إغلاق التصويت