ノード警報SMSが明け方に私の携帯を爆破したあの件で、私の最初の反応は「RPCがフラッディングされた」でした。iftop の中が kadcast ポートの外向けリトランスで埋まるまで気づかなかった——従来の gossip の「受け取ったら全ての隣接ノードに転送する」という癖が、リージョン間のジャッター時には自己増幅器になるんです。のちに Rusk のソースと 2024 年版ホワイトペーパーの Section 2 をじっと追って、Dusk がブロードキャストを Kadcast に置き換えたのは、帯域を節約する“ちょっとした修正”ではなく、P2P 層を XOR 距離による Kademlia DHT の探索として丸ごと書き換えているからだと分かりました：各ノードは bucket で連絡先を管理し、転送では XOR 距離が増加する方向の“いくつかの peer だけ”を選んでカスケードするので、全ネットにばらまきません。
ホワイトペーパーで引用された研究によれば、gossip と比べて帯域は 25%–50% 節約、stale block は 10%–30% 減、という話で、私はそれを“実験室の上限”として見ています。実運用では、provisioner ノードが数分おきに出入りし、東京〜フランクフルトの RTT が 40ms ほど揺れ、bucket の更新はイベント駆動ではなく周期的 ping に頼り、ルーティングテーブルの古さが数秒のうちに来る——その間のメッセージは結局フォールバックして洪水（泛洪）になります。節約できたはずの帯域が、また半分戻ってくる。
SA のコンセンサスは 3 段階（Generation → 1st/2nd Reduction → Agreement）で、委員会の投票メッセージはすべて Kadcast 経由です。転送経路が churn（入退会の揺れ）で断裂すると、2/3 の BLS 法定票を集められず、ブロックは「帯域を節約するかどうか」の問題ではなく、単に“ラウンドが止まる”だけになります。
gossip より強い点は、「メッセージの起源点」をばらして、直接の隣接ノードへの依存を減らしたところです。ついでに Phoenix の取引を隠す“取引元 IP”の関連付けの難度も一段高まります；その代償として、トラブルシューティングのための思考負荷が重く、mempool はデフォルトで 10000 件、本地の期限切れ戦略（Rusk デフォルトは 3 日）、そして node-installer の設定は 30 分——こうしたパラメータ分裂が、初心者の運用者の目には全部“幽霊バグ”に見える。
私としては Kadcast が値するかどうかは、25%–50% という紙の数値を見て判断しません。見るべき“硬い3つのこと”は次の通りです：bucket の更新が、ノードがダウンしてから 1 epoch 以内に収束するか；SA 投票が二つの分区（双分区）で行われたとき、残った連結部分グラフで 67% の法定を組み立てられるか；Provisioner の家庭用ブロードバンド・ノード比率が上がった後、末尾遅延（テールレイテンシー）が崩壊するか。これら三つを通過できるなら、それは金融チェーンにあるべき「構造化された配送」です。通過できないなら、運用に穴を掘らせる“きれいな論文”になってしまう。
#disk @Dusk $DUSK
ホワイトペーパーで引用された研究によれば、gossip と比べて帯域は 25%–50% 節約、stale block は 10%–30% 減、という話で、私はそれを“実験室の上限”として見ています。実運用では、provisioner ノードが数分おきに出入りし、東京〜フランクフルトの RTT が 40ms ほど揺れ、bucket の更新はイベント駆動ではなく周期的 ping に頼り、ルーティングテーブルの古さが数秒のうちに来る——その間のメッセージは結局フォールバックして洪水（泛洪）になります。節約できたはずの帯域が、また半分戻ってくる。
SA のコンセンサスは 3 段階（Generation → 1st/2nd Reduction → Agreement）で、委員会の投票メッセージはすべて Kadcast 経由です。転送経路が churn（入退会の揺れ）で断裂すると、2/3 の BLS 法定票を集められず、ブロックは「帯域を節約するかどうか」の問題ではなく、単に“ラウンドが止まる”だけになります。
gossip より強い点は、「メッセージの起源点」をばらして、直接の隣接ノードへの依存を減らしたところです。ついでに Phoenix の取引を隠す“取引元 IP”の関連付けの難度も一段高まります；その代償として、トラブルシューティングのための思考負荷が重く、mempool はデフォルトで 10000 件、本地の期限切れ戦略（Rusk デフォルトは 3 日）、そして node-installer の設定は 30 分——こうしたパラメータ分裂が、初心者の運用者の目には全部“幽霊バグ”に見える。
私としては Kadcast が値するかどうかは、25%–50% という紙の数値を見て判断しません。見るべき“硬い3つのこと”は次の通りです：bucket の更新が、ノードがダウンしてから 1 epoch 以内に収束するか；SA 投票が二つの分区（双分区）で行われたとき、残った連結部分グラフで 67% の法定を組み立てられるか；Provisioner の家庭用ブロードバンド・ノード比率が上がった後、末尾遅延（テールレイテンシー）が崩壊するか。これら三つを通過できるなら、それは金融チェーンにあるべき「構造化された配送」です。通過できないなら、運用に穴を掘らせる“きれいな論文”になってしまう。
#disk @Dusk $DUSK