عندما شاهدت Citadel2 الخاصة بـ 看$DUSK ، لفتني جدًا هذا القول: “إنجاز KYC مرة واحدة يكفي لإعادة استخدامه في كل مكان”. لقد استغرقت قليلًا من الوقت لأهدأ وأراجع الوثائق ومستودع الشيفرة، ثم اكتشفت أن هناك شروطًا ضمنية مدفونة هنا.
باختصار، تكون العملية كالتالي: يقوم المستخدم بإتمام التحقق من الهوية دون اتصال عبر LP، ثم يحصل على بيانات اعتماد مشفرة تُسجّل على السلسلة. لاحقًا، عند الوصول إلى كل تطبيق، يثبت عبر برهان ZK أنه ملتزم بالشروط دون الحاجة إلى كشف بيانات الخصوصية.
في البداية اعتقدت أنه ما دمت أُجري KYC مرة واحدة وأحصل على بيانات الاعتماد، فيمكنني استخدامها في كل مكان. لكن عند تتبّع منطق بروتوكول Citadel خطوة بخطوة، وجدت تفصيلة محورية: يملك مزوّد الخدمة Service Provider الحق في تحديد بنفسه أي License Provider يثق به.
Citadel نفسها لا تُلزم جميع مزودي الخدمة (SP) بتبنّي معيار واحد موحّد لبيانات الاعتماد. مثالًا: قد تعتمد الأعمال A على LP معيّن، بينما قد لا تعترف الأعمال B بذلك. إذا قمت بإجراء KYC داخل الأعمال A وأصدرت LP المعني بيانات اعتماد لا تقبلها الأعمال B، فستحتاج لإجراء KYC مرة أخرى. وبهذا فإن نطاق “إعادة استخدام KYC مرة واحدة” يُقيّد طبيعيًا بـ “دوائر صغيرة يتبادل فيها الطرفان الاعتراف بنفس مجموعة الـLP”. وبمجرد الخروج عن هذه الدائرة، تصبح إعادة الاستخدام بلا فاعلية $BTR
كنت أنوي معرفة مدى اكتمال وثائق التكامل الموجهة للمؤسسات. راجعت كل شيء تقريبًا، ووجدت أن W3sper SDK موجود بالفعل. لكن بالنسبة لإرشادات التكامل على مستوى المؤسسات وخطط إدارة الصلاحيات… لم أجد نسخة مكتملة بما يكفي. قد يكون أيضًا أنني بحثت في المكان غير المناسب، لكن على الأقل من القنوات العلنية، يبدو أن دمج المؤسسات مباشرة ليس عتبة منخفضة.
خذ مقارنة مع eIDAS في الاتحاد الأوروبي: في العالم الواقعي، يتم الدفع بالفعل نحو الاعتراف المتبادل بالهوية—لكن دون الاعتماد على ZK. الفكرة التقنية لـ Citadel صحيحة، لكن بروتوكول الهوية يعتمد بشدة على أثر الشبكة. لكي يعمل هذا النظام، يجب أن يوجد عدد كبير من LP المرخّصين، وأن تكون مختلف أنواع مزودي الأعمال (SP) مستعدة لقبول هذه البيانات. حاولت البحث إن كانت هناك أمثلة خارجية لـLP مرخصة تم تطبيقها بالفعل، لكن بعد جولة لم أجد معلومات علنية واضحة جدًا. قد يكون أيضًا أنها ما زالت في مرحلة مبكرة، وبالتالي لم تنتشر المعلومات بعد، لكن على الأقل ما يمكن رؤيته الآن هو أن الدفع يقوم أساسًا من #dusk نفسه، ولا تظهر آثار واضحة لمشاركة الأطراف الخارجية المرخّصة.
لن أُصدر حكمًا سلبيًا مؤقتًا، لكني سأظل أتابع إشارتين حاسمتين: تحقق انتشار LP مرخصة خارجية، وإطلاق JS SDK رسميًا. إلى أن لا أرى هاتين التغييرات، ما زالت “إعادة استخدام KYC مدى الحياة” أمامه طريق طويل جدًا @Dusk .
باختصار، تكون العملية كالتالي: يقوم المستخدم بإتمام التحقق من الهوية دون اتصال عبر LP، ثم يحصل على بيانات اعتماد مشفرة تُسجّل على السلسلة. لاحقًا، عند الوصول إلى كل تطبيق، يثبت عبر برهان ZK أنه ملتزم بالشروط دون الحاجة إلى كشف بيانات الخصوصية.
في البداية اعتقدت أنه ما دمت أُجري KYC مرة واحدة وأحصل على بيانات الاعتماد، فيمكنني استخدامها في كل مكان. لكن عند تتبّع منطق بروتوكول Citadel خطوة بخطوة، وجدت تفصيلة محورية: يملك مزوّد الخدمة Service Provider الحق في تحديد بنفسه أي License Provider يثق به.
Citadel نفسها لا تُلزم جميع مزودي الخدمة (SP) بتبنّي معيار واحد موحّد لبيانات الاعتماد. مثالًا: قد تعتمد الأعمال A على LP معيّن، بينما قد لا تعترف الأعمال B بذلك. إذا قمت بإجراء KYC داخل الأعمال A وأصدرت LP المعني بيانات اعتماد لا تقبلها الأعمال B، فستحتاج لإجراء KYC مرة أخرى. وبهذا فإن نطاق “إعادة استخدام KYC مرة واحدة” يُقيّد طبيعيًا بـ “دوائر صغيرة يتبادل فيها الطرفان الاعتراف بنفس مجموعة الـLP”. وبمجرد الخروج عن هذه الدائرة، تصبح إعادة الاستخدام بلا فاعلية $BTR
كنت أنوي معرفة مدى اكتمال وثائق التكامل الموجهة للمؤسسات. راجعت كل شيء تقريبًا، ووجدت أن W3sper SDK موجود بالفعل. لكن بالنسبة لإرشادات التكامل على مستوى المؤسسات وخطط إدارة الصلاحيات… لم أجد نسخة مكتملة بما يكفي. قد يكون أيضًا أنني بحثت في المكان غير المناسب، لكن على الأقل من القنوات العلنية، يبدو أن دمج المؤسسات مباشرة ليس عتبة منخفضة.
خذ مقارنة مع eIDAS في الاتحاد الأوروبي: في العالم الواقعي، يتم الدفع بالفعل نحو الاعتراف المتبادل بالهوية—لكن دون الاعتماد على ZK. الفكرة التقنية لـ Citadel صحيحة، لكن بروتوكول الهوية يعتمد بشدة على أثر الشبكة. لكي يعمل هذا النظام، يجب أن يوجد عدد كبير من LP المرخّصين، وأن تكون مختلف أنواع مزودي الأعمال (SP) مستعدة لقبول هذه البيانات. حاولت البحث إن كانت هناك أمثلة خارجية لـLP مرخصة تم تطبيقها بالفعل، لكن بعد جولة لم أجد معلومات علنية واضحة جدًا. قد يكون أيضًا أنها ما زالت في مرحلة مبكرة، وبالتالي لم تنتشر المعلومات بعد، لكن على الأقل ما يمكن رؤيته الآن هو أن الدفع يقوم أساسًا من #dusk نفسه، ولا تظهر آثار واضحة لمشاركة الأطراف الخارجية المرخّصة.
لن أُصدر حكمًا سلبيًا مؤقتًا، لكني سأظل أتابع إشارتين حاسمتين: تحقق انتشار LP مرخصة خارجية، وإطلاق JS SDK رسميًا. إلى أن لا أرى هاتين التغييرات، ما زالت “إعادة استخدام KYC مدى الحياة” أمامه طريق طويل جدًا @Dusk .