$DUSK لقد جربتُ تشغيل عددٍ لا بأس به من العقد عمليًا، لكن السبب الحقيقي الذي يرهق الناس ليس فقط ارتفاع حجم التداول بشكل حاد، بل كارثة البث العشوائي التي يطلقها نظام P2P على مستوى الطبقة الأساسية. أي شبكة قديمة عندما تتحرك تتعطل فورًا، والخلل كله يتجذر في آلية Gossip القديمة المتقادمة. فهي تقوم ببثٍ أعمى لكل المجموعة؛ وما إن ترتجف الشبكة قليلًا، فإن تأثير انهيار الثلج الناتج عن تكرار فقد الحزم يمكن أن يجهز ذاكرة خوادم كاملة في الحال.

لاحقًا، عندما قلبتُ كواليس الأساس لدى @Dusk ، اكتشفت أنهم نفذوا بعض الحيل الماكرة على أساس بنية Kadcast. المشروع لم يسلك طريق “غمر المياه على الجميع” القديم؛ بل استخدم مباشرة خوارزمية XOR لرسم شبكة توزيع موجّهة. كل جهاز يركز فقط على دفع البيانات ضمن نطاقه الصغير. بذلك، من المصدر يتم حشر الفوضى الناتجة عن البث الجماعي داخل مسارات ثابتة. حتى لو ارتفع حجم التداول فجأة، ستُكبَح البيانات المتناثرة على الأطراف.

لكن من الأخطاء التي اصطدمتُ بها على أرض الواقع، حتى لو كانت هناك خطة تخفيض حملٍ مذهلة على الرسومات، فلا بد من خصم شيء عند إدخالها إلى غرفة خوادم حقيقية. إدخال طوبولوجيا XOR في طبقة النقل يجعلها تبدو كعقد عادية على كمبيوتر عادي، لكن المشكلة أن عشرات الآلاف ينقطعون عن الشبكة ويُغلقون أجهزتهم يوميًا. بمجرد حدوث تخلّف واسع عن الركب، جدول التوجيه لن يواكب الأمر أصلًا. وإذا صادفتَ فُرقة في الشبكة، فإصلاح هذا النوع من المسارات الدقيقة أصعب بكثير من معالجة “البث الغامر”. وحتى مجرد محاولة التحقق من فقد الحزم يمكن أن يجنّن الناس. $BTC

عندما تقيّم قوة أساس سلسلة ما، لا تكتفِ بالنظر إلى اختبارات TPS المتضخمة. عليك أن ترى إن كانت البنية الأساسية ستتحمل “الانهيار الأسوأ” بالفعل. قفل البيانات بمسافات رياضية بحيث لا تتطاير عشوائيًا—هذا حقًا نهج عملي. لكن هل يمكن لهذه الفكرة أن تضمن الاستقرار في سيناريوهات التداول الواقعية التي تصبح فيها الشبكة في غاية الاختلال؟ أظن أننا لن نعرف إلا بعد أن نُجري اختبارًا لفترة قصيرة بكميات هائلة من المرور الفعلي “كي تُرضَخ” المشكلة للواقع. #dusk $ETH