Dusk はトラブルに遭うほど、私は気になる——誰がネットワークの復旧を握っているのか
Dusk のコンセンサス部分を読んでみて、通常の仕組みそのものは最も心配すべき点ではないと感じました。面白いのは、ネットワークが継続的にクォーラムを満たせないときです。
16 回の失敗したイテレーションの後、Succinct Attestation は emergency モードへ切り替わります。各ステップのタイムアウトは廃止され、複数のイテレーションを同時に開いて、妥当なブロックを見つけられる可能性を高めます。複数の candidate が同時にコンセンサスを達成した場合、より低いイテレーションに属するブロックが優先されます。
この設計により、いくつかの provisioner が遅れたり接続を失ったりしても、ネットワークが“詰まる”ことを防げます。しかし同時に、別の境界線にも目を向けたくなりました。ネットワーク状態が悪化したとき、復旧のしやすさがよりはっきりとステークの分布に依存し始めるのです。
最終案では、emergency ブロックは、provisioner のグループがネットワーク全体の総ステークの過半数を握っていることを要求した場合にのみ生成されます。いっぽう、コンセンサスに直接参加したい provisioner は、現在最低 1.000 DUSK のステークが必要です。
だから私は、staking を単に報酬を得る手段としてだけ見ていません。それが、システムが異常状態から脱する必要があるときに、誰がどれだけの重みを持つのかを決めるからです。
私にとって Dusk の重要なテストは、“ネットが一日スムーズに動くこと”ではありません。混雑が増し、いくつかのノードが遅れ、委員会（committee）が次々と変わっていく状況でも、ネットワークが回復できるかどうか——その際に、決定権が巨大なステークの一群に過度に集中しないかを確かめることです。
ある recovery メカニズムは技術的に非常に堅牢になり得ます。
しかし、ネット救済の権限がステークに応じてますます集中していくなら、本当に最も厳密に測るべきなのは decentralization です。
@Dusk $DUSK #dusk
$ONDO $BTC
Dusk のコンセンサス部分を読んでみて、通常の仕組みそのものは最も心配すべき点ではないと感じました。面白いのは、ネットワークが継続的にクォーラムを満たせないときです。
16 回の失敗したイテレーションの後、Succinct Attestation は emergency モードへ切り替わります。各ステップのタイムアウトは廃止され、複数のイテレーションを同時に開いて、妥当なブロックを見つけられる可能性を高めます。複数の candidate が同時にコンセンサスを達成した場合、より低いイテレーションに属するブロックが優先されます。
この設計により、いくつかの provisioner が遅れたり接続を失ったりしても、ネットワークが“詰まる”ことを防げます。しかし同時に、別の境界線にも目を向けたくなりました。ネットワーク状態が悪化したとき、復旧のしやすさがよりはっきりとステークの分布に依存し始めるのです。
最終案では、emergency ブロックは、provisioner のグループがネットワーク全体の総ステークの過半数を握っていることを要求した場合にのみ生成されます。いっぽう、コンセンサスに直接参加したい provisioner は、現在最低 1.000 DUSK のステークが必要です。
だから私は、staking を単に報酬を得る手段としてだけ見ていません。それが、システムが異常状態から脱する必要があるときに、誰がどれだけの重みを持つのかを決めるからです。
私にとって Dusk の重要なテストは、“ネットが一日スムーズに動くこと”ではありません。混雑が増し、いくつかのノードが遅れ、委員会（committee）が次々と変わっていく状況でも、ネットワークが回復できるかどうか——その際に、決定権が巨大なステークの一群に過度に集中しないかを確かめることです。
ある recovery メカニズムは技術的に非常に堅牢になり得ます。
しかし、ネット救済の権限がステークに応じてますます集中していくなら、本当に最も厳密に測るべきなのは decentralization です。
@Dusk $DUSK #dusk
$ONDO $BTC
