تفصيلة الخصوصية التي لم أتوقعها في Dusk ليست متعلقة بإخفاء الأرصدة. إنها تتعلق بما يحدث بعد نجاح إثبات هوية بالمعرفة الصفرية.

يستخدم معيار مسودة Citadel 2 لشهر مايو 2026 على السلسلة "session_id" كـ nullifier. وبالنسبة لنفس الترخيص المخفي والتحدي المقبول، يمكن للعقد رفض جلسة مكررة. يبدو هذا في البداية كحماية من إعادة التشغيل.

لكن المواصفة ترسم خطًا أكثر حدة: الـ nullifier يوقف إنشاء جلسة مكررة على السلسلة؛ ولا يمنع شخصًا ما من إعادة استخدام نفس ملف تعريف الارتباط (cookie) الخاص بالجَلسة المفصح عنه خارج السلسلة.

وهذا ما جعلني أتفحص الأمر مرتين.

في Citadel، يتحقق السلسلة من صحة التشفير ويسجل الجلسة. ومع ذلك، ما زال على مزوّد الخدمة فرض قواعده الخاصة ضد إعادة التشغيل، وثقة المُصدِر، والإلغاء، والانتهاء، وربط الحساب، وحدود المعدّل.

أعتقد أن هذا الفصل أكثر إثارة من شعارٍ بسيط مثل "الخصوصية + الامتثال". فهو يمنع البروتوكول الأساسي من ترميز سياسة وصول كل مؤسسة بشكل صارم، بينما يدفع مسؤولية التفويض الحقيقية إلى طبقة التطبيق.

المقايضة واضحة: لا يمكن للمطوّرين اعتبار "إثبات ZK صالح" مكافئًا لـ "مُعرّف وصول آمن وقابل لإعادة الاستخدام".

بالنسبة لـ @Dusk و $DUSK ، سأراقب كيف تُوحِّد ملفات تعريف Citadel في بيئة الإنتاج الاستخدام لمرة واحدة والربط والإلغاء دون الإضرار بالخصوصية. ما خيارات السياسة التي تصبح افتراضية — وأيّها يبقى خاصًا بالتطبيق؟ #dusk

#dusk $DUSK @Dusk