多くのブロックチェーンでは、大規模なノードがオフラインになると、選択肢は実質2つしかありません。つまり、当初の計画どおりに無理やりブロック生成を続ける(選出された検証者が揃わなければ、そのまま次のラウンドまで停止して待つ)か、あるいは完全に停止して人の介入を待つかです。Duskは、この2つの間に、専用の第三の答えを用意しました。

ホワイトペーパーのSection 3.6には、とても具体的に書かれています。もし大部分のProvisionerがオフライン、または隔離されてしまい、連続する複数ラウンドの反復でもブロック生成担当者(出塊人)を選べず、投票委員会の人数が揃わないまま失敗しきい値(現在は16回に設定)に到達すると、プロトコルは緊急モードへ切り替わります。

このモードでは、もともとのタイムアウト機構が無効化され、反復は実際に候補ブロックが生成され、検証ステップと承認ステップの両方で法定人数が揃うまで続行されます。さらに、複数の反復を同時に並行運用できるため、極端な状況でも有効なブロックを産み出せる確率が高まります。

それでもこの仕組みが耐えられない場合、プロトコルには最後の保険もあります。つまり、大多数の担保量を保有するProvisionerが共同でリクエストを発行し、取引を一切含まない「緊急ブロック」(新しいシードのみを含む)を生成して、チェーンを無限に停止させないために、まずは前へ一歩進めるのです。

私の見立てでは、この設計は本質的に「フォーク(分岐)リスク」と引き換えに「ネットワークの生存」を得るものです。複数の並行反復を許可することでフォーク確率は確実に上がり、後続のフォールバック規則で戦場を片付ける必要がありますが、その代わりにネットワークは極端な状況で完全にマヒしてしまうことがありません。

機関投資家にとっては、このような辺境シーンの扱いは、日常の秒単位の決済よりも、むしろデューデリジェンス(調査)に組み込む価値が高いかもしれません。通常状態での性能は、多くの金融系パブリックチェーンでも実現できる一方で、真に差を生むのはシステムが機能不全に陥ったときに、「機能を格下げしつつ稼働を継続できる」のか、それとも「そのまま停止してしまう」のか、という点です。

#dusk $DUSK @Dusk
あなた方は、チェーンの信頼性を評価するうえで、極端時の対応設計にどれくらいの重みを置くべきだと思いますか?
A. 权重很高,失灵表现最见真章
B. 权重一般,正常表现更常用
C. 得看具体业务场景需求
6 残り時間