#dusk $DUSK @Dusk

最初、Duskの「50回」イテレーション制限は単なる技術的な上限だと思っていました。調べるほど、それがネットワークが不一致をどう扱うかをのぞき見る小さな窓のように感じられてきたのです。

Duskのコンセンサスは、提案・検証・承認（ラティフィケーション）を通じて進むよう設計されており、準備者（provisioner）は決定論的なソーティションによって選ばれます。しかしメッセージが遅れて届いたり、準備者が消えたり、通信がぐちゃぐちゃになったりしたとき、コンセンサスはすぐには諦めません。収束するための追加のチャンスを得るのです。

そして、そのことで数字の読み方が変わりました。

「50回の試行」というより、本質的には、ネットワークが通常どおりに振る舞うのをやめたときのための“忍耐（パティエンス）”の予算のように感じられます。

さらに、タイムアウトしたイテレーションを短絡的に回避し、過去または未来のイテレーションからのメッセージを再伝播するDuskの工夫も興味深いものでした。私にはそこから、あまり自明ではない別の問題が示されているように思えます。回復とは「もう一度試す」だけではなく、そうした余分な試みを有益にすることだ、ということです。

そして、そこが面白いトレードオフにつながります。

イテレーションが少なすぎると、一時的な混乱が失敗に見えてしまうことがあります。多すぎれば、レイテンシがたまり続ける中で、ネットワークが合意を追いかけるために時間を費やしてしまうかもしれません。

だから結局、いつも次に戻ってきます。

Duskがどれくらいの不一致を許容できるのか。そして、不一致から回復するために設計されたその仕組みが、遅延の原因になってしまうのはどこからなのか？

@Dusk #dusk $DUSK