في الشهر الماضي سكنتُ في فندق بعد رحلة متأخرة. لم يحتج الموظف في الاستقبال سوى إلى التأكد من أن الحجز كان باسمي وأنني أستوفي متطلبات الفندق. ومع ذلك، سلّمتُ جواز سفري، ما كشف اسمي الكامل وتاريخ ميلادي ورقم جواز السفر وجنسيتي، وغيرها من التفاصيل التي لا علاقة لها بالحصول على غرفة.
إن النمط نفسه يواجهه التنظيم في مجال العملات المشفرة. قد لا يحتاج النظام إلا إلى معرفة ما إذا كان العنوان (Wallet) يخص مشاركًا مؤهلًا أو ما إذا كانت بعض فحوصات الامتثال قد اكتملت. لكن التحقق التقليدي من الهوية غالبًا ما يثبت الأهلية عبر كشف الهوية نفسها. وعلى بلوكتشين عامة، يخلق ذلك مفاضلة غير مريحة بين الامتثال والخصوصية المالية.
يتعامل @Dusk مع ذلك بشكل مختلف عبر Citadel 2. يقوم مزوّد الترخيص بالتحقق من المستخدم دون اتصال بالإنترنت (off-chain)، ويوقّع السمات المطلوبة، ويقوم بتشفير الترخيص الناتج، ثم يسجله لدى عقد Citadel. لاحقًا، يمكن للمستخدم إنشاء برهان معرفة صفرية يثبت حيازة ترخيص مُوقّع من LP دون الكشف عن الترخيص بعينه الذي تم استخدامه. بعد التحقق، ينشئ العقد جلسة عامة، ويقدّم المستخدم ملف تعريف الارتباط الخاص بالجلسة (session cookie) إلى مزوّد الخدمة بدلًا من كشف بيانات الاعتماد الأساسية.
مراجعة نقدية ذاتية: لكن تشبيه الفندق يوضح أيضًا القيْد. حتى لو استطعتُ إثبات أنني ضيف مؤهل دون إظهار جواز سفري، ما زال الفندق يقرر ما الوثائق التي يثق بها، وما الذي يُعدّ صالحًا، ومتى تنتهي صلاحية التفويض، ومتى يجب إلغاء الوصول. لا يُزيل Citadel 2 طبقة السياسة هذه. ما يزال مزوّد الخدمة يختار مزوّدي الترخيص الموثوقين، والسمات المقبولة، وقواعد الانتهاء، وظروف الإلغاء، وما إذا كان يمكن إعادة استخدام ملف تعريف ارتباط الجلسة. يمكن للخصوصية تقليل الإفصاح غير الضروري، لكنها لا تستطيع محو سياسات القبول السيئة.
يجب تقييم $DUSK بناءً على مدى قدرته على تقليل الإفصاح عبر طبقة الهوية مع الحفاظ على قابلية فرض الثقة والإلغاء والانتهاء وسياسات بيانات الاعتماد، وليس فقط على ما إذا كان يستخدم براهين معرفة صفرية.
#dusk $JCT $ON
إن النمط نفسه يواجهه التنظيم في مجال العملات المشفرة. قد لا يحتاج النظام إلا إلى معرفة ما إذا كان العنوان (Wallet) يخص مشاركًا مؤهلًا أو ما إذا كانت بعض فحوصات الامتثال قد اكتملت. لكن التحقق التقليدي من الهوية غالبًا ما يثبت الأهلية عبر كشف الهوية نفسها. وعلى بلوكتشين عامة، يخلق ذلك مفاضلة غير مريحة بين الامتثال والخصوصية المالية.
يتعامل @Dusk مع ذلك بشكل مختلف عبر Citadel 2. يقوم مزوّد الترخيص بالتحقق من المستخدم دون اتصال بالإنترنت (off-chain)، ويوقّع السمات المطلوبة، ويقوم بتشفير الترخيص الناتج، ثم يسجله لدى عقد Citadel. لاحقًا، يمكن للمستخدم إنشاء برهان معرفة صفرية يثبت حيازة ترخيص مُوقّع من LP دون الكشف عن الترخيص بعينه الذي تم استخدامه. بعد التحقق، ينشئ العقد جلسة عامة، ويقدّم المستخدم ملف تعريف الارتباط الخاص بالجلسة (session cookie) إلى مزوّد الخدمة بدلًا من كشف بيانات الاعتماد الأساسية.
مراجعة نقدية ذاتية: لكن تشبيه الفندق يوضح أيضًا القيْد. حتى لو استطعتُ إثبات أنني ضيف مؤهل دون إظهار جواز سفري، ما زال الفندق يقرر ما الوثائق التي يثق بها، وما الذي يُعدّ صالحًا، ومتى تنتهي صلاحية التفويض، ومتى يجب إلغاء الوصول. لا يُزيل Citadel 2 طبقة السياسة هذه. ما يزال مزوّد الخدمة يختار مزوّدي الترخيص الموثوقين، والسمات المقبولة، وقواعد الانتهاء، وظروف الإلغاء، وما إذا كان يمكن إعادة استخدام ملف تعريف ارتباط الجلسة. يمكن للخصوصية تقليل الإفصاح غير الضروري، لكنها لا تستطيع محو سياسات القبول السيئة.
يجب تقييم $DUSK بناءً على مدى قدرته على تقليل الإفصاح عبر طبقة الهوية مع الحفاظ على قابلية فرض الثقة والإلغاء والانتهاء وسياسات بيانات الاعتماد، وليس فقط على ما إذا كان يستخدم براهين معرفة صفرية.
#dusk $JCT $ON