لقد اختبرت عدة عقد على شبكة الاختبار @Dusk ، وبعد التقاط الحزم كانت أكبر ملاحظتي: ما زال كثير من مهندسي تشغيل الشبكة (الشبكة الرئيسية) يستخدمون مؤشرات من عصر مضى مثل “حدّ أقصى للمعالج (CPU) + مستوى الذاكرة”، لكنهم لا يلاحظون شيئًا تجاه تراكم إشارات بين العقد، أو الرسائل المكررة، أو تذبذب جدول التوجيه (Route Table). أواخر الأيام الأولى للبيتكوين كانت هناك مادة عكسية جاهزة كنموذج: بعد وصول معاملة واحدة إلى العقدة، يتم بثها بشكل عشوائي لكل الجيران دون تمييز؛ يتم تمريرها في نفس الوقت عبر 8 إلى 16 اتصالًا نظيرًا (Peer Connections)، فتتضخم سعة عرض الشبكة (Bandwidth) على نحو يتضاعف بشكل مضاعف (مستوى الضرب). في إحصاءات شبكة الاختبار المبكرة للبيتكوين، كانت النسخ الزائدة لبث معاملة واحدة تتجاوز غالبًا عدد الاتصالات بأكثر من ثلاث مرات. وعند زيادة التوازي، تمتلئ مقاطعات بطاقة الشبكة (NIC Interrupts) قبل اكتمال مزامنة الكتل.

Kadcast لم يسلك هذا الطريق القديم. إذ إنه يقوم بإدخال منطق مسافة XOR في Kademlia مباشرة إلى طبقة الانتشار: تحسب العقد أولًا المسافة بين الهدف ومعرّفها المحلي (ID)، ثم تضع الجيران في k-buckets مختلفة حسب طول البادئة (Prefix Length). أثناء المزامنة، يقوم بنقل متعدد (multicast) تدريجيًا عبر طبقات على طول مسار شجري. من واقع اختبارات الضغط التي أجريتها، كانت قمة عرض النطاق اللحظية أقل بوضوح من الفيض (flooding). كما صَعُبت على المجسات الخارجية إعادة استنتاج عنوان IP المصدر لأن إعادة الإرسال تمر عبر عدة قفزات. ومن حيث التصميم، توجد حجة لذلك: في محاكاة على مستوى ورقة البحث (paper-level simulation)، يقلّل Kadcast تكرار زائد (redundancy) البث من المستوى الخطي في Gossip إلى المستوى اللوغاريتمي، أي أنه يزيل رتبة مقدار (order of magnitude) واحدة.

لكن شكوكي تنبع بالضبط من هنا. فقد تم تخصيص كل الكفاءة إلى صحة جدول التوجيه، وهذا يعادل تفويض تحمّل الأخطاء في النظام الموزع إلى افتراضات حول الطوبولوجيا (الهيكل). بمجرد أن يتم قطع كابل ألياف بحرية، أو يقوم مهاجم بتلويث k-bucket معين بهويات Sybil رخيصة، ستقوم العقد بشكل متكرر بتفعيل إصلاحات التوجيه والتبديل إلى مسارات بديلة. ليست زيادة زمن الوصول للاستعلام (lookup) خطية، بل تصبح أكثر شدة بسبب التذبذب (jitter amplification): إذا فقد جدول التوجيه bucket عالي البادئة واحدًا، فقد تتدهور قفزات الاستعلام المحتملة من مستوى لوغاريتمي إلى حالة أقرب إلى التجريب الحَصري (exhaustive probing). في اختبارات الضغط رأيت مشهدًا أكثر لا بديهيّة: عند حقن 2000 معاملة بنفس القدر، كان عدد مرات مقاطعات بطاقة الشبكة لدى عقد الفيض أربع مرات أكثر من عقد Kadcast؛ لكن بعد تجاوز معدل فقد الحزم 3%، أصبحت مدة مزامنة الكتل في Kadcast تتفوّق بدلًا من أن تتأخر. وهذا النوع من التكلفة كافٍ لابتلاع مكافأة توفير عرض النطاق التي تحققت في البداية.

الشبكة العامة ليست مختبرًا؛ فإعادة الإرسال في TCP، واختراق NAT، وميزات QoS لدى مزودي الخدمة كلها ستزيد هشاشة منطق الطوبولوجيا. وعند تقييم هذا النوع من الشبكات الأساسية، ما يخيف أكثر ليس ارتفاع CPU، بل التدهور الصامت لجدول التوجيه: يبدو معدل الإنتاجية (throughput) طبيعيًا على السطح، لكن الواقع أن محاولات إعادة إرسال الإشارات (signaling retries) وإصلاح البُكِتات (bucket repairs) قد اخترقت بالفعل مستوى التحكم (control plane). #dusk $DUSK $BTC