اليوم، شارك V God وآخرون في تأليف ورقة بحثية حول بروتوكولات الخصوصية بعنوان "خصوصية Blockchain والامتثال التنظيمي: نحو توازن عملي" (خصوصية Blockchain والامتثال التنظيمي: نحو توازن عملي).
تتناول الورقة بروتوكولًا جديدًا لتعزيز الخصوصية قائمًا على العقود الذكية، ومجمع الخصوصية، وتناقش مزاياه وعيوبه، موضحة كيف يوازن بين المستخدمين الصادقين وغير الأمناء. يهدف البروتوكول إلى استخدام أدلة المعرفة الصفرية للتحقق من شرعية أموال المستخدمين دون الكشف عن سجل معاملاتهم الكامل، مع الموازنة بين متطلبات الخصوصية والمتطلبات التنظيمية أثناء تصفية الأموال المرتبطة بالنشاط الإجرامي.
تقوم Odaily Planet Daily الآن بتجميع جوهر الورقة على النحو التالي.
I. مقدمة
تتميز سلاسل الكتل العامة بالشفافية من حيث التصميم. الفكرة الأساسية هي أن أي شخص يمكنه اختيار التحقق من المعاملات دون الاضطرار إلى الاعتماد على طرف ثالث مركزي؛ ومن خلال تقليل التبعيات، فإنه يوفر أساسًا محايدًا لمختلف التطبيقات، بما في ذلك على سبيل المثال لا الحصر التمويل وهوية السيادة الذاتية.
ومع ذلك، من وجهة نظر الخصوصية، تمتلك مجموعات البيانات العامة كل معاملة تحتوي على كل عنوان blockchain. عندما يقوم شخص ما بنقل أصل إلى عنوان آخر، أو يتفاعل مع عقد ذكي، ستكون هذه المعاملة مرئية دائمًا على blockchain. ومن الواضح أن هذا لا يتماشى مع متطلبات الخصوصية.
على سبيل المثال: تدفع أليس ثمن العشاء في مطعم باستخدام محفظة blockchain. يعرف المستفيد الآن عنوان Alice ويمكنه تحليل جميع الأنشطة الماضية والمستقبلية على ذلك العنوان. وبالمثل، تعرف أليس الآن عنوان محفظة المطعم ويمكنها استخدام هذه المعلومات للحصول على عناوين المحفظة للضيوف الآخرين أو عرض إيرادات المطعم. أو يمكن لطرف ثالث (مثل وسائل التواصل الاجتماعي) يعرف المطعم وعنوان محفظة أليس أن يستنتج بسهولة عنوان السكن الفعلي لأليس ويدرس معاملاتها الماضية والمستقبلية.
**إن ظهور بروتوكولات تعزيز الخصوصية يهدف إلى حل المشكلات المذكورة أعلاه. فهو يسمح للمستخدمين بإيداع الأموال في البروتوكول، باستخدام عنوان واحد، وسحب الأموال من البروتوكول في وقت لاحق، باستخدام عنوان آخر. لا تزال جميع عمليات الإيداع والسحب مرئية على blockchain، ولكن المراسلات بين عمليات النقل والتحويلات المحددة لم تعد علنية. **
أحد أشهر بروتوكولات تحسين الخصوصية هو Tornado Cash. لقد نجح في حل المشكلات المذكورة أعلاه ويسمح للمستخدمين بالاحتفاظ ببعض الخصوصية. ومع ذلك، بالإضافة إلى المستخدمين الشرعيين الذين يحاولون حماية بياناتهم، يتم استخدام Tornado Cash أيضًا من قبل مجموعة متنوعة من الجهات الفاعلة السيئة. تظهر بيانات الإيداع أن مجموعة المتسللين قامت بنقل الأموال من خلال هذا البروتوكول. هناك أدلة على أن بروتوكول تعزيز الخصوصية هذا يُستخدم أيضًا من قبل مجموعات القرصنة الكورية الشمالية، مما أدى في النهاية إلى وضع عناوين العقود الذكية الخاصة بالبروتوكول على قائمة المواطنين المعينين خصيصًا والأشخاص المحظورين التي يحتفظ بها مكتب الولايات المتحدة لمراقبة الأصول الأجنبية (OFAC). (يُشار إليها غالبًا باسم قائمة SDN)).
**المشكلة الرئيسية في Tornado Cash هي عدم وضوح الخط الفاصل بين المستخدمين الشرعيين والمستخدمين المجرمين. **لذلك، تقدم Tornado Cash ميزة امتثال تسمح للمستخدمين بإنشاء دليل على مصدر الإيداع الذي تم سحبه منه. وفي حين تسمح هذه الآلية للأشخاص بإثبات براءتهم، فإنها تفعل ذلك على حساب الاضطرار إلى الثقة في وسيط مركزي وخلق عدم تناسق في المعلومات. في نهاية المطاف، تم استخدام الآلية من قبل عدد قليل من المستخدمين.
تناقش هذه الورقة امتدادًا لهذا النهج الذي يمكّن المستخدمين من التصديق علنًا على المعلومات حول الودائع التي قد تأتي منها عمليات السحب، دون فقدان الخصوصية. **تقترح مجمعات الخصوصية مفهومًا عامًا: السماح بإثبات العضوية ("أشهد أن انسحابي جاء من إحدى هذه الودائع") أو إثبات الاستبعاد ("أشهد أن انسحابي لم يأت من أي من هذه الودائع"). **تناقش هذه المقالة هذا الاقتراح وتشرح كيف يمكن استخدامه لتحقيق التوازن بين المستخدمين الصادقين وغير الأمناء.
لاحظ أن تجمعات الخصوصية توفر خيارات إضافية عن طريق توسيع مجموعة إجراءات المستخدم. لا يزال بإمكانهم تقديم شهادة أكثر تفصيلاً لأطراف مقابلة محددة إذا لزم الأمر. ومع ذلك، في بعض الحالات، قد يكون إثبات العضوية أو الاستبعاد كافيًا. بالإضافة إلى ذلك، يوفر خيار الإصدار العلني لهذه الشهادات عددًا من المزايا مقارنة بالإفصاح الثنائي.
2. الخلفية التقنية
في هذا القسم، نقدم نظرة عامة فنية قصيرة ونناقش العناصر الأساسية الفنية والمبادئ العامة للبروتوكولات مثل مجمعات الخصوصية.
1. خصوصية Blockchain قبل ZK-SNARKs
تاريخيًا، جادل مؤيدو البلوكتشين بأنه على الرغم من أن جميع المعاملات شفافة، إلا أن البلوكتشين يمكنها الحفاظ على الخصوصية لأنها توفر عدم الكشف عن هويتها.
ومع ظهور أدوات التجميع والتحليل الحديثة، أصبحت حماية الخصوصية هذه غير كافية. لتحسين خصوصية سلاسل الكتل العامة، تم تقديم تقنيات أكثر قوة مثل Token Join وMonero. ومع ذلك، لا تزال هذه التقنيات تحمل مخاطر تسرب البيانات. **
وأعقب ذلك تقنيات إثبات المعرفة الصفرية ذات الأغراض العامة مثل Zcash وTornado Cash، والتي يمكن أن تجعل مجموعة إخفاء الهوية لكل معاملة مساوية للمجموعة الكاملة لجميع المعاملات السابقة. غالبًا ما تسمى هذه التقنية ZK-SNARKs.
2、ZK-SNARKs
ZK-SNARKs هي تقنية تسمح للمبرهن بإثبات عبارة رياضية معينة حول البيانات العامة والخاصة، **مع استيفاء خاصيتين رئيسيتين: المعرفة الصفرية والبساطة. **
● عدم المعرفة: لن يتم الكشف عن أي معلومات حول البيانات الخاصة إلا لإثبات أن البيانات الخاصة المذكورة تتوافق مع المطالبات.
● **البساطة: **الأدلة قصيرة ويمكن التحقق منها بسرعة، حتى لو كانت الادعاءات المثبتة تتطلب حسابات تستغرق وقتًا طويلاً.
لقد حظيت ZK-SNARKs بالكثير من الاهتمام من مجتمع blockchain بسبب أهميتها القابلة للتوسع، مثل ZK-rollups. بالنسبة لتطبيقات الخصوصية، البساطة ليست ذات أهمية خاصة، ولكن المعرفة الصفرية ضرورية.
يمكن اعتبار "البيان" الذي أثبته ZK-SNARKs بمثابة نوع من البرامج يسمى "الدائرة"، والذي يحسب نتيجة الدالة f(x, w) مع المدخلات العامة والخاصة، ثم يثبت ذلك بالنسبة لجمهور معين input x ، يوجد مدخل خاص w بحيث يتم تقييم f(x, w) إلى True.
3. تطبيق ZK-SNARKs في أنظمة مثل Zcash وTornado Cash
هناك بعض الاختلافات الطفيفة بين الإصدارات المختلفة من Zcash والأنظمة المستوحاة منه مثل Tornado Cash. ومع ذلك، فإن المنطق الأساسي الذي يعتمدون عليه مشابه جدًا. يصف هذا القسم إصدارًا بسيطًا يتوافق تقريبًا مع كيفية عمل هذه البروتوكولات.
تتكون الرموز من أسرار يحتفظ بها أصحابها. يمكن استخلاص قيمتين من s:
● معرف الرمز المميز L = التجزئة (العلامات + 1)
● المبطلU = التجزئة (s + 2)
من بينها، يشير التجزئة إلى وظيفة تجزئة كلمة المرور، مثل SHA 256. بالنظر إلى الصورة، يمكن حساب معرف الرمز المميز والصفر. ومع ذلك، بالنظر إلى مجموعة من أدوات الصفر ومعرف الرمز المميز العام، يضمن السلوك العشوائي الزائف لوظيفة التجزئة أنه لا يمكنك تحديد أي جهاز تصفير مرتبط بمعرف الرمز المميز إلا إذا كنت تعرف السر الذي أنشأ كليهما.
يتتبع blockchain جميع معرفات الرموز المميزة التي تم "إنشاءها"، بالإضافة إلى جميع أدوات الصفر التي تم "إنفاقها". كلتا المجموعتين تنمو باستمرار (ما لم يرغب البروتوكول في فرض متى يجب إنفاق الرموز المميزة).
يتم تخزين مجموعة معرفات الرموز المميزة في بنية بيانات تسمى شجرة Merkle: إذا كانت الشجرة تحتوي على N من العناصر، فسيتم تجزئة كل عنصر مجاور (مما يؤدي إلى ⌈ N/2 ⌉ تجزئات)، ويتم تجزئة كل تجزئات متجاورة مرة أخرى (مما يؤدي إلى ⌈ N/4 ⌉)، وهكذا، حتى يتم دمج البيانات بأكملها في "تجزئة جذر" واحدة.
بالنظر إلى قيمة معينة في الشجرة وتجزئة الجذر، يمكن للمرء توفير فرع Merkle: "قيمة شقيقة" يتم تجزئةها معًا في كل خطوة على المسار من تلك القيمة إلى الجذر. يعد فرع Merkle مفيدًا لأنه عبارة عن جزء صغير من البيانات (سجل 2 (N)) يمكن استخدامه لإثبات أن أي قيمة معينة موجودة بالفعل في الشجرة. ويبين الشكل أدناه مثالاً لشجرة ميركل التي يبلغ ارتفاعها 4.
عندما يرسل المستخدمون عملات معدنية إلى الآخرين، فإنهم يقدمون ما يلي:
● Nullifier U الذي يريد أن ينفق
● معرف الرمز المميز L' للرمز المميز الجديد المطلوب إنشاؤه (يُطلب من المستلم تقديم هذا)
● ZK-SNARK.
يحتوي ZK-SNARK على المدخلات الخاصة التالية:
● أسرار المستخدم
● فرع Merkle في شجرة معرف الرمز المميز، مما يثبت أن الرمز المميز بمعرف الرمز المميز L = hash(s + 1) تم إنشاؤه بالفعل في وقت ما في الماضي
ويحتوي أيضًا على المدخلات العامة التالية:
● U، صفر الرموز المميزة التي يتم إنفاقها
● R، التجزئة الجذرية التي يتم توجيه أدلة Merkle ضدها
يثبت ZK-SNARK خاصيتين:
● U = التجزئة (s + 2)
● فروع ميركل صالحة
بالإضافة إلى ZK-SNARKs، يتحقق البروتوكول مما يلي:
● R هو التجزئة الجذرية الحالية أو التاريخية لشجرة معرف الرمز المميز
● U ليس ضمن مجموعة الصفرات المستهلكة
إذا كانت المعاملة صالحة، فإنها تضيف U إلى مجموعة أدوات التصفية المستهلكة وL' إلى قائمة معرفات الرمز المميز. يؤدي عرض U إلى منع إنفاق رمز مميز واحد بشكل مضاعف. ومع ذلك، لن يتم الكشف عن أي معلومات أخرى. **لا يستطيع العالم الخارجي إلا أن يرى متى يتم إرسال المعاملات؛ ولا يمكنه الحصول على نمط حول من يرسل أو يستقبل هذه المعاملات ولا يمكنه التمييز بين المصدر الموحد للرموز المميزة. **
هناك استثناءان للنمط المذكور أعلاه: الودائع والسحوبات. في الودائع، يمكن إنشاء معرفات الرمز المميز دون إبطال رمز مميز سابق معين. من منظور الحفاظ على الخصوصية، لا تكون الودائع مجهولة المصدر بسبب الارتباط بين L معين وحدث خارجي يسمح بإضافة L (في Tornado Cash، يكون إيداع ETH في النظام؛ وفي Zcash، يعد التعدين الجديد ZEC) عامًا.
بمعنى آخر، **ترتبط الودائع بتاريخ معاملاتها السابقة. **في حالة السحب، سيتم استهلاك الصفر دون إضافة معرف رمزي جديد. قد يؤدي هذا إلى فصل عمليات السحب من الودائع المقابلة وبشكل غير مباشر من تاريخ المعاملات السابقة. ومع ذلك، يمكن ربط عمليات السحب بأي معاملات مستقبلية تحدث بعد حدث السحب.
لم يكن لدى الإصدار الأول من Tornado Cash أي مفهوم للتحويلات الداخلية، بل كان يسمح فقط بالإيداع والسحب. الإصدارات اللاحقة، التي لا تزال في المرحلة التجريبية، سمحت أيضًا بالتحويلات الداخلية والعملات المعدنية من مختلف الطوائف، بما في ذلك دعم عمليات "التقسيم" و"الدمج". سنناقش كيفية توسيع نظام نقل العملات المعدنية الأساسي ومجمع الخصوصية ليشمل الطوائف العشوائية في الفصول اللاحقة.
4. ZK-SNARKs في تجمع الخصوصية
**الفكرة الأساسية لمجمع الخصوصية هي أن المستخدمين لا يثبتون فقط أن السحب مرتبط بإيداع سابق من خلال إثبات المعرفة الصفرية، بل يثبتون أيضًا أنه ينتمي إلى مجموعة ارتباط أكثر صرامة. **يمكن أن تكون المجموعة المرتبطة مجموعة فرعية من جميع الإيداعات التي تم إجراؤها مسبقًا، أو مجموعة تحتوي فقط على إيداعات المستخدم الخاصة، أو أي شيء بينهما. يحدد المستخدم المجموعة من خلال توفير جذر Merkle للمجموعة المرتبطة كمدخل عام.
كما هو موضح في الشكل أدناه، من أجل التبسيط، نحن لا نثبت بشكل مباشر أن المجموعة المرتبطة هي بالفعل مجموعة فرعية من الإيداعات التي تم إجراؤها مسبقًا؛ بدلاً من ذلك، نطلب فقط من المستخدم استخدام نفس معرف العملة كعقدة ورقية إثبات فرعين من ميركل من خلال المعرفة الصفرية:
● أدخل فرع Merkle للجذر R لمجموعة معرفات العملة الإجمالية
● أدخل فرع Merkle الخاص بـ RA الجذر لمجموعة الاقتران المتوفرة
القصد من ذلك هو وضع المجموعة الكاملة من الارتباطات في مكان ما (يمكن أن تكون متصلة بالسلسلة). المفهوم الأساسي هو: بدلاً من مطالبة المستخدمين بتحديد الإيداع الذي جاءت منه عمليات السحب بالضبط، أو على الطرف الآخر، عدم تقديم أي معلومات أخرى بخلاف إثبات عدم وجود إنفاق مزدوج، فإننا نسمح للمستخدمين بتوفير مجموعة من الخيارات التي يمكن من خلالها ربما جاءت الأموال، ويمكن أن تكون هذه المجموعة واسعة أو ضيقة كما يحلو لهم.
نحن نشجع النظام البيئي الذي يسهل على المستخدمين تحديد مجموعة من الارتباطات المتوافقة مع تفضيلاتهم. ستصف بقية هذه المقالة فقط البنية التحتية المستندة إلى هذه الآلية الأساسية البسيطة وعواقبها.
3. الاعتبارات العملية وحالات الاستخدام
تحليل كيفية استخدام بروتوكولات تعزيز الخصوصية عمليًا من منظور التطبيق.
1. حالات استخدام المجموعات المرتبطة
لتوضيح قيمة هذا البرنامج في بيئة إنفاذ القانون، إليك مثال:
لنفترض أن لدينا خمسة مستخدمين: أليس، بوب، كارل، ديفيد، إيف. المستخدمون الأربعة الأوائل هم مستخدمون صادقون وملتزمون بالقانون ولكنهم مهتمون بالخصوصية، في حين أن Eve هي لص. لأن الجمهور يعرف أن حواء هي لص من خلال المعلومات التي تفيد بسرقة العملات المعدنية الموجودة في العنوان الذي يحمل علامة "حواء". من الناحية العملية، يحدث هذا في كثير من الأحيان: في سلاسل الكتل العامة، يتم تتبع الأموال الناتجة عن استغلال نقاط الضعف في بروتوكولات التمويل اللامركزي لتحديد الأموال غير المشروعة التي تتدفق إلى Tornado Cash.
عندما يقوم كل من المستخدمين الخمسة بالسحب، يمكنهم اختيار المجموعة المرتبطة التي يريدون تحديدها. يجب أن تتضمن مجموعة الارتباطات الخاصة بهم الودائع الخاصة بهم، ولكن لديهم الحرية في اختيار أي من العناوين الأخرى يريدون تضمينها. كان الدافع لدى المستخدمين الأربعة الأوائل من ناحية هو الرغبة في حماية خصوصيتهم إلى أقصى حد ممكن. وهذا يحفزهم على الميل إلى جعل ارتباطهم أكبر. من ناحية أخرى، يريدون تقليل فرصة اعتبار عملاتهم مشبوهة من قبل التجار أو البورصات. هناك طريقة سهلة للقيام بذلك: لا يقومون بتضمين Eve في المجموعة المرتبطة بهم. ولذلك، فإن الاختيار واضح بالنسبة للأربعة: لتكن مجموعة ارتباطاتهم {Alice, Bob, Carl, David}.
بالطبع، تريد Eve أيضًا تعظيم مجموعة الارتباطات الخاصة بها. لكنها لا تستطيع استبعاد ودائعها الخاصة، لذا فهي مجبرة على جعل مجموعتها المرتبطة مساوية لمجموعة الودائع الخمسة. يتم عرض مجموعة مختارة من المشاركين في الشكل أدناه.
على الرغم من أن حواء نفسها لم تقدم أي معلومات، فمن خلال عملية حذف بسيطة، يمكننا استخلاص استنتاج واضح: الخطوة الخامسة للانسحاب لا يمكن أن تأتي إلا من حواء.
2. بناء المجموعات المرتبطة بها
أوضح القسم السابق إحدى الطرق الممكنة لاستخدام المجموعات المرتبطة في بروتوكول مشابه لتجمع الخصوصية، وكيف يمكن فصل المشاركين الصادقين عن المشاركين السيئين. لاحظ أن النظام لا يعتمد على إيثار أليس، وبوب، وكارل، وديفيد؛ بل لديهم حوافز واضحة لتبرير انفصالهم. دعونا الآن نلقي نظرة على بناء المجموعات المرتبطة بمزيد من التفصيل. عادة، هناك استراتيجيتان رئيسيتان لإنشاء مجموعات الارتباط. تم وصفها أدناه وتصورها في الصورة أدناه.
● **الإدراج (أو العضوية): **تحديد مجموعة محددة من الودائع التي لدينا دليل قاطع على أنها منخفضة المخاطر، وبناء مجموعة مرتبطة تحتوي على هذه الودائع فقط.
● استبعاد: حدد مجموعة محددة من الودائع التي لدينا أدلة قوية لنعتبرها عالية المخاطر وقم بإنشاء مجموعة ارتباطات تتضمن جميع الودائع باستثناء تلك الودائع.
ومن الناحية العملية، لا يقوم المستخدمون باختيار الودائع يدويًا لإدراجها في مجموعتهم المرتبطة. وبدلاً من ذلك، سيشترك المستخدمون في وسطاء نسميهم موفري المجموعات المرتبطة (ASPs)، الذين يقومون بإنشاء مجموعات مقترنة بخصائص محددة. **في بعض الحالات، يمكن إنشاء مزودي الخدمة (ASP) بالكامل على السلسلة، ولا يتطلب أي تدخل بشري (أو الذكاء الاصطناعي). وفي حالات أخرى، سيقوم مقدمو خدمات التطبيقات بإنشاء المجموعة المرتبطة بشكل مستقل ونشر المجموعة المرتبطة على السلسلة أو في أي مكان آخر.
نوصي بشدة بنشر جذر Merkle على الأقل لمجموعة الارتباط على السلسلة؛ وهذا يلغي قدرة مقدمي خدمات التطبيقات الضارين على تنفيذ أنواع معينة من الهجمات على المستخدمين (على سبيل المثال، منح مستخدمين مختلفين مجموعات اقتران مختلفة في محاولة لإخفاء هويتهم). . يجب أن تكون المجموعة بأكملها متاحة عبر واجهة برمجة التطبيقات (API) أو من خلال نظام تخزين لامركزي منخفض التكلفة مثل IPFS.
تعد القدرة على تنزيل المجموعة المرتبطة بأكملها أمرًا مهمًا لأنها تتيح للمستخدمين إنشاء إثباتات العضوية محليًا دون الكشف عن أي معلومات إضافية لمقدم خدمة ASP، ولا حتى الإيداعات المقابلة لعمليات السحب الخاصة بهم.
فيما يلي كيفية هيكلة خدمات ASP عمليًا:
● إضافة متأخرة، باستثناء العناصر السيئة: تتم إضافة أي إيداع تلقائيًا إلى المجموعة المرتبطة بعد فترة زمنية محددة (على سبيل المثال، 7 أيام)، ولكن إذا اكتشف النظام إيداعًا مرتبطًا بسلوك سيئ معروف (على سبيل المثال، سرقة واسعة النطاق أو عنوانًا في قائمة العقوبات التي نشرتها الحكومة)، فلن تتم إضافة الوديعة مطلقًا. ومن الناحية العملية، يمكن تحقيق ذلك من خلال المجموعات التي ينظمها المجتمع أو مقدمو خدمات فحص المعاملات الحاليون الذين يقومون بالفعل بتحديد وتتبع الودائع المرتبطة بالسلوك السيئ.
● الرسوم الشهرية لكل شخص: من أجل الانضمام إلى مجموعة مرتبطة، يجب أن تكون قيمة الإيداع أقل من الحد الأقصى الثابت، ويجب على المودع إثبات أنه يحمل بعض رموز الهوية (على سبيل المثال، من قبل حكومة مدعومة) دون علمه بذلك. أنظمة الهوية الوطنية أو آليات خفيفة مثل التحقق من حساب وسائل التواصل الاجتماعي). تم دمجها مع معلمة إضافية تشير إلى آلية التخلص للشهر الحالي للتأكد من أن كل هوية يمكنها فقط الالتزام بالودائع إلى المجموعة المرتبطة مرة واحدة شهريًا. يحاول التصميم تنفيذ روح العديد من القواعد الشائعة لمكافحة غسيل الأموال، حيث تسمح المدفوعات الصغيرة التي تقل عن حد معين بمستوى أعلى من الخصوصية. لاحظ أنه يمكن تنفيذ ذلك بالكامل كعقد ذكي، ولا يتطلب أي إشراف يدوي للحفاظ على التشغيل المستمر.
● **الرسوم الشهرية لأعضاء المجتمع الموثوق بهم: **تشبه الرسوم الشهرية لشخص واحد، ولكنها أكثر تقييدًا: يجب على المستخدمين إثبات أنهم أعضاء في مجتمع موثوق به للغاية. يوافق أعضاء المجتمع ذوو الثقة العالية على توفير الخصوصية لبعضهم البعض.
● ** التسجيل في الوقت الفعلي المستند إلى الذكاء الاصطناعي: ** يمكن لنظام AI ASP توفير درجة المخاطرة لكل إيداع في الوقت الفعلي، وسيقوم النظام بإخراج مجموعة مرتبطة تحتوي على الودائع ذات درجة المخاطرة أقل من حد معين. من المحتمل أن يقوم ASP بإخراج مجموعات متعددة تتوافق مع عتبات درجات المخاطر المتعددة.
4. مزيد من الوصف الفني
في هذا القسم، نقوم بتحليل كيفية دعم الاقتراح للطوائف التعسفية ومناقشة حالات خاصة مثل إعادة الشهادة، والشهادة المباشرة الثنائية، والشهادة التسلسلية.
1. دعم أي طائفة
نظام العملات المبسط لحماية الخصوصية أعلاه يدعم فقط تحويلات العملات من نفس الفئة. تدعم Zcash الفئات العشوائية باستخدام نموذج UTXO. يمكن أن تحتوي كل معاملة على مدخلات متعددة (تحتاج إلى نشر أداة التصفية لكل إدخال) ومخرجات متعددة (تحتاج إلى نشر معرف رمز مميز لكل مخرجات). يجب أن يكون كل معرف رمز مميز تم إنشاؤه مصحوبًا بقيمة فئة تشفير. بالإضافة إلى إثبات صلاحية الصفر، يجب أن تكون كل معاملة مصحوبة بإثبات إضافي بأن مجموع فئات العملات المعدنية التي تم إنشاؤها لا يتجاوز مجموع فئات العملات المعدنية المنفقة. ويوضح الشكل أدناه هذا الدليل الإضافي.
ويمكن توسيع هذا التصميم لدعم الودائع والسحوبات من خلال التعامل مع الودائع كمدخلات (غير مشفرة) والسحوبات كمخرجات (غير مشفرة). بالإضافة إلى ذلك، يمكن تقييد التصميم من أجل تبسيط التحليل. على سبيل المثال، من الممكن السماح فقط بالسحب الجزئي، مما يسمح للمعاملة بأن تحتوي على مدخل واحد مشفر ومخرجين: مخرج غير مشفر يمثل السحب، ومخرج "تغيير" مشفر يمثل الأموال المتبقية التي يمكن استخدامها لعمليات السحب المستقبلية.
والسؤال الطبيعي هو كيفية توسيع هذا التصميم لدعم تجمعات الخصوصية. إن إدراجه في مجمع الخصوصية دون تغيير ليس مثاليًا لأن الرسم البياني للمعاملات لا يتوافق مع ما نتوقعه بشكل بديهي: إذا قام المستخدم بإيداع 10 رموز مميزة ثم أنفق 1 + 2 + 3 + 4 في أربع رموز سحب متتالية، فإننا نريد معالجة الكل أربع عمليات سحب كمصدر للإيداع الأصلي المكون من 10 رموز. لكن النتيجة الفعلية هي كما هو موضح أدناه: مصدر السحب الأول هو إيداع 10 رموز، ثم مصدر السحب الثاني هو ناتج التغيير لـ 9 رموز تم إنشاؤها بواسطة السحب الأول، وهكذا تشبيهًا. وهذا يسبب مشاكل في الممارسة العملية لأنه يتطلب من ASP التحقق من صحة الإيداع الوسيط وإضافته إلى المجموعة المرتبطة به.
لكي تتمكن جميع عمليات السحب الأربعة في هذا المثال من الحصول على إيداع العملات المعدنية الأصلية كمصدر لها، نحتاج إلى حل مشكلتين:
● تأكد من عدم ربط كل عملية سحب جزئي بشكل علني بعمليات سحب أخرى
● السماح لكل سحب جزئي بأن يتضمن إيداعًا كعضو في المجموعة المرتبطة به
إذا كنا ندعم عمليات السحب الجزئية فقط، بدلاً من معاملات MIMO الأكثر تعقيدًا، وتأكدنا من أن كل عملية سحب لها "إيداع أصل" واحد محدد ومحدد، فهناك طرق متعددة للقيام بذلك مباشرة. يتمثل النهج الطبيعي والقابل للتطوير في نشر الوعد ببعض المعلومات من خلال المعاملات. على سبيل المثال، يمكننا أن نطلب من المعاملات أن تحتوي على تجزئة التزام (coinID+hash®) مع إضافة بعض القيمة العشوائية r لضمان التعمية، ونطلب من ZK-SNARKs إثبات أن الالتزام في المعاملة هو نفس المعاملة الأصلية. إذا كانت المعاملة الأصلية هي في حد ذاتها عملية سحب، فإن الالتزام يكون هو نفس معرف العملة الأصلية للإيداع، وإذا كانت المعاملة الأصلية عبارة عن إيداع، فإن الالتزام هو نفس معرف العملة الأصلية للإيداع. لذلك، يجب أن تحتوي كل معاملة في السلسلة على التزام بمعرف عملة الإيداع الأصلية وتحتاج إلى إثبات أن هذه القيمة موجودة في المجموعة المرتبطة التي توفرها المعاملة.
لتحسين الخصوصية ضد هجمات تجميع التوازن، يمكننا أيضًا دعم دمج العملات. على سبيل المثال، إذا كان لدي بعض العملات المعدنية المتبقية، فيمكنني دمجها مع إيداعي التالي. لاستيعاب ذلك، يمكننا أن نطلب من المعاملات الالتزام بمجموعة من معرفات العملات، ونطلب من المعاملات ذات المدخلات المتعددة الالتزام باتحاد معاملاتها الأصلية. سيحتوي السحب على دليل على أن جميع معرفات العملات الملتزمة بها موجودة في المجموعة المرتبطة بها.
2. ظروف خاصة
● إعادة الاعتماد: يحتاج المستخدمون إلى معلومات الإيداع السرية لسحب الودائع المشابهة لبروتوكولات مجمع الخصوصية. تُستخدم نفس المعلومات السرية أيضًا لإنشاء أدلة على عضوية مجموعة الجمعيات. يتيح الاحتفاظ بالمعلومات السرية للمستخدمين إنشاء أدلة جديدة لتناسب مجموعات مختلفة أو مجموعات مرتبطة محدثة. وهذا يمنح المستخدمين قدرًا أكبر من المرونة، ولكنه قد يؤدي أيضًا إلى مخاطر إضافية.
● الشهادة الثنائية المباشرة: في بعض الحالات، قد يُطلب من المستخدمين الكشف عن المصدر الدقيق للسحب للطرف الآخر. يمكن للمستخدمين إنشاء مجموعة مرتبطة تحتوي فقط على ودائعهم وإنشاء أدلة ضد تلك المجموعة. عادةً ما تكون هذه الأدلة استثناءات ولا تساهم إلا في الخصوصية الجزئية عند مشاركتها بين طرفين. ومع ذلك، تتطلب مشاركة الأدلة إنشاء افتراضات ثقة قوية.
● إثبات التسلسل: في اقتصاد المعاملات السريعة الذي يستخدم نظامًا مثل مجمع الخصوصية، يحتاج البروتوكول إلى التعديل للتكيف مع هذه البيئة. بالإضافة إلى أنواع معاملات الإيداع والسحب، يحتاج البروتوكول أيضًا إلى دعم عمليات الإرسال الداخلية لزيادة الكفاءة. بالإضافة إلى ذلك، من خلال تمرير فروع ومفاتيح Merkle، يمكن للمستخدمين نشر المعلومات المتعلقة بسجل المعاملات حتى يتمكن المستلمون من التحقق من مصدر الأموال. وهذا يضمن حصول كل مستخدم على الحد الأدنى من المعلومات التي يحتاجها ليكون واثقًا في الأموال التي يتلقاها.
من الناحية العملية، قد يكون للعملة المعدنية "أصول" متعددة. على سبيل المثال، بوب هو صاحب كشك قهوة ويتلقى 5 رموز مميزة من Alice، و4 رموز مميزة من Ashley، و7 رموز مميزة من Anne، وفي نهاية اليوم يحتاج إلى دفع 15 رموز مميزة لكارل لدفع ثمن العشاء. بدلاً من ذلك، ربما يكون ديفيد قد تلقى 15 رمزًا مميزًا من كارل، و25 رمزًا مميزًا من كريس، وأراد إيداع 30 رمزًا مميزًا إلى Emma (عملية تبادل). في هذه الحالات الأكثر تعقيدًا، نتبع نفس المبدأ: يمكن تجاهل التاريخ الذي تمت إضافته إلى المجموعة المرتبطة في وقت مبكر بما فيه الكفاية، بينما يجب تمرير التاريخ الأحدث.
خمسة، مزيد من التفاصيل
يمكن لنظام يشبه مجمع الخصوصية أن يسمح للمستخدمين بالحصول على مزيد من الحماية في خصوصية بيانات معاملاتهم المالية مع الحفاظ على القدرة على إثبات الانفصال عن النشاط غير المشروع المعروف. نتوقع أن يتم تحفيز المستخدمين الصادقين للمشاركة في مثل هذا المخطط من خلال مزيج من عاملين:
● الرغبة في الخصوصية
● الرغبة في تجنب إثارة الشكوك
1. الإجماع الاجتماعي وجمع الجمعيات
فإذا كان هناك إجماع كامل حول ما إذا كانت الأموال جيدة أم سيئة، فإن النظام سوف ينتج توازناً فاصلاً بسيطاً. يتمتع جميع المستخدمين الذين لديهم أصول "جيدة" بحافز قوي وقدرة على إثبات أنهم ينتمون إلى مجموعة ارتباطات "جيدة فقط". ومن ناحية أخرى، لن يتمكن الممثلون السيئون من تقديم هذا الدليل. لا يزال بإمكانهم إيداع الأموال "السيئة" في المجمع، لكن ذلك لن يفيدهم بأي شيء. يمكن للجميع بسهولة تحديد أن الأموال قد تم سحبها من بروتوكول معزز للخصوصية ومعرفة أن السحب يشير إلى مجموعة مرتبطة تحتوي على إيداعات من مصادر مشكوك فيها. علاوة على ذلك، فإن المال "السيئ" لا يلوث المال "الجيد". عندما يتم سحب الأموال من الودائع المشروعة، يمكن لأصحابها ببساطة استبعاد جميع الودائع "السيئة" المعروفة من المجموعة المرتبطة بها.
وحيثما يوجد إجماع عالمي، وحيث تعتمد الاستنتاجات حول ما إذا كان التمويل يعتبر "جيدا" أو "سيئا" على المنظور الاجتماعي أو الاختصاص القضائي، فإن مجموعة الجمعيات يمكن أن تختلف بشكل كبير. لنفترض أن هناك ولايتين قضائيتين لهما مجموعات مختلفة من القواعد. يمكن للموضوعات في كلا السلطتين القضائيتين (أ) و(ب) استخدام نفس بروتوكول تعزيز الخصوصية واختيار إصدار الشهادات التي تلبي متطلبات السلطات القضائية الخاصة بكل منهما. يمكن لكليهما تحقيق الخصوصية بسهولة ضمن المجموعات المرتبطة بهما واستبعاد عمليات السحب التي لا تتوافق مع متطلبات السلطات القضائية الخاصة بهما. إذا لزم الأمر، يمكن إصدار إثبات العضوية لتقاطع مجموعتين مرتبطتين، مما يثبت بشكل موثوق أن الودائع المقابلة لسحوباتها تتوافق مع متطلبات كلا السلطتين القضائيتين.
ولذلك، فإن الاقتراح مرن للغاية وينبغي اعتباره بنية تحتية محايدة. من ناحية، فهو يحارب الرقابة. فهو يسمح لأي شخص بالانضمام إلى مجموعة مرتبطة من اختياره والحفاظ على الخصوصية داخل مجتمعه الخاص. ومن ناحية أخرى، يمكن للغرباء أن يطلبوا أدلة ضد مجموعة معينة من الجمعيات التي تلبي متطلباتهم التنظيمية. لذلك، حتى لو كان هناك مجتمع من الجهات الفاعلة السيئة في بروتوكول تعزيز الخصوصية، فلن يتمكنوا من إخفاء الأصل المشبوه للودائع طالما أن المعلومات تنعكس بدقة في بناء المجموعة المرتبطة.
2. سمات المجموعات المرتبطة
تحتاج المجموعات الترابطية إلى خصائص معينة لتعمل. يجب أن تكون عمليات التحصيل دقيقة حتى يثق المستخدمون في أنهم يستخدمون أموالهم المسحوبة بأمان. علاوة على ذلك، يجب أن تكون خصائص كل مجموعة مستقرة، أي أقل احتمالية للتغير بمرور الوقت. وهذا يقلل من الحاجة إلى عمليات سحب إعادة التحقق من المجموعات الجديدة. أخيرًا، لتحقيق حماية ذات معنى للخصوصية، يجب أن تكون مجموعة الارتباطات كبيرة بما يكفي وتحتوي على أنواع مختلفة من الودائع. ومع ذلك، فإن هذه الخصائص تتعارض مع بعضها البعض. بشكل عام، قد تتمتع المجموعات الكبيرة والمتنوعة بخصائص خصوصية أفضل ولكنها قد تكون أقل دقة واستقرارًا، في حين أن الحفاظ على المجموعات الأصغر أسهل ولكنها توفر خصوصية أقل.
3. الاعتبارات العملية والمنافسة
يجب على الكيانات المنظمة التي تقبل الأصول المشفرة التأكد من أن القوانين واللوائح التي تخضع لها تسمح بقبول هذه الأموال. واليوم، تعتمد العديد من هذه الكيانات على ما يسمى بأدوات فحص المعاملات: البرامج أو الخدمات التي تحلل سلسلة الكتل لتحديد الأنشطة المشبوهة المحتملة، أو الروابط إلى عناوين غير مشروعة، أو غيرها من المعاملات غير المتوافقة. غالبًا ما تعبر أدوات الفحص عن المخاطر المرتبطة بكل عملية تداول من خلال درجة المخاطر. يعتمد هذا التصنيف على وجهة الأموال المحولة وتاريخ معاملاتها. قد تشكل بروتوكولات تعزيز الخصوصية تحديات في هذا الصدد. إنها تقضي على الرابط المرئي بين الودائع والسحوبات. ولذلك، في ظل وجود بروتوكولات تعزيز الخصوصية، يجب أن تأخذ درجة المخاطرة الشهادة في الاعتبار وتعيين درجة بناءً على مجموعة الارتباطات.
يتم توفير الأدوات والخدمات لفحص المعاملات بشكل أساسي من قبل الشركات المهنية ذات الخبرة في تحليل blockchain والمجالات القانونية ذات الصلة. ومن الناحية المثالية، سيكون لهذه الشركات (وأي شخص آخر) حق الوصول إلى جميع إثباتات العضوية والمجموعات المرتبطة بها من أجل توفير درجة مخاطر دقيقة لجميع المعاملات. لذلك، نوصي بتخزين جميع البراهين على blockchain أو أي مستودع إثبات آخر يمكن الوصول إليه بشكل عام. الاستثناء الوحيد هو شهادة العضوية ذات الحجم الأول المشتركة مع طرف مقابل محدد. ولأسباب واضحة، لا ينبغي أن تكون هذه الشهادات متاحة للعامة.
يؤدي تخزين الأدلة مباشرة على السلسلة إلى إضافة تكاليف معاملات إضافية، ولكنه يقلل من جهود التنسيق، ويجعل المنافسة أكثر عدالة، ويخفف من مخاطر شبه الاحتكار التي قد ينشئها مقدمو أدوات الفحص بسبب المعرفة بالأدلة غير العامة.
الإعداد العام لتجمع الخصوصية مرن للغاية. ومن خلال إنشاء مجموعة محددة من الارتباطات، يمكن تصميم البروتوكول ليناسب حالات الاستخدام المختلفة. فيما يلي مثالان لمجموعات الارتباطات الخاصة هذه:
● **يمكن لاتحاد الخدمات المصرفية التجارية إنشاء مجموعة مرتبطة تحتوي فقط على الودائع من عملائه. **يضمن هذا أن إثبات أي عمليات سحب تم إنشاؤها للتحصيل قد خضع لإجراءات اعرف عميلك (KYC) ومكافحة غسيل الأموال (AML) في أحد البنوك المشاركة، ولكنه لا يكشف عن عملية السحب التي تعود إلى أي عميل.
● **في الحالات التي يُطلب فيها من الوسطاء الماليين توثيق مصدر الأموال بشكل واضح، يمكنهم مطالبة المستخدمين بتقديم دليل ضد مجموعة مرتبطة تحتوي فقط على ودائع المستخدمين. **سيتم بعد ذلك تبادل هذا الدليل بشكل ثنائي مع الوسيط، مما يسمح له بتتبع الأموال كما لو أن المستخدم لم يستخدم مجمع الخصوصية مطلقًا. في حين أن هذا يتطلب من المستخدمين أن يثقوا في الوسيط حتى لا يكشف عن الأدلة، فإنه يمكّن المستخدمين من الالتزام باللوائح دون الحاجة إلى الكشف عن المعلومات للجمهور.
4. خيارات التصميم والبدائل
تتميز الإعدادات المستندة إلى مجموعات الارتباطات وإثباتات zk والإفصاحات الطوعية بالمرونة. وفي حين أن هذا مفيد جدًا في ضمان إمكانية تكييف الاقتراح مع ولايات قضائية مختلفة، إلا أنه يجب توخي الحذر الشديد فيما يتعلق بخيارات التصميم المحددة. وعلى وجه الخصوص، هناك نوعان من التعديلات المحتملة التي نعارضها. نعتقد أنها تمثل مشكلة من حيث متطلبات الثقة وقد تؤدي إلى إنشاء هياكل سوقية شبه احتكارية. فيما يلي وصف موجز لهذه البدائل ومناقشتها:
● الوصول المركزي: يمكن لوكالات إنفاذ القانون أو موفري نتائج مخاطر العملات المشفرة أو الجهات الفاعلة المماثلة الوصول لعرض الروابط بين معاملات المستخدم مع الحفاظ على الخصوصية من الآخرين.
● **القائمة البيضاء على مستوى النظام: **يمكن لأنظمة الخصوصية وضع قيود على أنواع المستخدمين الذين يمكنهم إيداع العملات المعدنية في مجموعاتهم، مما يتطلب منهم تقديم دليل إضافي أو مطالبة الودائع بالانتظار لفترة من الوقت يتم خلالها تسجيل المخاطر بشكل مركزي يمكن للنظام رفض الودائع.
تتشابه الطريقتان من حيث أنهما تمنحان امتيازات لكيانات محددة. وهذا يثير أسئلة معقدة تتعلق بالحوكمة: من يمكنه الوصول إلى هذه المعلومات؟ من لديه القدرة على إدارة الأذونات؟ ولا يبدو أن الشركات الخاصة تمثل خيارا جيدا، لأن أي امتيازات قد تخلق هيكل سوق احتكار القلة، حيث تتمتع قِلة من الشركات بإمكانية الوصول إلى البيانات التي تمكنها من تقديم هذه الخدمات، في حين أن شركات أخرى غير قادرة على المنافسة.
وعلى نحو مماثل، سوف نواجه العديد من قضايا الحكم والقضايا السياسية عند تفويض السلطات إلى المؤسسات العامة، وخاصة في السياقات الدولية. وحتى لو كانت المؤسسة جديرة بالثقة بنسبة 100% حتى الآن، ولا تستغل سلطتها لتحقيق أجندة سياسية، ولا تعتمد على كيانات أخرى قد تجبرها على إساءة استخدام سلطتها، فإن هذا الوضع يدل على حالة هادئة. مع مرور الوقت، تتغير المنظمات والأعضاء والبلدان والهياكل السياسية داخل المنظمات. وقد تكون هناك ضغوط خارجية وقد يؤدي وجود هذه الامتيازات إلى خلق حوافز إضافية لتعطيل نظام حوكمة المنظمة وكسب النفوذ عليه.
بالإضافة إلى ذلك، يمكن أن يكون للهجمات داخل المنظمة أو خارجها، أو الأخطاء نيابة عن كيان مركزي، عواقب بعيدة المدى. ونعتقد أنه ينبغي منع إنشاء مثل هذه النقاط المركزية للفشل.
ومع ذلك، فإننا ندرك أن أحجام المعاملات المختلفة والمواقف قد تتطلب مجموعات مختلفة من الأدلة. على سبيل المثال، بالنسبة للمعاملات الكبيرة، قد ينتهي الأمر بالعديد من المستخدمين إلى تقديم دليل أساسي على الاستبعاد على السلسلة وتقديم معلومات أكثر تفصيلاً حول مصدر الأموال إلى الأطراف المقابلة.
5. اتجاه البحث المتعمق
في حين تقدم هذه الدراسة لمحة عامة عن كيفية استخدام بروتوكولات تعزيز الخصوصية المستندة إلى zkSNARK في البيئات المنظمة، هناك العديد من الجوانب التي تستحق المزيد من البحث.
أولاً، يجب على الجميع أن يدركوا أن الخصوصية التي يتم تحقيقها من خلال هذه البروتوكولات تعتمد على العديد من العوامل المختلفة. قد يتمكن المهاجم من ربط عمليات السحب بودائع محددة بناءً على مجموعة ارتباطات كبيرة غير كافية، واختيار جذر سيئ، وخطأ المستخدم.
بالإضافة إلى ذلك، قد تؤثر اختيارات المستخدمين الآخرين سلبًا على خصوصيتك. في الحالات القصوى، يصدر كل فرد آخر في المجمع إثبات عضوية من الحجم الأول، مما يكشف عن وجود صلة مباشرة بين إيداعاتهم وسحوباتهم. من الواضح أن هذا سيكشف ضمنيًا عن العلاقة بين معاملات الإيداع والسحب الوحيدة المتبقية. في مثال أكثر دقة، يمكن استخدام القيود من أدلة العضوية المختلفة لاستخراج المعلومات وربما ربط الودائع والسحوبات باحتمالية عالية. بمجرد دمج هذه المعلومات المعتمدة مع بيانات تعريف المعاملة، قد تتعرض خصائص الخصوصية للبروتوكول للخطر.
أخيرًا، يمكن أن يختار ASP الخبيث تجميع مجموعة الارتباط المقترحة بطريقة تسمح له بتعظيم استخراج المعلومات أو زيادة عدم الكشف عن هويته عن طريق إضافة الودائع حيث تكون عمليات السحب المقابلة معروفة. تتطلب كل هذه المشكلات مزيدًا من البحث لتقييم خصائص الخصوصية المتوفرة. وعلى نفس المنوال، سيكون من المثير للاهتمام مواصلة التحقيق في خصائص التوازنات المنفصلة، ووضع نماذج لكيفية تصرف اللاعبين الجيدين والسيئين في ظل افتراضات معينة وكيف يؤثر الدليل العام على الأول على خصوصية الأخير.
يمكن للخبراء القانونيين إجراء المزيد من الأبحاث حول متطلبات الإفصاح المحددة. يتسم المخطط المقترح في هذه المقالة بالمرونة، ويمكن أن تساعد الرؤى المقدمة من الخبراء القانونيين في تصميم الاتفاقية والنظام البيئي المبني حولها لضمان الامتثال في مختلف الولايات القضائية القانونية.
6. الاستنتاج
في كثير من الحالات، تعتبر الخصوصية والامتثال متعارضتين مع بعضهما البعض. تقترح هذه الورقة أن هذا ليس هو الحال بالضرورة إذا كان بروتوكول تعزيز الخصوصية يمكّن المستخدمين من إثبات خصائص معينة لمصدر أموالهم. على سبيل المثال، من المفترض أن يتمكن المستخدمون من إثبات أن أموالهم ليست مرتبطة بودائع من مصادر غير مشروعة معروفة، أو أن الأموال جزء من مجموعة محددة من الودائع، دون الكشف عن أي معلومات إضافية.
مثل هذا الإعداد يمكن أن ينتج توازنًا منفصلاً حيث يتم تحفيز المستخدمين الصادقين بقوة لإثبات أنهم ينتمون إلى مجموعة ترابطية متوافقة ويحافظون على الخصوصية داخل تلك المجموعة. وفي المقابل، بالنسبة للمستخدمين غير الشرفاء، لا يمكنهم تقديم مثل هذا الدليل. وهذا يمكّن المستخدمين الصادقين من فصل أنفسهم عن ودائع الطرف الثالث الذين لا يتفقون معها، أو منعهم من استخدام أموالهم في بيئة متوافقة. نعتقد أن الاقتراح مرن ويمكن تكييفه مع المتطلبات التنظيمية المختلفة المحتملة.
ينبغي اعتبار هذه الورقة مساهمة في التعايش المستقبلي المحتمل بين الخصوصية والتنظيم المالي. نريد تسهيل المناقشات وتوجيه المحادثة في اتجاه أكثر إيجابية وبناءة. وسوف يتطلب الأمر التعاون بين الممارسين والأكاديميين في مختلف التخصصات وصناع السياسات والجهات التنظيمية لتوسيع هذا الاقتراح وتعديله؛ والهدف النهائي هو إنشاء بنية تحتية معززة للخصوصية يمكن استخدامها في بيئة منظمة.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
أحدث ورقة بحثية لبوتيرين: كيف يحمي بروتوكول تجمع الخصوصية خصوصية المستخدم ويلبي متطلبات الامتثال؟
الاسم:《خصوصية Blockchain والامتثال التنظيمي: نحو توازن عملي》
من: فيتاليك بوتيرين، جاكوب إيلوم، ماتياس نادلر، فابيان شار وأمين سليماني
التجميع: كيف زوج أوديلي بلانيت ديلي
اليوم، شارك V God وآخرون في تأليف ورقة بحثية حول بروتوكولات الخصوصية بعنوان "خصوصية Blockchain والامتثال التنظيمي: نحو توازن عملي" (خصوصية Blockchain والامتثال التنظيمي: نحو توازن عملي).
تتناول الورقة بروتوكولًا جديدًا لتعزيز الخصوصية قائمًا على العقود الذكية، ومجمع الخصوصية، وتناقش مزاياه وعيوبه، موضحة كيف يوازن بين المستخدمين الصادقين وغير الأمناء. يهدف البروتوكول إلى استخدام أدلة المعرفة الصفرية للتحقق من شرعية أموال المستخدمين دون الكشف عن سجل معاملاتهم الكامل، مع الموازنة بين متطلبات الخصوصية والمتطلبات التنظيمية أثناء تصفية الأموال المرتبطة بالنشاط الإجرامي.
تقوم Odaily Planet Daily الآن بتجميع جوهر الورقة على النحو التالي.
I. مقدمة
تتميز سلاسل الكتل العامة بالشفافية من حيث التصميم. الفكرة الأساسية هي أن أي شخص يمكنه اختيار التحقق من المعاملات دون الاضطرار إلى الاعتماد على طرف ثالث مركزي؛ ومن خلال تقليل التبعيات، فإنه يوفر أساسًا محايدًا لمختلف التطبيقات، بما في ذلك على سبيل المثال لا الحصر التمويل وهوية السيادة الذاتية.
ومع ذلك، من وجهة نظر الخصوصية، تمتلك مجموعات البيانات العامة كل معاملة تحتوي على كل عنوان blockchain. عندما يقوم شخص ما بنقل أصل إلى عنوان آخر، أو يتفاعل مع عقد ذكي، ستكون هذه المعاملة مرئية دائمًا على blockchain. ومن الواضح أن هذا لا يتماشى مع متطلبات الخصوصية.
على سبيل المثال: تدفع أليس ثمن العشاء في مطعم باستخدام محفظة blockchain. يعرف المستفيد الآن عنوان Alice ويمكنه تحليل جميع الأنشطة الماضية والمستقبلية على ذلك العنوان. وبالمثل، تعرف أليس الآن عنوان محفظة المطعم ويمكنها استخدام هذه المعلومات للحصول على عناوين المحفظة للضيوف الآخرين أو عرض إيرادات المطعم. أو يمكن لطرف ثالث (مثل وسائل التواصل الاجتماعي) يعرف المطعم وعنوان محفظة أليس أن يستنتج بسهولة عنوان السكن الفعلي لأليس ويدرس معاملاتها الماضية والمستقبلية.
**إن ظهور بروتوكولات تعزيز الخصوصية يهدف إلى حل المشكلات المذكورة أعلاه. فهو يسمح للمستخدمين بإيداع الأموال في البروتوكول، باستخدام عنوان واحد، وسحب الأموال من البروتوكول في وقت لاحق، باستخدام عنوان آخر. لا تزال جميع عمليات الإيداع والسحب مرئية على blockchain، ولكن المراسلات بين عمليات النقل والتحويلات المحددة لم تعد علنية. **
أحد أشهر بروتوكولات تحسين الخصوصية هو Tornado Cash. لقد نجح في حل المشكلات المذكورة أعلاه ويسمح للمستخدمين بالاحتفاظ ببعض الخصوصية. ومع ذلك، بالإضافة إلى المستخدمين الشرعيين الذين يحاولون حماية بياناتهم، يتم استخدام Tornado Cash أيضًا من قبل مجموعة متنوعة من الجهات الفاعلة السيئة. تظهر بيانات الإيداع أن مجموعة المتسللين قامت بنقل الأموال من خلال هذا البروتوكول. هناك أدلة على أن بروتوكول تعزيز الخصوصية هذا يُستخدم أيضًا من قبل مجموعات القرصنة الكورية الشمالية، مما أدى في النهاية إلى وضع عناوين العقود الذكية الخاصة بالبروتوكول على قائمة المواطنين المعينين خصيصًا والأشخاص المحظورين التي يحتفظ بها مكتب الولايات المتحدة لمراقبة الأصول الأجنبية (OFAC). (يُشار إليها غالبًا باسم قائمة SDN)).
**المشكلة الرئيسية في Tornado Cash هي عدم وضوح الخط الفاصل بين المستخدمين الشرعيين والمستخدمين المجرمين. **لذلك، تقدم Tornado Cash ميزة امتثال تسمح للمستخدمين بإنشاء دليل على مصدر الإيداع الذي تم سحبه منه. وفي حين تسمح هذه الآلية للأشخاص بإثبات براءتهم، فإنها تفعل ذلك على حساب الاضطرار إلى الثقة في وسيط مركزي وخلق عدم تناسق في المعلومات. في نهاية المطاف، تم استخدام الآلية من قبل عدد قليل من المستخدمين.
تناقش هذه الورقة امتدادًا لهذا النهج الذي يمكّن المستخدمين من التصديق علنًا على المعلومات حول الودائع التي قد تأتي منها عمليات السحب، دون فقدان الخصوصية. **تقترح مجمعات الخصوصية مفهومًا عامًا: السماح بإثبات العضوية ("أشهد أن انسحابي جاء من إحدى هذه الودائع") أو إثبات الاستبعاد ("أشهد أن انسحابي لم يأت من أي من هذه الودائع"). **تناقش هذه المقالة هذا الاقتراح وتشرح كيف يمكن استخدامه لتحقيق التوازن بين المستخدمين الصادقين وغير الأمناء.
لاحظ أن تجمعات الخصوصية توفر خيارات إضافية عن طريق توسيع مجموعة إجراءات المستخدم. لا يزال بإمكانهم تقديم شهادة أكثر تفصيلاً لأطراف مقابلة محددة إذا لزم الأمر. ومع ذلك، في بعض الحالات، قد يكون إثبات العضوية أو الاستبعاد كافيًا. بالإضافة إلى ذلك، يوفر خيار الإصدار العلني لهذه الشهادات عددًا من المزايا مقارنة بالإفصاح الثنائي.
2. الخلفية التقنية
في هذا القسم، نقدم نظرة عامة فنية قصيرة ونناقش العناصر الأساسية الفنية والمبادئ العامة للبروتوكولات مثل مجمعات الخصوصية.
1. خصوصية Blockchain قبل ZK-SNARKs
تاريخيًا، جادل مؤيدو البلوكتشين بأنه على الرغم من أن جميع المعاملات شفافة، إلا أن البلوكتشين يمكنها الحفاظ على الخصوصية لأنها توفر عدم الكشف عن هويتها.
ومع ظهور أدوات التجميع والتحليل الحديثة، أصبحت حماية الخصوصية هذه غير كافية. لتحسين خصوصية سلاسل الكتل العامة، تم تقديم تقنيات أكثر قوة مثل Token Join وMonero. ومع ذلك، لا تزال هذه التقنيات تحمل مخاطر تسرب البيانات. **
وأعقب ذلك تقنيات إثبات المعرفة الصفرية ذات الأغراض العامة مثل Zcash وTornado Cash، والتي يمكن أن تجعل مجموعة إخفاء الهوية لكل معاملة مساوية للمجموعة الكاملة لجميع المعاملات السابقة. غالبًا ما تسمى هذه التقنية ZK-SNARKs.
2、ZK-SNARKs
ZK-SNARKs هي تقنية تسمح للمبرهن بإثبات عبارة رياضية معينة حول البيانات العامة والخاصة، **مع استيفاء خاصيتين رئيسيتين: المعرفة الصفرية والبساطة. **
● عدم المعرفة: لن يتم الكشف عن أي معلومات حول البيانات الخاصة إلا لإثبات أن البيانات الخاصة المذكورة تتوافق مع المطالبات.
● **البساطة: **الأدلة قصيرة ويمكن التحقق منها بسرعة، حتى لو كانت الادعاءات المثبتة تتطلب حسابات تستغرق وقتًا طويلاً.
لقد حظيت ZK-SNARKs بالكثير من الاهتمام من مجتمع blockchain بسبب أهميتها القابلة للتوسع، مثل ZK-rollups. بالنسبة لتطبيقات الخصوصية، البساطة ليست ذات أهمية خاصة، ولكن المعرفة الصفرية ضرورية.
يمكن اعتبار "البيان" الذي أثبته ZK-SNARKs بمثابة نوع من البرامج يسمى "الدائرة"، والذي يحسب نتيجة الدالة f(x, w) مع المدخلات العامة والخاصة، ثم يثبت ذلك بالنسبة لجمهور معين input x ، يوجد مدخل خاص w بحيث يتم تقييم f(x, w) إلى True.
3. تطبيق ZK-SNARKs في أنظمة مثل Zcash وTornado Cash
هناك بعض الاختلافات الطفيفة بين الإصدارات المختلفة من Zcash والأنظمة المستوحاة منه مثل Tornado Cash. ومع ذلك، فإن المنطق الأساسي الذي يعتمدون عليه مشابه جدًا. يصف هذا القسم إصدارًا بسيطًا يتوافق تقريبًا مع كيفية عمل هذه البروتوكولات.
تتكون الرموز من أسرار يحتفظ بها أصحابها. يمكن استخلاص قيمتين من s:
● معرف الرمز المميز L = التجزئة (العلامات + 1)
● المبطلU = التجزئة (s + 2)
من بينها، يشير التجزئة إلى وظيفة تجزئة كلمة المرور، مثل SHA 256. بالنظر إلى الصورة، يمكن حساب معرف الرمز المميز والصفر. ومع ذلك، بالنظر إلى مجموعة من أدوات الصفر ومعرف الرمز المميز العام، يضمن السلوك العشوائي الزائف لوظيفة التجزئة أنه لا يمكنك تحديد أي جهاز تصفير مرتبط بمعرف الرمز المميز إلا إذا كنت تعرف السر الذي أنشأ كليهما.
يتتبع blockchain جميع معرفات الرموز المميزة التي تم "إنشاءها"، بالإضافة إلى جميع أدوات الصفر التي تم "إنفاقها". كلتا المجموعتين تنمو باستمرار (ما لم يرغب البروتوكول في فرض متى يجب إنفاق الرموز المميزة).
يتم تخزين مجموعة معرفات الرموز المميزة في بنية بيانات تسمى شجرة Merkle: إذا كانت الشجرة تحتوي على N من العناصر، فسيتم تجزئة كل عنصر مجاور (مما يؤدي إلى ⌈ N/2 ⌉ تجزئات)، ويتم تجزئة كل تجزئات متجاورة مرة أخرى (مما يؤدي إلى ⌈ N/4 ⌉)، وهكذا، حتى يتم دمج البيانات بأكملها في "تجزئة جذر" واحدة.
بالنظر إلى قيمة معينة في الشجرة وتجزئة الجذر، يمكن للمرء توفير فرع Merkle: "قيمة شقيقة" يتم تجزئةها معًا في كل خطوة على المسار من تلك القيمة إلى الجذر. يعد فرع Merkle مفيدًا لأنه عبارة عن جزء صغير من البيانات (سجل 2 (N)) يمكن استخدامه لإثبات أن أي قيمة معينة موجودة بالفعل في الشجرة. ويبين الشكل أدناه مثالاً لشجرة ميركل التي يبلغ ارتفاعها 4.
عندما يرسل المستخدمون عملات معدنية إلى الآخرين، فإنهم يقدمون ما يلي:
● Nullifier U الذي يريد أن ينفق
● معرف الرمز المميز L' للرمز المميز الجديد المطلوب إنشاؤه (يُطلب من المستلم تقديم هذا)
● ZK-SNARK.
يحتوي ZK-SNARK على المدخلات الخاصة التالية:
● أسرار المستخدم
● فرع Merkle في شجرة معرف الرمز المميز، مما يثبت أن الرمز المميز بمعرف الرمز المميز L = hash(s + 1) تم إنشاؤه بالفعل في وقت ما في الماضي
ويحتوي أيضًا على المدخلات العامة التالية:
● U، صفر الرموز المميزة التي يتم إنفاقها
● R، التجزئة الجذرية التي يتم توجيه أدلة Merkle ضدها
يثبت ZK-SNARK خاصيتين:
● U = التجزئة (s + 2)
● فروع ميركل صالحة
بالإضافة إلى ZK-SNARKs، يتحقق البروتوكول مما يلي:
● R هو التجزئة الجذرية الحالية أو التاريخية لشجرة معرف الرمز المميز
● U ليس ضمن مجموعة الصفرات المستهلكة
إذا كانت المعاملة صالحة، فإنها تضيف U إلى مجموعة أدوات التصفية المستهلكة وL' إلى قائمة معرفات الرمز المميز. يؤدي عرض U إلى منع إنفاق رمز مميز واحد بشكل مضاعف. ومع ذلك، لن يتم الكشف عن أي معلومات أخرى. **لا يستطيع العالم الخارجي إلا أن يرى متى يتم إرسال المعاملات؛ ولا يمكنه الحصول على نمط حول من يرسل أو يستقبل هذه المعاملات ولا يمكنه التمييز بين المصدر الموحد للرموز المميزة. **
هناك استثناءان للنمط المذكور أعلاه: الودائع والسحوبات. في الودائع، يمكن إنشاء معرفات الرمز المميز دون إبطال رمز مميز سابق معين. من منظور الحفاظ على الخصوصية، لا تكون الودائع مجهولة المصدر بسبب الارتباط بين L معين وحدث خارجي يسمح بإضافة L (في Tornado Cash، يكون إيداع ETH في النظام؛ وفي Zcash، يعد التعدين الجديد ZEC) عامًا.
بمعنى آخر، **ترتبط الودائع بتاريخ معاملاتها السابقة. **في حالة السحب، سيتم استهلاك الصفر دون إضافة معرف رمزي جديد. قد يؤدي هذا إلى فصل عمليات السحب من الودائع المقابلة وبشكل غير مباشر من تاريخ المعاملات السابقة. ومع ذلك، يمكن ربط عمليات السحب بأي معاملات مستقبلية تحدث بعد حدث السحب.
لم يكن لدى الإصدار الأول من Tornado Cash أي مفهوم للتحويلات الداخلية، بل كان يسمح فقط بالإيداع والسحب. الإصدارات اللاحقة، التي لا تزال في المرحلة التجريبية، سمحت أيضًا بالتحويلات الداخلية والعملات المعدنية من مختلف الطوائف، بما في ذلك دعم عمليات "التقسيم" و"الدمج". سنناقش كيفية توسيع نظام نقل العملات المعدنية الأساسي ومجمع الخصوصية ليشمل الطوائف العشوائية في الفصول اللاحقة.
4. ZK-SNARKs في تجمع الخصوصية
**الفكرة الأساسية لمجمع الخصوصية هي أن المستخدمين لا يثبتون فقط أن السحب مرتبط بإيداع سابق من خلال إثبات المعرفة الصفرية، بل يثبتون أيضًا أنه ينتمي إلى مجموعة ارتباط أكثر صرامة. **يمكن أن تكون المجموعة المرتبطة مجموعة فرعية من جميع الإيداعات التي تم إجراؤها مسبقًا، أو مجموعة تحتوي فقط على إيداعات المستخدم الخاصة، أو أي شيء بينهما. يحدد المستخدم المجموعة من خلال توفير جذر Merkle للمجموعة المرتبطة كمدخل عام.
كما هو موضح في الشكل أدناه، من أجل التبسيط، نحن لا نثبت بشكل مباشر أن المجموعة المرتبطة هي بالفعل مجموعة فرعية من الإيداعات التي تم إجراؤها مسبقًا؛ بدلاً من ذلك، نطلب فقط من المستخدم استخدام نفس معرف العملة كعقدة ورقية إثبات فرعين من ميركل من خلال المعرفة الصفرية:
● أدخل فرع Merkle للجذر R لمجموعة معرفات العملة الإجمالية
● أدخل فرع Merkle الخاص بـ RA الجذر لمجموعة الاقتران المتوفرة
القصد من ذلك هو وضع المجموعة الكاملة من الارتباطات في مكان ما (يمكن أن تكون متصلة بالسلسلة). المفهوم الأساسي هو: بدلاً من مطالبة المستخدمين بتحديد الإيداع الذي جاءت منه عمليات السحب بالضبط، أو على الطرف الآخر، عدم تقديم أي معلومات أخرى بخلاف إثبات عدم وجود إنفاق مزدوج، فإننا نسمح للمستخدمين بتوفير مجموعة من الخيارات التي يمكن من خلالها ربما جاءت الأموال، ويمكن أن تكون هذه المجموعة واسعة أو ضيقة كما يحلو لهم.
نحن نشجع النظام البيئي الذي يسهل على المستخدمين تحديد مجموعة من الارتباطات المتوافقة مع تفضيلاتهم. ستصف بقية هذه المقالة فقط البنية التحتية المستندة إلى هذه الآلية الأساسية البسيطة وعواقبها.
3. الاعتبارات العملية وحالات الاستخدام
تحليل كيفية استخدام بروتوكولات تعزيز الخصوصية عمليًا من منظور التطبيق.
1. حالات استخدام المجموعات المرتبطة
لتوضيح قيمة هذا البرنامج في بيئة إنفاذ القانون، إليك مثال:
لنفترض أن لدينا خمسة مستخدمين: أليس، بوب، كارل، ديفيد، إيف. المستخدمون الأربعة الأوائل هم مستخدمون صادقون وملتزمون بالقانون ولكنهم مهتمون بالخصوصية، في حين أن Eve هي لص. لأن الجمهور يعرف أن حواء هي لص من خلال المعلومات التي تفيد بسرقة العملات المعدنية الموجودة في العنوان الذي يحمل علامة "حواء". من الناحية العملية، يحدث هذا في كثير من الأحيان: في سلاسل الكتل العامة، يتم تتبع الأموال الناتجة عن استغلال نقاط الضعف في بروتوكولات التمويل اللامركزي لتحديد الأموال غير المشروعة التي تتدفق إلى Tornado Cash.
عندما يقوم كل من المستخدمين الخمسة بالسحب، يمكنهم اختيار المجموعة المرتبطة التي يريدون تحديدها. يجب أن تتضمن مجموعة الارتباطات الخاصة بهم الودائع الخاصة بهم، ولكن لديهم الحرية في اختيار أي من العناوين الأخرى يريدون تضمينها. كان الدافع لدى المستخدمين الأربعة الأوائل من ناحية هو الرغبة في حماية خصوصيتهم إلى أقصى حد ممكن. وهذا يحفزهم على الميل إلى جعل ارتباطهم أكبر. من ناحية أخرى، يريدون تقليل فرصة اعتبار عملاتهم مشبوهة من قبل التجار أو البورصات. هناك طريقة سهلة للقيام بذلك: لا يقومون بتضمين Eve في المجموعة المرتبطة بهم. ولذلك، فإن الاختيار واضح بالنسبة للأربعة: لتكن مجموعة ارتباطاتهم {Alice, Bob, Carl, David}.
بالطبع، تريد Eve أيضًا تعظيم مجموعة الارتباطات الخاصة بها. لكنها لا تستطيع استبعاد ودائعها الخاصة، لذا فهي مجبرة على جعل مجموعتها المرتبطة مساوية لمجموعة الودائع الخمسة. يتم عرض مجموعة مختارة من المشاركين في الشكل أدناه.
على الرغم من أن حواء نفسها لم تقدم أي معلومات، فمن خلال عملية حذف بسيطة، يمكننا استخلاص استنتاج واضح: الخطوة الخامسة للانسحاب لا يمكن أن تأتي إلا من حواء.
2. بناء المجموعات المرتبطة بها
أوضح القسم السابق إحدى الطرق الممكنة لاستخدام المجموعات المرتبطة في بروتوكول مشابه لتجمع الخصوصية، وكيف يمكن فصل المشاركين الصادقين عن المشاركين السيئين. لاحظ أن النظام لا يعتمد على إيثار أليس، وبوب، وكارل، وديفيد؛ بل لديهم حوافز واضحة لتبرير انفصالهم. دعونا الآن نلقي نظرة على بناء المجموعات المرتبطة بمزيد من التفصيل. عادة، هناك استراتيجيتان رئيسيتان لإنشاء مجموعات الارتباط. تم وصفها أدناه وتصورها في الصورة أدناه.
● **الإدراج (أو العضوية): **تحديد مجموعة محددة من الودائع التي لدينا دليل قاطع على أنها منخفضة المخاطر، وبناء مجموعة مرتبطة تحتوي على هذه الودائع فقط.
● استبعاد: حدد مجموعة محددة من الودائع التي لدينا أدلة قوية لنعتبرها عالية المخاطر وقم بإنشاء مجموعة ارتباطات تتضمن جميع الودائع باستثناء تلك الودائع.
ومن الناحية العملية، لا يقوم المستخدمون باختيار الودائع يدويًا لإدراجها في مجموعتهم المرتبطة. وبدلاً من ذلك، سيشترك المستخدمون في وسطاء نسميهم موفري المجموعات المرتبطة (ASPs)، الذين يقومون بإنشاء مجموعات مقترنة بخصائص محددة. **في بعض الحالات، يمكن إنشاء مزودي الخدمة (ASP) بالكامل على السلسلة، ولا يتطلب أي تدخل بشري (أو الذكاء الاصطناعي). وفي حالات أخرى، سيقوم مقدمو خدمات التطبيقات بإنشاء المجموعة المرتبطة بشكل مستقل ونشر المجموعة المرتبطة على السلسلة أو في أي مكان آخر.
نوصي بشدة بنشر جذر Merkle على الأقل لمجموعة الارتباط على السلسلة؛ وهذا يلغي قدرة مقدمي خدمات التطبيقات الضارين على تنفيذ أنواع معينة من الهجمات على المستخدمين (على سبيل المثال، منح مستخدمين مختلفين مجموعات اقتران مختلفة في محاولة لإخفاء هويتهم). . يجب أن تكون المجموعة بأكملها متاحة عبر واجهة برمجة التطبيقات (API) أو من خلال نظام تخزين لامركزي منخفض التكلفة مثل IPFS.
تعد القدرة على تنزيل المجموعة المرتبطة بأكملها أمرًا مهمًا لأنها تتيح للمستخدمين إنشاء إثباتات العضوية محليًا دون الكشف عن أي معلومات إضافية لمقدم خدمة ASP، ولا حتى الإيداعات المقابلة لعمليات السحب الخاصة بهم.
فيما يلي كيفية هيكلة خدمات ASP عمليًا:
● إضافة متأخرة، باستثناء العناصر السيئة: تتم إضافة أي إيداع تلقائيًا إلى المجموعة المرتبطة بعد فترة زمنية محددة (على سبيل المثال، 7 أيام)، ولكن إذا اكتشف النظام إيداعًا مرتبطًا بسلوك سيئ معروف (على سبيل المثال، سرقة واسعة النطاق أو عنوانًا في قائمة العقوبات التي نشرتها الحكومة)، فلن تتم إضافة الوديعة مطلقًا. ومن الناحية العملية، يمكن تحقيق ذلك من خلال المجموعات التي ينظمها المجتمع أو مقدمو خدمات فحص المعاملات الحاليون الذين يقومون بالفعل بتحديد وتتبع الودائع المرتبطة بالسلوك السيئ.
● الرسوم الشهرية لكل شخص: من أجل الانضمام إلى مجموعة مرتبطة، يجب أن تكون قيمة الإيداع أقل من الحد الأقصى الثابت، ويجب على المودع إثبات أنه يحمل بعض رموز الهوية (على سبيل المثال، من قبل حكومة مدعومة) دون علمه بذلك. أنظمة الهوية الوطنية أو آليات خفيفة مثل التحقق من حساب وسائل التواصل الاجتماعي). تم دمجها مع معلمة إضافية تشير إلى آلية التخلص للشهر الحالي للتأكد من أن كل هوية يمكنها فقط الالتزام بالودائع إلى المجموعة المرتبطة مرة واحدة شهريًا. يحاول التصميم تنفيذ روح العديد من القواعد الشائعة لمكافحة غسيل الأموال، حيث تسمح المدفوعات الصغيرة التي تقل عن حد معين بمستوى أعلى من الخصوصية. لاحظ أنه يمكن تنفيذ ذلك بالكامل كعقد ذكي، ولا يتطلب أي إشراف يدوي للحفاظ على التشغيل المستمر.
● **الرسوم الشهرية لأعضاء المجتمع الموثوق بهم: **تشبه الرسوم الشهرية لشخص واحد، ولكنها أكثر تقييدًا: يجب على المستخدمين إثبات أنهم أعضاء في مجتمع موثوق به للغاية. يوافق أعضاء المجتمع ذوو الثقة العالية على توفير الخصوصية لبعضهم البعض.
● ** التسجيل في الوقت الفعلي المستند إلى الذكاء الاصطناعي: ** يمكن لنظام AI ASP توفير درجة المخاطرة لكل إيداع في الوقت الفعلي، وسيقوم النظام بإخراج مجموعة مرتبطة تحتوي على الودائع ذات درجة المخاطرة أقل من حد معين. من المحتمل أن يقوم ASP بإخراج مجموعات متعددة تتوافق مع عتبات درجات المخاطر المتعددة.
4. مزيد من الوصف الفني
في هذا القسم، نقوم بتحليل كيفية دعم الاقتراح للطوائف التعسفية ومناقشة حالات خاصة مثل إعادة الشهادة، والشهادة المباشرة الثنائية، والشهادة التسلسلية.
1. دعم أي طائفة
نظام العملات المبسط لحماية الخصوصية أعلاه يدعم فقط تحويلات العملات من نفس الفئة. تدعم Zcash الفئات العشوائية باستخدام نموذج UTXO. يمكن أن تحتوي كل معاملة على مدخلات متعددة (تحتاج إلى نشر أداة التصفية لكل إدخال) ومخرجات متعددة (تحتاج إلى نشر معرف رمز مميز لكل مخرجات). يجب أن يكون كل معرف رمز مميز تم إنشاؤه مصحوبًا بقيمة فئة تشفير. بالإضافة إلى إثبات صلاحية الصفر، يجب أن تكون كل معاملة مصحوبة بإثبات إضافي بأن مجموع فئات العملات المعدنية التي تم إنشاؤها لا يتجاوز مجموع فئات العملات المعدنية المنفقة. ويوضح الشكل أدناه هذا الدليل الإضافي.
ويمكن توسيع هذا التصميم لدعم الودائع والسحوبات من خلال التعامل مع الودائع كمدخلات (غير مشفرة) والسحوبات كمخرجات (غير مشفرة). بالإضافة إلى ذلك، يمكن تقييد التصميم من أجل تبسيط التحليل. على سبيل المثال، من الممكن السماح فقط بالسحب الجزئي، مما يسمح للمعاملة بأن تحتوي على مدخل واحد مشفر ومخرجين: مخرج غير مشفر يمثل السحب، ومخرج "تغيير" مشفر يمثل الأموال المتبقية التي يمكن استخدامها لعمليات السحب المستقبلية.
والسؤال الطبيعي هو كيفية توسيع هذا التصميم لدعم تجمعات الخصوصية. إن إدراجه في مجمع الخصوصية دون تغيير ليس مثاليًا لأن الرسم البياني للمعاملات لا يتوافق مع ما نتوقعه بشكل بديهي: إذا قام المستخدم بإيداع 10 رموز مميزة ثم أنفق 1 + 2 + 3 + 4 في أربع رموز سحب متتالية، فإننا نريد معالجة الكل أربع عمليات سحب كمصدر للإيداع الأصلي المكون من 10 رموز. لكن النتيجة الفعلية هي كما هو موضح أدناه: مصدر السحب الأول هو إيداع 10 رموز، ثم مصدر السحب الثاني هو ناتج التغيير لـ 9 رموز تم إنشاؤها بواسطة السحب الأول، وهكذا تشبيهًا. وهذا يسبب مشاكل في الممارسة العملية لأنه يتطلب من ASP التحقق من صحة الإيداع الوسيط وإضافته إلى المجموعة المرتبطة به.
لكي تتمكن جميع عمليات السحب الأربعة في هذا المثال من الحصول على إيداع العملات المعدنية الأصلية كمصدر لها، نحتاج إلى حل مشكلتين:
● تأكد من عدم ربط كل عملية سحب جزئي بشكل علني بعمليات سحب أخرى
● السماح لكل سحب جزئي بأن يتضمن إيداعًا كعضو في المجموعة المرتبطة به
إذا كنا ندعم عمليات السحب الجزئية فقط، بدلاً من معاملات MIMO الأكثر تعقيدًا، وتأكدنا من أن كل عملية سحب لها "إيداع أصل" واحد محدد ومحدد، فهناك طرق متعددة للقيام بذلك مباشرة. يتمثل النهج الطبيعي والقابل للتطوير في نشر الوعد ببعض المعلومات من خلال المعاملات. على سبيل المثال، يمكننا أن نطلب من المعاملات أن تحتوي على تجزئة التزام (coinID+hash®) مع إضافة بعض القيمة العشوائية r لضمان التعمية، ونطلب من ZK-SNARKs إثبات أن الالتزام في المعاملة هو نفس المعاملة الأصلية. إذا كانت المعاملة الأصلية هي في حد ذاتها عملية سحب، فإن الالتزام يكون هو نفس معرف العملة الأصلية للإيداع، وإذا كانت المعاملة الأصلية عبارة عن إيداع، فإن الالتزام هو نفس معرف العملة الأصلية للإيداع. لذلك، يجب أن تحتوي كل معاملة في السلسلة على التزام بمعرف عملة الإيداع الأصلية وتحتاج إلى إثبات أن هذه القيمة موجودة في المجموعة المرتبطة التي توفرها المعاملة.
لتحسين الخصوصية ضد هجمات تجميع التوازن، يمكننا أيضًا دعم دمج العملات. على سبيل المثال، إذا كان لدي بعض العملات المعدنية المتبقية، فيمكنني دمجها مع إيداعي التالي. لاستيعاب ذلك، يمكننا أن نطلب من المعاملات الالتزام بمجموعة من معرفات العملات، ونطلب من المعاملات ذات المدخلات المتعددة الالتزام باتحاد معاملاتها الأصلية. سيحتوي السحب على دليل على أن جميع معرفات العملات الملتزمة بها موجودة في المجموعة المرتبطة بها.
2. ظروف خاصة
● إعادة الاعتماد: يحتاج المستخدمون إلى معلومات الإيداع السرية لسحب الودائع المشابهة لبروتوكولات مجمع الخصوصية. تُستخدم نفس المعلومات السرية أيضًا لإنشاء أدلة على عضوية مجموعة الجمعيات. يتيح الاحتفاظ بالمعلومات السرية للمستخدمين إنشاء أدلة جديدة لتناسب مجموعات مختلفة أو مجموعات مرتبطة محدثة. وهذا يمنح المستخدمين قدرًا أكبر من المرونة، ولكنه قد يؤدي أيضًا إلى مخاطر إضافية.
● الشهادة الثنائية المباشرة: في بعض الحالات، قد يُطلب من المستخدمين الكشف عن المصدر الدقيق للسحب للطرف الآخر. يمكن للمستخدمين إنشاء مجموعة مرتبطة تحتوي فقط على ودائعهم وإنشاء أدلة ضد تلك المجموعة. عادةً ما تكون هذه الأدلة استثناءات ولا تساهم إلا في الخصوصية الجزئية عند مشاركتها بين طرفين. ومع ذلك، تتطلب مشاركة الأدلة إنشاء افتراضات ثقة قوية.
● إثبات التسلسل: في اقتصاد المعاملات السريعة الذي يستخدم نظامًا مثل مجمع الخصوصية، يحتاج البروتوكول إلى التعديل للتكيف مع هذه البيئة. بالإضافة إلى أنواع معاملات الإيداع والسحب، يحتاج البروتوكول أيضًا إلى دعم عمليات الإرسال الداخلية لزيادة الكفاءة. بالإضافة إلى ذلك، من خلال تمرير فروع ومفاتيح Merkle، يمكن للمستخدمين نشر المعلومات المتعلقة بسجل المعاملات حتى يتمكن المستلمون من التحقق من مصدر الأموال. وهذا يضمن حصول كل مستخدم على الحد الأدنى من المعلومات التي يحتاجها ليكون واثقًا في الأموال التي يتلقاها.
من الناحية العملية، قد يكون للعملة المعدنية "أصول" متعددة. على سبيل المثال، بوب هو صاحب كشك قهوة ويتلقى 5 رموز مميزة من Alice، و4 رموز مميزة من Ashley، و7 رموز مميزة من Anne، وفي نهاية اليوم يحتاج إلى دفع 15 رموز مميزة لكارل لدفع ثمن العشاء. بدلاً من ذلك، ربما يكون ديفيد قد تلقى 15 رمزًا مميزًا من كارل، و25 رمزًا مميزًا من كريس، وأراد إيداع 30 رمزًا مميزًا إلى Emma (عملية تبادل). في هذه الحالات الأكثر تعقيدًا، نتبع نفس المبدأ: يمكن تجاهل التاريخ الذي تمت إضافته إلى المجموعة المرتبطة في وقت مبكر بما فيه الكفاية، بينما يجب تمرير التاريخ الأحدث.
خمسة، مزيد من التفاصيل
يمكن لنظام يشبه مجمع الخصوصية أن يسمح للمستخدمين بالحصول على مزيد من الحماية في خصوصية بيانات معاملاتهم المالية مع الحفاظ على القدرة على إثبات الانفصال عن النشاط غير المشروع المعروف. نتوقع أن يتم تحفيز المستخدمين الصادقين للمشاركة في مثل هذا المخطط من خلال مزيج من عاملين:
● الرغبة في الخصوصية
● الرغبة في تجنب إثارة الشكوك
1. الإجماع الاجتماعي وجمع الجمعيات
فإذا كان هناك إجماع كامل حول ما إذا كانت الأموال جيدة أم سيئة، فإن النظام سوف ينتج توازناً فاصلاً بسيطاً. يتمتع جميع المستخدمين الذين لديهم أصول "جيدة" بحافز قوي وقدرة على إثبات أنهم ينتمون إلى مجموعة ارتباطات "جيدة فقط". ومن ناحية أخرى، لن يتمكن الممثلون السيئون من تقديم هذا الدليل. لا يزال بإمكانهم إيداع الأموال "السيئة" في المجمع، لكن ذلك لن يفيدهم بأي شيء. يمكن للجميع بسهولة تحديد أن الأموال قد تم سحبها من بروتوكول معزز للخصوصية ومعرفة أن السحب يشير إلى مجموعة مرتبطة تحتوي على إيداعات من مصادر مشكوك فيها. علاوة على ذلك، فإن المال "السيئ" لا يلوث المال "الجيد". عندما يتم سحب الأموال من الودائع المشروعة، يمكن لأصحابها ببساطة استبعاد جميع الودائع "السيئة" المعروفة من المجموعة المرتبطة بها.
وحيثما يوجد إجماع عالمي، وحيث تعتمد الاستنتاجات حول ما إذا كان التمويل يعتبر "جيدا" أو "سيئا" على المنظور الاجتماعي أو الاختصاص القضائي، فإن مجموعة الجمعيات يمكن أن تختلف بشكل كبير. لنفترض أن هناك ولايتين قضائيتين لهما مجموعات مختلفة من القواعد. يمكن للموضوعات في كلا السلطتين القضائيتين (أ) و(ب) استخدام نفس بروتوكول تعزيز الخصوصية واختيار إصدار الشهادات التي تلبي متطلبات السلطات القضائية الخاصة بكل منهما. يمكن لكليهما تحقيق الخصوصية بسهولة ضمن المجموعات المرتبطة بهما واستبعاد عمليات السحب التي لا تتوافق مع متطلبات السلطات القضائية الخاصة بهما. إذا لزم الأمر، يمكن إصدار إثبات العضوية لتقاطع مجموعتين مرتبطتين، مما يثبت بشكل موثوق أن الودائع المقابلة لسحوباتها تتوافق مع متطلبات كلا السلطتين القضائيتين.
ولذلك، فإن الاقتراح مرن للغاية وينبغي اعتباره بنية تحتية محايدة. من ناحية، فهو يحارب الرقابة. فهو يسمح لأي شخص بالانضمام إلى مجموعة مرتبطة من اختياره والحفاظ على الخصوصية داخل مجتمعه الخاص. ومن ناحية أخرى، يمكن للغرباء أن يطلبوا أدلة ضد مجموعة معينة من الجمعيات التي تلبي متطلباتهم التنظيمية. لذلك، حتى لو كان هناك مجتمع من الجهات الفاعلة السيئة في بروتوكول تعزيز الخصوصية، فلن يتمكنوا من إخفاء الأصل المشبوه للودائع طالما أن المعلومات تنعكس بدقة في بناء المجموعة المرتبطة.
2. سمات المجموعات المرتبطة
تحتاج المجموعات الترابطية إلى خصائص معينة لتعمل. يجب أن تكون عمليات التحصيل دقيقة حتى يثق المستخدمون في أنهم يستخدمون أموالهم المسحوبة بأمان. علاوة على ذلك، يجب أن تكون خصائص كل مجموعة مستقرة، أي أقل احتمالية للتغير بمرور الوقت. وهذا يقلل من الحاجة إلى عمليات سحب إعادة التحقق من المجموعات الجديدة. أخيرًا، لتحقيق حماية ذات معنى للخصوصية، يجب أن تكون مجموعة الارتباطات كبيرة بما يكفي وتحتوي على أنواع مختلفة من الودائع. ومع ذلك، فإن هذه الخصائص تتعارض مع بعضها البعض. بشكل عام، قد تتمتع المجموعات الكبيرة والمتنوعة بخصائص خصوصية أفضل ولكنها قد تكون أقل دقة واستقرارًا، في حين أن الحفاظ على المجموعات الأصغر أسهل ولكنها توفر خصوصية أقل.
3. الاعتبارات العملية والمنافسة
يجب على الكيانات المنظمة التي تقبل الأصول المشفرة التأكد من أن القوانين واللوائح التي تخضع لها تسمح بقبول هذه الأموال. واليوم، تعتمد العديد من هذه الكيانات على ما يسمى بأدوات فحص المعاملات: البرامج أو الخدمات التي تحلل سلسلة الكتل لتحديد الأنشطة المشبوهة المحتملة، أو الروابط إلى عناوين غير مشروعة، أو غيرها من المعاملات غير المتوافقة. غالبًا ما تعبر أدوات الفحص عن المخاطر المرتبطة بكل عملية تداول من خلال درجة المخاطر. يعتمد هذا التصنيف على وجهة الأموال المحولة وتاريخ معاملاتها. قد تشكل بروتوكولات تعزيز الخصوصية تحديات في هذا الصدد. إنها تقضي على الرابط المرئي بين الودائع والسحوبات. ولذلك، في ظل وجود بروتوكولات تعزيز الخصوصية، يجب أن تأخذ درجة المخاطرة الشهادة في الاعتبار وتعيين درجة بناءً على مجموعة الارتباطات.
يتم توفير الأدوات والخدمات لفحص المعاملات بشكل أساسي من قبل الشركات المهنية ذات الخبرة في تحليل blockchain والمجالات القانونية ذات الصلة. ومن الناحية المثالية، سيكون لهذه الشركات (وأي شخص آخر) حق الوصول إلى جميع إثباتات العضوية والمجموعات المرتبطة بها من أجل توفير درجة مخاطر دقيقة لجميع المعاملات. لذلك، نوصي بتخزين جميع البراهين على blockchain أو أي مستودع إثبات آخر يمكن الوصول إليه بشكل عام. الاستثناء الوحيد هو شهادة العضوية ذات الحجم الأول المشتركة مع طرف مقابل محدد. ولأسباب واضحة، لا ينبغي أن تكون هذه الشهادات متاحة للعامة.
يؤدي تخزين الأدلة مباشرة على السلسلة إلى إضافة تكاليف معاملات إضافية، ولكنه يقلل من جهود التنسيق، ويجعل المنافسة أكثر عدالة، ويخفف من مخاطر شبه الاحتكار التي قد ينشئها مقدمو أدوات الفحص بسبب المعرفة بالأدلة غير العامة.
الإعداد العام لتجمع الخصوصية مرن للغاية. ومن خلال إنشاء مجموعة محددة من الارتباطات، يمكن تصميم البروتوكول ليناسب حالات الاستخدام المختلفة. فيما يلي مثالان لمجموعات الارتباطات الخاصة هذه:
● **يمكن لاتحاد الخدمات المصرفية التجارية إنشاء مجموعة مرتبطة تحتوي فقط على الودائع من عملائه. **يضمن هذا أن إثبات أي عمليات سحب تم إنشاؤها للتحصيل قد خضع لإجراءات اعرف عميلك (KYC) ومكافحة غسيل الأموال (AML) في أحد البنوك المشاركة، ولكنه لا يكشف عن عملية السحب التي تعود إلى أي عميل.
● **في الحالات التي يُطلب فيها من الوسطاء الماليين توثيق مصدر الأموال بشكل واضح، يمكنهم مطالبة المستخدمين بتقديم دليل ضد مجموعة مرتبطة تحتوي فقط على ودائع المستخدمين. **سيتم بعد ذلك تبادل هذا الدليل بشكل ثنائي مع الوسيط، مما يسمح له بتتبع الأموال كما لو أن المستخدم لم يستخدم مجمع الخصوصية مطلقًا. في حين أن هذا يتطلب من المستخدمين أن يثقوا في الوسيط حتى لا يكشف عن الأدلة، فإنه يمكّن المستخدمين من الالتزام باللوائح دون الحاجة إلى الكشف عن المعلومات للجمهور.
4. خيارات التصميم والبدائل
تتميز الإعدادات المستندة إلى مجموعات الارتباطات وإثباتات zk والإفصاحات الطوعية بالمرونة. وفي حين أن هذا مفيد جدًا في ضمان إمكانية تكييف الاقتراح مع ولايات قضائية مختلفة، إلا أنه يجب توخي الحذر الشديد فيما يتعلق بخيارات التصميم المحددة. وعلى وجه الخصوص، هناك نوعان من التعديلات المحتملة التي نعارضها. نعتقد أنها تمثل مشكلة من حيث متطلبات الثقة وقد تؤدي إلى إنشاء هياكل سوقية شبه احتكارية. فيما يلي وصف موجز لهذه البدائل ومناقشتها:
● الوصول المركزي: يمكن لوكالات إنفاذ القانون أو موفري نتائج مخاطر العملات المشفرة أو الجهات الفاعلة المماثلة الوصول لعرض الروابط بين معاملات المستخدم مع الحفاظ على الخصوصية من الآخرين.
● **القائمة البيضاء على مستوى النظام: **يمكن لأنظمة الخصوصية وضع قيود على أنواع المستخدمين الذين يمكنهم إيداع العملات المعدنية في مجموعاتهم، مما يتطلب منهم تقديم دليل إضافي أو مطالبة الودائع بالانتظار لفترة من الوقت يتم خلالها تسجيل المخاطر بشكل مركزي يمكن للنظام رفض الودائع.
تتشابه الطريقتان من حيث أنهما تمنحان امتيازات لكيانات محددة. وهذا يثير أسئلة معقدة تتعلق بالحوكمة: من يمكنه الوصول إلى هذه المعلومات؟ من لديه القدرة على إدارة الأذونات؟ ولا يبدو أن الشركات الخاصة تمثل خيارا جيدا، لأن أي امتيازات قد تخلق هيكل سوق احتكار القلة، حيث تتمتع قِلة من الشركات بإمكانية الوصول إلى البيانات التي تمكنها من تقديم هذه الخدمات، في حين أن شركات أخرى غير قادرة على المنافسة.
وعلى نحو مماثل، سوف نواجه العديد من قضايا الحكم والقضايا السياسية عند تفويض السلطات إلى المؤسسات العامة، وخاصة في السياقات الدولية. وحتى لو كانت المؤسسة جديرة بالثقة بنسبة 100% حتى الآن، ولا تستغل سلطتها لتحقيق أجندة سياسية، ولا تعتمد على كيانات أخرى قد تجبرها على إساءة استخدام سلطتها، فإن هذا الوضع يدل على حالة هادئة. مع مرور الوقت، تتغير المنظمات والأعضاء والبلدان والهياكل السياسية داخل المنظمات. وقد تكون هناك ضغوط خارجية وقد يؤدي وجود هذه الامتيازات إلى خلق حوافز إضافية لتعطيل نظام حوكمة المنظمة وكسب النفوذ عليه.
بالإضافة إلى ذلك، يمكن أن يكون للهجمات داخل المنظمة أو خارجها، أو الأخطاء نيابة عن كيان مركزي، عواقب بعيدة المدى. ونعتقد أنه ينبغي منع إنشاء مثل هذه النقاط المركزية للفشل.
ومع ذلك، فإننا ندرك أن أحجام المعاملات المختلفة والمواقف قد تتطلب مجموعات مختلفة من الأدلة. على سبيل المثال، بالنسبة للمعاملات الكبيرة، قد ينتهي الأمر بالعديد من المستخدمين إلى تقديم دليل أساسي على الاستبعاد على السلسلة وتقديم معلومات أكثر تفصيلاً حول مصدر الأموال إلى الأطراف المقابلة.
5. اتجاه البحث المتعمق
في حين تقدم هذه الدراسة لمحة عامة عن كيفية استخدام بروتوكولات تعزيز الخصوصية المستندة إلى zkSNARK في البيئات المنظمة، هناك العديد من الجوانب التي تستحق المزيد من البحث.
أولاً، يجب على الجميع أن يدركوا أن الخصوصية التي يتم تحقيقها من خلال هذه البروتوكولات تعتمد على العديد من العوامل المختلفة. قد يتمكن المهاجم من ربط عمليات السحب بودائع محددة بناءً على مجموعة ارتباطات كبيرة غير كافية، واختيار جذر سيئ، وخطأ المستخدم.
بالإضافة إلى ذلك، قد تؤثر اختيارات المستخدمين الآخرين سلبًا على خصوصيتك. في الحالات القصوى، يصدر كل فرد آخر في المجمع إثبات عضوية من الحجم الأول، مما يكشف عن وجود صلة مباشرة بين إيداعاتهم وسحوباتهم. من الواضح أن هذا سيكشف ضمنيًا عن العلاقة بين معاملات الإيداع والسحب الوحيدة المتبقية. في مثال أكثر دقة، يمكن استخدام القيود من أدلة العضوية المختلفة لاستخراج المعلومات وربما ربط الودائع والسحوبات باحتمالية عالية. بمجرد دمج هذه المعلومات المعتمدة مع بيانات تعريف المعاملة، قد تتعرض خصائص الخصوصية للبروتوكول للخطر.
أخيرًا، يمكن أن يختار ASP الخبيث تجميع مجموعة الارتباط المقترحة بطريقة تسمح له بتعظيم استخراج المعلومات أو زيادة عدم الكشف عن هويته عن طريق إضافة الودائع حيث تكون عمليات السحب المقابلة معروفة. تتطلب كل هذه المشكلات مزيدًا من البحث لتقييم خصائص الخصوصية المتوفرة. وعلى نفس المنوال، سيكون من المثير للاهتمام مواصلة التحقيق في خصائص التوازنات المنفصلة، ووضع نماذج لكيفية تصرف اللاعبين الجيدين والسيئين في ظل افتراضات معينة وكيف يؤثر الدليل العام على الأول على خصوصية الأخير.
يمكن للخبراء القانونيين إجراء المزيد من الأبحاث حول متطلبات الإفصاح المحددة. يتسم المخطط المقترح في هذه المقالة بالمرونة، ويمكن أن تساعد الرؤى المقدمة من الخبراء القانونيين في تصميم الاتفاقية والنظام البيئي المبني حولها لضمان الامتثال في مختلف الولايات القضائية القانونية.
6. الاستنتاج
في كثير من الحالات، تعتبر الخصوصية والامتثال متعارضتين مع بعضهما البعض. تقترح هذه الورقة أن هذا ليس هو الحال بالضرورة إذا كان بروتوكول تعزيز الخصوصية يمكّن المستخدمين من إثبات خصائص معينة لمصدر أموالهم. على سبيل المثال، من المفترض أن يتمكن المستخدمون من إثبات أن أموالهم ليست مرتبطة بودائع من مصادر غير مشروعة معروفة، أو أن الأموال جزء من مجموعة محددة من الودائع، دون الكشف عن أي معلومات إضافية.
مثل هذا الإعداد يمكن أن ينتج توازنًا منفصلاً حيث يتم تحفيز المستخدمين الصادقين بقوة لإثبات أنهم ينتمون إلى مجموعة ترابطية متوافقة ويحافظون على الخصوصية داخل تلك المجموعة. وفي المقابل، بالنسبة للمستخدمين غير الشرفاء، لا يمكنهم تقديم مثل هذا الدليل. وهذا يمكّن المستخدمين الصادقين من فصل أنفسهم عن ودائع الطرف الثالث الذين لا يتفقون معها، أو منعهم من استخدام أموالهم في بيئة متوافقة. نعتقد أن الاقتراح مرن ويمكن تكييفه مع المتطلبات التنظيمية المختلفة المحتملة.
ينبغي اعتبار هذه الورقة مساهمة في التعايش المستقبلي المحتمل بين الخصوصية والتنظيم المالي. نريد تسهيل المناقشات وتوجيه المحادثة في اتجاه أكثر إيجابية وبناءة. وسوف يتطلب الأمر التعاون بين الممارسين والأكاديميين في مختلف التخصصات وصناع السياسات والجهات التنظيمية لتوسيع هذا الاقتراح وتعديله؛ والهدف النهائي هو إنشاء بنية تحتية معززة للخصوصية يمكن استخدامها في بيئة منظمة.