Вступ: Недавно Віталік та деякі вчені спільно опублікували нову статтю, у якій згадується, як Tornado Cash реалізує схему протидії відмиванню грошей (в основному дозволяючи вивідникові довести, що їхня запис про депозит належить до множини, яка не містить брудних грошей), але в статті відсутнє детальне тлумачення бізнес-логіки та принципів Tornado Cash, що залишає деяких читачів в розпачі.

Варто зазначити, що проєкти приватності, представлені Tornado, дійсно використовують властивість нульового розголошення алгоритму ZK-SNARK, тоді як більшість проєктів, позначених ZK, використовують лише стислість ZK-SNARK. Люди часто плутають різницю між Validity Proof і ZK, і Tornado служить відмінним прикладом для розуміння застосування ZK. Автор цієї статті писав про принципи Tornado у 2022 році для Web3Caff Research, а сьогодні вибирає та розширює деякі розділи з цієї статті, організовуючи їх у цей матеріал, щоб систематично зрозуміти Tornado Cash.

Посилання на оригінальну статтю: https://research.web3caff.com/zh/archives/2663?ref=157

Принцип «Торнадо»

Tornado Cash використовує протокол змішування монет на основі нульових доказів, де його старша версія була запущена в 2019 році, а нова бета-версія була випущена наприкінці 2021 року. Стара версія Tornado досягла високого рівня децентралізації, оскільки її контракти на ланцюжку були відкритими для громадськості і не контролювалися жодним механізмом багатоадресних підписів, а код її фронтенду також був відкритим для громадськості та резервований в мережі IPFS. Завдяки простішій та зрозумілішій структурі старої версії Tornado, ця стаття спрямована на її пояснення. Основна ідея за Tornado полягає в тому, щоб змішати велику кількість дій з депозиту та виведення разом. Після внесення токенів в Tornado, депозитарі представляють ZK Proof для підтвердження того, що вони зробили депозит, а потім виводять на нову адресу, таким чином розриваючи зв'язок між адресами депозиту та виведення.

Конкретніше, Торнадо діє як скляна коробка, наповнена монетами, які внесли багато людей. Ми можемо побачити, хто вніс монети, але оскільки монети високо гомогенізовані, важко відслідкувати, яка монета була внесена ким, якщо хтось незнайомий знімає монету.

(Джерело: rareskills)Цей сценарій є досить поширеним; наприклад, коли ми обмінюємо ETH у пулі Uniswap, ми не можемо знати, чий ETH ми отримуємо, оскільки багато хто надав ліквідність Uniswap. Однак різниця полягає в тому, що кожного разу, коли ви обмінюєте токени на Uniswap, вам потрібно використовувати інші токени як еквівалентну вартість, і ви не можете «приватно» переказувати кошти комусь іншому; Тоді як у випадку зі змішувачем вам потрібно лише пред'явити депозит, щоб вивести. Щоб дії з депозиту та виведення коштів виглядали однорідними, кожен депозит у пул Tornado та кожне зняття коштів з нього залишаються однаковими за сумою. Наприклад, якщо в пулі є 100 вкладників і 100 тих, хто виводить кошти, вони хоч і видими, але не пов'язані між собою, а сума, внесена та виведена кожним з них, однакова.

Це може затемнювати відстеженість фінансових переказів, пропонуючи природну зручність для анонімізації транзакцій. Ключове питання полягає в тому: як виведення доводить, що вони здійснили депозит?

Адреса, з якої здійснюється виведення, не пов'язана з жодною адресою депозиту, тому як можна визначити їхню придатність для виведення? Найбільш прямий метод, схоже, полягає в тому, що виводник повинен розкрити, який депозитний запис належить йому, але це безпосередньо виявить їхню особу. Тут у гру вступають докази з нульовим знанням. Представляючи ZK Proof, що вони мають депозитний запис у контракті Tornado, який ще не був виведений, вивідник може успішно ініціювати виведення. Докази з нульовим знанням за своєю природою захищають конфіденційність, показуючи лише, що особа дійсно здійснила депозит у фондовому пулі, не розкриваючи, з яким депонентом вони відповідають.

Щоб довести, що «Я зробив депозит у пулі фонду Tornado» можна перекласти як «Мій депозитний запис можна знайти в контракті Tornado». Якщо ми використовуємо Cn для представлення депозитного запису, то виникає проблема: враховуючи, що набір депозитних записів Торнадо дорівнює {C1, C2, ... C100...}, Боб, який виводить кошти, доводить, що він використовував свій ключ для генерації деякої кількості Cn у депозитних записах, не розкриваючи, що це за конкретний Cn. Це пов'язано з особливою властивістю Merkle Proof. Всі записи про родовища Tornado включені в дерево Меркла, побудоване в ланцюжку, причому ці записи є його листовими вузлами нижнього рівня. Загальна кількість листків становить близько 2^20 > 1 млн, більшість з яких знаходяться в порожньому стані (присвоєно початкове значення). Щоразу, коли з'являється новий депозит, контракт записує його унікальне значення, зобов'язання, у листок, а потім оновлює корінь дерева Меркла.

