#dusk $DUSK اليوم كنت أقرأ وثائق طبقة الشبكة الخاصة بـ@Dusk . كنت أعتقد أن شبكات نظير-لنظير (P2P) الخاصّة بسلسلة الكتل (بلوك تشين) متشابهة إلى حد كبير—بثّ المعاملات، ومزامنة الكتل—ولا يوجد ما يستدعي تعمّقًا كبيرًا. لكن عندما رأيت مصطلح "Kadcast" أدركت أن Dusk لم تسلك الطريق القديم نفسه مع بروتوكول Gossip.
يعمل بروتوكول Gossip بطريقة تشبه لعبة نقل الرسائل: يختار كل عقدة عشوائيًا عدة جيران لتمرير الرسالة، ثم يقوم الجيران بتمريرها إلى جيرانهم، وفي النهاية يعرفها كامل الشبكة. ميزته أن لديه قدرة جيدة على التحمل (fault tolerance)، لكن ثمنه هو إهدار كبير في النطاق الترددي—قد يستقبل نفس العقدة الرسالة عدة مرات.
يستبدل Kadcast البثّ العشوائي بشبكة تغطية (overlay) مُهيكلة. بدلًا من اختيار الجيران عشوائيًا، تقوم العقدة بتمرير الرسائل بشكل موجّه وفقًا لبنية طوبولوجية منظمة. تقول الوثائق الرسمية إن ذلك يمكن أن يوفر بين 25% و50% من النطاق الترددي مقارنةً ببروتوكول Gossip التقليدي.
أفهم أن هذا التصميم يوازيه قيد يتمثل في أن تأكيد المعاملات في السيناريوهات المالية لا يمكن أن يعتمد على عشوائية عبارة "القيام ببثّها عدة مرات فحسب" لضمان وصولها. تعني التوجيهات المُهيكلة أن مسار انتشار الرسالة أكثر قابلية للتنبؤ، وأن التأخير (latency) أكثر قابلية للتحكم. وبالنسبة للأسواق المالية التي تتطلب تسويةً حتمية، فإن معرفة "كم تقريبًا من الوقت يستغرق وصول الرسالة" لا تقل أهمية عن معرفة أنها وصلت بالفعل.
لكن للوجه الآخر لهذا التحسين: الشبكات المُهيكلة تكون أكثر حساسية لانضمام العقد وخروجها. إذا كانت أعداد كبيرة من العقد غير متصلة في الوقت نفسه، فهل سيؤدي ذلك إلى إبطاء إعادة بناء جدول التوجيه (routing table) وبالتالي إبطاء كامل الشبكة؟ لم أجد بيانات تأخير في الوثائق العامة الحالية تحت تقلبات كبيرة في أعداد العقد.
عند النظر إلى طبقة الشبكة لـ#dusk ، لا أريد فقط رؤية TPS وزمن إنتاج الكتل، بل أريد رؤية توفير النطاق الترددي الفعلي وتوزيع التأخير بعد إطلاق Kadcast على الشبكة الرئيسية ضمن التوزيع الحقيقي للعقد. إن كانت الطبقة الأساسية لـDUSK تعمل بثبات، فحينها فقط سيكون للتطبيقات المالية التي فوقها أساس متين.#dusk @Dusk