先週、カラチでテストネットのリレー設定をしていた自分のノードが、重いメッセージトラフィックをシミュレートしようとすると、ずっとラグり続けました。原因は自分の回線が弱いだけだと思っていて、いつも対処してきた典型的な地元ISPの問題だと決めつけていました。
ところが、Duskがピアツーピア通信をどう扱うのかを実際に読んでみて、私の前提が逆だったと気づきました。ラグの原因は生の帯域ではなく、距離に関係なく、すべてのノードが隣接ノードへメッセージを無差別に繰り返し配信する「洪水（flooding）型のブロードキャスト」がいかに非効率に動くか、そこにありました。
DuskはKadcastを使います。これはKademliaのXOR距離の構造に基づいています。ノードは、距離が大きくなるにつれて段階的に選択したピアへだけメッセージを転送し、盲目的な反復ではなく連鎖的に伝播させるのです。これにより、Ethereumが依拠するゴシップ型プロトコルのような方式に比べて、冗長な送信が大幅に減ります。また、メッセージが広いネットワークに届くまでに複数ホップを経るため、どこから発信されたのかが自然にわかりにくくなります。これは、金融取引におけるDuskのプライバシー重視の方針とも整合しています。
ただし、ホワイトペーパーには明確に書かれていないのが、逆境下の実環境における正確なレイテンシーの数値です。たとえば、不安定なインフラの地域で、地域的な混雑が起きたときに具体的にどうなるのか、といった点です。そこは、確信をもって埋められません。
DUSKの本当の試験は、制御されたテストネット条件だけでなく、ノード数が数千規模にスケールしたときに、Kadcastが現実のネットワーク負荷下でも効率面で優位性を維持できるかどうかです。
こちらのどなたか、Duskノードを実際に十分長く運用していて、伝播スピードの違いを自分の手で体感した方はいませんか？
#dusk $DUSK @Dusk
ところが、Duskがピアツーピア通信をどう扱うのかを実際に読んでみて、私の前提が逆だったと気づきました。ラグの原因は生の帯域ではなく、距離に関係なく、すべてのノードが隣接ノードへメッセージを無差別に繰り返し配信する「洪水（flooding）型のブロードキャスト」がいかに非効率に動くか、そこにありました。
DuskはKadcastを使います。これはKademliaのXOR距離の構造に基づいています。ノードは、距離が大きくなるにつれて段階的に選択したピアへだけメッセージを転送し、盲目的な反復ではなく連鎖的に伝播させるのです。これにより、Ethereumが依拠するゴシップ型プロトコルのような方式に比べて、冗長な送信が大幅に減ります。また、メッセージが広いネットワークに届くまでに複数ホップを経るため、どこから発信されたのかが自然にわかりにくくなります。これは、金融取引におけるDuskのプライバシー重視の方針とも整合しています。
ただし、ホワイトペーパーには明確に書かれていないのが、逆境下の実環境における正確なレイテンシーの数値です。たとえば、不安定なインフラの地域で、地域的な混雑が起きたときに具体的にどうなるのか、といった点です。そこは、確信をもって埋められません。
DUSKの本当の試験は、制御されたテストネット条件だけでなく、ノード数が数千規模にスケールしたときに、Kadcastが現実のネットワーク負荷下でも効率面で優位性を維持できるかどうかです。
こちらのどなたか、Duskノードを実際に十分長く運用していて、伝播スピードの違いを自分の手で体感した方はいませんか？
#dusk $DUSK @Dusk