Наприклад, якщо депозит Боба був 10 000-м у історії Tornado, характеристичне значення Cn, пов'язане з цим депозитом, буде введено в 10 000-й листок дерева Меркла, тобто C10000 = Cn. Після цього контракт автоматично обчислює новий корінь і оновлює його. Щоб заощадити обчислювальні ресурси, контракт Tornado кешує дані з партії раніше змінених вузлів, таких як Fs1, Fs2 та Fs0 на діаграмі нижче.

(Джерело: RareSkills)

Доказ Меркла своєю природою є лаконічним та легким, використовуючи простоту структур даних дерева в процесах пошуку/відстеження. Щоб зовнішньо довести, що транзакція TD існує в дереві Меркла, потрібно лише надати Доказ Меркла, відповідний Кореню, що досить просто. Якщо дерево Меркла особливо велике, з 2^20 листями нижнього рівня (тобто 1 мільйон записів про депозити), Доказ Меркла потрібно буде включати лише значення 21 вузла, що є дуже коротким.

Щоб довести, що транзакція H3 дійсно міститься в дереві Меркла, необхідно продемонструвати, що, використовуючи H3 та інші частини даних на дереві Меркла, можна згенерувати корінь, а дані, необхідні для генерації кореня (включаючи Td), є доказом Меркла. Коли Боб знімає кошти, йому потрібно довести, що його сертифікат відповідає депозитному хешу Cn, записаному на дереві Меркла в бухгалтерській книзі Торнадо. Іншими словами, він повинен довести дві речі: Cn існує у вигаданому Дереві Меркла ончейн Торнадо, зокрема, побудувавши доказ Меркла, що містить Cn; Cn пов'язаний з депозитним сертифікатом Боба.

Бізнес-логіка Торнадо пояснена

