Dusk がネットワーク上でブロックをどのように運ぶのかを追跡していた。いつものゴシップの氾濫（フラッド）話を期待していたのに、見つかったのはもっと狭く、意図的なものだった。

Kadcast は氾濫しない。ルーティングする。Kademlia の XOR 距離構造を使い、各ノードはデータをすべての相手へではなく、特定のピアのバケットへ向けて決定論的な経路で転送する。効率の話としては、そこで多くの人が止まる。

しかし、構造化ルーティングには明白な弱点がある。経路上のノードがオフラインになったら、メッセージはそこで死んでしまうのか？ そこで私は立ち止まった。Kadcast は、バケットごとに 1 本の経路に頼っていない。冗長性パラメータ β を使い、同じチャンクを受け取って再転送する複数のデリゲートをバケットごとに選ぶ。1 つ失っても、他が運び続ける。

さらに RaptorQ も組み込まれている。前方誤り訂正（FEC）のデータとして符号化され、受信側は、すべてのパケットが無傷で到着する必要なしに、部分フラグメントだけから元のデータを復元できる。

つまり耐障害性は「ノードが生き残り続ける」ことの話ではない。プロトコルがそうはならない前提で、経路構造そのものに冗長性を織り込むことで成り立っているのだ。無差別な氾濫（ブラインド・フラッド）で誤魔化すのではない。

そして気になる。β は、バリデータ集合が大きくなるにつれて冗長性コストは帯域を圧迫し、代わりに冗長性が減れば信頼性は下がる――そのような状況で、いったいどこで調整されているのだろう。Dusk は規模が上がったとき、実際どこでその線を引く？

#dusk $DUSK @Dusk