Duskのドキュメントを、実際のコンセンサス挙動と照らし合わせて一晩かけて検証しました。そこで私の印象に残ったのは、プライバシーレイヤーではなく、Dusk @Dusk $DUSK #dusk が「ブロック生成」を「ブロックの承認（ratification）」から切り離し、1つのバリデータセットが両方を担うのではなく、2つの別々の委員会に分けている点です。多くのチェーンでは、コンセンサスを単一の役割として捉え、2つの帽子をかぶせています。しかしここでは、生成（generator）がスループットを最適化し、承認（ratifier）が最終性の安全性を担っていて、この2つの目的は自動的には一致しません。ドキュメントやテストネット上の活動を見ても、2つの委員会が本当に食い違ったときに何が起きるのか――オフラインになるバリデータがいる、という話ではなく、生成と承認の間で実際に判断が割れるケースです――について、きれいな答えを見つけられませんでした。アーキテクチャには解決のための道筋が組み込まれていることは明らかです。通常の条件下ではチェーンが停止していないからです。でも「まだ停止していない」と「敵対的な不一致のもとできれいに解決する」は、別の主張です。現時点のほぼすべての利用が、その経路に対して強い負荷をかけていないのは、活動がまだ軽量で協調的なことが多いためです。これは今のところ見えない設計上の選択で、誰かがプレッシャー下で試してみて初めて、その輪郭がはっきりします。実際にはどんなふうになるのか、気になります。