У фронтенд-коді користувальницького інтерфейсу Tornado багато функцій попередньо реалізовано. Коли вкладник відкриває веб-сторінку Tornado Cash та натискає кнопку депозиту, супровідний фронтенд-код генерує два випадкові числа, K та r, локально. Потім він обчислює значення Cn = Hash(K, r) та передає Cn (який у діаграмі нижче називається зобов'язанням) контракту Tornado, який вставляє його в дерево Меркля, записане останнім. Фактично, K та r діють як приватні ключі. Вони критично важливі, і система підбадьорює користувачів зберігати їх надійно. K та r знову знадобляться під час виведення.

(Опція encryptedNote дозволяє користувачам шифрувати облікові дані K та r за допомогою приватного ключа та зберігати їх на блокчейні, щоб запобігти забуттю). Важливо, що всі ці операції відбуваються офлайн, що означає, що контракт Tornado та зовнішні спостерігачі не мають уявлення про K та r. Якщо K та r витікають, це майже те ж саме, що й крадіжка приватних ключів гаманця.

Після отримання депозиту від користувача та подання Cn=Hash(K, r) договором Tornado записує Cn в нижньому шарі дерева Меркла як новий листовий вузол, оновлюючи також значення Root. Таким чином, Cn безпосередньо пов'язаний з дією депозиту користувача, що дозволяє стороннім знати, якому користувачеві відповідає кожен Cn, хто вніс токени в змішувач, та записи депозитів Cn кожного депозитора.

Під час процесу виведення коштів клієнт вводить облікові дані/приватний ключ (випадкові числа K і r, згенеровані під час депозиту) на веб-сторінці інтерфейсу. Програма в інтерфейс-коді Tornado Cash використовує K і r, Cn=Hash(K, r) і доказ Меркла, що відповідає Cn, як вхідні параметри для генерації ZK Proof. Це доводить, що Cn існує в дереві Меркла як депозитний запис, а K і r є обліковими даними, відповідними Cn. Цей крок по суті доводить: я знаю ключ, що відповідає депозитному запису на дереві Меркла. Коли ZK Proof подається до контракту Tornado, ці чотири параметри приховуються, захищаючи конфіденційність. Генерація ZK Proof включає додаткові параметри, включаючи корінь Меркла, записаний у контракті Tornado під час відкликання, спеціальну адресу одержувача A та ідентифікатор nf для запобігання повторним атакам. Ці три параметри публічно публікуються в блокчейні, що не ставить під загрозу конфіденційність.

Деталь, на яку слід звернути увагу, полягає у використанні двох випадкових чисел, K і r, для генерації Cn замість одного випадкового числа, що забезпечує підвищений захист від зіткнень. A означає адресу одержувача відкликання, обрану тим, хто відкликає. Ідентифікатор nf, призначений для запобігання повторним атакам, обчислюється як nf=Hash(K), де K — одне з двох випадкових чисел, що використовуються на кроці депозиту для генерації Cn. Це пов'язує nf безпосередньо з Cn, встановлюючи кореляцію один до одного між кожним Cn і відповідним йому nf. Мета запобігання повторним атакам пов'язана з особливістю конструкції мікшера, яка зберігає невідомим зв'язок між сумами виведення коштів і конкретним листям дерева Меркла (Cn), що дозволяє потенційно зловживати повторними зняттям коштів, поки пул коштів не буде вичерпаний.

Ідентифікатор nf працює аналогічно до обов'язкового поля, пов'язаного з кожною адресою Ethereum, що запобігає повторному відтворенню транзакцій. Коли відбувається виведення, перевірка гарантує, що поданий nf не був використаний раніше; якщо не використаний, виведення є дійсним, і nf записується. Будь-яка спроба створити nf, який не пов'язаний з жодним зареєстрованим депозитом Cn, не вдасться виробити дійсний ZK Proof, що робить виведення невдалим.

Якщо хтось випадковим чином згенерує незареєстрований невзаємозамінний (nf) контракт, чи спрацює це? Звичайно, ні. Коли той, хто знімає, генерує доказ з нульовим розголошенням (ZK Proof), він повинен переконатися, що nf дорівнює хешу (K), де випадкове число K пов'язане з депозитним записом Cn. Це означає, що nf пов'язаний із записаним депозитом Cn. Якщо хтось сфабрикує nf довільно, цей nf не відповідатиме жодному депозитному запису, що унеможливлює створення дійсного доказу ZK. Отже, процес виведення коштів не може бути успішно завершений, і операція виведення коштів зазнає невдачі. Хтось може запитати: чи можна обійтися без нф? Оскільки користувач, який знімає кошти, повинен надати доказ ZK під час зняття, щоб довести його зв'язок з певним Cn, чому б просто не перевірити, чи відповідний доказ ZK надсилався в блокчейн щоразу, коли відбувається зняття? Однак цей підхід є дуже дорогим, оскільки контракт Tornado Cash не зберігає на постійній основі минулі ZK Proofs через значні втрати місця для зберігання. Порівняння кожного нового доказу ZK, представленого в блокчейні, з існуючими доказами менш ефективне, ніж встановлення невеликого ідентифікатора, такого як nf, і постійне його зберігання.

Згідно з прикладом коду функції виведення, необхідні параметри та бізнес-логіка такі: Користувач надсилає ZK Proof та nf (NullifierHash) = Hash (K), вказує адресу отримувача для виведення, а ZK Proof приховує значення Cn, K та r, що ускладнює зовнішнім особам визначення ідентичності користувача. Отримувач часто використовує нову, чисту адресу, яка не розголошує особисту інформацію.

Однак є незначна проблема: коли користувачі знімають кошти, щоб їх не можна було відстежити, вони часто ініціюють транзакцію виведення коштів з новоствореної адреси. Наразі за новою адресою не вистачає ETH для оплати плати за газ. Таким чином, ініціюючи зняття коштів, адреса зняття повинна чітко заявити ретранслятора про сплату комісії за газ від його імені. Після цього контракт мікшера вираховує частину з відкликання користувача, щоб компенсувати ретранслятор.

У підсумку, Tornado Cash може затемнити зв'язок між забирачами та вкладниками. У ситуаціях з великою кількістю користувачів це схоже на те, як злочинець зливається з натовпом у шумному районі, ускладнюючи поліції відстеження. Процес виведення включає в себе використання ZK-SNARKs, із прихованою частиною свідка, що містить критичну інформацію про забирача, що є ключовим аспектом усього міксера. На даний момент Tornado, схоже, є одним з найбільш кмітливих проектів на рівні додатків, пов'язаних із ZK.

Відмова:

1. Ця стаття є репринтом з [Гік Веб3], Усі авторські права належать оригінальному авторові [Фауст, гік веб3]. Якщо є заперечення проти цього передруку, будь ласка, зв'яжіться з Gate Learn команди, і вони оперативно впораються з цим.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно тими, хто їх висловив, і не становлять жодної інвестиційної поради.
3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіатування перекладених статей заборонені.