#dusk $DUSK

最近、取引ライフサイクルのドキュメントを @Dusk について読み直していたら、以前自分があることをあまりにも単純に考えていたと気づきました：

取引の実行が成功したことは、そのステータスが金融システムで「事実」として扱えるようになったことを意味しません。

DuskDS では、取引はまず受信され、伝播され、実行されますが、その後さらに最終確定（final confirmation）を経る必要があります。

公式ドキュメントでも、特に次のように注意しています：

included、accepted、confirmed は、支払いの最終確定（payment finality）としてそのまま直接みなしてはいけない。

理由は複雑ではありません。

取引が accepted ブロックに入ったとしても、そのブロックはロールバックされる可能性があります。

本当に finalized になって、はじめて状態が deterministic finality（決定的な最終確定）に入ったと言えます。

Dusk の Succinct Attestation では、さらに次の段階を経ます：

Proposal
→ Validation
→ Ratification

Ratification が完了することで、ブロックがようやく本当の意味で final になります。

私は、この細部のほうが「何 TPS か」という点よりも見どころだと思います。

なぜなら、取引所や金融システムが本当に恐れているのは、取引が数秒遅れて見えることではないからです。

恐れているのは：

私はこのステータスに基づいてユーザーへ入金（会計処理）してしまったのに、基盤となる状態が後でまた変わってしまうことです。

そのため Dusk は、取引所向けの integration ドキュメントでも、メモリープール、included event、または accepted だが未確定のブロックがあるだけで、仕訳を前倒ししてはいけないと明確に求めています。

これは、finality をとても現実的に説明していると思います。

finality はパフォーマンス用語ではありません。

そして、それは次の問いに答えるものです：

システムは、どの時点からなら、その状態が撤回されても心配しなくてよくなるのか？

Dusk の公式サイトで現在提示されている finality の指標は、おおよそ 10 秒です。

私は、その数字が見栄えのするものかどうかよりも、主ネットの実負荷がかかった後に、この「accepted から finalized まで」の境界がずっと明確に、安定して保てるかのほうが気になります。

金融システムが最後に本当に依存するのは、結局この一点です。