@Dusk_Foundation
最初は、ダスクのコンセンサス・ラウンドは十分な票が集まるのを待つだけの、単なる「待ち」の問題だと考えていました。けれど反復（イテレーション）の構造を詳しく見るほど、印象に残ったのは、失敗した試みが単に消え去るわけではないという点でした。検証や承認（ratification）が失敗した場合、プロトコルは別の反復へ進み、新しいジェネレーターと、決定論的なソーティションによって選ばれた委員会が用いられます。これは小さいながらも興味深い依存関係を生みます。つまり後の試みは、先行する試みで起きたことによって部分的に形づくられるのです。ホワイトペーパーでは、1ラウンドを最大50回の反復に制限しているのさえも、失敗が「無視してよい例外」扱いではないことを示唆しています。つまり、失敗は上限のあるプロセスの中に収まらなければならない。私は、一般的な「高速な確定（fast finality）」の説明よりも、その点のほうがより興味深いと思いました。この場でのコンセンサスは、成功する協調だけでなく、うまくいかなかった協調を管理することも含んでいるようです。ネットワーク参加が完璧に信頼できないときには、そうせざるを得ないのかもしれません。すると残る、より静かな疑問はこうです。コンセンサス・システムは、合意を取りにいく試みを繰り返すことによるコストと、しつこく続ける（永続性）ことのバランスを、どう取るべきなのでしょうか？ #dusk $DUSK @Dusk $DUSK