إذا خرجت إحدى المعاملات من يدك، فإن الاختبار الحقيقي ليس مدى سرعة جهازك المحلي، بل ما إذا كانت هذه الرسالة تصل بشكل منظم إلى العقدة التي تحتاجها. لا يرى المستخدمون هذا الطريق، لكنّه يؤثر على سبب بطء التوافق وسبب ظهور المعالجة المكررة.

تخيّل الشبكة كأنها مدينة: الطريقة الأكثر بدائية هي أن ينسخ كل تقاطع نفس الإشعار إلى جميع التقاطعات المجاورة. بالطبع سينتشر الإشعار، لكن الثمن هو كمّ هائل من التكرار. لا يقوم Kadcast على أن يهتف كل عقدة مرةً أخرى، بل يستفيد من تنظيم المسارات باستخدام مسافات Kademlia وقياسات XOR، بحيث تُوضَع الرسالة داخل علاقة إحالة بنيوية، مما يقلّل من الفيضان العشوائي.

الأهم هنا ليس «إلى أي مدى بات Dusk قريبًا»، بل أنك أخيرًا أصبحت تطرح سؤالًا أدق: أين تكمن تكلفة تغطية الرسائل؟ زمن التنفيذ يجيب فقط عن سرعة معالجة العقد للأشياء، بينما يجب أن يجيب مسار الانتشار عن كيفية وصول الرسالة إلى عقد أخرى. إذا لم ترَ كلتا المعادلتين، فلن تستطيع اعتبار نتيجة محلية أداءً شاملاً.

وبالطبع، فإن Kadcast كما ورد في الورقة البيضاء هو تصميم آلية، وليس تقريرًا معياريًا عن الشبكة الرئيسية الحالية. قد تغيّر أحجام العقد وتذبذب الشبكة والمسارات الفعلية النتيجة النهائية. عند النظر إلى @Dusk ، سأرسم هذا المسار أولًا، ثم أقيّم ما إذا كان التوافق يتم إبطاؤه بسبب البثّ المتكرر. أما $DUSK فهي رمز أصلي للشبكة، ولا يمكنها أن تشهد على صحة هذه الخريطة؛ كما ينبغي أن تبدأ المناقشة التقنية الخاصة بـ #dusk من كيفية وصول الرسالة.

ومن زاوية الاستخدام العادي، لا تظهر رسالة التأكيد من العدم؛ فهي تمر عبر الانتشار والاستقبال والمعالجة المكررة. لا يمكننا بالطبع أن نستنتج نتائج قاطعة للشبكة الرئيسية مباشرةً من الورقة البيضاء، لكن يمكننا أولًا أن نطرح السؤال بالطريقة الصحيحة: إذا كان محرك التنفيذ ما يزال يستخدم طريقة تغطية للرسائل غير فعّالة، فما الطبقة التي ستعطل التجربة النهائية التي يراها المستخدم؟ إدخال المسار ضمن تقييم الأداء هو بالضبط ما يجعل هذه الآلية تستحق الملاحظة.

انظر إلى المسار أولًا، ثم إلى الأرقام—لا تعكس الترتيب. لا تكتفِ بمشاهدة سرعة التنفيذ.