#dusk $DUSK @Dusk $DUSK

提案・検証・承認：Duskの最終ブロックへの三段階プロセス

私は、Duskにおけるブロックの最終確定が「単一の投票」と同じように動くのだと、ずっと思い込んでいました――提案して、確認して、完了。

しかし実際は、三つの別々のステップで、それぞれが「なぜそうなるのか」を確かめるために私は一つずつ追っていく必要がありました。

提案（Proposal）ステップでは、決定論的なソーティションによりプロビジョナーを1人選び、そのプロビジョナーが候補ブロックを生成してブロードキャストします。タイムアウトまでに何も届かなければ、そのイテレーションは単に失敗します――候補は出ず、また私がドキュメントから確認できる限りでは、代替となる生成ステップもありません。

次に何が起きるのかを追いました。出力は検証（Validation）へ渡されます。ここでは新しい委員会が、ランダムに選ばれます。委員会は候補を現在のチェーンティップに照らしてチェックし、有効（Valid）か無効（Invalid）かに投票します。有効側に2/3の定足数が必要で、無効側は単純多数による判定――どちらの閾値でもそのステップはそこで終了します。

3つ目のステップ、そして私がほとんど見落としかけたポイントがこれです：承認（Ratification）。ここではさらに別の委員会が、ブロックの内容ではなく、検証が実際に本当の定足数に達したかどうかに対して投票します。同じく2/3または多数決のルールが適用されます。

3つの委員会、3つの別々の判断――前のステップがすでに行った仕事を繰り返すようなステップは見つけられませんでした。

私にとって際立ったのは、このシーケンスがメインネット前にどれほど入念に精査されたかです。Duskは、スタック全体に対して10回の監査を実施し、200ページ以上のレポートを作成しました。その10件のうち1件、Oak SecurityによるものはSA（Secure/Slashing Auditingなどの文脈に相当する部分）を特に扱い、スラッシングのインセンティブや投票ロジックに関する問題を指摘していました――すべて、ローンチ前に重大なものとして解決されています。

つまり、私の見立てでは「ブロックを最終化する」とは、単一の判断ではありません。独立して検証される3つのチェックが順番に積み重なっており、各チェックはプロセスを再起動できる――ラウンドごとに最大50イテレーションまで失敗しうる、ということです。

このレベルのローンチ前の精査は、本当にここでのリスクを減らしているのでしょうか。それとも、すり抜けた欠陥があると、後で見つけるのがその分だけさらに難しくなるだけなのでしょうか？