#dusk $DUSK اليوم قمتُ بتفكيك بروتوكول الإجماع لـ@Dusk ، وعلقتُ على كلمة واحدة: "committee-based". كثير من سلاسل PoS تستخدم آلية اللجان، لكن SA الخاصة بـDusk — Succinct Attestation — تتبع نهجًا من ثلاث خطوات: الاقتراح والتحقق والموافقة، تُنفَّذ كل خطوة بواسطة مُوفِّر (provisioner) مختلف يتم اختياره عشوائيًا.
الخطوة الأولى: يقوم provisioner بإنشاء كتلة مرشَّحة وبثّها. الخطوة الثانية: تتحقق لجنة التحقق من صلاحية الكتلة. الخطوة الثالثة: تقوم لجنة الموافقة الأخرى بالتحقق من نتيجة التحقق وتُنهِي الكتلة في النهاية. يبدو أنها أضافت خطوة إضافية، لكن هذه الخطوة تفصل بين "التحقق" و"تأكيد نتيجة التحقق".
أفهم نية التصميم هنا: إذا كان التحقق والموافقة تتمّان بواسطة المجموعة نفسها من الأشخاص، فإن نتيجة التحقق بحد ذاتها تصبح حكمًا نهائيًا دون أي موازنة. إن تقسيمها إلى خطوتين يعني أن لجنة الموافقة لا تحتاج فقط إلى النظر في الكتلة، بل أيضًا أن تتحقق مما إذا كانت لجنة التحقق قد أنجزت عملها بجدية. وهذا يعادل إضافة طبقة فحص جودة داخل الإجماع.
وهذا التصميم يفرض أيضًا قيدًا ضمنيًا: اللجان يتم اختيارها عشوائيًا بناءً على كمية الرهن (الضمان). يريد المهاجم السيطرة على خطوة ما، لكنه يحتاج إلى التحكم في كمية كبيرة من الرهن، فضلًا عن ضرورة أن يتم اختياره بالصدفة ضمن نفس اللجنة في الوقت نفسه. الاحتمال هنا أصعب بكثير من التحكم في مجموعة تحقق واحدة.
لكن ثمن الإجماع المتدرّج هو التأخير. كلما زادت الخطوات زادت دورة الاتصالات. كيفية الحفاظ على تأكيد منخفض التأخير في سيناريوهات المعاملات المالية عالية التردد، هو أمر لم أجد له حتى الآن بيانات كافية في الوثائق العامة.
وبالنظر إلى طبقة الإجماع لـ#dusk ، سأستمر في متابعة الفاصل الزمني بين إصدار الكتلة وإنهائها نهائيًا، وتيرة تبديل اللجان، ومعدل الانقسامات الفعلي في الشبكة. بما أن DUSK هو أصل مُرهَن، فإن فرضيات الأمان الخاصة بالإجماع تحدد مباشرة نوع المخاطر التي يواجهها المُرهِنون. #dusk @Dusk