#dusk $DUSK
Duskのホワイトペーパーで「emergency mode（緊急モード）」という語が何度も出てきて、私はその先へ読み進め続けていました。実際にその章を読むと、名前が示唆する以上に仕組みが具体的でした。

通常のDuskコンセンサス：各ラウンドは最大50回の反復まで進みます。各ステップ（Proposal、Validation、Ratification）にはタイムアウトがあります。タイムアウトまでにクォーラムが形成されなければ、そのステップは次へ進み、やがて新しい反復が始まります。逐次的で、上限があり、予測可能です。

緊急モードは異なります。これは16回連続で失敗した反復の後に発動します。ここでいう失敗とは、通常クォーラムが形成されないことを指します。多くの場合、バリデータがオフラインだったり、孤立していたりします。発動すると：ステップのタイムアウトが無効になります。新しい反復が開始されますが、進行中の各反復は閉じずにそのまま残ります。複数の開いた反復が並行して動きます。これによりブロック生成の可能性が高まりますが、フォークの可能性も高まります。

緊急モードで発生したフォークは、最も低い反復番号のブロックを選ぶことで解決されます。それでもネットワークがブロックを作れない場合の最後の手段は、緊急ブロックです。空のブロック（取引なし）で、グローバル公開鍵を使ってDuskというエンティティが署名します。過半数のステークを保有するプロビジョナーがそれを要求します。

ではなぜ、ネットワークは速くなりたいときに単に緊急モードを動かさないのでしょうか。

通常モードは、よりきれいなファイナリティと引き換えに、ある程度の速度を犠牲にします。並行して開かれる反復は、ストレス下でのライブネスを高めますが、複雑さも生みます。空ブロックへのフォールバックは中央集権的な介入です。チェーンは動き続けますが、動かしているのはDuskというエンティティです。

私が特に興味深いと感じたのは、緊急ブロックという設計上の問いです。つまり、ライブネスの保証が最終的にDuskエンティティの可用性と、署名する意思に依存するということになります。プロトコルの安全性と分散性は、そこでわずかに異なる方向へ引っ張られます。

まだ説明されていないのは、通常ブロックが緊急ブロックに置き換わったときに、飛行中（インフライト）の取引はどうなるのかという点です。次のラウンドに再度含められるのか、それとも破棄されるのか。@Dusk

$DUSK #dusk