قبل بضعة أشهر، قام فريق العملات الرقمية في a16z بنشر تحدي ناكاموتو، قائمة بأهم المشاكل التي يجب حلها في blockchain. الرابع على وجه الخصوص لفت انتباهنا: "الخصوصية القابلة للبرمجة المتوافقة" ، حيث كنا نفكر بنشاط في هذا الأمر لبعض الوقت. اليوم ، نقترح حلا أوليا باستخدام التشفير المتجانس وبروتوكول العقد الذكي السري fhEVM (إذا لم تكن معتادا على fhEVM ، فيمكنك قراءة مقالاتنا حول السرية رمز ERC20 و مزادات عمياء٠

fhEVM هو EVM عادي مع بعض الإعدادات المسبقة التي تمكن من الحساب على الحالات المشفرة باستخدام مكتبة التشفير المتماثل TFHE-rs لدينا. من وجهة نظر المطور، لا يوجد تشفير معني: فقط يكتبون رمز Solidity باستخدام أنواع البيانات المشفرة التي نوفرها (euint32، ebool، إلخ). أحد المزايا الكبيرة لـ fhEVM مقابل حلول الخصوصية الأخرى هو أن جميع البيانات والحسابات تحدث على السلسلة. هذا يعني أنه يمكنك الحصول على نفس مستوى القابلية للتركيب وتوافر البيانات كعقود النص العادية.

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

في هذا المقال، سنوضح كيفية بناء رمز ERC20 متوافق، باستخدام DIDs على السلسلة الرئيسية. يمكن العثور على الشيفرة المصدرية لهذا البرنامج التعليمي في مجلد الأمثلةمن مستودع fhEVM.

تجريد الهوية عبر السلسلة، DIDs سرية

معرف اللامركزية (DID) هو هوية رقمية فريدة تصدرها كيان مثل حكومة أو مسجل أو شركة أو المستخدم نفسه. يمكن ربط هذا DID بمفتاح تشفيري يثبت ملكية المستخدم للDID، مثل محفظة EVM. ولكن يمكن أيضًا تخزين مجموعة كاملة من السمات، مثل عمر المستخدم، الجنسية، رقم الضمان الاجتماعي إلخ. يمكن استخدام هذه السمات بدورها لإثبات أنك تفي ببعض الشروط (المسماة "شهادة"،) مثل كونك أكبر من 18 عامًا أو عدم كونك مواطنًا في نارنيا.

معظم DIDs مُنفذة على جانب العميل، وتستخدم البراهين على عدم المعرفة لإنشاء التصديقات. بينما هذا جيد في العديد من الحالات، إلا أنه يصبح سريعًا معقدًا عندما يكون هناك مستخدمون متعددون مشاركون في عملية، عندما يتعين عليك تطبيق قواعد معقدة على الDID، أو عندما تحتاج إلى الاحتفاظ بمجموعة مشتركة من القواعد للجميع لاتباعها. إنه تقريبًا نفس التنازل كما هو الحال في التطبيقات على الحافة مقابل التطبيقات السحابية.

ومع ذلك ، فإن وجود سجل DID مركزي من شأنه أن يحل هذه المشكلات ، حيث يمكنك ببساطة أن تطلب من السجل التحقق من امتثال الجميع. كما أنه سيجعل من الأسهل تتبع اللوائح ، حيث ستحتاج فقط إلى تنفيذها في مكان واحد. ستكون blockchain بنية تحتية مثالية لهذا ، لأنها ستمكن من التركيب بين DIDs والتطبيقات التي تتطلب الامتثال ، وكذلك قابلية التركيب بين اللوائح نفسها.

المشكلة: الجميع سيشاهدون هوية الجميع!

لحسن الحظ لدينا حل: التشفير المتجانس ، وبشكل أكثر تحديدا fhEVM! بفضل القدرة على إمكانية التركيب في حالة مشفرة ، يمكننا استضافة DIDs للمستخدم مباشرة onchain في شكل مشفر ، ولدينا تطبيقات متوافقة للتحقق من السمات باستخدام مكالمة عقد بسيطة. إن القدرة على إدارة الهوية عبر عقد ذكي ، والذي نسميه "تجريد الهوية" ، يشبه كيف يمكن للمرء إدارة الأموال عبر عقد ذكي مع تجريد الحساب.

هذا البرنامج التعليمي يحتوي على 3 أجزاء:

• تتم مجردة الهوية عبر عقد سجل مسؤول عن إدارة الهويات والشهادات. هنا نفترض أن معرفات الهوية الرقمية هي هويات حكومية رسمية. يتم إدارة السجل نفسه من قبل سلطة مركزية (على سبيل المثال، AFNIC) التي يمكنها إنشاء مسجلين (على سبيل المثال، شركات KYC مثل Onfido، Jumio، إلخ.) الذين بدورهم يمكنهم إنشاء معرفات مستخدمين. بعد ذلك يمر المستخدم من خلال مسجله لإدارة وتحديث معرفاته الرقمية.
• التنظيم هو مصطلح يُعرف في عقد يُشفر مجموعة من القواعد لتحويل الرموز بين الأفراد، بناءً على المعلومات الواردة في هوياتهم الرقمية المفcentralized. بشكل أساسي، يفرض التنظيم على مستوى العقد بدلاً من مستوى المستخدم.
• تم تنفيذ التحويلات السرية المتماشية في عقد ERC20 متوافق يستخدم عقد التنظيم لفرض الامتثال في تحويلات الرمز، من دون أي تغييرات في واجهة برمجة التطبيقات الخاصة بـ ERC20 نفسها. في هذا المثال نستخدم عقد ERC20 سري، حيث تكون الأرصدة والمبالغ مخفية، ولكن سيعمل بنفس الكفاءة مع رمز ERC20 عادي وعلني.

هندسة بروتوكول Onchain Confidential DID الخاص بنا

عقد تسجيل الهوية

عقد IdentityRegistry هو سجل لمعرفات المستخدمين التي يتم إصدارها من قبل المسجلين وتتضمن مجموعة من المعرفات المشفرة، مثل جنسيتهم، وعمرهم، ورقم الضمان الاجتماعي وما إلى ذلك. يتم تخزين هذه المعرفات كقيم بتية مشفرة (euint32).

العقد يدير أيضا الأذونات، مثل:

• تمكين مالك العقد (مثل شركة الفجيرة الوطنية للتأمين) من إضافة أو إزالة أو تحديث المسجلين.
• تمكين المسجلين من إضافة أو إزالة أو تحديث هويات الجدول الزمني للمستخدم التي أنشأوها.
• السماح للمستخدمين بمنح عقود ذكية الوصول إلى سمات معينة من هوياتهم الرقمية. من المهم هنا أن يلاحظ المستخدم أنه مسؤول عن عدم منح الوصول للعقود الخبيثة، تمامًا كما أنه مسؤول عن عدم السماح للعقود الخبيثة بإنفاق رموزهم.

كخطوة أولى، دعونا نقوم بتنفيذ المنطق لإنشاء وإدارة DIDs:

الآن الخطوة التالية هي تنفيذ المنطق للمعرفات ومراقبة الوصول.

المعرف هو ببساطة سلسلة نصية (على سبيل المثال، "تاريخ الميلاد") وقيمة مشفرة بـ 32 بت. يمكن إنشاءه أو تحديثه فقط من قبل المسجل. المستخدم لا يمكنه إنشاء معرفاته الخاصة، حيث نريد أن تكون معتمدة من قبل المسجل.

نظرًا لأن معرفات مشفرة، فإن المستخدم يحتاج إلى منح إذن لعقد للوصول إلى قيم معينة، والتي سنتعامل معها من خلال آلية تحكم في الوصول بسيطة تشبه كيف يمكنك السماح لعقد بإنفاق رموز ERC20 الخاصة بك.

الهوية القانونية للسجل هو EIP712WithModifier ، Ownable

يمكننا الآن إنهاء عقد تسجيل الهوية الخاص بنا عن طريق إضافة الحاصلين الضروريين ، مع بعض الشروط ومعالجة الأخطاء.

عقد IdentityRegistry هو EIP712WithModifier، Ownable

العقد التنظيمي

الخطوة التالية هي إنشاء عقد التنظيم الخاص بنا.

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

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

في هذا المثال، سنقوم بتنفيذ بعض القواعد الأساسية:

• التحويلات داخل البلاد غير محدودة، ولكن التحويلات إلى الخارج محدودة إلى 10,000 رمز.
• لا يمكن لمستخدم موضوع على القائمة السوداء نقل أو استلام الرموز.
• لا يمكن للمستخدم نقل الرموز إلى بلد موجود في قائمة الدول المحظورة.

بدلا من إخفاق المعاملة، التي قد تكشف معلومات حساسة، سنقوم ببساطة بتعيين مبلغ التحويل إلى 0 إذا لم تتم الوفاء بإحدى الشروط. يستخدم هذا المشغل الثلاثي المتماثل تسمى cmux: value = TFHE.cmux(encryptedCondition, valueIfTrue, valueIfFalse

العقد ERC20 السري المطابق

الآن بعد أن لدينا سجل هوية وعقد تنظيم، يمكننا أخيرًا إنشاء عقد الرمز الممتثل، المحافظ على الخصوصية. سيكون هذا العقد يسمى CompliantERC20 وله الميزات الرئيسية التالية:

• تم تشفير رصيد المستخدم ومبلغ التحويل.
• يتم فرض الامتثال في التحويلات عن طريق استدعاء عقد اللوائح.
• يمكن منح رؤية أرصدة معينة لعناوين مسموح بها (على سبيل المثال المنظمون)

يتم استدعاء عقد التنظيم عبر مكالمة بسيطة. وهذا يعني أن المستخدمين يجب أن يقدموا إذنا لعقد ERC20 قبل بدء أي تحويل؛ وإلا سيتم إلغاء التحويل.

وأخيراً، يمكننا الآن إنشاء عقد ERC20 الخاص بنا:

بالمثل لكيفية منح المستخدمين الإذن لبروتوكولات ديفي لإنفاق رموزهم، سيحتاجون إلى منح الإذن للعقد للوصول إلى المعرفات اللازمة من قبل عقد التنظيم. يتم ذلك عبر استدعاء Identity.grantAccess(contractAddress، identifiers)، والذي يمكن استرداده عن طريق استدعاء طريقة العرض ERC20.identifiers(). يأتي هذا القائمة مباشرة من عقد ERC20Rules للسماح بتحديث الخصائص.

الامتثال والخصوصية يمكن أن تتواجد معًا!

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

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

روابط إضافية

• نجمة مستودع Zama fhEVM على Githubلتأييد عملنا.
• مراجعة وثائق fhEVM لـ Zama.
• احصل على الدعم على موقعناقنوات المجتمع.
• ساعد في تقدم مجال التشفير المتماثل مع برنامج زاما للمكافآت: إنشاء لعبة على السلسلة تحافظ على الحالات الخاصة مخفية باستخدام الخصوصية القابلة للبرمجة fhEVM لـ Zama (15,000€ في الجائزة).

إخلاء المسؤولية:

1. تم نشر هذه المقالة من [zama]. جميع حقوق الطبع والنشر تنتمي إلى الكاتب الأصلي [fhEVM]. إذا كانت هناك اعتراضات على هذا النشر مرجوا التواصل معبوابة تعلمالفريق، وسوف يتولى التعامل معها بسرعة.
2. إخلاء المسؤولية عن المسؤولية: الآراء والآراء المعبر عنها في هذه المقالة هي فقط تلك المؤلف ولا تشكل أي نصيحة استثمارية.
3. تتم الترجمات للمقال إلى لغات أخرى من قبل فريق Gate Learn. ما لم يرد غير ذلك، فإن نسخ أو توزيع أو سرقة المقالات المترجمة ممنوعة.