私は、Duskが実際にどのようにブロックを確定するのかを追跡していました。というのも、マーケティング文句が常に「数秒で不可逆の確定」であるからです。技術的には確かにその通りです。しかしドキュメントではブロックの状態が段階— Accepted（受理） / Confirmed（確認済み） / Stable（安定） / Final（最終確定）—に分けられていて、そこが面白いところでした。

ブロックが「Accepted」であるとは、単に、そのラウンドの3つの合意（コンセンサス）ステップを通過したという意味にすぎません。まだ再編成（リオーガナイズ）される可能性はあります。 「Confirmed」とは、その後のブロックがそれに基づいて構築されることを意味します。 「Final」だけが決定論的に保証され、暗号学的に不可逆な状態であり、確率的な確認ではなく、明示的な暗号のアテステーション（証明/証跡）によってブロックが確定されます

つまり、そのギャップは合意設計そのものにはありません。Succinct Attestationは、ナカモト式の確率的な決済を回避するように本当に作られています。ギャップがあるのは、ウォレット、取引所、またはインテグレータがそのブロックを「決済済み（settled）」として扱うタイミングです。ユーザーやアプリが「Accepted」を最終と読み取ってしまうなら、それはプロトコル上の欠陥ではなく、「まさにその間違いを防ぐために実際に構築されたプロトコル」の上に成立するUX（ユーザー体験）上の前提の問題です。

規制対象の資産の決済において、その区別は単なる見た目の違いではありません。適合した清算（クリアリング）イベントと、時期尚早なものとの差になります。

それでも気になっているのですが、取引量が$DUSK スケールして、ラウンドごとの少数のプロビジョナー委員会を超えてきたとき、保守的なインテグレータは結局ここをどういうデフォルトにしているのでしょうか。

@Dusk #DUSK