もし1回の取引があなたの手から発信されたなら、真の試練はローカルマシンがどれだけ速いかではなく、そのメッセージがそれを必要とするノードに、秩序立って到達できるかどうかです。ユーザーにはこの道筋は見えませんが、それが共通認識（コンセンサス）がなぜ遅いのか、なぜ重複処理が起きるのかに影響します。

ネットワークを1つの都市だと考えてください。最も乱暴な方法は、各交差点が同じ通知をすべての隣接交差点に書き写すことです。通知は確かに広がりますが、その代償は大量の重複です。Kadcastの発想は、すべてのノードに毎回叫ばせることではなく、Kademliaの距離とXOR距離を使って、メッセージを構造化された転送関係に投入し、無差別なフラッディングを減らす点にあります。

ここで最も重要なのは「Duskがどれだけ早く到達したか」ではありません。あなたがようやく持てた、より正確な問いは何か——メッセージのカバーにかかるコストはどこにあるのか？ 実行時間は、ノードが事柄を処理する速度にしか答えません。伝播の経路は、メッセージが他のノードにどう送られるかに答えます。帳尻を両方見ていないのに、局所的な結果を全体の性能とみなすことはできません。

もちろん、ホワイトペーパーにおけるKadcastはメカニズム設計であり、現行メインネットのベンチマーク報告ではありません。ノード規模、ネットワークの変動、実際の経路などによって、最終結果は変わりえます。@Dusk を見てみれば、まずこの経路を描き、共通認識が重複したブロードキャストに引きずられていないかを判断します。$DUSK はネットワークネイティブのトークンであり、この図の証拠にはできません。#dusk の技術的な議論も、メッセージがどう到達するのかから始めるべきです。

一般的な利用の観点では、確認メッセージは何もないところから突然現れるわけではありません。必ず伝播、受信、そして重複処理を経ます。私たちはホワイトペーパーからむやみにメインネットに結論を下すことはできませんが、まず問いの立て方を正しくすることはできます。もし実行エンジンのメッセージのカバー方法がまだ非効率なら、ユーザーが最終的に目にする体験は、どの層によって引きずられるのか？ 経路を性能に組み込むこと——それこそが、このメカニズムを観察する価値のあるポイントです。

まず経路、次に数字。順序は逆にしてはいけません。実行速度だけを見ないでください。