証券決済において、「注文がマッチングした」「資金が凍結された」「法律上決済が完了した」は別物です。ブロックチェーンにおける confirmation も同様です。@Dusk の公式サイトは確定的な決済を強調していますが、ホワイトペーパーでは finality を「数秒で着金」とは単純化せず、異常時にブロックが置き換えられる可能性についても引き続き議論しています。

まず fallback を見てみましょう。同一ラウンドのコンセンサスで、複数の候補ブロックが結果として成立した場合、ノードは iteration がより低いものを優先して選び、より高い iteration の分岐はロールバックします。あるブロックがネットワークに受け入れられたとしても、それが以後のすべての状態で絶対に安定していることを意味するわけではありません。

ホワイトペーパーでは emergency mode も設計されています。連続して16回 iteration が失敗すると、手順のタイムアウトが取り消され、複数の open iteration を並行して進め、いずれかの候補ブロックが検証・承認された時点で前進します。さらに進められない場合、ネットワークの多数の総質押を保有する provisioners が emergency block の生成を要求できます。これは取引を含まず、主に新しい seed を書き込み、ネットワークが前進を取り戻せるようにします。#dusk

$DUSK の rolling finality は、このように 4 種類の状態を区別します。accepted は、ブロックに成功した証明があるものの、より低い iteration によって置き換えられる可能性がまだあることを意味します。attested は、前の iteration がすべて失敗し、現在のブロックはそれより低い iteration によって置き換えられないことを意味します。confirmed は、後続ブロックの支えを得た状態です。final は、親ブロックもすでに final であることを要求します。もしそれまでに attested されていない iteration が n 個ある場合、accepted ブロックは confirmed に入る前に、連続した attested あるいは confirmed のブロックを 2×n 個 経験する必要があります。

そう考えると、私は「秒級の最終性」という一言のほうが正直だと思います。つまり、通常の経路における速度と、異常時の安定性を分けて扱い、遅延・オフライン・分岐が実際に起こり得ることを認めているからです。