私はDuskの「簡潔な証明（Succinct Attestation）」のコンセンサスについて掘り下げ、あるイテレーションで委員会がブロックを生成できなかった場合に、実際に何が起きるのかを理解しようとしていました。最初の私の前提はこうです。失敗したイテレーションとは、何かがおかしなことになったという意味だ――障害、見落とされたスロット、回避すべき問題など。
しかしそれは違いました。
Duskのコンセンサスはイテレーションで動作し、それぞれのイテレーションには、提案・検証・承認（ratification）を行うためにランダムに選ばれた独自の委員会が割り当てられます。委員会が定足数に到達しなかった場合――例えば、十分なバリデータが間に合って応答しなかった、あるいはネットワークの遅延があったなど、派手な出来事でなくても――その状況を「失敗して穴を埋めるべきもの」として扱うことはありません。システムは単に次のイテレーションへ進み、改めて新しく選ばれた委員会で再開します。ブロックが失われることも、チェーンが分岐することも、ロールバックが発生することもありません。試みは期限切れになるだけで、別のバリデータが責任を持つ形でコンセンサスが再挑戦します。
私が印象的に感じたのは、これは設計に「保険として後付け」されたものではなく、デフォルトの期待そのものだという点です。プロトコルは、いくつかのイテレーションは最終化されないことがあると前提としており、その前提に基づいて委員会のローテーションを組み立てています。すべてのイテレーションが成功することを願う（希望を軸にする）のではなく、そうした前提のもとで設計されているのです。

これによって、Duskにおける「ブロックタイム」の読み方が変わります。タイムアウト付きの1回の試行、という話ではありません。失敗は日常的で特別な例外ではなく、最終性（finality）は、実際に収束したイテレーションを待つだけの「一連の試行」のことです。

私はまだ、孤発的に定足数を逃したのではなく、持続的なネットワーク負荷のもとで、この挙動がどうなるのかは確信できていません。@Dusk #dusk $DUSK