#dusk $DUSK
لقد عدت خلال اليومين الأخيرين لإعادة مشاهدة Citadel 2 الخاصة بـ @Dusk .
في السابق كنت أفهمها دائمًا على أنها «أداة هوية لـ ZK»، لكنني أعتقد الآن أن هذا الوصف مبالغ فيه بعض الشيء.
في الحقيقة، لم يكن هدفها أن تتخذ نيابةً عن المنصة الكثير من القرارات.
يبدأ المستخدم بإجراء تحققٍ دون اتصال (Offline) عبر License Provider للحصول على credential. وبعد ذلك، عند الوصول إلى خدمة ما، يستخدم ZK لإثبات أنه يمتلك فعلًا مؤهلية/صلاحية صالحة.
حتى هذه المرحلة، ما يمكن لـ Citadel إثباته هو أن هذه credential صحيحة ولا يوجد بها مشكلة.
لكن ما إذا كانت المنصة تعترف فعلًا بهذه الجهة LP (License Provider) — وهل ما زال الـ credential قابلاً للاستخدام حاليًا — وهل تم سحبه (revocation) — وهل يلزم إعادة التحقق من session أم لا… فهذه الأمور لا يتولى Citadel تلقائيًا التعامل معها نيابةً عنك.
عندما بدأت القراءة هنا، كنت مترددًا قليلًا أيضًا، وشعرت أنها كأنها «تعمل نصف العمل فقط».
لاحقًا اتضح لي الأمر: فالأعمال المالية أصلًا من غير الممكن أن تكون لها مجموعة واحدة فقط من قواعد القبول.
نفس الـ credential، في مناطق مختلفة، ومنتجات مختلفة، ومنصات مختلفة — هل يمكن استخدامه أم لا — هذا بحد ذاته أمر آخر.
لذلك، وبالنسبة لي الآن، أجد تصميم Citadel 2 أكثر احتواءً وضبطًا.
فهو يتولى أولًا التعامل مع سؤال: «هل هذا الإثبات حقيقي؟» أما سؤال: «هل هذا الإثبات يكفي؟» فيُترك للحكم عليه من قبل العمل/المنطق التفصيلي الخاص.
بما في ذلك revocation وexpiration وإعادة تشغيل session (session replay) — لم يتم تغليفها على أنها بروتوكول واحد يقوم بحل كل شيء نيابةً عنك.
هذا الموضع يهمني كثيرًا.
لأن العديد من المشاريع عندما تقترب من ZK، تميل بسهولة إلى إسناد أي مشكلة إلى عبارة «يمكن حلها بالتشفير».
حتى الآن، الانطباع الذي تركه Citadel 2 لدي ليس بهذه الضبابية/المبالغة.
إنه أقرب إلى كونه ينظف طبقة إثبات الصلاحية أولًا، وبعدها تُترك القواعد اللاحقة: من عليه مسؤولية تلك القواعد، فهو المسؤول عنها كما هي.
لقد عدت خلال اليومين الأخيرين لإعادة مشاهدة Citadel 2 الخاصة بـ @Dusk .
في السابق كنت أفهمها دائمًا على أنها «أداة هوية لـ ZK»، لكنني أعتقد الآن أن هذا الوصف مبالغ فيه بعض الشيء.
في الحقيقة، لم يكن هدفها أن تتخذ نيابةً عن المنصة الكثير من القرارات.
يبدأ المستخدم بإجراء تحققٍ دون اتصال (Offline) عبر License Provider للحصول على credential. وبعد ذلك، عند الوصول إلى خدمة ما، يستخدم ZK لإثبات أنه يمتلك فعلًا مؤهلية/صلاحية صالحة.
حتى هذه المرحلة، ما يمكن لـ Citadel إثباته هو أن هذه credential صحيحة ولا يوجد بها مشكلة.
لكن ما إذا كانت المنصة تعترف فعلًا بهذه الجهة LP (License Provider) — وهل ما زال الـ credential قابلاً للاستخدام حاليًا — وهل تم سحبه (revocation) — وهل يلزم إعادة التحقق من session أم لا… فهذه الأمور لا يتولى Citadel تلقائيًا التعامل معها نيابةً عنك.
عندما بدأت القراءة هنا، كنت مترددًا قليلًا أيضًا، وشعرت أنها كأنها «تعمل نصف العمل فقط».
لاحقًا اتضح لي الأمر: فالأعمال المالية أصلًا من غير الممكن أن تكون لها مجموعة واحدة فقط من قواعد القبول.
نفس الـ credential، في مناطق مختلفة، ومنتجات مختلفة، ومنصات مختلفة — هل يمكن استخدامه أم لا — هذا بحد ذاته أمر آخر.
لذلك، وبالنسبة لي الآن، أجد تصميم Citadel 2 أكثر احتواءً وضبطًا.
فهو يتولى أولًا التعامل مع سؤال: «هل هذا الإثبات حقيقي؟» أما سؤال: «هل هذا الإثبات يكفي؟» فيُترك للحكم عليه من قبل العمل/المنطق التفصيلي الخاص.
بما في ذلك revocation وexpiration وإعادة تشغيل session (session replay) — لم يتم تغليفها على أنها بروتوكول واحد يقوم بحل كل شيء نيابةً عنك.
هذا الموضع يهمني كثيرًا.
لأن العديد من المشاريع عندما تقترب من ZK، تميل بسهولة إلى إسناد أي مشكلة إلى عبارة «يمكن حلها بالتشفير».
حتى الآن، الانطباع الذي تركه Citadel 2 لدي ليس بهذه الضبابية/المبالغة.
إنه أقرب إلى كونه ينظف طبقة إثبات الصلاحية أولًا، وبعدها تُترك القواعد اللاحقة: من عليه مسؤولية تلك القواعد، فهو المسؤول عنها كما هي.