#dusk $DUSK 翻DUSK 的 سجلات التزاماته على GitHub أكثر إثارة للاهتمام من قراءة الورقة البيضاء. من أبريل إلى يونيو 2026، ظهر في مستودع rusk مصطلح عالي التكرار: revocation. وثلاث إصدارات minor release متتالية كانت تقوم باستكمال حالات الحد المتعلقة بإبطال/تعليق أوراق اعتماد Citadel—مثل: كيف يُعالج "رمز المستثمر المؤهل" الذي تم توقيعه بعد إفلاس الجهة، وكيف تتم مزامنة قوائم الإبطال عبر الولايات القضائية، وهل يجب إبطال/إلغاء إثباتات ZK التي تم توليدها بالفعل بعد الإبطال.
وهذا بالضبط هو الضعف الطري في DUSK الذي يسهل تجاهله. الجميع يركز على الخصوصية في UTXO الخاص بـ Phoenix والإفصاح الانتقائي لـ Hedger، ويظنون أن نموذج "إخفاء افتراضي + تفويض قابل للتدقيق" قد حل تعارض الخصوصية والامتثال. لكن مرساة الثقة في طبقة هوية Citadel ليست دوائر ZK، بل المُصدِر نفسه—فإذا أفلس المُصدِر أو تم تعليق ترخيصه، فإن كل credential التي أصدرها في التاريخ تصبح، من الناحية القانونية، ورقًا فارغًا فورًا، غير أن الإثباتات التي تم توليدها على السلسلة باستخدام تلك الـ credential لا تصبح تلقائيًا غير صالحة.
وهذا يعيدنا إلى مشكلة قديمة: إثبات ZK بأن "كنتُ مستوفيًا للشروط آنذاك" ليس هو الشيء نفسه كأن تقول "ما زلتُ مستوفيًا للشروط"؛ فالحالة الأخيرة تتطلب فحصًا للإبطال بشكل فوري، وفحص الإبطال الفوري إما أن يتم عبر السلسلة (بتكلفة gas مرتفعة) أو عبر oracle (مع تراجع/انخفاض في نموذج الثقة). لا تمنح وثائق DUSK حاليًا إلا قدرًا محدودًا من التفصيل حول معلمات الحوكمة الحرجة مثل نافذة تأخير الإبطال، وتأمين المسؤولية عن المُصدِر، وتعيين/ربط بيانات الاعتماد عبر الولايات القضائية—وهذه هي الأسئلة الأولى التي يطرحها التدقيق (due diligence) لدى المؤسسات المالية المرخصة.
يمكن للكود أن يحل "كيف نُثبت"، لكنه لا يحل "من يملك الحكم". إذا لم يقم DUSK خلال السنة القادمة بكتابة إطار حوكمة Citadel في ملحقات اتفاقية قانونية، وعدم إلزام NPEX أو جهات مرخصة مثل 21X بتحمل مسؤولية الإصدار بشكل تعاقدي، فستبقى—في نظر المؤسسات—مجرد "منتج تحقق تقني"، وليس بنية تحتية مالية يمكن الاستعانة/الاعتماد عليها لإدارتها.
#dusk @Dusk