هوية البروتوكول هي المفتاح الأساسي لفهم اختلاف Concordium (CCD) عن شبكات البلوكشين العامة الأخرى. في حين تعتمد معظم الشبكات على معادلة "العنوان = الهوية" وتضع التحقق من الهوية (KYC) على منصات مركزية، تُضمِّن Concordium الربط بين الكيانات الموثقة والحسابات مباشرة في البروتوكول. هذا يضمن أن جميع المعاملات، وتسجيلات الوكلاء، وفحوصات السمات قائمة على أساس موحد للمساءلة.
غالبًا ما يُطرح سؤال: إذا كان الامتثال مطلوبًا، لماذا لا يتم رفع نتائج التحقق من الهوية (KYC) مباشرة على السلسلة؟ توضح Concordium أن السلسلة تحتاج فقط إلى تفويض ونتائج سمات قابلة للتحقق، وليس كشف السجلات الحساسة بشكل دائم. هنا يأتي دور إثباتات المعرفة الصفرية (ZKP) كحل وسط يحقق ذلك.
ما الذي تحله هوية البروتوكول؟ وما الفرق بينها وبين "إخفاء العنوان"؟
النموذج المعتاد في البلوكشين هو الاسم المستعار: العناوين قابلة للتتبع لكن لا ترتبط دائمًا بأطراف خاضعة للمساءلة. قد يكون هذا كافيًا للتحويلات البسيطة، لكن لخدمات التوقيع، أو الوصول القائم على المؤهلات، أو لمعاملات PayFi للمؤسسات، يحتاج الأطراف إلى معرفة "من المسؤول" و"هل شروط الامتثال مستوفاة"—دون كشف جميع البيانات الشخصية.
| النموذج |
مكان الهوية |
أبرز القيد |
| إخفاء العنوان |
لا يوجد ربط على مستوى البروتوكول |
صعوبة المساءلة، والامتثال يعتمد على منصات خارج السلسلة |
| وضع علامة تحقق الهوية في المنصة |
قاعدة بيانات مركزية |
البيانات معزولة، والاعتراف عبر التطبيقات محدود |
| هوية البروتوكول |
ربط عند إنشاء الحساب |
يتطلب دعم منظومة إصدار هوية قوية |
في Concordium، يُربط كل حساب على البروتوكول بجهة أو شركة تم التحقق منها من جهة إصدار معتمدة، ويُفرض هذا الربط ضمن قواعد الشبكة، وليس كإضافة اختيارية في تطبيق لامركزي (DApp). هذا يتيح تسجيل وتحقق سجل الوكلاء بالعودة إلى أطراف معتمدة وموثقة.
كيف يتم ربط حسابات Concordium بأشخاص أو جهات حقيقية؟
تتم عملية الربط على مستويين: تحقق خارج السلسلة، وإشارة مرجعية على السلسلة. يقدّم المستخدم المستندات المطلوبة إلى جهة إصدار معترف بها ضمن منظومة Concordium، وبعد إتمام KYC أو KYB، تمنح الجهة كائن هوية لحساب المستخدم. ما يظهر على السلسلة هو مرجع الهوية والبنية التشفيرية المرتبطة بالحساب، وليس نسخًا نصية مكشوفة من المستندات الأصلية.
كائن الهوية يمنح الحساب "أصلًا موثقًا": كل إجراء يوقعه الحساب—من إنشاء وكيل إلى بدء معاملة أو تقديم إثبات سمة—يمكن ربطه بكيان معتمد من الجهة المصدرة. تخضع عمليات الإلغاء والتحديث والانتهاء لسياسات البروتوكول والجهة معًا، ووفق معايير وثائق الشبكة.
وهذا يختلف عن "فتح حساب في منصة مركزية ثم السحب على السلسلة": تظل عمليات KYC في المنصة المركزية داخلية، ويبقى عنوان السلسلة مجهولًا. بينما تستهدف Concordium أن تحمل الحسابات على السلسلة سلسلة موثقة من المسؤولية منذ البداية.
كيف تعمل إثباتات المعرفة الصفرية؟ وما الذي تثبته؟
تسمح إثباتات المعرفة الصفرية للمُثبِت بإثبات صحة عبارة للمُحقِّق دون كشف المزيد من التفاصيل. في Concordium، تتعلق هذه الإثباتات غالبًا بالسمات: هل المستخدم فوق 18 عامًا، يقيم في دولة معينة، مؤهل كمستثمر معتمد، أو ضمن حد إنفاق معين.
الآلية تمر بأربع خطوات: تتحقق جهة الهوية من المستندات خارج السلسلة وتدرج بيانات الاعتماد في كائن الهوية؛ يُنشئ المستخدم ZKP محليًا حسب الحاجة؛ يتحقق المُحقِّق (عقد ذكي أو تطبيق أو وكيل) من صلاحية الإثبات فقط؛ وتكون النتيجة نعم/لا أو تحقق عتبة، دون إدخال بيانات الشهادات الأصلية إلى السلسلة.
| نوع الإثبات |
ما يستقبله المُحقِّق |
ما يظهر للعامة/على السلسلة |
| إثبات عمر |
"≥18" صحيح |
لا يُكشف تاريخ الميلاد |
| إثبات إقامة |
"ضمن الولاية" صحيح |
لا يُكشف العنوان |
| إثبات مؤهل |
"يمتلك مستوى الاستثمار" صحيح |
لا يُكشف الدخل أو الأصول |
تغلف منتج Verify and Access هذه الفحوصات بواجهات يستدعيها المطورون والتطبيقات، ليحصل الوكلاء أو الواجهات الأمامية على إشارات تفويض واضحة قبل الوصول للخدمات المقيدة. في مقارنة Concordium مع Worldcoin: يركز World ID على "الإنسان الفريد"، أما Concordium فتستخدم ZKP للتحقق من الالتزام بمتطلبات الامتثال أو الأعمال المحددة.
بالنسبة لمؤسسات الأعمال، يمكن أن يتطلب التسجيل "حسابًا موثقًا مع إثبات سمة محدد" دون الحاجة لتجميع بيانات KYC كاملة. وفي إطارات عمل الوكلاء، يمكن إدراج فحوصات التفويض قبل استدعاء الأدوات، لمنع الوكلاء غير الموثقين من استخدام واجهات برمجة التطبيقات المقيدة. يشمل عمر كائن الهوية التحديثات أو الإلغاء: عند تحديث حالة الهوية أو سياسات الجهة، يُعاد إصدار أو إبطال بيانات الاعتماد، ما يسمح بتطور المساءلة على مستوى الحساب وفقًا للاحتياجات التنظيمية.
الشكل 1. تدفق إثبات السمة بالمعرفة الصفرية في Concordium: من كائن الهوية حتى نتيجة التحقق دون كشف بيانات المستخدم الأصلية.
كيف تختلف هوية البروتوكول عن KYC التقليدي على السلسلة؟
تُفهم "KYC على السلسلة" خطأً غالبًا بأنها تخزين معلومات الهوية نصًا أو مشفرة في الكتل. تتجنب Concordium ذلك: ما يُحفظ فقط هو ربط الهوية وإمكانية التحقق من الإثبات، وليس مستودعًا لمعلومات التعريف الشخصية (PII). فيما يلي أبعاد المقارنة:
| البُعد |
KYC التقليدي على السلسلة (المفهوم الخاطئ) |
هوية بروتوكول Concordium |
| بيانات السلسلة |
قد تتضمن بيانات شخصية واضحة أو مشفرة |
كائن هوية + نتيجة إثبات |
| الخصوصية |
يصعب التراجع بعد النشر |
ZKP تمكّن الإفصاح الانتقائي |
| التوافقية |
تكرار KYC عبر المنصات |
إعادة استخدام الإثباتات لنفس الحساب في سيناريوهات متعددة |
| المساءلة |
تعتمد على المنصة |
سلسلة تفويض على مستوى الحساب |
في أنظمة RegTech والوكلاء، يكمن الفرق في أن التحقق يتم من نتائج تشفيرية واعتمادات الجهة، وليس عبر الثقة في نسخة مركزية من الحقول. سيناريوهات PayFi، وإصدار العملات المستقرة، وصناديق الرموز غالبًا ما تتطلب إثبات الأهلية أو الولاية بدون كشف الملف الكامل—ولهذا صُمّم الجمع بين هوية البروتوكول وZKP: "إثبات قابل للتحقق بأقل قدر من الإفصاح".
من وجهة نظر المطور، التطبيقات لا تتعامل مع حزم KYC مباشرة، بل تستدعي Verify and Access أو واجهات إثبات على المحفظة للحصول على نتائج تفويض (نعم/لا أو تعداد)، وتقرر السماح بالمعاملات أو استدعاء الوكلاء أو المحتوى. هذا يقلل أعباء الامتثال على الواجهات والعقود الذكية، ويتطلب منطق منتج واضح: لكل إجراء إثبات سمة مطلوب.
ما مزايا وقيود هوية البروتوكول؟
المزايا: نقل فحوصات الامتثال للبروتوكول، تقليل تكرار دمج وحدات الهوية في التطبيقات؛ فصل إثبات الامتثال عن كشف البيانات عبر ZKP؛ الحسابات الموثقة توفر أساس تفويض موحد للوكلاء. في المؤسسات، يمكن التركيز على الحسابات وأحداث الإثبات في السجلات، دون توزيع حزم KYC الخام.
أما القيود: جودة الهوية تعتمد على تغطية ومعايير جهات الإصدار، الفروقات التنظيمية الإقليمية تؤدي لاختلاف السمات، وتوليد ZKP يتطلب محافظ محلية محدثة، ما يزيد التعقيد عن العناوين المجهولة. في حال انتهاء صلاحية الجهة أو بيانات الاعتماد، يجب تحديث الإثباتات. الهوية على مستوى البروتوكول لا تعالج الاحتيال خارج السلسلة بالكامل—بل تعالج "سمات قابلة للتحقق ومسؤولية للتفاعلات على السلسلة".
ولا تلغي الحاجة لتدقيق خارجي: قد يطلب المنظمون أو الشركاء السجلات من جهات الإصدار، لكن هذه السجلات ليست بحاجة لأن تكون عامة ودائمة على السلسلة بسبب تفاعل واحد فقط على السلسلة. على المشاريع تقديم شرح واضح للموازنة بين الخصوصية والامتثال، وتجنب إساءة فهم أن ZKP تعني "عدم التتبع التام".
الملخص
تُدمج Concordium "الكيانات الموثقة" ضمن نموذج الحساب على مستوى البروتوكول، بينما تتيح إثباتات المعرفة الصفرية التحقق من السمات دون كشف البيانات الأصلية. فهم هذا المزيج ضروري لاستكشاف سجل الوكلاء، Verify and Access، وسيناريوهات PayFi.
الأسئلة الشائعة
ما هي هوية البروتوكول في Concordium؟
هوية البروتوكول تعني ربط حسابات Concordium بكيان بشري أو تجاري تم التحقق منه من جهة إصدار عند الإنشاء. تحتفظ السلسلة بكائنات الهوية ومرجعيات التشفير، وليس بيانات الهوية الأصلية، مما يمنح الحسابات مصادر تفويض موثوقة ويدعم إثبات السمات بالمعرفة الصفرية لاحقًا.
كيف تتحقق Concordium من الهوية؟
للتحقق مرحلتان: خارج السلسلة، تكمل جهة الإصدار KYC/KYB وتمنح كائن الهوية؛ على السلسلة أو عبر Verify and Access، يتم التحقق من إثباتات المعرفة الصفرية التي ينشئها المستخدم. عادة يتسلم المُحقِّق فقط استنتاجات بشأن استيفاء السمات، وليس محتوى الشهادة الأصلي.
كيف تحمي إثباتات المعرفة الصفرية الخصوصية؟
تسمح إثباتات المعرفة الصفرية للمُثبِت بتقديم دليل صالح للمُحقِّق بأن "الشرط محقق" دون كشف التفاصيل الحساسة المطلوبة. مثل إثبات "فوق 18 عامًا" دون كشف تاريخ الميلاد. تستخدم Concordium ذلك لتقليل كشف البيانات الشخصية على السلسلة في حالات الامتثال.
ما العلاقة بين هوية البروتوكول والوكلاء؟
يربط سجل الوكلاء الوكلاء بحسابات Concordium الموثقة. تشكل هوية البروتوكول أساس سلسلة مساءلة الوكيل: يمكن للأطراف التحقق من هوية وكيل والعودة لطرف مفوض ومعتمد من جهة إصدار الهوية. بدون هذه الطبقة، لا يمكن ربط هوية الوكيل على السلسلة بمسؤول حقيقي بشكل موثوق.
ما هي قيود هوية البروتوكول؟
تشمل القيود: تغطية جهات الإصدار، الفروقات التنظيمية، إدارة تحديث بيانات الاعتماد وانتهائها، ومنحنى التعلم لعمليات ZKP في المحافظ. تعزز هوية البروتوكول المساءلة على السلسلة وإثبات السمات، لكنها لا تستبدل الضوابط الخارجية أو جميع عمليات مكافحة الاحتيال.
