#dusk $DUSK 証券のバックオフィスで最も危険な提示は、「失敗」ではない場合があり、「受理済み」である点だ。失敗なら少なくとも人は止まるが、受理済みだとお金と引き換えにすべてが完了した、というふうに誤解されやすい。オンチェーンでも同じだ。ブロックがローカル台帳に取り込まれたからといって、それが絶対に置き換え不能な最後の段階まで到達したことを意味しない。
私は@Dusk のホワイトペーパーを読み直して、Rolling Finalityを理解し、Duskがすべての「確認」を1語にまとめたのではなく、accepted、attested、confirmed、finalの4つの状態に分けていることに気づいた。acceptedのブロックは成功の証明を得ているとはいえ、それがより高いイテレーションから来ていて、かつ前の（より低い）イテレーションに失敗の証明がない場合、後からより低いイテレーションの正当なブロックが出てくると置き換えられる可能性がある。すると、その後のブロックも一緒に巻き戻る。
attestedはさらに安定している。というのも、それは第0イテレーションから来るか、あるいはそれ以前のイテレーションですでに失敗の証明が残っている必要があるからだ。confirmedは、さらに後続のブロックが現在のチェーンに信頼性（信憑性）を継続的に積み重ねてくれることも要する。そしてfinalだけが、親ブロックもすでにfinalになっていることを意味し、祖先パス全体が封じられて再び置き換えられることはなくなる。
ホワイトペーパーには具体例もある。あるブロックが第5回イテレーションで生成されたが、それまで失敗の証明を持つのは2回分のイテレーションだけだった。そのブロックはまずacceptedとして印が付く。そして、その後4つ連続したattestedまたはconfirmedのブロックを待って初めてconfirmedに入る。つまり、「すでにブロックが出た」ことと、「証券の決済を不可撤回の事実として扱える」ことの間には、確かにいくつかの段階が挟まることがありうるのだ。
私はこの誠実さを評価する。金融システムが最も恐れるのは、確率を“緑のチェック”の中に隠してしまうことだ。だが同時に、プロダクト側にも課題を突きつけてくれる。ウォレット、取引所、登録システムは結局どの状態を表示するのか？ユーザーがacceptedを見たとき、譲渡や償還を継続してよいのか？UIが統一的に「成功」とだけ書いてしまうと、どれほど厳密なコンセンサス状態でもプロダクトの文言によって平たくされてしまう。
だから私はDuskの秒単位の終結性を、平均で何秒だったかだけでは見ない。異常なイテレーションのもとでacceptedからfinalへ進む分布も見るし、アプリケーションが本当にfinalになるまで帳尻を合わせているのかも確認する。終結性はマーケティングの数字ではなく、「ほぼ完了」を「完了」と言い換えられないという規律のセットなのだ。