私は、ダスクがコンセンサスを「ひとつの大きな決定」として扱っていないことに、改めて気づかされます。

プロセスは段階に分かれています。まずブロックが準備されて提案され、その後、投票参加者がそれを評価し、ネットワークがその結果の状態について合意に達するのです。

この分離は見落とされやすいのですが、最終結果は単に
「そのブロックが受理された」ということにすぎません。

しかし仕組みとしては、候補となる状態を作ることと、それに対してネットワークが合意することとを、有用に切り分けています。もし提案が間違っていれば、ブロック生成それ自体を受理とみなすのではなく、投票段階で別の機会としてそれを拒否できます。
その構造は良いと思います。

トレードオフは調整（コーディネーション）です。追加の段階が増えるほど、次の段階と正しく連携できなければならず、相互に依存する要素が増えるほど、システムの理解が難しくなります。

では、コンセンサスを明示的な段階に分解することで、ダスクは悪い提案に対してより耐性を高めるのでしょうか。それとも、追加の調整が単に別の故障箇所（失敗の起点）を生み出すだけなのでしょうか？

#dusk @Dusk $DUSK