مقدمة: مؤخرًا، قام فيتاليك وبعض العلماء بنشر ورقة بحثية جديدة، حيث ذكروا كيف ينفذ Tornado Cash نظامًا لمكافحة غسيل الأموال (مما يسمح في الأساس للمسحوب أن يثبت أن سجل إيداعه ينتمي إلى مجموعة لا تحتوي على أموال قذرة)، لكن الورقة تفتقر إلى تفسير مفصل للمنطق التجاري ومبادئ Tornado Cash، مما يترك بعض القراء في حيرة.
يجدر بالذكر أن مشاريع الخصوصية التي يمثلها الإعصار هي تلك التي تستخدم حقًا خاصية عدم المعرفة الخاصة بخوارزمية ZK-SNARK، في حين أن معظم المشاريع المصنفة بـ ZK تستخدم فقط الاختصارات لـ ZK-SNARK. غالبًا ما يربك الناس الفرق بين دليل الصحة و ZK، ويعتبر الإعصار حالة ممتازة لفهم تطبيق ZK. كتب مؤلف هذه المقالة عن مبادئ الإعصار في عام 2022 لبحوث Web3Caff، واليوم يختار ويوسع في بعض الأقسام من تلك المقالة، وينظمها في هذا الجزء لفهم الإعصار بشكل منهجي.
الرابط الأصلي للمقال: https://research.web3caff.com/zh/archives/2663?ref=157
يستخدم Tornado Cash بروتوكول خلط العملات يعتمد على براهين المعرفة الصفرية ، مع إطلاق نسخته القديمة في عام 2019 وإصدار تجريبي جديد في نهاية عام 2021. حقق الإصدار الأقدم من Tornado مستوى عال من اللامركزية ، حيث كانت عقودها على السلسلة مفتوحة المصدر ولا يتم التحكم فيها بواسطة أي آلية متعددة التوقيعات ، كما أن رمز الواجهة الأمامية الخاص بها مفتوح المصدر ومدعوم على شبكة IPFS. نظرا للهيكل الأبسط والأكثر قابلية للفهم للإصدار القديم من Tornado ، تركز هذه المقالة على شرحه. الفكرة الرئيسية وراء Tornado هي مزج عدد كبير من إجراءات الإيداع والسحب معا. بعد إيداع الرموز المميزة في Tornado ، يقدم المودعون إثبات ZK لإثبات قيامهم بالإيداع ثم السحب إلى عنوان جديد ، وبالتالي قطع الرابط بين عناوين الإيداع والسحب.
على وجه التحديد، يعمل Tornado على النحو الذي يشبه صندوق زجاجي مليء بالعملات التي يقوم العديد من الأشخاص بإيداعها. يمكننا رؤية من قام بإيداع العملات، ولكن نظرًا لأن العملات متجانسة تمامًا، من الصعب تتبع أي عملة تم إيداعها بواسطة من إذا قام شخص غير معروف بسحب عملة.
(المصدر: المهارات النادرة)هذا السيناريو شائع إلى حد ما. على سبيل المثال ، عندما نقوم بمبادلة ETH في مجمع Uniswap ، لا يمكننا معرفة من نحصل على ETH لأن الكثيرين قدموا السيولة إلى Uniswap. ومع ذلك ، فإن الاختلاف هو أنه في كل مرة تقوم فيها بمبادلة الرموز المميزة على Uniswap ، تحتاج إلى استخدام الرموز المميزة الأخرى كتكلفة مكافئة ، ولا يمكنك تحويل الأموال "بشكل خاص" إلى شخص آخر ؛ بينما ، مع الخلاط ، ما عليك سوى إظهار إثبات الإيداع للسحب. لجعل إجراءات الإيداع والسحب تبدو متجانسة ، يتم الاحتفاظ بكل إيداع في مجمع Tornado وكل سحب منه ثابتا في المبلغ. على سبيل المثال ، إذا كان هناك 100 مودع و 100 سحب في مجموعة ، على الرغم من ظهورهم ، إلا أنهم يظهرون غير مرتبطين ، والمبلغ المودع والمسحوب من قبل كل منهم هو نفسه.
هذا يمكن أن يحجب قابلية تتبع تحويلات الأموال، مما يوفر راحة طبيعية لتجهيل المعاملات. السؤال الرئيسي هو: كيف يثبت السحب أنه قد قام بإيداع؟
العنوان الذي يقوم بالسحب غير مرتبط بأي عناوين إيداع، فكيف يمكن تحديد أهليتهم للسحب؟ يبدو أن الطريقة الأكثر مباشرة هي أن يكشف الشخص القائم بالسحب عن سجل الإيداع الخاص بهم، ولكن هذا سيكشف هويتهم مباشرة. هنا تأتي أدلة عدم المعرفة إلى اللعب. من خلال تقديم دليل عدم المعرفة أن لديهم سجل إيداع في عقد الإعصار الذي لم يتم سحبه بعد، يمكن للشخص القائم بالسحب بنجاح بدء عملية السحب. تحمي أدلة عدم المعرفة بشكل طبيعي الخصوصية، مكشفة فقط أن الشخص قام فعلاً بإيداع في صندوق الأموال، دون الكشف عن هوية الوديعة التي يتوافقون معها.
لإثبات "لقد قمت بإيداع في بركة صندوق الإعصار" يمكن ترجمتها إلى "يمكن العثور على سجل الإيداع الخاص بي في عقد الإعصار." إذا استخدمنا Cn لتمثيل سجل الإيداع، يصبح المشكلة: بفرض أن مجموعة سجلات الإيداع في الإعصار هي {C1، C2، ... C100 ...}، يثبت المسحوب، بوب، أنه استخدم مفتاحه لإنشاء بعض Cn في سجلات الإيداع دون الكشف عن الموقع المحدد لـ Cn. هذا يشمل الخاصية الخاصة لبرهان ميركل. تم دمج جميع سجلات الإيداع في الإعصار في شجرة ميركل مُنشأة على السلسلة، مع هذه السجلات كأوراق أسفل الطبقة. إجمالي عدد الأوراق حوالي 2^20 أكبر من مليون ورقة، معظمها في حالة فارغة (تم تعيين قيمة ابتدائية لها). كلما حدث إيداع جديد، يسجل العقد قيمته الفريدة، Commitment، في ورقة، ثم يحدث جذر شجرة ميركل.
على سبيل المثال، إذا كان إيداع بوب العاشرة ضمن تاريخ Tornado، فإن القيمة الخاصة Cn المرتبطة بهذا الإيداع ستُدخل في العقدة العاشرة من شجرة Merkle، أي C10000 = Cn. يقوم العقد بحساب جذر جديد تلقائيًا وتحديثه. من أجل توفير الموارد الحسابية، يقوم عقد Tornado بتخزين مؤقت للبيانات من مجموعة من العقد التي تم تغييرها مسبقًا، مثل Fs1، Fs2، و Fs0 في الdiagram أدناه.
(المصدر: RareSkills)
برهان ميركل، بطبيعته، موجز وخفيف الوزن، يستفيد من ببساطة هياكل البيانات الشجرية في عمليات البحث/التتبع. لإثبات خارجيًا أن صفقة TD موجودة في شجرة ميركل، يحتاج المرء فقط إلى تقديم برهان ميركل متوافق مع الجذر، وهو أمر بسيط للغاية. إذا كانت شجرة ميركل كبيرة بشكل خاص، مع 2^20 قاعدة أوراق في المستوى السفلي (أي سجلات إيداع مليون)، فإن برهان ميركل سيحتاج فقط لتضمين قيم 21 عقدة، وهو أمر قصير للغاية.
لإثبات أن عملية H3 موجودة فعلاً داخل شجرة ميركل، يجب على الشخص أن يثبت أنه باستخدام H3 وأجزاء أخرى من البيانات على شجرة ميركل، يمكن إنشاء الجذر، والبيانات اللازمة لإنشاء الجذر (بما في ذلك Td) تشكل دليلا ميركل. عندما يقوم بوب بالسحب، يحتاج إلى إثبات أن شهادته تتوافق مع تجزئة الإيداع Cn المسجلة على شجرة ميركل في دفتر الأمطار. بمعنى آخر، يجب عليه أن يثبت شيئين: Cn موجودة داخل شجرة ميركل الخيالية على سلسلة الكتل، على وجه الخصوص من خلال بناء دليل ميركل يحتوي على Cn؛ Cn مرتبطة بشهادة إيداع بوب.
في كود واجهة المستخدم الأمامية لواجهة مستخدم Tornado ، تم تنفيذ العديد من الوظائف مسبقًا. عندما يفتح المودع صفحة Tornado Cash وينقر فوق زر الإيداع، يقوم الكود الأمامي المرافق بتوليد رقمين عشوائيين، K و r، محليًا. ثم يقوم بحساب قيمة Cn=Hash(K, r) ويمرر Cn (المشار إليه كالالتزام في الرسم البياني أدناه) إلى العقد Tornado، الذي يدخله في شجرة Merkle المسجلة من قبل هذا الأخير. في الجوهر، تعمل K و r كمفاتيح خاصة. إنها حاسمة، ويطالب النظام المستخدمين بحفظها بشكل آمن. يتعين استخدام K و r مرة أخرى أثناء السحب.
(خيار encryptedNote يسمح للمستخدمين بتشفير الاعتماد K و r بمفتاح خاص وتخزينه على سلسلة الكتل لمنع النسيان) بشكل مهم، تحدث جميع هذه العمليات خارج السلسلة، مما يعني أن عقد Tornado والمراقبون الخارجيون غير على علم ب K و r. إذا تم تسريب K و r، فإنه يشبه سرقة مفاتيح المحافظ.
بمجرد استلام إيداع من المستخدم وتقديم Cn=Hash(K، r)، يسجل عقد الإعصار Cn في الطبقة السفلية لشجرة Merkle كورقة ورقة جديدة، مع تحديث قيمة الجذر أيضًا. وبالتالي، يرتبط Cn مباشرة بإجراء إيداع المستخدم، مما يسمح للأشخاص الخارجيين بمعرفة أي مستخدم يتوافق مع كل Cn، الذين قاموا بإيداع الرموز في الخلاط، وسجلات الإيداع Cn لكل مودع.
أثناء عملية السحب ، يقوم السحب بإدخال بيانات الاعتماد / المفتاح الخاص (الأرقام العشوائية K و r التي تم إنشاؤها أثناء الإيداع) على صفحة الويب الأمامية. يستخدم البرنامج في كود الواجهة الأمامية ل Tornado Cash K و r و CN = Hash (K ، r) و Merkle Proof المقابل ل Cn كمعلمات إدخال لإنشاء ZK Proof. هذا يثبت أن Cn موجود في Merkle Tree كسجل إيداع ، و K و r هما أوراق الاعتماد المقابلة ل Cn. تثبت هذه الخطوة بشكل أساسي: أعرف المفتاح المقابل لسجل الإيداع على شجرة ميركل. عندما يتم تقديم دليل ZK إلى عقد Tornado ، يتم إخفاء هذه المعلمات الأربعة ، مما يحمي الخصوصية. يتضمن إنشاء ZK Proof معلمات إضافية ، بما في ذلك جذر Merkle المسجل في عقد Tornado في وقت الانسحاب ، وعنوان مستلم مخصص A ، ومعرف nf لمنع هجمات إعادة التشغيل. يتم نشر هذه المعلمات الثلاثة علنا على blockchain ، والتي لا تعرض الخصوصية للخطر.
من التفاصيل التي يجب ملاحظتها استخدام رقمين عشوائيين ، K و r ، لإنشاء Cn بدلا من رقم عشوائي واحد ، مما يوفر أمانا متزايدا ضد الاصطدامات. A يمثل عنوان مستلم السحب ، الذي اختاره المسحوب. يتم حساب المعرف nf ، المصمم لمنع هجمات إعادة التشغيل ، على أنه nf = Hash (K) ، حيث K هو أحد الرقمين العشوائيين المستخدمين في خطوة الإيداع لإنشاء Cn. هذا يربط nf مباشرة ب Cn ، مما يؤدي إلى إنشاء ارتباط واحد لواحد بين كل Cn و nf المقابل له. يرجع الغرض من منع هجمات إعادة التشغيل إلى ميزة تصميم الخلاط ، والتي تحافظ على الارتباط بين مبالغ السحب وأوراق شجرة Merkle المحددة (Cn) غير معروفة ، مما يسمح بإساءة الاستخدام المحتملة لعمليات السحب المتكررة حتى يتم استنفاد مجمع الأموال.
يعمل معرف nf بشكل مماثل للعدم السري المرتبط بكل عنوان Ethereum ، مما يمنع إعادة تشغيل المعاملات. عند حدوث سحب ، يتأكد الفحص من أن nf المقدم لم يتم استخدامه من قبل ؛ إذا لم يتم استخدامه ، فإن السحب صالح ، ويتم تسجيل nf. أي محاولة لإنشاء nf غير مرتبط بأي إيداع مسجل Cn ستفشل في إنتاج دليل ZK صالح ، مما يجعل السحب غير ناجح.
إذا قام شخص ما بإنشاء عقد غير قابل للاستبدال (nf) غير مسجل بشكل عشوائي ، فهل سينجح؟ بالطبع لا. عندما يقوم الساسحب بإنشاء دليل على المعرفة الصفرية (ZK Proof) ، يجب عليه التأكد من أن nf يساوي التجزئة (K) ، حيث يرتبط الرقم العشوائي K بسجل الإيداع Cn. هذا يعني أن nf مرتبط بإيداع مسجل Cn. إذا قام شخص ما بتلفيق nf بشكل تعسفي ، فلن يتطابق nf هذا مع أي سجلات إيداع ، مما يجعل من المستحيل إنشاء دليل ZK صالح. وبالتالي ، لا يمكن إكمال عملية السحب بنجاح ، وستفشل عملية السحب. قد يسأل البعض: هل من الممكن المتابعة بدون nf؟ نظرا لأن المنسحب يحتاج إلى تقديم دليل ZK أثناء السحب لإثبات ارتباطه ب CN معين ، فلماذا لا تتحقق فقط مما إذا كان قد تم تقديم دليل ZK المقابل إلى blockchain في كل مرة يحدث فيها سحب؟ ومع ذلك ، فإن هذا النهج مكلف للغاية لأن عقد Tornado Cash لا يخزن بشكل دائم ZK Proofs السابقة بسبب إهدار مساحة التخزين الكبيرة. إن مقارنة كل دليل ZK جديد يتم إرساله إلى blockchain مع البراهين الحالية أقل كفاءة من تعيين معرف صغير مثل nf وتخزينه بشكل دائم.
وفقًا لمثال كود وظيفة السحب، البارامترات المطلوبة والمنطق التجاري هي كما يلي: يقدم المستخدم دليل ZK و nf (NullifierHash) = Hash (K)، ويحدد عنوان المستلم للسحب، ويخفي دليل ZK قيم Cn و K و r، مما يجعل من المستحيل على الأشخاص الخارجيين تحديد هوية المستخدم. المستلم يستخدم في كثير من الأحيان عنوانًا جديدًا ونظيفًا، والذي لا يكشف عن المعلومات الشخصية.
ومع ذلك، هناك مشكلة طفيفة: عندما يقوم المستخدمون بالسحب للبقاء غير قابلين للتتبع، في كثير من الأحيان يبدؤون عملية سحب التحويل من عنوان تم إنشاؤه حديثًا. في هذا الوقت، يفتقر العنوان الجديد إلى ETH لدفع رسوم الغاز. لذلك، عند بدء عملية السحب، يجب على عنوان السحب أن يعلن صراحة عن وسيط لدفع رسوم الغاز نيابة عنه. بعد ذلك، يقوم عقد المزج بخصم جزء من سحب المستخدم لتعويض الوسيط.
في الختام، يمكن لـ Tornado Cash أن يحجب الاتصال بين السحب والودائع. في حالات وجود قاعدة مستخدمين كبيرة، يشبه الأمر الجناة الاندماج في حشد في منطقة مزدحمة، مما يجعل من الصعب على الشرطة تتبعه. ينطوي عملية السحب على استخدام ZK-SNARKs، مع جزء الشاهد المخفي يحتوي على معلومات حرجة حول السحب، وهو جانب رئيسي من المزج بأكمله. حاليًا، يبدو أن Tornado هو أحد أكثر مشاريع طبقة التطبيقات العبقرية المتعلقة بـ ZK.
แชร์
مقدمة: مؤخرًا، قام فيتاليك وبعض العلماء بنشر ورقة بحثية جديدة، حيث ذكروا كيف ينفذ Tornado Cash نظامًا لمكافحة غسيل الأموال (مما يسمح في الأساس للمسحوب أن يثبت أن سجل إيداعه ينتمي إلى مجموعة لا تحتوي على أموال قذرة)، لكن الورقة تفتقر إلى تفسير مفصل للمنطق التجاري ومبادئ Tornado Cash، مما يترك بعض القراء في حيرة.
يجدر بالذكر أن مشاريع الخصوصية التي يمثلها الإعصار هي تلك التي تستخدم حقًا خاصية عدم المعرفة الخاصة بخوارزمية ZK-SNARK، في حين أن معظم المشاريع المصنفة بـ ZK تستخدم فقط الاختصارات لـ ZK-SNARK. غالبًا ما يربك الناس الفرق بين دليل الصحة و ZK، ويعتبر الإعصار حالة ممتازة لفهم تطبيق ZK. كتب مؤلف هذه المقالة عن مبادئ الإعصار في عام 2022 لبحوث Web3Caff، واليوم يختار ويوسع في بعض الأقسام من تلك المقالة، وينظمها في هذا الجزء لفهم الإعصار بشكل منهجي.
الرابط الأصلي للمقال: https://research.web3caff.com/zh/archives/2663?ref=157
يستخدم Tornado Cash بروتوكول خلط العملات يعتمد على براهين المعرفة الصفرية ، مع إطلاق نسخته القديمة في عام 2019 وإصدار تجريبي جديد في نهاية عام 2021. حقق الإصدار الأقدم من Tornado مستوى عال من اللامركزية ، حيث كانت عقودها على السلسلة مفتوحة المصدر ولا يتم التحكم فيها بواسطة أي آلية متعددة التوقيعات ، كما أن رمز الواجهة الأمامية الخاص بها مفتوح المصدر ومدعوم على شبكة IPFS. نظرا للهيكل الأبسط والأكثر قابلية للفهم للإصدار القديم من Tornado ، تركز هذه المقالة على شرحه. الفكرة الرئيسية وراء Tornado هي مزج عدد كبير من إجراءات الإيداع والسحب معا. بعد إيداع الرموز المميزة في Tornado ، يقدم المودعون إثبات ZK لإثبات قيامهم بالإيداع ثم السحب إلى عنوان جديد ، وبالتالي قطع الرابط بين عناوين الإيداع والسحب.
على وجه التحديد، يعمل Tornado على النحو الذي يشبه صندوق زجاجي مليء بالعملات التي يقوم العديد من الأشخاص بإيداعها. يمكننا رؤية من قام بإيداع العملات، ولكن نظرًا لأن العملات متجانسة تمامًا، من الصعب تتبع أي عملة تم إيداعها بواسطة من إذا قام شخص غير معروف بسحب عملة.
(المصدر: المهارات النادرة)هذا السيناريو شائع إلى حد ما. على سبيل المثال ، عندما نقوم بمبادلة ETH في مجمع Uniswap ، لا يمكننا معرفة من نحصل على ETH لأن الكثيرين قدموا السيولة إلى Uniswap. ومع ذلك ، فإن الاختلاف هو أنه في كل مرة تقوم فيها بمبادلة الرموز المميزة على Uniswap ، تحتاج إلى استخدام الرموز المميزة الأخرى كتكلفة مكافئة ، ولا يمكنك تحويل الأموال "بشكل خاص" إلى شخص آخر ؛ بينما ، مع الخلاط ، ما عليك سوى إظهار إثبات الإيداع للسحب. لجعل إجراءات الإيداع والسحب تبدو متجانسة ، يتم الاحتفاظ بكل إيداع في مجمع Tornado وكل سحب منه ثابتا في المبلغ. على سبيل المثال ، إذا كان هناك 100 مودع و 100 سحب في مجموعة ، على الرغم من ظهورهم ، إلا أنهم يظهرون غير مرتبطين ، والمبلغ المودع والمسحوب من قبل كل منهم هو نفسه.
هذا يمكن أن يحجب قابلية تتبع تحويلات الأموال، مما يوفر راحة طبيعية لتجهيل المعاملات. السؤال الرئيسي هو: كيف يثبت السحب أنه قد قام بإيداع؟
العنوان الذي يقوم بالسحب غير مرتبط بأي عناوين إيداع، فكيف يمكن تحديد أهليتهم للسحب؟ يبدو أن الطريقة الأكثر مباشرة هي أن يكشف الشخص القائم بالسحب عن سجل الإيداع الخاص بهم، ولكن هذا سيكشف هويتهم مباشرة. هنا تأتي أدلة عدم المعرفة إلى اللعب. من خلال تقديم دليل عدم المعرفة أن لديهم سجل إيداع في عقد الإعصار الذي لم يتم سحبه بعد، يمكن للشخص القائم بالسحب بنجاح بدء عملية السحب. تحمي أدلة عدم المعرفة بشكل طبيعي الخصوصية، مكشفة فقط أن الشخص قام فعلاً بإيداع في صندوق الأموال، دون الكشف عن هوية الوديعة التي يتوافقون معها.
لإثبات "لقد قمت بإيداع في بركة صندوق الإعصار" يمكن ترجمتها إلى "يمكن العثور على سجل الإيداع الخاص بي في عقد الإعصار." إذا استخدمنا Cn لتمثيل سجل الإيداع، يصبح المشكلة: بفرض أن مجموعة سجلات الإيداع في الإعصار هي {C1، C2، ... C100 ...}، يثبت المسحوب، بوب، أنه استخدم مفتاحه لإنشاء بعض Cn في سجلات الإيداع دون الكشف عن الموقع المحدد لـ Cn. هذا يشمل الخاصية الخاصة لبرهان ميركل. تم دمج جميع سجلات الإيداع في الإعصار في شجرة ميركل مُنشأة على السلسلة، مع هذه السجلات كأوراق أسفل الطبقة. إجمالي عدد الأوراق حوالي 2^20 أكبر من مليون ورقة، معظمها في حالة فارغة (تم تعيين قيمة ابتدائية لها). كلما حدث إيداع جديد، يسجل العقد قيمته الفريدة، Commitment، في ورقة، ثم يحدث جذر شجرة ميركل.
على سبيل المثال، إذا كان إيداع بوب العاشرة ضمن تاريخ Tornado، فإن القيمة الخاصة Cn المرتبطة بهذا الإيداع ستُدخل في العقدة العاشرة من شجرة Merkle، أي C10000 = Cn. يقوم العقد بحساب جذر جديد تلقائيًا وتحديثه. من أجل توفير الموارد الحسابية، يقوم عقد Tornado بتخزين مؤقت للبيانات من مجموعة من العقد التي تم تغييرها مسبقًا، مثل Fs1، Fs2، و Fs0 في الdiagram أدناه.
(المصدر: RareSkills)
برهان ميركل، بطبيعته، موجز وخفيف الوزن، يستفيد من ببساطة هياكل البيانات الشجرية في عمليات البحث/التتبع. لإثبات خارجيًا أن صفقة TD موجودة في شجرة ميركل، يحتاج المرء فقط إلى تقديم برهان ميركل متوافق مع الجذر، وهو أمر بسيط للغاية. إذا كانت شجرة ميركل كبيرة بشكل خاص، مع 2^20 قاعدة أوراق في المستوى السفلي (أي سجلات إيداع مليون)، فإن برهان ميركل سيحتاج فقط لتضمين قيم 21 عقدة، وهو أمر قصير للغاية.
لإثبات أن عملية H3 موجودة فعلاً داخل شجرة ميركل، يجب على الشخص أن يثبت أنه باستخدام H3 وأجزاء أخرى من البيانات على شجرة ميركل، يمكن إنشاء الجذر، والبيانات اللازمة لإنشاء الجذر (بما في ذلك Td) تشكل دليلا ميركل. عندما يقوم بوب بالسحب، يحتاج إلى إثبات أن شهادته تتوافق مع تجزئة الإيداع Cn المسجلة على شجرة ميركل في دفتر الأمطار. بمعنى آخر، يجب عليه أن يثبت شيئين: Cn موجودة داخل شجرة ميركل الخيالية على سلسلة الكتل، على وجه الخصوص من خلال بناء دليل ميركل يحتوي على Cn؛ Cn مرتبطة بشهادة إيداع بوب.
في كود واجهة المستخدم الأمامية لواجهة مستخدم Tornado ، تم تنفيذ العديد من الوظائف مسبقًا. عندما يفتح المودع صفحة Tornado Cash وينقر فوق زر الإيداع، يقوم الكود الأمامي المرافق بتوليد رقمين عشوائيين، K و r، محليًا. ثم يقوم بحساب قيمة Cn=Hash(K, r) ويمرر Cn (المشار إليه كالالتزام في الرسم البياني أدناه) إلى العقد Tornado، الذي يدخله في شجرة Merkle المسجلة من قبل هذا الأخير. في الجوهر، تعمل K و r كمفاتيح خاصة. إنها حاسمة، ويطالب النظام المستخدمين بحفظها بشكل آمن. يتعين استخدام K و r مرة أخرى أثناء السحب.
(خيار encryptedNote يسمح للمستخدمين بتشفير الاعتماد K و r بمفتاح خاص وتخزينه على سلسلة الكتل لمنع النسيان) بشكل مهم، تحدث جميع هذه العمليات خارج السلسلة، مما يعني أن عقد Tornado والمراقبون الخارجيون غير على علم ب K و r. إذا تم تسريب K و r، فإنه يشبه سرقة مفاتيح المحافظ.
بمجرد استلام إيداع من المستخدم وتقديم Cn=Hash(K، r)، يسجل عقد الإعصار Cn في الطبقة السفلية لشجرة Merkle كورقة ورقة جديدة، مع تحديث قيمة الجذر أيضًا. وبالتالي، يرتبط Cn مباشرة بإجراء إيداع المستخدم، مما يسمح للأشخاص الخارجيين بمعرفة أي مستخدم يتوافق مع كل Cn، الذين قاموا بإيداع الرموز في الخلاط، وسجلات الإيداع Cn لكل مودع.
أثناء عملية السحب ، يقوم السحب بإدخال بيانات الاعتماد / المفتاح الخاص (الأرقام العشوائية K و r التي تم إنشاؤها أثناء الإيداع) على صفحة الويب الأمامية. يستخدم البرنامج في كود الواجهة الأمامية ل Tornado Cash K و r و CN = Hash (K ، r) و Merkle Proof المقابل ل Cn كمعلمات إدخال لإنشاء ZK Proof. هذا يثبت أن Cn موجود في Merkle Tree كسجل إيداع ، و K و r هما أوراق الاعتماد المقابلة ل Cn. تثبت هذه الخطوة بشكل أساسي: أعرف المفتاح المقابل لسجل الإيداع على شجرة ميركل. عندما يتم تقديم دليل ZK إلى عقد Tornado ، يتم إخفاء هذه المعلمات الأربعة ، مما يحمي الخصوصية. يتضمن إنشاء ZK Proof معلمات إضافية ، بما في ذلك جذر Merkle المسجل في عقد Tornado في وقت الانسحاب ، وعنوان مستلم مخصص A ، ومعرف nf لمنع هجمات إعادة التشغيل. يتم نشر هذه المعلمات الثلاثة علنا على blockchain ، والتي لا تعرض الخصوصية للخطر.
من التفاصيل التي يجب ملاحظتها استخدام رقمين عشوائيين ، K و r ، لإنشاء Cn بدلا من رقم عشوائي واحد ، مما يوفر أمانا متزايدا ضد الاصطدامات. A يمثل عنوان مستلم السحب ، الذي اختاره المسحوب. يتم حساب المعرف nf ، المصمم لمنع هجمات إعادة التشغيل ، على أنه nf = Hash (K) ، حيث K هو أحد الرقمين العشوائيين المستخدمين في خطوة الإيداع لإنشاء Cn. هذا يربط nf مباشرة ب Cn ، مما يؤدي إلى إنشاء ارتباط واحد لواحد بين كل Cn و nf المقابل له. يرجع الغرض من منع هجمات إعادة التشغيل إلى ميزة تصميم الخلاط ، والتي تحافظ على الارتباط بين مبالغ السحب وأوراق شجرة Merkle المحددة (Cn) غير معروفة ، مما يسمح بإساءة الاستخدام المحتملة لعمليات السحب المتكررة حتى يتم استنفاد مجمع الأموال.
يعمل معرف nf بشكل مماثل للعدم السري المرتبط بكل عنوان Ethereum ، مما يمنع إعادة تشغيل المعاملات. عند حدوث سحب ، يتأكد الفحص من أن nf المقدم لم يتم استخدامه من قبل ؛ إذا لم يتم استخدامه ، فإن السحب صالح ، ويتم تسجيل nf. أي محاولة لإنشاء nf غير مرتبط بأي إيداع مسجل Cn ستفشل في إنتاج دليل ZK صالح ، مما يجعل السحب غير ناجح.
إذا قام شخص ما بإنشاء عقد غير قابل للاستبدال (nf) غير مسجل بشكل عشوائي ، فهل سينجح؟ بالطبع لا. عندما يقوم الساسحب بإنشاء دليل على المعرفة الصفرية (ZK Proof) ، يجب عليه التأكد من أن nf يساوي التجزئة (K) ، حيث يرتبط الرقم العشوائي K بسجل الإيداع Cn. هذا يعني أن nf مرتبط بإيداع مسجل Cn. إذا قام شخص ما بتلفيق nf بشكل تعسفي ، فلن يتطابق nf هذا مع أي سجلات إيداع ، مما يجعل من المستحيل إنشاء دليل ZK صالح. وبالتالي ، لا يمكن إكمال عملية السحب بنجاح ، وستفشل عملية السحب. قد يسأل البعض: هل من الممكن المتابعة بدون nf؟ نظرا لأن المنسحب يحتاج إلى تقديم دليل ZK أثناء السحب لإثبات ارتباطه ب CN معين ، فلماذا لا تتحقق فقط مما إذا كان قد تم تقديم دليل ZK المقابل إلى blockchain في كل مرة يحدث فيها سحب؟ ومع ذلك ، فإن هذا النهج مكلف للغاية لأن عقد Tornado Cash لا يخزن بشكل دائم ZK Proofs السابقة بسبب إهدار مساحة التخزين الكبيرة. إن مقارنة كل دليل ZK جديد يتم إرساله إلى blockchain مع البراهين الحالية أقل كفاءة من تعيين معرف صغير مثل nf وتخزينه بشكل دائم.
وفقًا لمثال كود وظيفة السحب، البارامترات المطلوبة والمنطق التجاري هي كما يلي: يقدم المستخدم دليل ZK و nf (NullifierHash) = Hash (K)، ويحدد عنوان المستلم للسحب، ويخفي دليل ZK قيم Cn و K و r، مما يجعل من المستحيل على الأشخاص الخارجيين تحديد هوية المستخدم. المستلم يستخدم في كثير من الأحيان عنوانًا جديدًا ونظيفًا، والذي لا يكشف عن المعلومات الشخصية.
ومع ذلك، هناك مشكلة طفيفة: عندما يقوم المستخدمون بالسحب للبقاء غير قابلين للتتبع، في كثير من الأحيان يبدؤون عملية سحب التحويل من عنوان تم إنشاؤه حديثًا. في هذا الوقت، يفتقر العنوان الجديد إلى ETH لدفع رسوم الغاز. لذلك، عند بدء عملية السحب، يجب على عنوان السحب أن يعلن صراحة عن وسيط لدفع رسوم الغاز نيابة عنه. بعد ذلك، يقوم عقد المزج بخصم جزء من سحب المستخدم لتعويض الوسيط.
في الختام، يمكن لـ Tornado Cash أن يحجب الاتصال بين السحب والودائع. في حالات وجود قاعدة مستخدمين كبيرة، يشبه الأمر الجناة الاندماج في حشد في منطقة مزدحمة، مما يجعل من الصعب على الشرطة تتبعه. ينطوي عملية السحب على استخدام ZK-SNARKs، مع جزء الشاهد المخفي يحتوي على معلومات حرجة حول السحب، وهو جانب رئيسي من المزج بأكمله. حاليًا، يبدو أن Tornado هو أحد أكثر مشاريع طبقة التطبيقات العبقرية المتعلقة بـ ZK.