Введение:

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

Следует отметить, что проекты, подобные Tornado, которые представляют собой проекты в области конфиденциальности, действительно используют аспект нулевого знания алгоритма ZK-SNARK. Тем временем, большинство решений, рекламирующих ZK, такие как Rollups, просто используют лаконичность ZK-SNARK. Часто люди склонны смешивать Доказательство Правильности с ZK, и Tornado служит отличным примером для пояснения реального применения ZK.

Автор этой статьи написал статью о принципах Tornado еще в 2022 году для исследований Web3Caff. Сегодня мы извлекли и расширили определенные разделы из этой оригинальной работы, чтобы обеспечить системное понимание Tornado Cash.

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

Принцип "Tornado"

Tornado Cash использует доказательство нулевого знания в качестве протокола смешивания. В то время как его старая версия была запущена в 2019 году, бета-версия обновленной модели была выпущена в конце 2021 года. Более ранняя версия Tornado достигла хорошего уровня децентрализации благодаря тому, что ончейн-контракты были открытым исходным кодом и свободны от контроля мультиподписи. Более того, код фронтенда был открытым исходным кодом и резервировался в сети IPFS. Из-за простоты более ранней версии Tornado данный материал сосредотачивается на ее объяснении.

Основной подход Tornado заключается в смешивании множества действий по депозиту и выводу вместе. После депонирования токенов в Tornado депозиторы предъявляют ZK Proof для подтверждения своего предыдущего депозита, а затем выводят их, используя новый адрес, тем самым разрывая связь между адресами депозита и вывода.

Более кратко можно представить Tornado как стеклянный ящик, наполненный монетами (Coins), внесенными многими людьми. Мы можем видеть, кто внес монеты, но эти монеты очень однородны. Если кто-то незнакомый возьмет монету из ящика, будет трудно отследить, кто изначально положил эту монету туда.

（Источник изображения: rareskills）

Такие сценарии кажутся обыденными. Когда мы обмениваем несколько ETH из пула Uniswap, невозможно определить, чей ETH мы получили, учитывая многочисленных поставщиков ликвидности для Uniswap. Однако разница заключается в процессе. Для Uniswap обмен токенов требует другой токен в качестве эквивалентной стоимости, и средства не могут быть «переданы» в «приватном» порядке. В отличие от этого, миксер просто требует, чтобы снимающий представил свой квитанцию о депозите.

Для того чтобы действия по депозиту и выводу выглядели однородными, пул Tornado поддерживает однородность сумм депозита и вывода. Например, если у пула есть 100 депозиторов и 100 выводящих, хотя действия общедоступны, между ними не кажется быть никакой связи. Каждый вносит депозит и выводит одинаковую сумму, что затрудняет отслеживание движения средств. Очевидно, что это обеспечивает встроенное преимущество для отмывания денег.

Ключевой вопрос возникает: при выводе, как доказать свой предыдущий депозит? Адрес, инициирующий вывод, не связан ни с одним адресом депозита, так как можно подтвердить право на вывод? Самый прямой метод заключается в том, чтобы выводящий раскрыл свою запись депозита, но это выставит его личность. Вот где вступают в игру доказательства нулевого знания.

С помощью доказательства ZK снимающая сторона может подтвердить, что у неё есть запись о депозите в контракте Tornado и что этот депозит ещё не был снят. Преимущество доказательств с нулевым разглашением заключается в их способности сохранять конфиденциальность. Публика знает только о том, что снимающая сторона действительно сделала депозит, но не может определить их конкретную личность.

Для того чтобы доказать, что «Я внес депозит в пул Tornado», можно перевести как «Мой депозитный рекорд можно найти в контракте Tornado». Если Cn обозначает депозитный рекорд, то учитывая установленный депозитный рекорд Tornado в виде {C1, C2,…C100…}, Бобу необходимо доказать, что он использовал свой приватный ключ для создания рекорда в этом наборе, не раскрывая, какой именно Cn это. Это использует уникальные свойства доказательства Меркля.

Все записи о депозите Tornado агрегируются в построенное on-chain дерево Меркля. Большинство этих листьев (около 2^20, более 1 миллиона) остаются пустыми (с начальным значением). Каждый новый депозит обновляет соответствующий лист обязательства, а затем корень дерева.

Например, если депозит Боба был десятым тысячным в истории Торнадо, связанное значение Cn будет десятым тысячным листом дерева, т.е. C10000 = Cn. Затем контракт автоматически вычислит новый корень.

（источник изображения: RareSkills）

Доказательство Меркля само по себе краткое и эффективное. Чтобы доказать, что транзакция TD существует в дереве Меркля, достаточно предоставить соответствующее доказательство Меркля, которое остается компактным даже в том случае, если дерево Меркля огромно.

Для подтверждения того, что транзакция, скажем, H3, действительно включена в дерево Меркля, нужно доказать, что с использованием H3 и других данных из дерева Меркля можно сгенерировать корень. Эти данные (включая Td) составляют доказательство Меркля. Когда Боб хочет снять средства, ему нужно проверить две вещи:

·Cn находится в Merkle Tree, построенном on-chain Tornado, для которого он может составить доказательство Merkle, содержащее Cn；

·Cn связан с депозитным купоном Боба.

Объяснение бизнес-логики торнадо

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

«ЗашифрованнаяЗаметка» - это дополнительная функция, которая позволяет пользователям шифровать учетные данные k и r с помощью частного ключа и сохранять их на цепи, чтобы избежать забывания.

Строки, указанные выше, выполняются вне сети, что означает, что ни контракт Tornado, ни внешние наблюдатели не знают о K и r. Если K и r будут раскрыты, это аналогично краже приватного ключа вашего кошелька.

