لنلقِ نظرة على أداء البلوكشين؛ من بين كل عشرة أشخاص، تسعة أول رد فعل لديهم هو TPS. والباقي ربما ينظر إلى التأخير. لكن بخصوص مشروع Dusk تحديدًا: إذا فتحت ورقةه البيضاء وتتبعتها بدقة، ستجد أن هناك شيئًا يستحق المتابعة أكثر من سرعة المعاملات—وهو كيف “يتحدث” كل عقدة مع الأخرى.
فكرة “البِسطة” جيدة، على كل حال—BTC ما هبطش كثير!
وأنا أقول هذا ليس لأن TPS غير مهم، بل لأن “الحساب بسرعة” و“النقل بسرعة” هما أصلًا أمران مختلفان. حتى لو كان مستوى التنفيذ لديك قويًا جدًا، وحتى لو كان تصميم الإجماع بالغ الدقة، إن تعطّلت الرسائل داخل شبكة العقد—كأن تصل الاقتراحات إلى المتحققين متأخرة، أو لا تعود نتائج التحقق إلى لجنة ratification—فسيضطر سير الخطوات الثلاث برمته إلى الانتظار. إذا وصل البلوك متأخرًا ببضع ثوانٍ، فهذا قد يقلل جودة التجربة بشكل خفيف، أما إن طال التأخير فقد تؤدي إلى أن ترى عقد مختلفة بلوكات مرشحة مختلفة، فيقفز معدل stale block بسرعة كبيرة.
اختار Dusk طريق Kadcast. ليس نمط بثٍ من نوع Gossip حيث “تمرّر الرسالة لأي شخص”، بل يعتمد على شبكة تغطية مهيكلة مبنية على Kademlia DHT؛ حيث تحدد مسافة XOR بين معرّفات العقد مسار التوجيه، فتتوسع الرسائل طبقةً بعد طبقة مثل شجرة. يبدو هذا أكاديميًا، أليس كذلك؟ لكن الفكرة الأساسية في جملة واحدة: كل رسالة تسلك الطريق الذي يجب أن تسلكه فقط، دون أن تذهب في مسارات لا داعي لها.
تستشهد الورقة البيضاء بأبحاث تقول إن Kadcast يوفر 25% إلى 50% من عرض النطاق مقارنةً بـ Gossip. على سبيل المثال: إذا كان الاستهلاك سابقًا 100 وحدة من عرض النطاق، فسيكون الآن تقريبًا 50 إلى 75. لكن هذه الأرقام لا يمكن ترجمتها مباشرة إلى “نصف تكلفة العقد”. فالإعدادات المادية لم تتغير، وحسابات الإثبات لم تتغير، وتكاليف التخزين لم تتغير—التغير الوحيد هو تكلفة النقل على طبقة الشبكة. ومع ذلك، بالنسبة لمن يشغّل العقد: ماذا يعني خفض عرض النطاق للنصف؟ يعني أنه يمكن—ضمن نفس شروط عرض النطاق—الانضمام إلى عدد أكبر من العقد، أو أن نفس حجم الشبكة لا ينخنق بسهولة بسبب تكاليف عرض النطاق.
هناك تفصيل يوضح المشكلة جيدًا. في وثائق العقد، تم وضع 9000/udp كمنفذ ضروري لـ Kadcast؛ وللمُزوِّد Provisioner أن يشارك في الإجماع يجب أن تكون هذه القناة قابلة للوصول. أما 8080/tcp فهو اختياري، ولا يُستخدم إلا عند الحاجة إلى واجهة الاستعلام. بعبارة أخرى: Kadcast ليس مجرد زينة في مخطط البنية—بل إنه يحدد مباشرةً ما إذا كانت العقد قادرة على الوصول إلى عتبة المشاركة في الإجماع.
ومن يعرف بث BTC من نظير إلى نظير يدرك أن طريقة عبور الرسائل داخل شبكة العقد ليست أمرًا بسيطًا. @Dusk $DUSK #dusk
فكرة “البِسطة” جيدة، على كل حال—BTC ما هبطش كثير!
وأنا أقول هذا ليس لأن TPS غير مهم، بل لأن “الحساب بسرعة” و“النقل بسرعة” هما أصلًا أمران مختلفان. حتى لو كان مستوى التنفيذ لديك قويًا جدًا، وحتى لو كان تصميم الإجماع بالغ الدقة، إن تعطّلت الرسائل داخل شبكة العقد—كأن تصل الاقتراحات إلى المتحققين متأخرة، أو لا تعود نتائج التحقق إلى لجنة ratification—فسيضطر سير الخطوات الثلاث برمته إلى الانتظار. إذا وصل البلوك متأخرًا ببضع ثوانٍ، فهذا قد يقلل جودة التجربة بشكل خفيف، أما إن طال التأخير فقد تؤدي إلى أن ترى عقد مختلفة بلوكات مرشحة مختلفة، فيقفز معدل stale block بسرعة كبيرة.
اختار Dusk طريق Kadcast. ليس نمط بثٍ من نوع Gossip حيث “تمرّر الرسالة لأي شخص”، بل يعتمد على شبكة تغطية مهيكلة مبنية على Kademlia DHT؛ حيث تحدد مسافة XOR بين معرّفات العقد مسار التوجيه، فتتوسع الرسائل طبقةً بعد طبقة مثل شجرة. يبدو هذا أكاديميًا، أليس كذلك؟ لكن الفكرة الأساسية في جملة واحدة: كل رسالة تسلك الطريق الذي يجب أن تسلكه فقط، دون أن تذهب في مسارات لا داعي لها.
تستشهد الورقة البيضاء بأبحاث تقول إن Kadcast يوفر 25% إلى 50% من عرض النطاق مقارنةً بـ Gossip. على سبيل المثال: إذا كان الاستهلاك سابقًا 100 وحدة من عرض النطاق، فسيكون الآن تقريبًا 50 إلى 75. لكن هذه الأرقام لا يمكن ترجمتها مباشرة إلى “نصف تكلفة العقد”. فالإعدادات المادية لم تتغير، وحسابات الإثبات لم تتغير، وتكاليف التخزين لم تتغير—التغير الوحيد هو تكلفة النقل على طبقة الشبكة. ومع ذلك، بالنسبة لمن يشغّل العقد: ماذا يعني خفض عرض النطاق للنصف؟ يعني أنه يمكن—ضمن نفس شروط عرض النطاق—الانضمام إلى عدد أكبر من العقد، أو أن نفس حجم الشبكة لا ينخنق بسهولة بسبب تكاليف عرض النطاق.
هناك تفصيل يوضح المشكلة جيدًا. في وثائق العقد، تم وضع 9000/udp كمنفذ ضروري لـ Kadcast؛ وللمُزوِّد Provisioner أن يشارك في الإجماع يجب أن تكون هذه القناة قابلة للوصول. أما 8080/tcp فهو اختياري، ولا يُستخدم إلا عند الحاجة إلى واجهة الاستعلام. بعبارة أخرى: Kadcast ليس مجرد زينة في مخطط البنية—بل إنه يحدد مباشرةً ما إذا كانت العقد قادرة على الوصول إلى عتبة المشاركة في الإجماع.
ومن يعرف بث BTC من نظير إلى نظير يدرك أن طريقة عبور الرسائل داخل شبكة العقد ليست أمرًا بسيطًا. @Dusk $DUSK #dusk