Privacy Pools — это протокол приватных переводов на базе Ethereum, в котором конфиденциальность достигается без жёсткого конфликта с требованиями комплаенса. Ключевая идея: пользователь может выводить средства из «пула приватности» и одновременно публиковать нулевое разглашение (*zero-knowledge*) доказательство того, что его депозит не связан с заранее отмеченными нежелательными источниками, либо что он принадлежит «доброжелательному» подмножеству (*association set*). Таким образом возникает «разделяющее равновесие»: честным участникам проще легально пользоваться приватностью, а злоумышленники со временем вытесняются из «здоровых» множеств.
В отличие от классических миксеров, Privacy Pools строят поведение вокруг ассоциативных множеств и подмножеств депозитов с открыто определяемыми правилами «благонадёжности». Пользователь ничего не раскрывает публично, однако способен доказать «невиновность» перед контрагентом, биржей, банком или аудиторами — при желании и в приватном порядке.
Мотивация и контекст
Проблема миксеров. Традиционные протоколы (в духе Tornado Cash) смешивают депозиты, разрывая ончейн-связь между входом и выходом. Это эффективно для приватности, но «один плохой участник» отравляет всю анонимную массу. В результате добросовестные пользователи рискуют «попутно» оказаться в одном наборе с украденными активами и попасть под ограничения комплаенса.
Принцип Privacy Pools. Вместо того чтобы просто доказывать «мой вывод связан с *каким-то* депозитом из пула», пользователь доказывает членство в более узком наборе — множестве депозитов, *не содержащем* нежелательных адресов/транзакций. Этим множеством управляет независимый «поставщик ассоциаций» (или целая экосистема таких поставщиков). Так система позволяет честным пользователям отделяться от злоумышленников — и при необходимости демонстрировать это отделение.
Компатибельность с комплаенсом. Регулируемым участникам (биржи, брокеры, кастодианы) не нужно «разворачивать» полный граф трат — им достаточно проверить корректность ZK-доказательства о принадлежности вывода к «чистому» множеству. Это можно делать оффчейн в рамках их процедур AML/KYC и политик риска, *без деанонимизации* клиента в ончейн-пространстве.
Архитектура протокола
Компоненты.
- Пул депозитов (Deposit Tree). Контракт поддерживает Merkle-дерево депозитов (листья — коммитменты на депозиты). На каждом депозите привязывается публичный параметр (например, величина/«номинал») и секретные трапыdoors владельца.
- Nullifier’ы. Как и в миксерах, при выводе публикуется «анти-дубль» — nullifier, который уникально «погашает» конкретный депозит. Это предотвращает двойную трату, не раскрывая, какой именно лист погашен.
- Ассоциативные множества. Сторонние провайдеры публикуют «срезы» депозитного дерева — *подмножества* (allowlist) или «изъятия» из полного множества (denylist). Эти подмножества кодируются компактно (битовые строки, дополнительные Merkle-деревья или коммитменты) и могут свободно распространяться.
- Прувер и верификатор ZK. Пользователь локально строит zk-доказательство (включения своего депозита в «хорошее» множество или исключения из «плохого» множества), плюс корректности nullifier’а; контракт или внешний проверяющий валидирует доказательство.
Поток событий. 1) Deposit. Пользователь вносит фиксированный/параметризуемый «номинал» в контракт пула, публикуя коммитмент (лист) и необходимые публичные параметры. 2) Association. Поставщики ассоциаций периодически выпускают наборы «допустимых» (или «исключаемых») депозитов. 3) Prove. При выводе пользователь локально собирает Merkle-путь к своему депозиту, а также доказательство соответствия выбранному ассоциативному множеству (включение/исключение) без раскрытия индекса листа. 4) Withdraw. В транзакции указываются: публичная часть nullifier’а; данные для проверки zkSNARK/zkSTARK; целевой адрес для вывода. Контракт убеждается, что депозит не тратился, и что доказательство корректно относительно выбранного множества.
Почему это работает. Если множество «чистых» депозитов составлено добросовестно (по внешнему анализу ончейн-графа), любое корректное доказательство смерти nullifier’а и членства в множестве сообщает проверяющему: «мои средства не связаны с адресами/событиями из отмеченных источников». При этом ни сам депозит, ни его индекс не раскрываются.
Ассоциативные множества: кто и как их делает
Поставщики ассоциаций (Association Set Providers). Это могут быть:
- аналитические компании и on-chain-следопыты,
- саморегулируемые организации и пулы валидаторов,
- консорциумы бирж/кастодианов,
- сообщества (DAO),
- даже отдельные корпоративные risk-офисы.
Каждый поставщик публикует *описание правил*, по которым формируется множество, и *криптографический коммитмент* этого множества. Политики формируются открыто и могут конкурировать на рынке: кошельки/биржи выбирают какие множества им доверять.
Allowlist vs denylist.
- Allowlist (включение). Пользователь доказывает, что его депозит принадлежит «чистому» подмножеству, составленному из источников, не связанных с инцидентами/санкциями.
- Denylist (исключение). Пользователь доказывает, что его депозит не принадлежит объединению «плохих» источников (в том числе рекурсивно «заражённых» путей).
Доверие и конкуренция. У провайдеров разные критерии, SLA и уровни консервативности. Биржа может потребовать доказательства относительно двух и более независимых множеств, чтобы снизить риск ложного включения/исключения.
Доказательства включения и исключения
Включение (membership). Прувер доказывает:
- «я знаю лист L в *Deposit Tree*,
- L порождает nullifier N,
- L входит в *Subset Tree* (множество «чистых» депозитов)»
— при этом не раскрывая ни L, ни позицию. Проверяющий убеждается, что N не видели раньше и что zk-доказательство консистентно с публичным корнем Subset Tree.
Исключение (exclusion). Прувер доказывает:
- «я знаю лист L из Deposit Tree»,
- «L не принадлежит *Bad-Set* (объединению подозрительных листьев)»,
- «мой nullifier N соответствует L»
— всё также без раскрытия индекса. Техника может комбинировать «бинарный поиск» по дереву с доказательством «значение находится между узлами, но не совпадает», либо работать на уровне битовых масок/коммитментов на «блоки» листьев. Существуют практичные варианты построения таких доказательств прямо в браузере, если есть локальный Merkle-путь к депозиту.
Выбор режима. В UX кошелька это может быть «галочка»: «доказывать включение в allowlist»/«доказывать исключение из denylist». Биржи часто проще принимают включение (allowlist), но юзер вправе предъявить и *exclusion* там, где это соответствует политике риска.
Сравнение с альтернативами
Классические миксеры. Их сила — в простоте, но слабость — в «заражении» анонимного множества: один инцидент — и весь пул под подозрением. В Privacy Pools пользователь сам выбирает, продолжать ли работать с данным поставщиком множеств, и может переиспользовать доказательства для разных контрагентов.
Shielded-пулы (например, Zcash). Зашифрованный пул с нативной приватностью сильно улучшает UX, но в кросс-экосистемной комплаенс-практике часто нужен «канал объяснения происхождения». Privacy Pools строит такой канал через наборы ассоциаций и проверяемые доказательства — без раскрытия траектории монет.
АА и smart-кошельки. В связке с Account Abstraction кошельки могут автоматизировать генерацию и кэширование доказательств, делать «пакетные» выводы на L2, оптимизировать комиссии и подписи — сохраняя совместимость со стандартными RPC и роллапами Rollups.
UX и поток пользователя
Добавление средств. Пользователь депонирует активы (обычно ETH/стейблкоины) в контракт пула. Коммитмент и публичный номинал попадают в дерево депозитов; в кошельке сохраняются секреты (nullifier trapdoor и пр.).
Выбор множества. В настройках кошелька или на фронтенде пула указывается один или несколько «провайдеров ассоциаций». По умолчанию кошелёк может рекомендовать наборы с хорошей репутацией и понятными критериями.
Создание доказательства. На этапе вывода кошелёк извлекает Merkle-путь к депозиту и формирует zk-доказательство *membership* или *exclusion* относительно выбранного множества. Вычислительная нагрузка сегодня укладывается в возможности десктоп/мобайл при умеренных размерах дерева; для длинных деревьев используют «пачки»/частичную синхронизацию.
Публикация вывода. Контракт проверяет: nullifier не использован, доказательство проходит относительно актуальных корней дерева депозитов и множества ассоциаций. При успехе — перевод на адрес получателя кошелька.
Доказательство третьим лицам. По запросу биржи/банка пользователь может переслать «самодостаточный» пакет: публичные корни деревьев, свой zk-пруф, данные о nullifier’е. Проверка идёт оффчейн и не требует раскрытия полного ончейн-графа.
Комиссии и производительность
Ончейн расходы. Deposit/withdraw — обычные транзакции Ethereum-транзакциями с вызовом контракта; комиссия зависит от выбранной L1/L2 и текущей нагрузки. В роли «движка доказательств» применяют zkSNARK/zkSTARK (верификация на L1 дешёвая в SNARK-сценариях, дороже — для STARK без агрессивной оптимизации).
Off-chain вычисления. Генерация пруфа — основная нагрузка на устройство пользователя. Современные имплементации делают это в браузере или в нативном кошельке, кэшируя подготовительные артефакты. Пакетные оптимизации и «тонкие» пруверы уменьшают задержки.
Mempool и фронт-ран. Поскольку выводы имеют предсказуемую форму, фронт-ран не несёт серьёзной угрозы приватности (смысл в содержимом пруфа, а не в цене газа). Тем не менее кошельки применяют обычные меры вроде maxFeePerGas/maxPriorityFee и ретраев.
Риски и ограничения
Качество ассоциативных множеств. Если провайдер ошибочно пометил «чистые» депозиты как «плохие», честный пользователь вынужден искать альтернативного провайдера или доказывать *exclusion*. Решение — мульти-провайдерность и внутренние аттестации качества.
Риски централизации. Если рынок провайдеров скукожится до 1–2 компаний, модель станет фактически «квазицензурной». Важно поддерживать открытые форматы множеств, конкурентность и простую интеграцию в кошельки.
Сложные случаи происхождения. В реальном графе транзакций «грязные» средства могут смешаться, а «заражение» распространяется по ветвям. Политики провайдеров должны чётко описывать глубину анализа (рекурсивность) и пороговые правила, чтобы не превратить систему в «тотальную презумпцию виновности».
Юридические рамки. Privacy Pools — инструмент, а не гарантия правовой чистоты. Биржи/банки в разных юрисдикциях будут трактовать доказательства по-своему; пользователю важно понимать местные правила и не нарушать законы.
Экономика атак. Теоретически возможны «отравления» множеств (подача фейковых «добрых» листьев) и попытки коррелировать выводы по таймингу/суммам. Лечатся валидациями со стороны провайдеров, батчингом и деноминациями.
Интеграции с L2 и будущее экосистемы
L2-выводы. Privacy Pools хорошо сочетаются с роллапсами: депозиты на L1 → массовые выводы в L2 с пруфами → дешёвые частые платежи в приватной зоне L2 → при необходимости «обратный мост» на L1 с новым доказательством.
Смарт-кошельки. С Account Abstraction кошельки автоматизируют «проверки на соответствие политике»: выбирают поставщика множеств, заранее тасуют деноминации, планируют комиссии и выполняют вывод «в одно нажатие».
Навигация по приватности. В связке с нашими базовыми материалами Приватность и Безопасность в крипте пользователи получают более гибкий набор инструментов: от простых stealth-платежей до полноценной «доказываемой приватности» под требования бизнеса.
Сравнение подходов к приватности на Ethereum
| Решение | Где «живёт» приватность | Комплаенс-френдли доказательства | Роль провайдеров | UX/Особенности |
|---|---|---|---|---|
| Privacy Pools | Ончейн-пул + оффчейн пруфы | Да (membership/exclusion) | Провайдеры ассоциативных множеств | Гибкое отделение «честных» пользователей |
| Классические миксеры | Ончейн-пул | Нет (обычно) | Нет | Приватность «общего котла», риск «заражения» |
| Shielded-пулы (zk) | Ончейн зашифрованный пул | Ограниченно (внешние каналы) | Нет | Превосходный UX, но слабая «объяснимость» |
| Таин-платёж через DEX/DeFi | Off-chain опосредование | Нет | Нет | Косвенная приватность, риск утечек |
| Кастодиальные сервисы | Off-chain у провайдера | Зависят от сервиса | Провайдер = «всё» | Централизация, KYC by default |
Практика внедрения (для кошельков и сервисов)
Кошельки.
- Встраивайте двойной режим пруфов: *allowlist membership* и *denylist exclusion*.
- Кэшируйте ветви Merkle и подготовку пруверов; показывайте оценку времени/ресурсов.
- Добавляйте «мульти-провайдера»: пользователю проще предъявлять доказательство сразу по 2–3 множествам.
- Объясняйте UX различия: что именно доказывается и кому будет отправлено (биржа, мерчант).
- Поддержите L2: вывод с пруфом на Rollup и обратно на L1 по запросу.
Биржи/бизнес.
- Примите машиночитаемые форматы множеств и верификации пруфов; храните аудиторский след.
- Не завязывайтесь на одного провайдера; определите «политику глубины» анализа.
- Введите SLA-процедуры: сколько времени принимаете пруфы, при каких видах инцидентов требуется повторное доказательство.
Провайдеры множеств.
- Публикуйте открытые спецификации и хеши корней; версионируйте релизы множеств.
- Описывайте источники данных, методики рекурсии по графу, критерии «добра/зла».
- Придерживайтесь «policy-as-code»: пусть кошельки могут автоматически проверять совместимость.
FAQ
Чем Privacy Pools отличаются от Tornado Cash? В Tornado Cash анонимное множество «монолитно», и связь с «плохими» депозитами обесценивает приватность для всех. В Privacy Pools пользователь доказывает, что его депозит принадлежит «хорошему» множеству (или не принадлежит «плохому»), и это доказуемо без раскрытия личности/трассы.
Нужно ли проходить KYC? Нет, на уровне протокола — не нужно. Но конкретная биржа/банк может запросить ваше zk-доказательство о «чистоте» относительно их множества. Это альтернатива тотальному KYC при переводах из приватных пулов.
Кто решает, что «хорошо», а что «плохо»? Независимые провайдеры ассоциативных множеств. Вы можете выбирать, какому из них доверять, или предъявлять доказательство сразу по нескольким.
Можно ли использовать один и тот же депозит много раз? Нет. Nullifier не позволит «потратить» депозит дважды: как только вы вывели средства с пруфом, второй раз тот же лист использовать нельзя.
Насколько это тяжело для устройства? Создание пруфа занимает секунды/минуты в зависимости от размера деревьев и устройства. Современные реализации поддерживают встроенный прувер в браузере/кошельке.
Будет ли это работать на L2? Да, архитектура совместима с роллапами. Верификация пруфов на L2 дешевле, а мостирование на L1 возможно с минимальными доработками.