昨夜、Dusk のドキュメントを振り返って読んでいたら、緊急モードのセクションを見て、コンセンサスの捉え方が少し変わりました。
最初は、緊急メカニズムはバリデータがオフラインになったときの単なるバックアップだと思いました。ですが、詳細はもっと興味深いです。
Dusk はバリデーションおよび承認（ratification）委員会を使い、ランダムに選ばれたプロビジョナ（provisioners）が、提案されたブロックが有効かどうか、そしてその結果を受け入れるべきかどうかを投票します。定足数（quorum）は投票内容によって異なる閾値が必要で、有効（Valid）投票では 2/3 のスーパー多数が含まれます。
では、ネットワークがその定足数を得られない場合はどうなるのでしょう？
ドキュメントによると、16 回の失敗を経るとプロトコルは緊急モードに入ります。タイムアウトして諦めるのではなく、十分な支持を得られる候補が出るまで、イテレーション（反復）は開いたままにできます。複数のイテレーションを同時に走らせることもあり、ブロック生成の可能性は高まる一方で、フォークが起こる可能性も生まれます。
このトレードオフが面白いと思いました。
複数の候補ブロックがコンセンサスに到達した場合、プロトコルは最も低いイテレーションの候補を選んでフォークを解決します。長引くネットワーク混雑や部分的な隔離のもとで、特にネットワークの異なる部分がメッセージを異なるタイミングで見ている場合に、この挙動がどうなるのか気になります。
最終的なフォールバックはさらに珍しいです。最後のイテレーションが失敗した場合、全総投資（total stake）の過半数を保有するプロビジョナが緊急ブロックを要求できます。そのブロックにはトランザクションが含まれず、ネットワークを次のラウンドへ進めるためのものです。
このことは、私にとってガバナンスと分散化に関する疑問を投げかけます。
緊急ブロックに過半数のステークを要求することで有用な安全メカニズムになるのか、それとも重大なネットワーク障害の際に影響力の行使ポイントになり得るのか。
さらに、通信が大きく妨害されているのに、異なる委員会が動き続ける場合、システムはどれほど堅牢なのでしょう？
まだエッジケースを掘り下げている最中ですが、私が特に理解する価値があると思うコンセンサス設計の部分はまさにこれです。
@Dusk $DUSK #dusk
#dusk $DUSK @Dusk
最初は、緊急メカニズムはバリデータがオフラインになったときの単なるバックアップだと思いました。ですが、詳細はもっと興味深いです。
Dusk はバリデーションおよび承認（ratification）委員会を使い、ランダムに選ばれたプロビジョナ（provisioners）が、提案されたブロックが有効かどうか、そしてその結果を受け入れるべきかどうかを投票します。定足数（quorum）は投票内容によって異なる閾値が必要で、有効（Valid）投票では 2/3 のスーパー多数が含まれます。
では、ネットワークがその定足数を得られない場合はどうなるのでしょう？
ドキュメントによると、16 回の失敗を経るとプロトコルは緊急モードに入ります。タイムアウトして諦めるのではなく、十分な支持を得られる候補が出るまで、イテレーション（反復）は開いたままにできます。複数のイテレーションを同時に走らせることもあり、ブロック生成の可能性は高まる一方で、フォークが起こる可能性も生まれます。
このトレードオフが面白いと思いました。
複数の候補ブロックがコンセンサスに到達した場合、プロトコルは最も低いイテレーションの候補を選んでフォークを解決します。長引くネットワーク混雑や部分的な隔離のもとで、特にネットワークの異なる部分がメッセージを異なるタイミングで見ている場合に、この挙動がどうなるのか気になります。
最終的なフォールバックはさらに珍しいです。最後のイテレーションが失敗した場合、全総投資（total stake）の過半数を保有するプロビジョナが緊急ブロックを要求できます。そのブロックにはトランザクションが含まれず、ネットワークを次のラウンドへ進めるためのものです。
このことは、私にとってガバナンスと分散化に関する疑問を投げかけます。
緊急ブロックに過半数のステークを要求することで有用な安全メカニズムになるのか、それとも重大なネットワーク障害の際に影響力の行使ポイントになり得るのか。
さらに、通信が大きく妨害されているのに、異なる委員会が動き続ける場合、システムはどれほど堅牢なのでしょう？
まだエッジケースを掘り下げている最中ですが、私が特に理解する価値があると思うコンセンサス設計の部分はまさにこれです。
@Dusk $DUSK #dusk
#dusk $DUSK @Dusk
