ドキュメントを読み返し、2つの領域に想定以上に時間を費やしました。Kadcastのフォールトトレランスと、プロトコルのファイナリティ（確定）ルールです。
最初は、KadcastがKademliaのDHTを使っている点が比較的わかりやすく見えました。ノードはピアが消えたときにルーティングテーブルを更新でき、また各バケット内の複数のピアが、1つのノードが失敗した場合の代替経路になります。ですが、考えたのは次の点です。ノードが常に参加・離脱し、信頼性が揺らぐような状況で、ネットワークはどれくらいの速さで適応できるのでしょうか？ さらに、参加が極端に偏ると、ルーティング構造の弱い部分が生まれてしまうことはあるのでしょうか。
合意状態モデルは、さらに興味深いものでした。
ID @Dusk のブロックは、受理済み（accepted）、アテステーション済み（attested）、確認済み（confirmed）、そして最終的にファイナライズ（final）へと進みます。理解の助けになったのは、「アテステーション済み」と「受理済み」の区別です。過去のイテレーションが失敗していた場合、成功したブロックは受理されるものの、なお置き換え可能な状態に残ることがあります。失敗したイテレーションが多いほど、確認にかかる時間は長くなります。
たとえば、過去2回のイテレーションが失敗している場合、受理済みのブロックが確認済みになるためには、連続して4つのアテステーション済みブロックまたは確認済みブロックが必要です。
これは私に、セキュリティと分散化の観点でいくつかの疑問を投げかけます。一時的なネットワーク不安定性に対して、最終確定を不必要に遅くすることなく、十分な保護を提供できるのでしょうか？ また、分断や障害が多数のノードにわたって相関して起きる場合、プロトコルはどのように振る舞うのでしょうか。孤立した障害ではなく、連動して障害が発生する状況です。
さらに、ルーティングテーブルの動態と、合意のファイナリティが、深刻なネットワーク障害の期間にどのように相互作用するのかも気になります。
私の理解はまだ進行中なので、こうしたトレードオフを他の人がどのように解釈しているのか、ぜひ伺いたいです。
Kadcastは、どんな障害シナリオを特にうまく扱えると思いますか？ そして、その前提がどこで検証され得るのでしょうか？
$DUSK #dusk
#dusk $DUSK @Dusk
最初は、KadcastがKademliaのDHTを使っている点が比較的わかりやすく見えました。ノードはピアが消えたときにルーティングテーブルを更新でき、また各バケット内の複数のピアが、1つのノードが失敗した場合の代替経路になります。ですが、考えたのは次の点です。ノードが常に参加・離脱し、信頼性が揺らぐような状況で、ネットワークはどれくらいの速さで適応できるのでしょうか？ さらに、参加が極端に偏ると、ルーティング構造の弱い部分が生まれてしまうことはあるのでしょうか。
合意状態モデルは、さらに興味深いものでした。
ID @Dusk のブロックは、受理済み（accepted）、アテステーション済み（attested）、確認済み（confirmed）、そして最終的にファイナライズ（final）へと進みます。理解の助けになったのは、「アテステーション済み」と「受理済み」の区別です。過去のイテレーションが失敗していた場合、成功したブロックは受理されるものの、なお置き換え可能な状態に残ることがあります。失敗したイテレーションが多いほど、確認にかかる時間は長くなります。
たとえば、過去2回のイテレーションが失敗している場合、受理済みのブロックが確認済みになるためには、連続して4つのアテステーション済みブロックまたは確認済みブロックが必要です。
これは私に、セキュリティと分散化の観点でいくつかの疑問を投げかけます。一時的なネットワーク不安定性に対して、最終確定を不必要に遅くすることなく、十分な保護を提供できるのでしょうか？ また、分断や障害が多数のノードにわたって相関して起きる場合、プロトコルはどのように振る舞うのでしょうか。孤立した障害ではなく、連動して障害が発生する状況です。
さらに、ルーティングテーブルの動態と、合意のファイナリティが、深刻なネットワーク障害の期間にどのように相互作用するのかも気になります。
私の理解はまだ進行中なので、こうしたトレードオフを他の人がどのように解釈しているのか、ぜひ伺いたいです。
Kadcastは、どんな障害シナリオを特にうまく扱えると思いますか？ そして、その前提がどこで検証され得るのでしょうか？
$DUSK #dusk
#dusk $DUSK @Dusk
