財布の中の「既確認」って書かれた小さなアイコンが、ぱっと見は地味で平凡に見える。けれどDuskの最終性に関するドキュメントを読み終えて初めて気づいたのだ——この目立たない表示の背後には、圧縮された4種類ものまったく異なる信頼度レベルが隠されている。
新しく出てきたブロックはまず「受け入れられた」という段階を経る。この時点で、同じラウンドの中にもっと早い候補ブロックが現れれば、いつでも差し替えられる可能性がある。踏ん張って「証明された」レベルまで昇格できて初めて、その“差し替えられる運命”から免れる。さらに上は、後続ブロックが積み重なって形作られる「ロック済み」。そして「完全に確定」する段階では、そのブロックの親がそれぞれのフローをすべて完了するのを待たなければならない。
肝心なのは、新生から完全確定までにどれだけの後続ブロックが裏付けとして必要か、その答えに一律のルールがないことだ。この数字は、そのブロックが生まれた時点で、失敗の試行を何回経験していたかに連動している——生まれが波乱めであるほど、先天的な不確実性を埋め合わせるために、より多くの“確認”が必要になる。同じ「確認」というラベルでも、実際の価値は大きく隔たる。
この考え方に沿って他のモジュールを見ていくと、別の場所でも同じ階層化の哲学が使われているのが分かった。異なる種類の取引をルーティングする役目を担う中核コントラクトは、取引の属性に応じてそれぞれを適切な検証用チャネルに振り分け、各自の手続きを終えた後で、チェーン上の台帳へ一括して登録する。見える送金も、暗号化された送金も、口座型のものも、手形型のものも、すべて同じ方式で着地する。
さらに撮合（マッチング）の場面に視点を移すと面白いことが起きる。1件ごとの約定を市場が認めるには、チェーン上に再検証可能な痕跡を残さなければならない。段階的な最終性は、アプリケーションに目盛り付きの判断定規を与える——いつ外部にコミットを約束でき、いつは取り急ぎ仮勘定として記帳するに留めるのか、その匙加減をノード自身が握る。
代償として、このレイヤーの複雑さは一般のユーザーには見えない。極端なネットワーク分岐が起きたとき、この“情報差”が誰の頭上に降りかかり、影響が具体的にどれほどになるのか——それは引き続き観察していく必要がある。
#dusk @Dusk $DUSK