مقدمة:

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

من الجدير بالذكر أن مشاريع مثل Tornado، التي تمثل مشاريع خصوصية، تستخدم حقًا جانب الصفر المعرفي لخوارزمية ZK-SNARK. في الوقت نفسه، تعتمد معظم الحلول التي تحمل راية ZK، مثل Rollups، فقط على إيجاز ZK-SNARK. غالبًا ما يميل الناس إلى الخلط بين دليل الصحة و ZK، ويعتبر Tornado مثالًا ممتازًا لتوضيح التطبيق العملي لـ ZK.

كان مؤلف هذه المقالة قد كتب قطعة عن مبادئ الإعصار في عام 2022 لبحوث Web3Caff. اليوم، قمنا باستخراج وتوسيع بعض الأقسام من تلك العمل الأصلي لتوفير فهم منهجي لنقدم نقداً للنقد.

Original Article Link:https://research.web3caff.com/zh/archives/2663?ref=157

مبدأ "الإعصار"

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

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

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

（图源：rareskills）

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

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

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

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

لإثبات "لقد قمت بإيداع في حوض الإعصار" يمكن ترجمتها إلى "يمكن العثور على سجل إيداعي في عقد الإعصار." إذا كان Cn يعبر عن سجل إيداع، فإنه بالنظر إلى مجموعة سجلات إيداع الإعصار على النحو التالي {C1، C2، ... C100 ...}، يحتاج بوب إلى إثبات أنه استخدم مفتاحه الخاص لإنشاء سجل في هذه المجموعة دون الكشف عن Cn الخاص به. يستفيد هذا من الخصائص الفريدة لبرهان ميركل.

تم تجميع جميع سجلات إيداع Tornado في شجرة Merkle المُنشأة على السلسلة. يظل الغالبية العظمى من هذه الأوراق (حوالي 2^20، أكثر من مليون) فارغة (بقيمة ابتدائية). يُحدث كل إيداع جديد ورقة التزام مقابلة ثم جذر الشجرة.

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

（المصدر: RareSkills）

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

للتحقق من أن الصفقة، مثل H3، قد تم تضمينها فعلًا في شجرة Merkle، يجب على الشخص أن يثبت ذلك باستخدام H3 وبيانات أخرى من شجرة Merkle يمكن أن تولد الجذر. تشكل هذه البيانات (بما في ذلك Td) دليل Merkle. عندما يرغب بوب في السحب، يحتاج إلى التحقق من شيئين:

·تقع Cn في شجرة Merkle المبنية على السلسلة بواسطة Tornado، حيث يمكنه بناء دليل Merkle يحتوي على Cn؛

· يرتبط Cn بقسيمة إيداع بوب.

شرح منطق أعمال الإعصار

في كود الواجهة الأمامية لواجهة مستخدم Tornado ، تم تنفيذ العديد من الوظائف مسبقًا. عندما يفتح المودع صفحة Tornado Cash وينقر على زر الإيداع، يقوم الكود الأمامي المرفق بتوليد رقمين عشوائيين، K و r، محليًا. ثم يقوم بحساب قيمة Cn=Hash(K, r)، ممررًا Cn (المشار إليه باسم التزام في الرسم البياني أدناه) إلى عقد Tornado ليتم دمجه في شجرته Merkle. ببساطة، تعمل K و r كمفاتيح خاصة. إنها حرجة، ويُنصح بتخزينها بأمان، حيث سيتعين استخدامها مرة أخرى أثناء عملية السحب.

ميزة "encryptedNote" هي ميزة اختيارية تسمح للمستخدمين بتشفير أوراق الاعتماد K و r بمفتاح خاص وتخزينها على السلسلة لمنع النسيان.

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

عند تلقي إيداع المستخدم و Cn = Hash (K ، r) المحسوب ، يضع عقد Tornado Cn في المستوى الأساسي لشجرة Merkle ، ويحولها إلى عقدة ورقة جديدة ثم يقوم بتحديث قيمة الجذر. ومع ذلك ، من المهم أن نفهم أن أوراق شجرة Merkle هذه لا يتم تسجيلها ضمن حالة العقد ولكن يتم تسجيلها فقط كمعلمات حدث في الكتل السابقة. عقد تورنادو يسجل فقط جذر ميركل. أثناء السحب ، يمكن للمستخدمين إثبات ، عبر Merkle Proof ، أن سجل الإيداع يتوافق مع جذر Merkle الحالي ، وهو مفهوم يشبه إلى حد ما عمليات سحب جسر العميل الخفيفة عبر السلسلة. يكشف هذا التصميم عن براعة تورنادو: لتوفير تكاليف الغاز ، لم يتم تسجيل شجرة ميركل الكاملة في حالة العقد ، بل جذرها فقط. يتم تسجيل أوراق الشجرة ببساطة في سجلات الكتلة التاريخية ، وهي آلية تشبه إلى حد ما مبدأ توفير الغاز في Rollup (على الرغم من اختلاف التفاصيل).