Получив депозит пользователя и вычислив Cn=Hash(K, r), контракт Tornado помещает Cn на базовый уровень дерева Меркля, превращая его в новый листовой узел и последующим образом обновляя значение корня. Однако важно понимать, что листья этого дерева Меркля не регистрируются в статусе контракта, а записываются лишь в качестве параметров событий в прошлых блоках. Контракт Tornado регистрирует только корень Меркля. При выводе пользователи могут доказать, с помощью доказательства Меркля, что запись депозита соответствует текущему корню Меркля, концепция отчасти напоминает выводы моста межцепочных клиентов light client. Этот дизайн раскрывает оригинальность Tornado: чтобы сэкономить на газовых расходах, полное дерево Меркля не регистрируется в статусе контракта, только его корень. Листья дерева просто записываются в исторические блок-записи, механизм отчасти аналогичен принципу экономии газа Rollup (хотя детали отличаются).

Во время процесса вывода выводящее лицо вводит учетные данные/приватные ключи (случайные числа K и r, сгенерированные во время депозита) на веб-странице фронтенда. Код фронтенда Tornado Cash использует K и r, Cn=Hash(K, r), и доказательство Меркля, соответствующее Cn, для генерации ZK-доказательства, тем самым подтверждая, что Cn соответствует записи о депозите в дереве Меркля, и что K и r являются действительными учетными данными для Cn. Этот шаг в основном доказывает знание ключей записи о депозите в дереве Меркля. Когда ZK-доказательство представляется контракту Tornado, все четыре параметра скрываются, обеспечивая незнание сторонников, включая сам контракт Tornado, и тем самым защищая конфиденциальность пользователя.

Интересный момент заключается в том, что при выполнении операции депозита используются два случайных числа, K и r, для генерации Cn вместо одного, потому что одно случайное число может быть недостаточно безопасным и потенциально поддающимся методу грубой силы.

Относительно символа “A” на иллюстрации, он представляет адрес для получения вывода и предоставляется лицом, совершающим вывод. Тем временем, “nf” является идентификатором, установленным для предотвращения атак повторной передачи, его значение определяется как nf=Hash(K), где K является одним из двух случайных чисел (K и r), используемых при депозите для генерации Cn. Таким образом, каждому Cn соответствует соответствующий nf, и они уникально связаны.

Почему нужно предотвращать атаки повторной передачи? Благодаря особенностям конструкции миксера при выводе средств неясно, какой депозит в дереве Меркла соответствует выведенным средствам. Поскольку связь между вкладчиком и выведенными суммами остается неясной, злоумышленники могут использовать это и многократно выводить средства из миксера, истощая пул токенов.

Здесь идентификатор nf работает аналогично счетчику транзакций «nonce», присущему каждому адресу Ethereum, установленному для предотвращения повторных транзакций. При запросе на вывод пользователи должны представить nf. Система проверяет, использовался ли этот nf ранее: если да, вывод отменяется; если нет, вывод выполняется, и nf записывается, гарантируя, что его последующее использование приведет к его аннулированию.

Некоторые могут задаться вопросом: Может ли кто-то подделать nf, который контракт не записал? Это маловероятно. При генерации доказательства ZK важно убедиться, что nf=Hash(K), и случайное число K связано с записью депозита Cn. Если кто-то произвольно создаст nf, он не совпадет ни с одним из записанных депозитов, что делает невозможной генерацию действительного доказательства ZK, в результате чего процесс вывода средств приостановится.

Другие могут спросить: существует ли способ обойти использование nf? Поскольку выводы должны представить доказательство ZK, подтверждающее их связь с определенным Cn, не будет ли достаточно проверить, было ли соответствующее доказательство ZK уже зарегистрировано в сети? Однако затраты, связанные с таким подходом, чрезмерны, поскольку контракт Tornado Cash не вечно хранит ранее представленные доказательства ZK, чтобы избежать потерь памяти. Сравнивать каждое новое доказательство ZK с существующими для обеспечения согласованности требует гораздо больше ресурсов, чем просто регистрировать компактный идентификатор, подобный nf.

В соответствии с примером кода функции вывода, требуемые параметры и бизнес-логика следующие: Пользователи представляют доказательство ZK, nf (NullifierHash) = Hash(K), и назначают адрес получателя для вывода. Доказательство ZK скрывает значения Cn, K и r, обеспечивая невозможность определения личности пользователя внешним миром. Обычно получатели указывают чистый, новый адрес, чтобы предотвратить раскрытие личной информации.

Однако возникает небольшое препятствие: когда пользователи выводят средства, они часто используют только что созданные адреса для инициирования транзакции вывода с целью обеспечения невозможности отслеживания. В такие моменты эти новые адреса не имеют достаточно ETH для оплаты комиссии за газ. Поэтому при выводе адрес должен явно указать посредника для оплаты комиссии за газ. Впоследствии контракт миксера удерживает часть суммы вывода пользователя для компенсации посредника.

В заключение, Tornado Cash может затруднить связь между вкладчиками и выводящими. Когда есть большая база пользователей, это похоже на преступника, смешавшегося с оживленной толпой, что затрудняет задачу властям. Процесс вывода использует ZK-SNARK, причем скрытая «свидетель» часть содержит ключевую информацию о выводящем. Это, вероятно, самая важная функция миксера. В настоящее время Tornado, возможно, является одним из самых умных приложений, связанных с ZK.

Отказ от ответственности：

1. Эта статья перепечатана с [средний]. Все авторские права принадлежат оригинальному автору [Faust,极客web3]. Если у вас есть возражения к этому перепечатыванию, пожалуйста, свяжитесь с командой Gate Learn（gatelearn@gate.io）, и они немедленно разберутся с этим.
2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, принадлежат исключительно автору и не являются какими-либо инвестиционными рекомендациями.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.