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

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

المستخدم يثبت أنه يملك ترخيصًا صالحًا دون الكشف عن هويته، وعقد الترخيص على Dusk يتحقق منه، ثم يتم إلحاق nullifier، ويتم إصدار ملف تعريف ارتباط (session cookie). تبدو الخطوة الأخيرة كأن الوصول مُنح، صحيح؟ لكن الخطوة الأخيرة في التسلسل هي التي لا يذكرها أحد. يقوم مزوّد الخدمة بجلب تلك الجلسة، ويتحقق من الكوكي محليًا، ثم يقرر هو نفسه في النهاية ما إذا كان سيمنح الخدمة فعليًا. Citadel لا يفعل سوى التأكد من أن بيانات الاعتماد حقيقية ولم تُعاد استخدامها مسبقًا. ولا يقول شيئًا عن ما إذا كانت تلك بيانات الاعتماد أصلاً كافية لما يريده مزوّد الخدمة.

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

ما أراقبه ليس مدى سرعة توليد الإثباتات على Dusk. بل ما إذا كان مزوّدو الخدمة يبنون فعليًا منطق سياسة حقيقي فوق Citadel، أم أن عملية التحقق تصبح بهدوء مجرد بوابة “نجح/فشل” إضافية بخطوات أكثر.

إذا كان النظام يستطيع إثبات شيء أنه صحيح لكن لا يستطيع تحديد ماذا يعني هذا “الصدق” فعليًا، فالشعور هو أن عنق الزجاجة الحقيقي لم يكن الإثبات. كان دائمًا الطرف الذي يسأل السؤال.

$DUSK

$TUT

$PORTAL


إلى أين ينبغي أن تذهب نمذجة الوصول في Citadel 2 بعد ذلك؟