一条証券決済チェーンで最も気まずい瞬間は、必ずしもハッカーが侵入してくることではない。誰も目に見える形で悪事を働いていないのに、台帳はいつまでも次のページへ進めないのだ。ノードが切断され、ネットワークが分断され、委員会が必要票を集められない。お金は失われていないが、皆がただ待つことになる。一般のパブリックチェーンではこれを「混雑」と呼ぶが、金融市場ではそのまま「決済事故」になりかねない。

私は@Dusk のホワイトペーパーのEmergency Mode（緊急モード）を改めて読み直し、この状況は起こり得ないふりをしていないことを見つけた。Succinct Attestationは1ラウンドあたり最大50回まで反復（イテレーション）を実行する。連続16回の反復が失敗すると、プロトコルは緊急モードに入る。通常手順におけるタイムアウトは無効化され、NoCandidateやNoQuorumももはや推進（進行）の結果として扱われなくなる。すでに開始済みの反復は、候補ブロックおよび検証・承認の2段階で、本当に法定票数（定足数）に達するまで待ち続けられる。

この設計の意図は非常に明確だ。普段の合意形成はタイムアウトによって次の人のバッチに切り替えられるが、極端な場合に「誰も揃わない」という理由だけで問題を先送りし続けることはできない。システムは、複数のオープン反復を並行してぶら下げたままにすることさえ厭わず、委員会が確認できるブロックが出るまで待ち、台帳が前進し続ける確率を高めようとする。

しかし代償もホワイトペーパーに書かれている。並行反復によって同一ラウンドに複数の「合意済み」候補ブロックが生じ得るため、フォーク（分岐）のリスクはむしろ上がる。プロトコルは、反復番号（イテレーション番号）が最も低い候補ブロックを選んで収束させるしかない。最後まで復旧できない場合でも、多数のステーキング権（質押権）は、取引を含まない緊急の空ブロックを共同で要求できる。Duskノードが新しいシードを生成し、ネットワークはこのラウンドを越えられる。

私はこれを「決して停止しない」という意味には受け取らない。むしろ災害復旧（ディザスタ・リカバリ）の手順書だ。合意形成が失速し得ることを認め、その復旧を誰がどう進め、復旧の際に何を犠牲にしてもよいかを定めている。今後$DUSK の金融決済能力を見るとき、私は正常状態で何秒でブロックが出るかだけでなく、緊急モードが実際にどれくらいの回数と継続時間で発動されるのか、フォークの数、空ブロック要求の有無をより重視する。

本当の機関レベルの基盤インフラとは、「故障が一度も起きない」ことではない。故障が起きたときのルールが事前に明記され、そしてその代償が誰にでも見える形で示されていることだ。
#dusk