أثناء عملية السحب، يقوم الشخص الذي يسحب بإدخال بيانات الاعتماد / المفاتيح الخاصة (أرقام عشوائية K و r تم إنشاؤها أثناء الإيداع) على صفحة الويب الأمامية. يستخدم كود Tornado Cash frontend K و r، Cn=Hash(K، r)، والدليل السملي المتوافق مع Cn لتوليد إثبات ZK، مما يؤكد بذلك أن Cn يتوافق مع سجل إيداع على شجرة Merkle وأن K و r هما بيانات اعتماد صالحة ل Cn. يثبت هذا الخطوة بشكل أساسي معرفة مفاتيح سجل الإيداع على شجرة Merkle. عند تقديم إثبات ZK إلى عقد Tornado، يتم إخفاء جميع المعلمات الأربعة، مما يضمن أن الأشخاص الخارجيين، بما في ذلك عقد Tornado نفسه، يظلون غير على علم، مما يحمي خصوصية المستخدم بذلك.

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

بالنسبة للرمز “A” في الرسم التوضيحي، يمثل العنوان الذي يتم استلام السحب إليه والمقدم من المسحوب. في هذه الأثناء، “nf” هو معرف يتم تعيينه لمنع هجمات الإعادة، حيث يتم تحديد قيمتها كـ nf=Hash(K)، حيث K هو واحد من الرقمين العشوائيين (K و r) المستخدمين خلال الوديعة لتوليد Cn. وعلى هذا النحو، كل Cn له nf مقابل، وهما مرتبطان بشكل فريد.

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

هنا، يعمل معرف nf بشكل مماثل لعداد المعاملات "nonce" الخاص بكل عنوان Ethereum، الذي تم إنشاؤه لمنع إعادة تشغيل المعاملات. عند طلب السحب، يجب على المستخدمين تقديم nf. يقوم النظام بالتحقق مما إذا تم استخدام هذا nf مسبقًا: إذا تم ذلك، يتم إبطال السحب؛ إذا لم يكن كذلك، يتم استمرار السحب، ويتم تسجيل nf، مما يضمن أن استخدامه لاحقًا سيؤدي إلى إبطاله.

قد يتساءل البعض: هل يمكن لشخص ما تزوير nf الذي لم يتم تسجيله في العقد؟ هذا أمر غير مرجح. خلال توليد ZK Proof ، من الضروري التأكد من nf=Hash(K)، والرقم العشوائي K مرتبط بسجل الإيداع Cn. إذا قام شخص ما بإنشاء nf بشكل تعسفي، فلن يتطابق مع أي من الإيداعات المسجلة، مما يجعل من الصعب توليد ZK Proof صالح، وبالتالي تعطيل عملية السحب.

قد يسأل البعض: هل هناك طريقة لتجنب استخدام nf؟ بمراعاة أنه يجب على المنسحبين تقديم ZK Proof، الذي يشهد ارتباطهم بـ Cn معين، هل لا يكفي التحقق مما إذا كان قد تم بالفعل تسجيل ZK Proof مقابل على السلسلة؟ ومع ذلك، تكاليف هذا النهج باهظة لأن عقد Tornado Cash لا يخزن بشكل دائم ZK Proofs المقدمة مسبقًا لتجنب هدر التخزين. المقارنة بين كل ZK Proof جديد والموجودة بالفعل لضمان الاتساق تتطلب موارد أكثر بكثير من تسجيل معرف مضغوط مثل nf.

وفقًا لمثال رمز وظيفة السحب، البارامترات المطلوبة والمنطق التجاري هي كما يلي: يقدم المستخدمون دليل ZK، nf (NullifierHash) = Hash(K)، ويعينون عنوان المستلم لعملية السحب. يخفي دليل ZK قيم Cn، K، و r، مما يضمن عدم قدرة العالم الخارجي على تحديد هوية المستخدم. عادةً، سيقوم المستلمون بتحديد عنوان نظيف جديد لمنع كشف المعلومات الشخصية.

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

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

تنصل:

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