#dusk $DUSK بمجرد أن يتم التشفير، كيف تعرف عقدة التحقق أن هذه المعاملة حقيقية؟ في البداية ظننتُ أنه إما يجب التضحية بالسرعة والتحقق ببطء، أو أن على كل عقدة أن تحصل على النص الصريح، وهذان الطريقان بدا كلٌ منهما غير مريح.
لاحقًا، عندما أعدتُ قراءة آلية الإجماع Succinct Attestation الخاصة بـ Dusk، اكتشفت أنها لم تسلك أصلًا أيًّا من الطريقين اللذين توقعتُهما. فهي تستخدم أسلوبًا قابلًا للطي في تجميع الإثباتات — حيث يمكن ضغط الإثباتات الجزئية الناتجة عن عدة مُتحققين إلى دليل واحد مدمج، ولا يبقى على السلسلة في النهاية إلا هذا الدليل الواحد. بمعنى آخر، عملية التحقق نفسها موزعة، لكن الأثر المسجل على السلسلة مختصر.$SPCXB
وبالمقارنة مع ما يحدث في PoS التقليدي، حيث يجب على كل مُتحقق أن يبث توقيعه بشكل منفصل ثم تُكدَّس مجموعة من التواقيع داخل الكتلة، فإن ما يوفره هذا النهج ليس القدرة الحاسوبية، بل عرض النطاق وتضخم الحالة. من أكثر ما تخشاه سلاسل الخصوصية أن البيانات المشفرة تكون متضخمة أصلًا، وإذا أضفتَ إليها مجموعة من التواقيع الزائدة فلن تتمكن العقد من العمل أصلًا. هذا التصميم في DUSK يعادل فصل "تكلفة الإجماع" عن "تكلفة الخصوصية" وتحسينهما كلٌّ على حدة، بحيث لا يتعارضان.
ما يحلّه هذا فعلًا ليس سؤال "هل الإجماع سريع أم لا"، بل جعل تكلفة التحقق في سلسلة الخصوصية لا تنمو خطيًا مع عدد المشاركين — وهذا يكاد يكون سؤالًا لا مفر منه في سيناريوهات التمويل المنظم حيث قد يكون عدد الأطراف المشاركة عشرات أو مئات.$AKE
وبالطبع، لا أرى أنه مثالي تمامًا. فإذا كان هناك خلل في عملية توليد الإثبات المجمّع، فقد يتم "تغليف" خطأ عقدة سيئة داخل الدليل النهائي، وسيصبح إسناد المسؤولية أصعب بكثير من النموذج التقليدي. كما أن أداء هذه الآلية تحت حالات التجزئة الشبكية الشديدة لا يزال، وفق البيانات المتاحة علنًا، غير كافٍ تمامًا.
فهل يمكن فعلًا أن تكون كفاءة الإجماع في سلسلة خصوصية سريعة وقابلة للتحقق في الوقت نفسه؟ شاركونا آراءكم في التعليقات.#dusk @Dusk