#dusk $DUSK @Dusk

كنت أجلس مع طبقة الامتثال لدى Dusk لفترة من الوقت، وتبيّن أن شيئًا لم أكن أستطيع تأكيده في البداية كان مذكورًا بشكل مباشر بالفعل.

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

ما كنت غير متأكد منه في البداية: أي الإجراءات تحتاج فعلًا إلى هذه البوابة مقابل تلك التي تظل مفتوحة. توضح وثائق Dusk الخاصة بالبنية التحتية للسوق هذا مباشرةً. فهي تنص على أن تقديم الخدمة والإفصاح — الإبلاغ، والإجراءات المؤسسية، والوصول الانتقائي إلى المعلومات المطلوبة — يمكن تنفيذه بطرق مختلفة عبر تطبيقات مختلفة، حيث توفر Dusk اللبنات الأساسية للبروتوكول ومسارات التنفيذ، وليس قاعدة ثابتة على مستوى الشبكة بالكامل.

هذا يؤكد ما كنت قد شككت فيه فقط سابقًا. قرار فرض البوابة ليس من بروتوكول Dusk الذي يفرض أن "الإجراء X يحتاج دائمًا إلى ترخيص". بل إن كل تطبيق مبني على Citadel يختار ما الذي سيتم تقييده.

مثال NPEX (dApp المُنظّم) الذي يجرى طرحه فعليًا على DuskEVM اعتبارًا من عام 2026 هو أوضح اختبار حي لذلك — مع أنني أريد أن أكون دقيقًا: هذا الطرح جارٍ، وليس نشرًا مكتملًا ومؤكّدًا أستطيع الإشارة إليه كدليل نهائي مُنجز بعد.

يجعلني ذلك أفكر في أن السؤال الأعمق ليس "ما الذي تفرض Citadel بوابته" — بل أن Citadel لم تكن مُصممة أصلًا لتجيب عن هذا السؤال على مستوى البروتوكول. الإجابة كان من المتوقع دائمًا أن تأتي من الجهة التي تُصدر الأصل فوقه.

لذا فإن عبارة "بعض الإجراءات تتطلب ترخيصًا بينما لا تتطلبه أخرى" ليست سياسة موحّدة على مستوى Dusk. إنها خيار تهيئة خاص بكل مُصدر، باستخدام أدوات قامت Dusk ببنائها خصيصًا لتُضبط بهذه الطريقة.

على أي حال، الوقت سيخبر 👍