> يجمع المطور ameen.eth بين مفهوم "إثبات البراءة" مع Tornado Cash لتقديم اتجاه آخر مفاده أن "الخصوصية لا تساوي الجريمة".
** بقلم: ألبرت لين **
مقدمة
TornadoCash هي خدمة معاملات مجهولة معروفة في عالم العملات المشفرة. تستخدم TornadoCash تقنية ZKP (Zero-Knowledge Proof) لإخفاء مصدر الأموال. جادلت الحكومة الأمريكية بأن مثل هذه الآلية سهلت أنشطة التدفق المالي غير المشروع ، وفي النهاية تم فرض عقوبات عليها من قبل وزارة الخزانة الأمريكية في أغسطس 2022 وأجبرت على إزالتها من على الرفوف. يبدو أن حماية الخصوصية وغسيل الأموال يسيران جنبًا إلى جنب في كثير من الحالات. أثناء السعي وراء الخصوصية ، غالبًا ما يستخدم المجرمون ميزات الخصوصية هذه لغسل الأموال غير المشروعة. هل يمكن إيجاد طريقة تتيح للأفراد التمتع بالخصوصية مع الحد من غسيل الأموال بشكل فعال؟ قد تعطي Privacy-Pools من قبل ameen.eth ، المطور المبكر لـ TornadoCash ، توجيهًا. (يتأثر فقط موقع الويب للواجهة الأمامية ومستودع GitHub لجزء الشطب ، ولا يتأثر جزء العقد لأنه موجود على blockchain. وأخيرًا ، أعاد GitHub المستودع تحت جهود Electronic Frontier Foundation. للحصول على التفاصيل ، من فضلك الرجوع إلى هنا)
مقدمة مبدأ تورنادو كاش
قبل تقديم مجموعات الخصوصية ، يجب أن تفهم مبادئ التصميم المتعلقة بـ TornadoCash. للحصول على مقدمة مفصلة ، يرجى الرجوع إلى مقالتي السابقة "تفكيك تورنادو كاش: دليل المبتدئين لشرح وظيفتها للأصدقاء". فيما يلي استعراض موجز لمبادئ تصميم TornadoCash.
تستخدم TornadoCash الإيصالات (الالتزامات) للتحكم في الوصول. يتم إنشاء الإيصال عن طريق تجزئة السر (القيمة السرية) والمُبطل (رمز الخروج) ، ولا يمكن سحب كل إيصال إلا مرة واحدة. استخدم Merkle Tree (شجرة التجزئة) لتسجيل معلومات الإيداع ، واستخدم الإيصال كعقدة ورقية وحساب Merkle Root (جذر شجرة التجزئة). يحتاج المستخدم فقط إلى توفير البيانات من الورقة إلى الجذر لإثبات ما إذا كانت البيانات إحدى أوراق Merkle Tree ، وإثبات بشكل غير مباشر أنه كان هناك أموال مودعة في TornadoCash من قبل. استخدم Zero-Knowledge Proof لإخفاء مصدر الإيداع ، واستخدم nullifier لمنع هجوم السحب المزدوج.
** إيصال تورنادو كاش له معنيان **
إثبات أن المرسل قد أودع الأموال من قبل
تأكد من أن كل مستلم يمكنه المطالبة بالأموال مرة واحدة فقط
「إثبات البراءة」
وفقًا لمبدأ تصميم TornadoCash ، يمكن فقط معرفة أن الأموال المستلمة يجب أن تأتي من وديعة سابقة ، ولكن لا يُعرف الإيداع الذي أتت منه. هذا هو الغرض الرئيسي للمجرمين الذين يستخدمون TornadoCash في أنشطة غسيل الأموال غير القانونية ، وهو أيضًا السبب الذي يجعل الحكومة الأمريكية تنظم TornadoCash. إذا تمكنا من اقتراح إثبات آخر (ZKP) لإثبات أن الأموال المستلمة ليست من الإيداعات المدرجة في قائمة الرفض ، وما إذا كان يمكن إثبات أن الدفعة ليست من المجرمين ، فهذا هو "إثبات البراءة" ("إثبات البراءة ") المفهوم الأساسي.
** يمكن تقسيم مفهوم "إثبات البراءة" إلى اتجاهين **
دليل على أن الأموال الواردة هي من تحصيل الأموال المودعة في القائمة المسموح بها (القائمة المسموح بها)
دليل على أن الأموال التي يتم سحبها لم تأت من مجموعة الأموال المودعة في قائمة الرفض (قائمة الرفض)
كلتا الطريقتين يمكن أن تثبت أن أموال السحب ليست من الودائع في قائمة الرفض. النهج الموضح في الشكل أدناه هو استخدام قائمة الرفض لإثبات أن الأموال المستلمة لا تأتي من الإيداع (الأحمر) في قائمة الرفض.
مصدر:
مبدأ تصميم مجمعات الخصوصية
يضيف Privacy-Pools مفهوم "إثبات البراءة" إلى TornadoCash. بالإضافة إلى المعنى الأصلي لإيصال TorandoCash ، فإن إيصال دفع Privacy-Pools له معنى ثالث: "إثبات أن الأموال المستلمة تأتي من الإيداعات في القائمة المسموح بها".
إيصال مجموعات الخصوصية يعني:
إثبات أن المرسل قد أودع الأموال من قبل
تأكد من أن كل مستلم يمكنه المطالبة بالأموال مرة واحدة فقط
دليل على أن الأموال المراد سحبها تأتي من الودائع في القائمة المسموح بها
نستخدم هنا Allow Merkle Tree لشرح كيفية استخدام Privacy-Pools لـ "Proof-of-Innocence" في هذا النظام (Allow Merkle Tree هو مفهوم استخدام قائمة الأذونات). بادئ ذي بدء ، يتميز برنامج Allow Merkle Tree بعدة خصائص
السماح لـ Merkle Tree كما يوحي الاسم هو Merkle Tree
ارتفاع الشجرة وعدد العقد متماثلان مع Deposit Merkle Tree of Privacy-Pools.
تتوافق جميع أوراق Allow Merkle Tree مع موضع ورقة (إيداع) Deposit Merkle Tree.
يمكن تقسيم بيانات Allow Merkle Tree Leaf إلى الفئتين التاليتين:
مسموح: يشير إلى أن الإيداع في هذا الموقع مسموح به. (المراكز التي لم يتم إيداعها بعد مسموح بها أيضًا بشكل افتراضي)
محظور: يشير إلى أن الإيداع في هذا الموقع مرفوض.
كما هو مبين في الشكل أدناه ، فإن وضعي الفهرس 0 و 1 عبارة عن أموال قانونية في Deposit Merkle Tree ، كما يُسمح أيضًا بالمواقف المقابلة لورقة Allow Merkle Tree.
بافتراض أن المجرم اليوم يريد القيام بأنشطة غسيل الأموال ، فإنه يودع الأموال غير المشروعة التي تم الحصول عليها بعد الهجوم في مجمعات الخصوصية ، وموقع الإيداع هو Deposit Merkle Tree index: 2. نحن نعلم أنها أموال غير مشروعة ، لذلك نقوم بتحديثها للحظر في مركز Allow Merkle Tree المقابل: 2.
حالة جمع قائمة الأذونات
بافتراض أن المستخدم الذي يودع اليوم في القائمة المسموح بها للحكومة الأمريكية يريد سحب الأموال ، فإنه يحتاج إلى تقديم "دليل على أن الإيداع موجود في Dposit Merkle Tree" و "دليل على أن الشخص الموجود في قائمة الولايات المتحدة المسموح بها مسموح به". يتضمن الدليل المطابق لقائمة سماح الولايات المتحدة Allow Merkle Root (المقدم من المستخدم ، والجذر الفرعي في الكود) وقيمة العقدة التي سيتم تمريرها في الطريق. عندما تتحقق Privacy-Pools من مرحلة ZKP ، ستستخدم قيمة الورقة على النحو المسموح به (keccak256 (مسموح به) في الكود الفعلي) وقيمة العقدة المحددة لتمريرها لإنشاء جذر Merkle. تحقق من أن Merkle Root هذا هو نفسه Allow Merkle Root الذي يوفره المستخدم. إذا تم تمرير التحقق من نفس الممثل ، فهذا يعني أن صندوق السحب من وديعة موجودة في قائمة تصاريح حكومة الولايات المتحدة.
حالة جمع قائمة الرفض
اليوم ، يريد المستخدم غير المدرج في القائمة المسموح بها للحكومة الأمريكية سحب الأموال ، ويتم وضع علامة على موقع الإيداع المقابل على أنه محظور في قائمة الحكومة الأمريكية المسموح بها. سيؤدي هذا إلى عدم قدرة المستخدم على استخدام Allow Merkle Root في قائمة أذونات حكومة الولايات المتحدة لسحب الأموال ، لأنه لا يمكن إنشاء الدليل المقابل وسيفشل التحقق (لأن Privacy-Pools تستخدم قيمة المسموح بها للورقة الحسابات ، وستكون قائمة أذونات الحكومة الأمريكية هي الموقع الذي تم تمييزه على أنه محظور ، لذلك لا يمكن حساب نفس Merkle Root).
يفرض مثل هذا التصميم على المستخدم تقديم اسم آخر لـ Merkle Root لسحب الأموال (تحتاج أخرى Allow Merkle Trees إلى تحديد موقع الإيداع على النحو المسموح به من أجل حساب نفس السماح لـ Merkle Root بتمرير التحقق). قد يتم الحفاظ على هذا Allow Merkle Tree الآخر من قبل الحكومات أو المؤسسات الأخرى ، أو حتى يتم إنشاؤه بواسطة هذا المستخدم نفسه. اليوم ، يمكن للحكومة الأمريكية استخدام Allow Merkle Root المستخدم عند السحب لتحديد ما إذا كانت أموال المستخدم تتوافق مع قوانين ولوائح حكومة الولايات المتحدة ، وذلك لتحقيق الغرض من التتبع. إذا كان المستخدم يستخدم Allow Merkle Tree الذي أنشأه بنفسه أو غير موثوق به ، فمن المحتمل جدًا أن يأتي صندوق السحب من وديعة إشكالية (كل طرف ثالث موثوق به Allow Merkle Tree يشير إلى موقع الإيداع على أنه محظور).
أسئلة مكررة
** س: إذا تم توفير Allowroot من قبل المنسحب ، فهل من الممكن تزوير مزيف السماح لـ Merkle Root لإثبات أن الورقة هي وديعة في القائمة المسموح بها ، هل هذا يعني أنه لا يزال من الممكن سحب الأموال؟ **
** ج: ** الجواب نعم ، من الممكن بالفعل أخذ المال. وأشار المؤلف على وجه التحديد إلى أن مثل هذه الآلية ليست منع المجرمين من أخذ الأموال ، ولكن حتى لو تمكنوا من أخذها ، فسيكون معروفًا أن الأموال هي أموال على قائمة الرفض. عندما يقدم المنسحب عرضًا غير مقنع لـ Allow Merkle Root ، يمكن اعتباره بشكل أساسي منسحبًا من قائمة الرفض. يعتقد المؤلف أن سبب السماح بذلك هو الحفاظ على الطبيعة اللامركزية لهذه الخدمة. لأن كل برنامج Allow Merkle Tree يحتاج إلى إدارة سلطة معينة لتحديث حالة كل طرف. إذا كان جذر شجرة معين إلزاميًا ، فهذا يعني أن شخصًا ما لديه سلطة معينة للتحكم في سحب الأموال ، وهو ما لا يتماشى مع روح اللامركزية.
** س: من سيقرر ما إذا كانت المعاملة من أموال القائمة المرفوضة؟ **
** ج: ** الجزء الذي رأيته لم يذكر على وجه التحديد ، وما أفهمه هو أن هذا الجزء يجب أن تقوم به كل وكالة تنظيمية. بافتراض أن حكومة الولايات المتحدة تريد اليوم التحقق من أموال Privacy-Pools القذرة ، يمكنه التحقق مما إذا كان أموالًا قذرة عن طريق التحقق من Allow Merkle Root لكل معاملة. بالنسبة لنوع السماح لـ Merkle Root المسموح به ، هذا لكل وكالة تنظيمية للحكم بنفسها.
الخصوصية - رمز تجمعات
الكود الرئيسي وتعليقات المؤلف مرفقة هنا ، على أمل مساعدة الجميع على فهم المنطق الرئيسي من خلال الكود.
// دوائر / سحب \ _من \ _ فرعية.سيركوم
template WithdrawFromSubset (المستويات ، القيمة المتوقعة) {
// عام
جذر إدخال الإشارة ؛
مجموعة فرعية لإدخال الإشارة
مبطل إدخال إشارة ؛
أصول مدخلات الإشارة // abi.encode (رمز ، مبلغ) .snarkHash () ؛
مسار إدخال الإشارة // وضح ما إذا كانت البيانات تمثل الجزء الأيسر أو الجانب الأيمن.
إدخال إشارة رئيسيةدليل [levels] ؛ // إنشاء البيانات المطلوبة لجذر الإيداع.
مجموعة فرعية لإدخال الإشارة [levels] ؛ // بناء البيانات المطلوبة للسماح الجذر.
// حساب المبطل والالتزام.
تجزئة المكون = CommitmentNullifierHasher () ،
hasher.secret <== secret؛
hash.path <== مسار ؛
hasher.assetMetadata <== assetMetadata ؛
المبطل === hasher.nullifier ؛
// المتوقعةValue: keccak256 ("المسموح بها")٪ p
المكون doubleTree = DoubleMerkleProof (المستويات ، القيمة المتوقعة) ؛
doubleTree.leaf <== hasher.commitment ؛
// قم بتحويل المسار إلى بتات لتحديد ما إذا كانت الورقة اليسرى أو الجهة اليمنى.
// يمكن ملاحظة أن شجرة الإيداع والسماح للشجرة تشترك في نفس المسار.
doubleTree.path <== مسار ؛
لـ (i = 0 ؛ i المرجع:
> عنوان متخفي
> تحليل مثيل Tornado Cash
> مقدمة لتطوير ZKP والعقود الذكية
> [ZKP Reading Club] تورنادو كاش
> تورنادو كاش - كيف يعمل | DeFi + إثبات المعرفة الصفرية
> فهم متعمق لتفاصيل تورنادو كاش الفنية
> 0xhhh Thread إدخال ميزات جديدة ومبادئها
> فيديو تجريبي
> حديث فيتاليك حول كيفية تحسين تورنادوف 2
> حمامات الخصوصية v0tweet
> تقديم إثبات البراءة المبني على TornadoCash
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
اشرح مبدأ تصميم Tornado Cash V2 بالتفصيل
> يجمع المطور ameen.eth بين مفهوم "إثبات البراءة" مع Tornado Cash لتقديم اتجاه آخر مفاده أن "الخصوصية لا تساوي الجريمة".
** بقلم: ألبرت لين **
مقدمة
TornadoCash هي خدمة معاملات مجهولة معروفة في عالم العملات المشفرة. تستخدم TornadoCash تقنية ZKP (Zero-Knowledge Proof) لإخفاء مصدر الأموال. جادلت الحكومة الأمريكية بأن مثل هذه الآلية سهلت أنشطة التدفق المالي غير المشروع ، وفي النهاية تم فرض عقوبات عليها من قبل وزارة الخزانة الأمريكية في أغسطس 2022 وأجبرت على إزالتها من على الرفوف. يبدو أن حماية الخصوصية وغسيل الأموال يسيران جنبًا إلى جنب في كثير من الحالات. أثناء السعي وراء الخصوصية ، غالبًا ما يستخدم المجرمون ميزات الخصوصية هذه لغسل الأموال غير المشروعة. هل يمكن إيجاد طريقة تتيح للأفراد التمتع بالخصوصية مع الحد من غسيل الأموال بشكل فعال؟ قد تعطي Privacy-Pools من قبل ameen.eth ، المطور المبكر لـ TornadoCash ، توجيهًا. (يتأثر فقط موقع الويب للواجهة الأمامية ومستودع GitHub لجزء الشطب ، ولا يتأثر جزء العقد لأنه موجود على blockchain. وأخيرًا ، أعاد GitHub المستودع تحت جهود Electronic Frontier Foundation. للحصول على التفاصيل ، من فضلك الرجوع إلى هنا)
مقدمة مبدأ تورنادو كاش
قبل تقديم مجموعات الخصوصية ، يجب أن تفهم مبادئ التصميم المتعلقة بـ TornadoCash. للحصول على مقدمة مفصلة ، يرجى الرجوع إلى مقالتي السابقة "تفكيك تورنادو كاش: دليل المبتدئين لشرح وظيفتها للأصدقاء". فيما يلي استعراض موجز لمبادئ تصميم TornadoCash.
تستخدم TornadoCash الإيصالات (الالتزامات) للتحكم في الوصول. يتم إنشاء الإيصال عن طريق تجزئة السر (القيمة السرية) والمُبطل (رمز الخروج) ، ولا يمكن سحب كل إيصال إلا مرة واحدة. استخدم Merkle Tree (شجرة التجزئة) لتسجيل معلومات الإيداع ، واستخدم الإيصال كعقدة ورقية وحساب Merkle Root (جذر شجرة التجزئة). يحتاج المستخدم فقط إلى توفير البيانات من الورقة إلى الجذر لإثبات ما إذا كانت البيانات إحدى أوراق Merkle Tree ، وإثبات بشكل غير مباشر أنه كان هناك أموال مودعة في TornadoCash من قبل. استخدم Zero-Knowledge Proof لإخفاء مصدر الإيداع ، واستخدم nullifier لمنع هجوم السحب المزدوج.
** إيصال تورنادو كاش له معنيان **
「إثبات البراءة」
وفقًا لمبدأ تصميم TornadoCash ، يمكن فقط معرفة أن الأموال المستلمة يجب أن تأتي من وديعة سابقة ، ولكن لا يُعرف الإيداع الذي أتت منه. هذا هو الغرض الرئيسي للمجرمين الذين يستخدمون TornadoCash في أنشطة غسيل الأموال غير القانونية ، وهو أيضًا السبب الذي يجعل الحكومة الأمريكية تنظم TornadoCash. إذا تمكنا من اقتراح إثبات آخر (ZKP) لإثبات أن الأموال المستلمة ليست من الإيداعات المدرجة في قائمة الرفض ، وما إذا كان يمكن إثبات أن الدفعة ليست من المجرمين ، فهذا هو "إثبات البراءة" ("إثبات البراءة ") المفهوم الأساسي.
** يمكن تقسيم مفهوم "إثبات البراءة" إلى اتجاهين **
كلتا الطريقتين يمكن أن تثبت أن أموال السحب ليست من الودائع في قائمة الرفض. النهج الموضح في الشكل أدناه هو استخدام قائمة الرفض لإثبات أن الأموال المستلمة لا تأتي من الإيداع (الأحمر) في قائمة الرفض.
مبدأ تصميم مجمعات الخصوصية
يضيف Privacy-Pools مفهوم "إثبات البراءة" إلى TornadoCash. بالإضافة إلى المعنى الأصلي لإيصال TorandoCash ، فإن إيصال دفع Privacy-Pools له معنى ثالث: "إثبات أن الأموال المستلمة تأتي من الإيداعات في القائمة المسموح بها".
إيصال مجموعات الخصوصية يعني:
نستخدم هنا Allow Merkle Tree لشرح كيفية استخدام Privacy-Pools لـ "Proof-of-Innocence" في هذا النظام (Allow Merkle Tree هو مفهوم استخدام قائمة الأذونات). بادئ ذي بدء ، يتميز برنامج Allow Merkle Tree بعدة خصائص
يمكن تقسيم بيانات Allow Merkle Tree Leaf إلى الفئتين التاليتين:
كما هو مبين في الشكل أدناه ، فإن وضعي الفهرس 0 و 1 عبارة عن أموال قانونية في Deposit Merkle Tree ، كما يُسمح أيضًا بالمواقف المقابلة لورقة Allow Merkle Tree.
بافتراض أن المجرم اليوم يريد القيام بأنشطة غسيل الأموال ، فإنه يودع الأموال غير المشروعة التي تم الحصول عليها بعد الهجوم في مجمعات الخصوصية ، وموقع الإيداع هو Deposit Merkle Tree index: 2. نحن نعلم أنها أموال غير مشروعة ، لذلك نقوم بتحديثها للحظر في مركز Allow Merkle Tree المقابل: 2.
حالة جمع قائمة الأذونات
بافتراض أن المستخدم الذي يودع اليوم في القائمة المسموح بها للحكومة الأمريكية يريد سحب الأموال ، فإنه يحتاج إلى تقديم "دليل على أن الإيداع موجود في Dposit Merkle Tree" و "دليل على أن الشخص الموجود في قائمة الولايات المتحدة المسموح بها مسموح به". يتضمن الدليل المطابق لقائمة سماح الولايات المتحدة Allow Merkle Root (المقدم من المستخدم ، والجذر الفرعي في الكود) وقيمة العقدة التي سيتم تمريرها في الطريق. عندما تتحقق Privacy-Pools من مرحلة ZKP ، ستستخدم قيمة الورقة على النحو المسموح به (keccak256 (مسموح به) في الكود الفعلي) وقيمة العقدة المحددة لتمريرها لإنشاء جذر Merkle. تحقق من أن Merkle Root هذا هو نفسه Allow Merkle Root الذي يوفره المستخدم. إذا تم تمرير التحقق من نفس الممثل ، فهذا يعني أن صندوق السحب من وديعة موجودة في قائمة تصاريح حكومة الولايات المتحدة.
حالة جمع قائمة الرفض
اليوم ، يريد المستخدم غير المدرج في القائمة المسموح بها للحكومة الأمريكية سحب الأموال ، ويتم وضع علامة على موقع الإيداع المقابل على أنه محظور في قائمة الحكومة الأمريكية المسموح بها. سيؤدي هذا إلى عدم قدرة المستخدم على استخدام Allow Merkle Root في قائمة أذونات حكومة الولايات المتحدة لسحب الأموال ، لأنه لا يمكن إنشاء الدليل المقابل وسيفشل التحقق (لأن Privacy-Pools تستخدم قيمة المسموح بها للورقة الحسابات ، وستكون قائمة أذونات الحكومة الأمريكية هي الموقع الذي تم تمييزه على أنه محظور ، لذلك لا يمكن حساب نفس Merkle Root).
يفرض مثل هذا التصميم على المستخدم تقديم اسم آخر لـ Merkle Root لسحب الأموال (تحتاج أخرى Allow Merkle Trees إلى تحديد موقع الإيداع على النحو المسموح به من أجل حساب نفس السماح لـ Merkle Root بتمرير التحقق). قد يتم الحفاظ على هذا Allow Merkle Tree الآخر من قبل الحكومات أو المؤسسات الأخرى ، أو حتى يتم إنشاؤه بواسطة هذا المستخدم نفسه. اليوم ، يمكن للحكومة الأمريكية استخدام Allow Merkle Root المستخدم عند السحب لتحديد ما إذا كانت أموال المستخدم تتوافق مع قوانين ولوائح حكومة الولايات المتحدة ، وذلك لتحقيق الغرض من التتبع. إذا كان المستخدم يستخدم Allow Merkle Tree الذي أنشأه بنفسه أو غير موثوق به ، فمن المحتمل جدًا أن يأتي صندوق السحب من وديعة إشكالية (كل طرف ثالث موثوق به Allow Merkle Tree يشير إلى موقع الإيداع على أنه محظور).
أسئلة مكررة
** س: إذا تم توفير Allowroot من قبل المنسحب ، فهل من الممكن تزوير مزيف السماح لـ Merkle Root لإثبات أن الورقة هي وديعة في القائمة المسموح بها ، هل هذا يعني أنه لا يزال من الممكن سحب الأموال؟ **
** ج: ** الجواب نعم ، من الممكن بالفعل أخذ المال. وأشار المؤلف على وجه التحديد إلى أن مثل هذه الآلية ليست منع المجرمين من أخذ الأموال ، ولكن حتى لو تمكنوا من أخذها ، فسيكون معروفًا أن الأموال هي أموال على قائمة الرفض. عندما يقدم المنسحب عرضًا غير مقنع لـ Allow Merkle Root ، يمكن اعتباره بشكل أساسي منسحبًا من قائمة الرفض. يعتقد المؤلف أن سبب السماح بذلك هو الحفاظ على الطبيعة اللامركزية لهذه الخدمة. لأن كل برنامج Allow Merkle Tree يحتاج إلى إدارة سلطة معينة لتحديث حالة كل طرف. إذا كان جذر شجرة معين إلزاميًا ، فهذا يعني أن شخصًا ما لديه سلطة معينة للتحكم في سحب الأموال ، وهو ما لا يتماشى مع روح اللامركزية.
** س: من سيقرر ما إذا كانت المعاملة من أموال القائمة المرفوضة؟ **
** ج: ** الجزء الذي رأيته لم يذكر على وجه التحديد ، وما أفهمه هو أن هذا الجزء يجب أن تقوم به كل وكالة تنظيمية. بافتراض أن حكومة الولايات المتحدة تريد اليوم التحقق من أموال Privacy-Pools القذرة ، يمكنه التحقق مما إذا كان أموالًا قذرة عن طريق التحقق من Allow Merkle Root لكل معاملة. بالنسبة لنوع السماح لـ Merkle Root المسموح به ، هذا لكل وكالة تنظيمية للحكم بنفسها.
الخصوصية - رمز تجمعات
الكود الرئيسي وتعليقات المؤلف مرفقة هنا ، على أمل مساعدة الجميع على فهم المنطق الرئيسي من خلال الكود.
// دوائر / سحب \ _من \ _ فرعية.سيركوم
template WithdrawFromSubset (المستويات ، القيمة المتوقعة) {
// عام
جذر إدخال الإشارة ؛
مجموعة فرعية لإدخال الإشارة
مبطل إدخال إشارة ؛
أصول مدخلات الإشارة // abi.encode (رمز ، مبلغ) .snarkHash () ؛
سحب إدخال الإشارة // abi.encode (مستلم ، استرداد ، ترحيل ، رسوم) .snarkHash () ؛
// خاص
سر إدخال الإشارة ؛
مسار إدخال الإشارة // وضح ما إذا كانت البيانات تمثل الجزء الأيسر أو الجانب الأيمن.
إدخال إشارة رئيسيةدليل [levels] ؛ // إنشاء البيانات المطلوبة لجذر الإيداع.
مجموعة فرعية لإدخال الإشارة [levels] ؛ // بناء البيانات المطلوبة للسماح الجذر.
// حساب المبطل والالتزام.
تجزئة المكون = CommitmentNullifierHasher () ،
hasher.secret <== secret؛
hash.path <== مسار ؛
hasher.assetMetadata <== assetMetadata ؛
المبطل === hasher.nullifier ؛
// المتوقعةValue: keccak256 ("المسموح بها")٪ p
المكون doubleTree = DoubleMerkleProof (المستويات ، القيمة المتوقعة) ؛
doubleTree.leaf <== hasher.commitment ؛
// قم بتحويل المسار إلى بتات لتحديد ما إذا كانت الورقة اليسرى أو الجهة اليمنى.
// يمكن ملاحظة أن شجرة الإيداع والسماح للشجرة تشترك في نفس المسار.
doubleTree.path <== مسار ؛
لـ (i = 0 ؛ i المرجع:
> عنوان متخفي
> تحليل مثيل Tornado Cash
> مقدمة لتطوير ZKP والعقود الذكية
> [ZKP Reading Club] تورنادو كاش
> تورنادو كاش - كيف يعمل | DeFi + إثبات المعرفة الصفرية
> فهم متعمق لتفاصيل تورنادو كاش الفنية
> 0xhhh Thread إدخال ميزات جديدة ومبادئها
> فيديو تجريبي
> حديث فيتاليك حول كيفية تحسين تورنادوف 2
> حمامات الخصوصية v0tweet
> تقديم إثبات البراءة المبني على TornadoCash