لقد اختبرت عقدًا في بيئة الاختبار قرابة نصف سنة، وصرت الآن معتادًا أن أبدأ أولًا بنبش أساسيات طبقة الانتشار في السلاسل العامة. مؤخرًا وقعت في حفرة: وصلت سعة النطاق في العقد إلى حدها الأقصى مباشرةً، فامتلأت رسالة التنبيه بالبريد حتى صارت صفحة كاملة. في البداية ظننت أن ذلك بسبب اندفاع حجم المعاملات بقوة، لكن بعد أن راجعت السجلات فهمت الحقيقة: إن الإعداد الافتراضي في الطبقة السفلية هو ضخّ البيانات عبر الشبكة كلها بشكل عشوائي/واسع النطاق، وعندما تهتز العقد قليلًا، تُدفع الرسائل المتكررة بلا هوادة حتى كأنك داخل زحمة سير.
لاحقًا قرأت مستند @Dusk ، ووقفت عند جزء Kadcast. توقفت طويلًا فعلًا. فهو لا يستخدم أسلوب الانتشار الأعمى المعتاد؛ بل يعتمد على بنية Kademlia: تُحسب مسافة XOR انطلاقًا من تجزئة هوية العقدة لتصنيف العقد المستهدفة إلى صناديق/حاويات توجيه مختلفة. أثناء البث لا يتم إرسال الرسائل عشوائيًا إلى الجميع؛ بل يتم الترتيب حسب المسافة على طبقات، ثم يُعاد تشكيل المزامنة عبر الشبكة كلها إلى شجرة بث/إرسال متعددة مُهيكلة. أثناء اختباري محليًا، انخفضت بوضوح قمم استخدام النطاق، وبعد مرور الرسائل عبر عدة قفزات صار من الصعب على الأطراف الخارجية الاستدلال على المرسل فقط من خلال سمات تدفق البيانات. الورقة البيضاء تقول إنه يوفر 25%-50% من النطاق مقارنةً بـ Gossip التقليدي؛ أنا شخصيًا أعتبر هذا مجرد مرجع—لأن تكرار تشغيل/إيقاف العقد، واهتزازها عبر المناطق، وتأخر تحديث جدول التوجيه، إن اجتمعت كلها، فمن المؤكد أن الوفر الفعلي سينخفض. وبالتكامل مع BitVM3 للتأكد/التحقق كحل احتياطي، لا توجد حتى فرصة لدخول المعاملات غير المتوافقة/غير النظامية من الأساس. هذه الفكرة تشترك في منطق الطبقة التحتية نفسه مع منطق الرهن: فالقواعد مُثبّتة ومُحكمة داخل التشفير.
لكن الاعتماد العالي على منطق الطوبولوجيا له ثمن. فإذا صادفت تقسيمًا عبر دول (Network partition) أو قام عقد خبيثة بسكب بيانات قذرة داخل صناديق التوجيه، فإن كلفة البحث عند تبديل المسارات البديلة قد تلتهم سريعًا ميزة انخفاض التأخير. التحكم في النطاق أمر جيد فعلًا: المستخدم العادي الذي يراهن لا يحتاج إلى سحب خط مخصص، والانخفاض في العتبة ملحوظ، لكن تصحيح الأخطاء/استكشاف المشكلات مقارنةً بالبث التقليدي أعقد—لا بد أن تكون واعيًا بذلك.
كما وقعت في حفرة أيضًا عند الربط عبر السلاسل. الانتقال من الشبكة الرئيسية إلى BSC ليس مجرد نقل مباشر. يجب نقل DUSK الأصلي إلى حساب جسر رسمي. بعد أن تثبت الشبكة الرئيسية/التحقق القفل، يتم توليد BEP20 وفق عنوان BSC المحدد في Memo. يجب أن تكون الكمية أكبر من 1 DUSK؛ والرسوم هي رسوم الشبكة الرئيسية زائد رسوم جسر مقدارها 1 DUSK تقريبًا. وقت الوصول قرابة ساعة؛ أما الوصول الفعلي فيساوي حجم الإرسال ناقص 1.
يعالج Kadcast مخاطر التكرار والبحث عن المصدر رياضيًا بالمسافة، لكن في بيئة الشبكات العامة حيث تدخل العقد وتخرج باستمرار، هل تحديث جدول التوجيه سريع بما يكفي؟ وهل تجمع المسارات البديلة سميك بما يكفي؟ هذه هي الأشياء التي يجب حقًا مراقبتها. اجتيازها يعني ترقية عملية؛ وإن لم يسر الأمر فسيكون الأمر مجرد ديكور على الورق. $DUSK #dusk $DUSK
لاحقًا قرأت مستند @Dusk ، ووقفت عند جزء Kadcast. توقفت طويلًا فعلًا. فهو لا يستخدم أسلوب الانتشار الأعمى المعتاد؛ بل يعتمد على بنية Kademlia: تُحسب مسافة XOR انطلاقًا من تجزئة هوية العقدة لتصنيف العقد المستهدفة إلى صناديق/حاويات توجيه مختلفة. أثناء البث لا يتم إرسال الرسائل عشوائيًا إلى الجميع؛ بل يتم الترتيب حسب المسافة على طبقات، ثم يُعاد تشكيل المزامنة عبر الشبكة كلها إلى شجرة بث/إرسال متعددة مُهيكلة. أثناء اختباري محليًا، انخفضت بوضوح قمم استخدام النطاق، وبعد مرور الرسائل عبر عدة قفزات صار من الصعب على الأطراف الخارجية الاستدلال على المرسل فقط من خلال سمات تدفق البيانات. الورقة البيضاء تقول إنه يوفر 25%-50% من النطاق مقارنةً بـ Gossip التقليدي؛ أنا شخصيًا أعتبر هذا مجرد مرجع—لأن تكرار تشغيل/إيقاف العقد، واهتزازها عبر المناطق، وتأخر تحديث جدول التوجيه، إن اجتمعت كلها، فمن المؤكد أن الوفر الفعلي سينخفض. وبالتكامل مع BitVM3 للتأكد/التحقق كحل احتياطي، لا توجد حتى فرصة لدخول المعاملات غير المتوافقة/غير النظامية من الأساس. هذه الفكرة تشترك في منطق الطبقة التحتية نفسه مع منطق الرهن: فالقواعد مُثبّتة ومُحكمة داخل التشفير.
لكن الاعتماد العالي على منطق الطوبولوجيا له ثمن. فإذا صادفت تقسيمًا عبر دول (Network partition) أو قام عقد خبيثة بسكب بيانات قذرة داخل صناديق التوجيه، فإن كلفة البحث عند تبديل المسارات البديلة قد تلتهم سريعًا ميزة انخفاض التأخير. التحكم في النطاق أمر جيد فعلًا: المستخدم العادي الذي يراهن لا يحتاج إلى سحب خط مخصص، والانخفاض في العتبة ملحوظ، لكن تصحيح الأخطاء/استكشاف المشكلات مقارنةً بالبث التقليدي أعقد—لا بد أن تكون واعيًا بذلك.
كما وقعت في حفرة أيضًا عند الربط عبر السلاسل. الانتقال من الشبكة الرئيسية إلى BSC ليس مجرد نقل مباشر. يجب نقل DUSK الأصلي إلى حساب جسر رسمي. بعد أن تثبت الشبكة الرئيسية/التحقق القفل، يتم توليد BEP20 وفق عنوان BSC المحدد في Memo. يجب أن تكون الكمية أكبر من 1 DUSK؛ والرسوم هي رسوم الشبكة الرئيسية زائد رسوم جسر مقدارها 1 DUSK تقريبًا. وقت الوصول قرابة ساعة؛ أما الوصول الفعلي فيساوي حجم الإرسال ناقص 1.
يعالج Kadcast مخاطر التكرار والبحث عن المصدر رياضيًا بالمسافة، لكن في بيئة الشبكات العامة حيث تدخل العقد وتخرج باستمرار، هل تحديث جدول التوجيه سريع بما يكفي؟ وهل تجمع المسارات البديلة سميك بما يكفي؟ هذه هي الأشياء التي يجب حقًا مراقبتها. اجتيازها يعني ترقية عملية؛ وإن لم يسر الأمر فسيكون الأمر مجرد ديكور على الورق. $DUSK #dusk $DUSK