Главная Top Privacy Pools: баланс приватности и комплаенса, видение Виталика

Privacy Pools: баланс приватности и комплаенса, видение Виталика

От

21.09.2023

В сентябре Виталик Бутерин (Ethereum Foundation), Якуб Иллум (Chainalysis), Матиас Надлер, Фабиан Шер (оба – Университет Базеля) и Амин Солеймани (ex-Tornado Cash) опубликовали статью, в которой изложили концепцию Privacy Pools, нового протокола на базе смарт-контракта, позволяющего, по замыслу авторов, повысить конфиденциальность транзакций в публичных блокчейнах без ущерба для комплаенса.

В основе предложения лежит идея о том, чтобы позволить пользователям публиковать zero-knowledge доказательство того, что их средства (не) были получены из известных (не)законных источников, не раскрывая публично весь граф своих транзакций. Достигается это через доказательство принадлежности к тому или иному настраиваемому ассоциированному множеству — пулу, удовлетворяющему определённым регулятивным требованиям или общественному консенсусу.

Ключевые идеи

Использовать zero-knowledge доказательства (ZK-proofs) для сокрытия связи между транзакциями депозита и вывода в протоколе микшера типа Tornado Cash. Это позволяет скрыть граф транзакций пользователя.
Протокол позволяет пользователям создавать “ассоциированные множества” (association sets) — ограниченные анонимные множества из депозитов, с которыми может быть связан пользовательский вывод. Микширование де-факто ограничивается выбранным ассоциированным множеством.
Пользователи могут доказывать принадлежность к соблюдающим комплаенс — например, исключающим известные незаконные депозиты, — ассоциированным множествам, не раскрывая, какой именно депозит в этом пуле принадлежал им.
Честные пользователи имеют стимул выбирать соблюдающие комплаенс сеты, в то время как известные криминальные источники не имеют такой возможности. Это формирует “разделительное равновесие”.
Ассоциированные множества могут строиться по различным правилам — например, требовать от всех пользователей прохождения KYC или точечно исключать высокорисковые депозиты, — благодаря чему разные сеты могут удовлетворять различным регулятивным требованиям.
Пользователи не раскрывают публично свои ассоциированные множества, но только собственную принадлежность к тому или иному сету.
При необходимости пользователи могут раскрывать контрагентам непосредственный источник средств. Ясно, что это подразумевает доверие.
Для ускорения цепочки транзакций пользователи передают историю расходуемых монет, чтобы доказать, что исходный источник средств отвечает определённым правилам.

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

Давайте теперь изучим предложение подробнее.

Навигация:

Введение
Технический контекст
- Различия Privacy Pools и Tornado Cash
Практическое применение и сценарии использования
Технические подробности
- Поддержка произвольных номиналов
- Особые случаи
Обсуждение

Введение: почему это важно и механизм работы

Почему это важно

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

Авторы предложения приводят такой пример: вы идёте в ресторан и оплачиваете ужин со своего блокчейн-кошелька. Получателю становится известен ваш адрес вместе со всей его историей транзакций, прошлой и будущей. Аналогично и вы теперь знаете адрес кошелька ресторана, и можете при желании воспользоваться этим для получения адресов его посетителей или составить представление об этой части доходов ресторана. И третьи лица, знающие биткойн-адрес ресторана и о том, что вы там бываете (например, из социальных сетей), могут довольно легко вычислить ваш биткойн-адрес вместе с историей транзакций по нему, прошлых и будущих.

Пример с рестораном можно (пока) назвать гипотетическим, но в целом эта концепция применима к любым операциям в публичных блокчейнах: транзакции записываются в открытом виде, и доступны для анализа любому желающему.

Эта проблема привела к появлению протоколов, повышающих конфиденциальность транзакций. В общем случае такие протоколы позволяют пользователям вносить средства в протокол с одного адреса и, позже, выводить их уже на другой адрес. Транзакции депозита и вывода средств по-прежнему записываются в блокчейн, но связь между конкретными депозитом и выводом скрывается.

Одним из наиболее известных подобных “приватных” протоколов — попросту, миксеров, — является Tornado Cash. Он успешно решает описанную выше проблему, позволяя пользователям сохранять конфиденциальность. Однако, помимо законопослушных пользователей, беспокоящихся о конфиденциальности своих данных, Tornado Cash активно использовался и различными злоумышленниками, включая крупнейшую хакерскую группировку Lazarus Group, ассоциируемую с Северной Кореей, о чём свидетельствуют ончейн-данные о депозитах на адрес смарт-контракта миксера. В конечном счёте это привело к включению адресов Tornado Cash в санкционный список (SDN) Управления по контролю за иностранными активами (OFAC) США, что стало первым неприятным прецедентом введения санкций против смарт-контракта с открытым исходным кодом, а позднее — и уголовного преследования разработчика протокола.

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

В своей статье Бутерин и соавт. рассматривают расширение этого подхода, которое позволило бы пользователям публиковать информативное, но вс\ же достаточно широкое доказательство того, с каким множеством депозитов связана конкретная транзакция вывода. Это позволяет реализовать доказательства принадлежности или, наоборот, непричастности к определённому множеству. Общая концепция протокола была предложена Амином Солеймани в Privacy Pools (GitHub). В сентябрьской же статье авторы подробно рассматривают это предложение и объясняют, как его можно использовать для формирования разделительного равновесия между законопослушными пользователями микшера (с сохранением конфиденциальности) и криминальными акторами.

Механизм работы

Privacy Pools: баланс приватности и комплаенса, видение Виталика — *(Источник)*

Пользователи делают депозиты в общий privacy pool как обычно. Каждому депозиту присваивается уникальная пара секрет/coin-ID.
При выводе средств пользователь определяет ассоциированное множество — то множество депозитов, с которыми, по его утверждению, может быть связан данный вывод.
Пользователь предоставляет zkSNARK доказательство, показывающее:
1. что его coin-ID есть в общем дереве депозитов;
2. что его coin-ID есть также в дереве хешей указанного ассоциированного множества.
Корень дерева хешей ассоциированного множества публичен, но отдельные его участники не раскрываются.
Ассоциированные множества курируются провайдерами на основе определённых правил, например, недопуска депозитов от известных криминальных адресов или UTXO с криминальной историей.
Доказывая принадлежность к отвечающему требованиям комплаенса ассоциированному множеству, пользователь демонстрирует соответствие регулятивным требованиям, не раскрывая непосредственно своего депозита.
При необходимости пользователи могут предоставлять контрагентам и непосредственный источник средств, раскрывая конкретный депозит, но это подразумевает высокий уровень доверия к контрагенту.
При быстром расходовании по цепочке транзакций пользователи передают также минимально необходимую историю “монет”, чтобы показать соответствие комплаенсу конечного источника средств.
У пользователей есть стимул подтверждать принадлежность к “комплаентным” множествам и возможность это сделать, в то время как криминальные пользователи не могут предоставить такого доказательства.

Два ключевых стимула

…которые, как ожидают авторы, будут способствовать принятию Privacy Pools честными пользователями

Желание конфиденциальности.

Публичные блокчейны раскрывают все детали транзакций. Это нарушает конфиденциальность пользователей.
Privacy Pools скрывает детали транзакций и нарушает построение графов, повышая уровень конфиденциальности.
Пользователи мотивированы использовать этот протокол для сохранения конфиденциальности своих финансовых операций.

Желание избежать подозрений.

Незаконная деятельность на прозрачных блокчейнах вызывает подозрения и приводит к проблемам с внесением в “чёрные” санкционные списки.
Privacy Pools позволяют пользователям доказать отсутствие связи с незаконными источниками.
Честные пользователи заинтересованы в использовании этой возможности, чтобы избежать подозрений в неправомерных действиях или “замораживания” средств.
Уже само участие в системе показывает, что вы не пытаетесь скрыть незаконное происхождение средств.Стимулы сбалансированы для массового принятия: от использования Privacy Pools выигрывают и те, кто стремится к конфиденциальности, и те, кто заинтересован в соблюдении регулятивных требований.

То есть по замыслу авторов, Privacy Pools стремится к нахождению идеального баланса между конфиденциальностью и соблюдению регулятивных требований на публичных блокчейнах.

Технический контекст

В этом разделе авторы приводят краткий технический обзор, обсуждают составные блоки и общие принципы работы Privacy Pools и подобных ему протоколов.

Приватность блокчейнов до ZK-SNARK

Исторически сторонники блокчейнов утверждали, что блокчейн может сохранять конфиденциальность, несмотря на прозрачность всех транзакций в нём, благодаря псевдонимности пользователей. Сатоши в своей уайтпейпер писал, что «приватность можно сохранить, если публичные ключи будут анонимными. Открытой будет информация о том, что кто-то отправил кому-то некоторую сумму, но без привязки к конкретным личностям».

К сожалению, такой уровень конфиденциальности оказался недостаточным перед лицом современных методов кластеризации и анализа. Нефинансовые приложения ещё больше усложняют сохранение конфиденциальности, часто требуя от пользователей публикации ончейн иного рода информации о себе. Например, регистрация имени на децентрализованных сервисах доменных имён, таких как ENS, предполагает выполнение транзакции в блокчейне Ethereum, создавая публичную связь между транзакциями и доменным именем в ENS.

По этой причине для публичных блокчейнов создаются дополнительные инструменты повышения конфиденциальности их пользователей. Первым нетривиальным решением такого рода, получившим значительное распространение, стали CoinJoin. Протокол CoinJoin предполагает объединение небольших групп пользователей и смешивание их монет между собой в рамках одной транзакции. По записям в блокчейне при этом можно увидеть только общее множество входов и выходов данного раунда CoinJoin-микширования, но не то, с каким входом соотносится какой выход. По задумке пользователь мог участвовать во многих раундах CoinJoin-микширования подряд с разными группами пользователей, таким образом скрывая источник средств среди множества возможных входов. Авторы протокола Monero пошли дальше, использовав схему кольцевой подписи (PDF), позволяющую пользователям микшировать свои монеты с несколькими другими пользователями без всякого взаимодействия вне блокчейна. По мере совершенствования технологии (PDF) число участников каждого раунда микширования росло, увеличивая анонимное множество каждой транзакции. Однако такие методы итеративного микширования в малых группах неизбежно несут в себе риски утечки данных (PDF).

Следующим логическим шагом в поисках повышения криптографической приватности стала реализация zero-knowledge proofs (“доказательств с нулевым знанием”) общего назначения в блокчейнах типа Zcash и ончейн смарт-контрактах наподобие Tornado Cash. В таких системах анонимное множество каждой транзакции потенциально равно множеству всех предыдущих транзакций. Zero-knowledge proofs такого типа в криптосфере и научном сообществе чаще всего называют ZK-SNARK.

ZK-SNARK

ZK-SNARK — это технология, позволяющая доказывающему доказать математические утверждения о некоторой комбинации открытых и закрытых данных, которыми он обладает, таким образом, чтобы это удовлетворяло двум ключевым свойствам:

Нулевое знание: то есть никакая часть приватных данных не раскрывается, кроме того факта, что эти данные удовлетворяют доказываемому утверждению.
Сжатость: доказательство короткое (в байтах) и может быть проверено очень быстро, даже если в основе доказываемого утверждения лежат тяжёлые вычисления, выполняемые длительное время.

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

“Утверждение”, доказываемое ZK-SNARK, выражается как тип программы, которую часто называют “схемой”. Математически её возможно и достаточно представить как функцию f(x,w) → True, False, где x — открытый вход, w — приватный вход, а f(.) — вычисляемая функция. ZK-SNARK доказывает, что для заданного значения x, известного как проверяющему, так и проверяемому, проверяющему известно w, такое, что f(x,w) возвращает True.

Пример: ZK-SNARK в Zcash и Tornado Cash-подобных системах

Между разными версиями Zcash и разными версиями вдохновлённых им систем, таких как Tornado Cash, есть незначительные различия. Однако базовая логика работы этих протоколов очень похожа. Её описанию — в некотором упрощении — и посвящён этот раздел.

Цифровая “монета” состоит из секрета s , который хранит её владелец. Из s могут быть получены два значения:

Публичный coin-ID L = hash(s+1)
Аннулирующий элементU = hash(s+2)

hash здесь обозначает криптографическую хеш-функцию, например SHA256. Имея s, можно вычислить coin-ID и аннулирующий элемент (nullifier). Однако при наличии множества аннулирующих элементов и публичных coin-ID псевдослучайное поведение хеш-функции гарантирует, что вы не сможете определить, какой аннулирующий элемент связан с каким coin-ID, если только не знаете секрет s, их сгенерировавший.

В блокчейне ведётся учёт всех уже “созданных” coin-ID и всех уже “потраченных” “нуллификаторов”. Оба множества постоянно растут, если только протокол не хочет ввести лимит времени, в течение которого монеты должны быть потрачены.

Множество coin-ID хранится в структуре данных, называемой деревом хешей: если дерево содержит N элементов, то хешируется каждая смежная пара элементов (что даёт ⌈ N/2 ⌉ хешей), потом хешируется каждая смежная пара этих хешей (давая ⌈ N/4 ⌉ хешей), и так далее, пока все данные не будут сведены к одному корневому хешу.

Имея конкретное значение в дереве и корневой хеш, можно определить ветвь этого дерева — “сестринские” значения, получаемые объединением хешей на каждом шаге от данного значения до корневого хеша. Эта ветка полезна тем, что представляет собой небольшой (log2(N) хешей) фрагмент данных, который можно использовать для доказательства нахождения в дереве любого из записанных в нём конкретных значений.

L, по которому производится проверка; нижняя строка дерева представляет собой полный набор данных. Зелёным показан корневой хеш R, синим — путь от листа к корню дерева, фиолетовым — “сестринские” узлы на каждом уровне. Заметьте, что путь можно вычислить, начав с листа и хешируя его вместе с сестринским узлом на каждом уровне, так что нет необходимости предоставлять сам путь.

Отправляя монету кому-то ещё, пользователь предоставляет (i) аннулирующий элемент U, который он хочет потратить, (ii) новый coin-ID L′, который он хочет создать (он попросит получателя его предоставить), и (iii) ZK-SNARK.

ZK-SNARK содержит следующие приватные входные данные:

Секрет пользователя s
Ветку в дереве coin-ID, доказывающую, что монета с ID
L = hash(s+1) действительно была создана в какой-то момент в прошлом

Он также содержит следующие публичные входы:

U — нуллификатор расходуемой монеты
R — корневой хеш, по которому проверяется наличие coin-ID в дереве

ZK-SNARK доказывает два свойства:

U = hash(s+2)
Валидность соответствующей ветви дерева хешей

За пределами ZK-SNARK протокол проверяет также, что:

R является текущим или историческим корневым хешем дерева coin-ID
U не входит в множество уже потраченных нуллификаторов

Если транзакция валидна, то она добавляет U в множество потраченных нуллификаторов, а L′ — в список coin-ID.

Раскрытие U не позволяет дважды потратить одну монету. Однако никакая другая информация не раскрывается. Всё, что видно извне, — это время отправки транзакций; наблюдатель не получает никаких знаний об отправителях или получателях, или о том, какая монета является “той же”, что и предыдущая.

Из этой схемы есть два исключения: транзакции депозита и вывода. В случае депозита coin-ID создаётся без необходимости аннулирования предыдущей монеты. Депозиты не являются сохраняющими приватность в том смысле, что связь между данным L и внешним событием, позволившим добавить этот L (в Tornado Cash это депозит ETH в систему, в Zcash — майнинг новых ZEC), является публичной. Другими словами, депозиты связаны с прошлой историей транзакций. При выводе средств аннулирующий элемент расходуется без добавления нового coin-ID. Это скрывает связь вывода с соответствующим депозитом и, как следствие, с историей прошлых транзакций. Однако этот вывод может быть связан с любыми последующими транзакциями.

В первой версии Tornado Cash не было концепции внутренних переводов, она предполагала только пополнение и вывод средств. Более поздние версии, пока ещё находящиеся в стадии эксперимента (альфа-тестирования), также позволяют осуществлять внутренние переводы, а также использовать транзакции произвольного номинала, включая поддержку split (“разделения”) и merging (“слияния”) — операций, необходимых для работы с произвольными номиналами. О том, как расширить базовые системы конфиденциального трансфера и Privacy Pools до работы с произвольными номиналами, поговорим в следующем разделе.

ZK-SNARK в Privacy Pools

Основная идея Privacy Pools заключается в следующем: вместо zero-knowledge доказательства просто связи с некоторым сделанным ранее депозитом, пользователь доказывает принадлежность к более ограниченному ассоциированному множеству. Ассоциированное множество может включать в себя все сделанные ранее депозиты, только собственный депозит конкретного пользователя, или средний вариант — некое подмножество сделанных депозитов. Пользователь определяет конкретное ассоциированное множество, предоставляя в качестве публичного ввода корневой хеш соответствующего дерева.

Чтобы не усложнять, мы не доказываем напрямую, что ассоциированный сет действительно является подмножеством сделанных ранее депозитов; вместо этого мы просто требуем от пользователя предоставить zero-knowledge доказательства принадлежности [одного и того же] coin-ID к веткам двух деревьев хешей: (i) от R, корня общего множества coin-ID, и (ii) от корня предоставленного ассоциированного множества R_A.

Подразумевается, что полное ассоциированное множество доступно где-то — в блокчейне или где-либо ещё. В этом и заключается основная концепция: вместо того чтобы делать выбор между указанием точного депозита, с которым ассоциируется пользовательский вывод, или (другая крайность) вовсе не предоставлять никакой информации, кроме доказательства отсутствия двойной траты, пользователю здесь даётся возможность указать множество возможных источников происхождения его средств, произвольно широкое или узкое. Это, по мнению авторов, способствует формированию экосистемы, которая облегчит пользователям определение ассоциированных множеств, соответствующих их предпочтениям. Остальная часть статьи посвящена описанию инфраструктуры, созданной на основе этой простой базовой механики, а также её последствиям.

Различия Privacy Pools и Tornado Cash

Основное различие состоит в том, что в Tornado Cash используется универсальное анонимное множество, что означает, что все вводимые средства смешиваются в одном пуле, независимо от их происхождения или каких-либо иных факторов.

В Privacy Pools используется настраиваемое анонимное множество, то есть пользователи могут выбирать, с какими депозитами будут микшироваться их средства исходя из собственных предпочтений и потребностей.

Privacy Pools vs. Tornado Cash

Функциональность	Privacy Pools	Tornado Cash
Выборочное раскрытие информации	Позволяет пользователям подтверждать принадлежность к настраиваемым ассоциированным сетам, отвечающим определённым регуляторным требованиям или общественному мнению	Позволяет пользователям выбирать различные анонимные множества в зависимости от количества ETH или ERC-20 токенов, которые они хотят микшировать
Комплаенс	Позволяет пользователям опционально доказывать соответствие или несоответствие требованиям комплаенса через принадлежность к определённым ассоциированным сетам	Не имеет встроенных функций комплаенса и внесён в “чёрный список” Минфина США за содействие незаконной деятельности
Стимулы	Стимулирует честное поведение через доказательства комплаенса, поскольку честные пользователи будут иметь преимущество перед нечестными с точки зрения репутации и доверия	Не имеет никаких стимулов к соблюдению требований комплаенса, обладая свободным доступом и бездоверительным механизмом работы
Гибкость	Обладает большей гибкостью в плане соответствия регулятивным требованиям, поскольку ассоциированные сеты можно настраивать и обновлять в соответствии с меняющимися правилами и требованиями различных юрисдикций и организаций	Имеет фиксированное анонимное множество для каждой суммы депозита, что может быть несовместимо с регулятивными требованиями или пользовательскими предпочтениями
“Заражение” монет в пуле	Предотвращяет “порчу” монет между различными сетами, поскольку каждый сет имеет собственные пул монет и доказательства	Все средства микшируются в общем пуле, что может приводить к “заражению” средств из разных источников
Раскрытие данных контрагентам	Позволяет предоставлять доказательства непосредственно контрагентам, без раскрытия данных другим сторонам	Не предусматривает прямого взаимодействия между пользователями
Сокрытие связи между транзакциями	Нарушает построение графа транзакций с помощью zero-knowledge proofs (zK-SNARK)	Нарушает построение графа транзакций с помощью zero-knowledge proofs (zK-SNARK)
Уровень приватности	Предлагает различный уровень приватности в зависимости от размера сета, то есть пользователи могут выбирать (из имеющихся вариантов), в насколько большом или малом сете они хотят микшировать свои средства	Устанавливает фиксированное большое анонимное множество для каждой суммы депозита, не подразумевая пользовательского выбора и контроля
Передоказательство / Re-Proofing)	Допускает re-proofing согласно обновлённым ассоциированным сетам, позволяя пользователям обновлять свои доказательства соответствия или несоответствия комплаенсу	Не допускает никаких обновлений или изменений в анонимных множествах
Передача истории	Обеспечивает передачу истории для быстрых трат, что позволяет пользователям тратить свои средства сразу после их вывода из пула, не дожидаясь подтверждений или новых блоков	Требует ожидания подтверждений или новых блоков, прежде чем расходовать полученные из пула средства

Практическое применение и сценарии использования

После этого технического введения авторы переходят к прикладной стороне вопроса, анализируя, как приватные протоколы могут использоваться на практике.

Варианты использования ассоциированных множеств

Ценность этой схемы в контексте правоприменения авторы иллюстрируют на простом примере. Предположим, что у нас есть пять пользователей: Алиса, Боб, Карл, Дэвид и Ева. Первые четверо — законопослушные пользователи, заинтересованные тем не менее в сохранении конфиденциальности, а вот Ева — грабительница. Предположим также, что это тоже известная информация. У сообщества может не быть данных о реальной личности Евы, однако у него достаточно доказательств, чтобы заключить, что монеты, отправляемые на адрес, который мы здесь обозначили как “Ева”, являются крадеными. Подобное часто происходит на практике: например, большинство криминальных средств, поступавших в Tornado Cash, были получены в результате многочисленных взломов DeFi-протоколов (благо они случаются не реже раза в неделю) — событий, легко прослеживаемых в публичных блокчейнах.

При выводе средств каждый из пяти пользователей может выбрать, какое ассоциированное множество указать. Это ассоциированное множество обязательно должно включать их собственный депозит, но в остальном они могут свободно выбирать, какие ещё адреса в него включить. Сначала рассмотрим стимулы Алисы, Боба, Карла и Дэвида. С одной стороны, они хотят максимизировать уровень приватности. Это толкает их к тому, чтобы сделать свои ассоциированные множества как можно более широкими. С другой стороны, они хотят снизить вероятность того, что их монеты вызовут подозрения у продавцов или бирж. И у них есть простой способ решить эту задачу: не включать в своё ассоциированное множество Еву. Таким образом, для всех четверых выбор очевиден: выбрать ассоциированное множество {Alice, Bob, Carl, David}.

Ева, конечно, тоже хочет максимизировать своё ассоциированное множество. Но она не может исключить из него собственный депозит, и потому вынуждена сделать свой ассоциированный сет равным множеству из всех пяти депозитов.

Притом что сама Ева не предоставляет никакой компрометирующей её информации, методом простого исключения несложно определить, что вывод, связанный с депозитом №5, мог быть сделан только Евой.

В целом, протокол Privacy Pools очень гибок и способен адаптироваться к большому количеству вариантов использования через создание специальных ассоциированных множеств, как, например:

	Цель	Функциональность	Использование
Стандартное	Адаптируемое множество общего назначения	Исключает известные незаконные источники средств, обновляется динамически	Средний пользователь избегает ассоциаций с криминальными средствами
Проверенное	Доверенное окружение	Включает только верифицированных и допущенных пользователей, депозиты ограничены	Платформы требуют доверия и верификации
Юрисдикция А	Соответствие требованиям комплаенса определённой юрисдикции	Применяет регулятивные требования Юрисдикции А	Для пользователей из Юрисдикции А
Биржа X	Соответствие внутренним требованиям комплаенса определённой платформы	Включает депозиты только от пользователей биржи X	Обеспечивает выполнение внутренних требований комплаенса биржи X
Потребительское	Создано для обычных пользователей	Ориентировано на депозиты малого размера, с меньшей вероятностью имеющие криминальное происхождение	Для повседневных транзакций среднестатистических пользователей
Организация Y	Обеспечение приватности и внутреннего комплаенса	Исключительно для участников организации Y	Обеспечение комплаенса и доверия между участниками организации

Построение ассоциированных множеств

Предыдущий раздел иллюстрирует один из возможных способов использования ассоциированных множеств в Privacy Pools-подобных протоколах, а также то, как честные участники могут избежать ассоциаций с “плохими акторами”. Авторы подчёркивают также, что система не полагается на альтруизм Алисы, Боба, Карла или Дэвида: у честных пользователей есть ясный стимул доказать свою непричастность к криминальным средствам.

Теперь рассмотрим подробнее построение ассоциированных множеств. Обобщая, есть две основные стратегии построения ассоциированных множеств:

Выборочное включение: допускать в сет только низкорисковые депозиты, соответствующие определённым критериям.
Выборочное исключение: определить критерии высокорисковых депозитов и допускать в сет любые депозиты, кроме тех, что отвечают заданным критериям.

На практике пользователи не будут отбирать депозиты для включения в ассоциативное множество вручную. Скорее, они будут подписываться на услуги посредников, которых авторы называют провайдерами ассоциированных множеств (association set providers, или ASP), генерирующих ассоциированные сеты с определёнными свойствами.

В некоторых случаях ASP могут быть реализованы полностью ончейн и без вмешательства человека (или AI). В других случаях ASP могут генерировать ассоциированные сеты самостоятельно и публиковать их в блокчейне или где-то ещё.

Авторы настоятельно рекомендуют публиковать в блокчейне как минимум корневой хеш ассоциированного сета, чтобы сократить пространство для атак на пользователей со стороны злонамеренных ASP — например, предоставляющих разным пользователям разные ассоциативные множества в попытке их деанонимизировать. Сеты в целом должны быть доступны либо через API, либо, в идеале, на недорогой децентрализованной системе хранения данных, например, IPFS.

Важно предоставлять возможность загрузки полного ассоциированного сета, поскольку это позволяет пользователям генерировать доказательства принадлежности к нему локально, не раскрывая никакой дополнительной информации о том, какой депозит соответствует осуществляемому ими выводу средств, даже ASP.

Авторы приводят несколько практических примеров того, по каким критериям могут строить свою работу ASP. Например:

Исключать депозиты, связанные с хищениями или санкциями, для создания “чистого” сета депозитов.
Включать в “верифицированное” множество депозиты только от верифицированных по KYC пользователей.
Создавать ассоциированные множества для конкретной юрисдикции в соответствии с её законодательством.

Провайдеры (ASP) от имени пользователей занимаются всеми деталями формирования ассоциированных множеств. Пользователи просто выбирают ASP, которому доверяют, и используют предоставляемые им ассоциированные сеты. ASP становится посредником, абстрагирующим сложность построения таких множеств.

Типы ассоциированных множеств	Описание
Добавление с задержкой, исключение “плохих акторов”	Депозиты добавляются в сет с некоторой задержкой (например, в 7 дней), если за это время они не были идентифицированы как незаконные. Это даёт время на проверку депозитов
$n/мес. на пользователя	Включаются только депозиты, не превышающие определённого порогового значения. Пользователи проходят идентификацию и могут совершать только один депозит в месяц. Лимит на пользователя аналогичен правилам AML. Это можно реализовать полностью ончейн
$n/мес. на участника комьюнити	То же, что и выше, но только для участников определённого комьюнити, прямо и/или косвенно поручающихся друг за друга. Обеспечивает подотчётность на уровне сообщества
AI-скрининг	AI-система оценивает уровни риска депозитов. ASP создаёт несколько ассоциированных множеств на основе определённых пороговых значений этой оценки
Сет консорциума	Консорциум проверенных субъектов, например банков, создаёт сет из своих клиентских депозитов. Клиенты могут приватно подтверждать своё членство в консорциуме
Сет биржи	Биржа создаёт сет из депозитов своих клиентов, чтобы обеспечить возможность конфиденциального подтверждения происхождения средств на брокерском счёте
Потребительский сет	Включает только некрупные рядовые потребительские депозиты, с меньшей вероятностью имеющих незаконное происхождение
Динамическое исключение “плохих акторов”	ASP динамически удаляет из сета любые депозиты, отмечаемые ончейн смарт-контрактами как запрещённые

Технические подробности

В этом разделе авторы анализируют, как в предлагаемом протоколе можно реализовать поддержку произвольных номиналов транзакций и обсуждают особые кейсы, как re-proofing (“передоказательство”), а также прямые доказательства между двумя сторонами (bilateral direct) и последовательные доказательства.

Поддержка произвольных номиналов

Упрощённые системы сохранения конфиденциальности, описанные выше, поддерживают только транзакции одного номинала. В Zcash поддержка произвольных номиналов реализована благодаря использованию модели UTXO. Каждая транзакция может иметь несколько входов (что требует публикации нуллификатора, аннулирующего элемента, для каждого входа) и несколько выходов (подразумевая публикацию coin-ID для каждого выхода). Каждый созданный coin-ID должен содержать зашифрованное значение номинала. Помимо подтверждения валидности нуллификаторов, каждая транзакция должна сопровождаться дополнительно доказательством того, что сумма номиналов создаваемых монет не превышает сумму номиналов расходуемых монет.

Этот дизайн можно расширить до поддержки депозитов и выводов, если просто рассматривать депозит как (незашифрованный) вход, а вывод — как (незашифрованный) выход. Для упрощения анализа конструкция может быть ограничена. Например, можно разрешить только частичный вывод, при этом транзакции будут иметь один зашифрованный вход и два выхода: один незашифрованный — собственно, вывод, — и зашифрованный change выход с оставшимися средствами, которые могут быть использованы в последующих выводах, — сдача.

Возникает естественный вопрос: как можно расширить этот дизайн до поддержки Privacy Pools? Просто подключить его к Privacy Pools “как есть” не выглядит идеальным решением, поскольку граф транзакций не соответствует нашему интуитивному ожиданию: если пользователь пополняет счёт на 10 монет, а затем тратит их в четырёх последовательных выводах по 1 + 2 + 3 + 4 монеты, то мы хотели бы видеть все четыре вывода как имеющие в качестве источника первоначальный депозит в 10 монет. Но получим мы то, что показано на рисунке 7 ниже: первый вывод имеет в качестве источника исходный депозит на 10-монет, но затем второй вывод ссылается как на источник уже на сдачу в 9 монет, созданную первым выводом, и так далее. На практике это вызывает проблемы, поскольку требует от провайдера (ASP) проверки и добавления в ассоциированное множество промежуточных депозитов.

Если мы хотим, чтобы все четыре частичных вывода в этом примере могли ссылаться как на источник на исходный депозит в 10 монет, то нужно решить одновременно две проблемы: (i) убедиться, что каждый частичный вывод не связан публично с другими, и (ii) позволить каждому частичному выводу заявлять этот депозит в качестве члена своего ассоциированного множества.

Если предполагать поддержку только частичного вывода (а не более сложные транзакции с несколькими входами и выходами), гарантируя, что каждый вывод имеет один определённый “исходный депозит”, то есть множество способов, с помощью которых это можно реализовать напрямую. Один естественный и очень расширяемый подход — это передача некоторых ссылок на информацию через транзакции. Например, мы можем потребовать включать в транзакцию коммитмент hash(coinID+hash(r)), добавив некоторое случайное значение r для ослепления, а ZK-SNARK должен будет доказывать, что коммитмент в транзакции ссылается на то же значение, что и его родитель, если родитель сам является выводом, или просто на coin-ID исходного депозита, если родитель является депозитом. В результате каждая транзакция в цепочке должна содержать ссылку на coin-ID исходного депозита и доказательство того, что это значение присутствует в ассоциированном множестве, на которое ссылается транзакция.

Для повышения защищённости от эвристики простого суммирования номиналов (например, если я вношу 10 монет и вывожу 7,2859, а затем ещё 2,7141, то эти два вывода можно соотнести между собой и с депозитом на основании одного только суммирования номиналов) мы, возможно, захотим предусмотреть также поддержку слияния монет (coin merging): если у пользователя осталось несколько монет, то он может объединить их со следующим своим депозитом. Чтобы адаптировать протокол к такому сценарию, можно потребовать, чтобы транзакция ссылалась на некое множество coin-ID, а транзакция с несколькими входами ссылалась на объединение своих “родителей”. Таким образом, вывод будет содержать доказательство того, что все coin-ID, на которые он ссылается, находятся в его ассоциированном множестве.

Особые случаи

Переподтверждение / Re-Proofing

Для вывода депозита из Privacy Pools-подобного протокола пользователь должен предоставить секретную информацию о депозите. Эта же секретная информация затем используется для доказательства принадлежности к определённому ассоциированному множеству.

Протокол Privacy Pools позволяет пользователям генерировать новые доказательства для обновлённой версии исходного ассоциированного множества, сохраняя свою секретную информацию.

Если я хочу вывести средства и опубликовать доказательство участия в определённом ассоциированном множестве, то позже я могу сгенерировать новое доказательство против обновлённого ассоциированного множества, используя свои секретные данные о выводе.
Это обеспечивает гибкость в случае изменения множеств. Однако длительное хранение секретов сопряжено с определёнными рисками.

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

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

Двусторонние прямые доказательства

Протокол Privacy Pools поддерживает двусторонние прямые доказательства, позволяющие пользователю раскрыть другой стороне точное происхождение своего вывода без раскрытия всего множества депозитов.

Я могу выборочно раскрыть определённый свой депозит контрагенту, создав ассоциированное множество с одним участником.
Более продвинутый вариант: zero-knowledge доказательство:
- участия в ассоциированном множестве, ИЛИ
- что я являюсь контрагентом, ИЛИ
- временная метка, показывающая, что доказательство было создано не слишком давно.
Это ограничивает возможность неправомерного использования доказательства.

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

Другой, более продвинутый вариант заключается в том, что Алиса предоставляет zero-knowledge доказательство того, что одно из следующих утверждений является истинным: (i) «данный вывод соотносится с таким-то ассоциированным множеством», или (ii) «я банк», или (iii) «согласно этому конкретному сервису временных меток (это может быть сервер или блокчейн), с момента создания этого доказательства прошло более 10 секунд». Только банк, получивший доказательство в реальном времени (iii) и знающий, что он не создавал его самостоятельно (ii), сможет доверять доказательству: если же доказательство попадёт в чужие руки, то убедить получателя в том, что оно не подделано, будет сложно. Таким образом можно устранить большую часть риска контрагента в отношении утечки конфиденциальной информации.

Последовательные доказательства

Протокол Privacy Pools поддерживает последовательные доказательства, позволяя пользователям генерировать новое доказательство для обновлённой версии исходного ассоциированного множества.

Для быстрого перерасходования добавлены внутренние транзакции отправки.
Отправители передают историю получателям, чтобы доказать, что исходный источник отвечает требованиям комплаенса.
Более старая история может быть опущена после того, как ASP добавил её в ассоциированный сет.

Представим себе сценарий из более долгосрочного будущего, в котором Privacy Pools-подобные системы не просто используются время от времени, но применяются в подавляющем большинстве транзакций. Именно к такому миру стремятся системы сохранения конфиденциальности, такие как Zcash. При этом возникают некоторые новые сложности, которые не проявляются в мире, где Privacy Pools используется эпизодически.

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

Предположим, что Алиса отправляет монеты Бобу; то есть она выполняет внутреннюю транзакцию, которая расходует (возможно, частично) coin-ID, принадлежащий Алисе, и создаёт новый coin-ID с параметрами, предоставленными Бобом. Затем Боб хочет немедленно потратить эти монеты, отправив их Карлу, и он предпочёл бы, чтобы его расходная транзакция также была приватной. Здесь мы сталкиваемся с проблемой задержки включения. Во многих конфигурациях, которые мы рассматривали выше, провайдеры (ASP) не захотят немедленно добавлять новую монету Боба в свой ассоциированный сет, поскольку им необходимо иметь в виду вероятность того, что источником средств является не Алиса, а некто, только что укравший средства из кошелька Алисы. Задержка включения делается, чтобы дать Алисе время сообщить об инциденте, а третьим лицам — время его обнаружить.

В другом подобном сценарии “Алиса” — это DeFi-протокол, а Боб хочет вывести средства из него и немедленно использовать их в частном платеже Карлу. В этом сценарии на одного участника меньше, но в остальном он структурно очень похож на предыдущий.

В условиях активной экономики с большим числом быстрых транзакций одни и те же средства могут перемещаться несколько раз в неделю и чаще, и задержки включения будут создавать для такой среды серьёзную проблему. Одним из возможных её решений может быть то, что, если в кошельке пользователя недостаточно монет, “созревших” для включения в ассоциированное множество, то пользователь может отправить их в простой, не сохраняющей конфиденциальность, публичной транзакции. Однако авторы предлагают и другой вариант, призванный сократить объём утечки информации.

Когда Боб платит Карлу, Боб также напрямую передаёт тому ветку дерева хешей и секрет, использовавшиеся для генерации платежа. Это позволяет Карлу видеть то же, что видит Боб: платёж от Алисы в истории монет. Если впоследствии окажется, что на депозит были добавлены и быстро переведены монеты, связанные с известным недобросовестным актором, то Карл сможет доказать, что его монеты получены из благонадёжного источника.

Если Карл затем отправит монеты Дэвиду, то передаст тому ветку дерева хешей и секрет от Боба, плюс добавит собственный. Теперь предположим, что Дэвид отправит полученные монеты дальше Эмме, но к этому времени депозит, сделанный Алисой, уже будет добавлен в ассоциированное множество. Тогда Дэвиду уже не нужно предоставлять ветку и секрет от Алисы; вместо этого, он может просто сгенерировать доказательство принадлежности к ассоциированному множеству от имени Алисы. Как только платёж Боба будет добавлен в ассоциированное множество, ветка и секрет Боба также станут неактуальными. Концепция заключается в том, чтобы каждый пользователь получал только самую минимальную информацию, необходимую для того, чтобы быть уверенным в получаемых средствах.

На практике у монет в одном платеже может быть несколько “источников”. Боб может быть, например, продавцом кофе и получить 5 монет от Алисы, 4 — от Эшли и 7 монет от Анны, а в конце дня ему нужно отправить 15 монет Карлу, чтобы заплатить за ужин. Дэвид, в свою очередь, возможно, получил 15 монет от Карла, ещё 25 от Криса и хочет переслать 30 монет, скажем, на биржу. В этих более сложных случаях можно следовать тому же принципу: историю, уже добавленную в ассоциированное множество, можно игнорировать, а более свежую историю необходимо передавать дальше.

Обсуждение

Системы, подобные Privacy Pools, позволяют пользователям добиться большей конфиденциальности своих финансовых транзакций, сохраняя при этом возможность доказать свою непричастность к известной противоправной деятельности. Авторы предложения ожидают, что добросовестных пользователей будет мотивировать к участию в такой схеме сочетание двух факторов: (i) стремление к конфиденциальности и (ii) желание избежать подозрений.

Общественный консенсус и ассоциированные множества

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

В ситуации, когда глобального консенсуса нет, а суждение о том, какие средства считать “хорошими” или “плохими”, зависит от точки зрения, принятой в данном сообществе или юрисдикции, ассоциированные множества могут существенно различаться. Предположим, что существуют две юрисдикции с различными наборами правил. Субъекты юрисдикций A и B могли бы использовать один и тот же приватный протокол и выпускать доказательство, удовлетворяющее требованиям их соответствующей юрисдикции. Оба могут легко достичь конфиденциальности в рамках своего ассоциированного множества и исключить транзакции вывода, не соответствующие требованиям соответствующей юрисдикции. При необходимости можно выпускать дополнительное доказательство на пересечении правил обоих ассоциированных множеств, тем самым убедительно демонстрируя, что депозит, соответствующий такому выводу, отвечает требованиям обеих юрисдикций.

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

Свойства ассоциированных множеств

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

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

Выбор дизайна и альтернативные решения

Система, основанная на ассоциативных множествах, zero-knowledge доказательствах и добровольном раскрытии информации, является очень гибкой. И хотя это очень хорошо для потенциальной адаптации предложения к требованиям различных юрисдикций, нужно быть очень осторожным в отношении выбора конкретного дизайна протокола. Авторы выделяют две потенциальных корректировки, против которых они сочли нужным выступить непосредственно в предложении, считая их (и небезосновательно) проблематичными в отношении требований к доверию и потенциально способными привести к возникновению квазимонополистических рыночных структур.

Централизованный доступ: получение доступа к просмотру связей между транзакциями для правоохранительных органов, провайдеров услуг по оценке рисков и аналогичных субъектов, притом что эти данные остаются закрытыми для всех остальных.
Общий разрешительный список в масштабах системы: введение ограничений на общий доступ к системе с требованием от пользователей либо некоего дополнительного доказательства, либо некоторого периода ожидания депозита, в течение которого централизованная система оценки рисков может его отклонить.

Оба подхода весьма схожи в том смысле, что они предоставляют особые привилегии определённым субъектам. В связи с этим возникают сложные вопросы управления: кто получает доступ к этой информации? И кто получает право управлять разрешениями?

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

Аналогичным образом, в случае передачи полномочий государственным учреждениям, особенно в международном контексте, возникнет множество вопросов, связанных с управлением и политикой. Даже если бэкдор будет предоставлен организации, которая на сегодняшний день заслуживает 100% доверия, не использует эти полномочия в политических целях и не зависит от других организаций, которые могли бы оказать на неё давление с целью злоупотребить её полномочиями, наивно было бы полагать, что это статичная игра. Организации, их члены, национальные государства и политические структуры внутри организации меняются со временем. Возможно давление извне, и существование особых привилегий может создавать дополнительные стимулы для недобросовестных субъектов к подрыву и получению влияния на систему управления организацией.

Более того, любого рода атака на организацию — изнутри или извне — или ошибка представителя централизованной структуры могут иметь далеко идущие последствия. Создание такой центральной точки отказа было бы ошибкой.

При этом авторы замечают, что различные размеры транзакций и ситуации могут потребовать различных комбинаций доказательств. Например, для крупных транзакций многие пользователи, вероятнее всего, будут публиковать базовое доказательство исключения ончейн и дополнительно предоставлять более подробную информацию об источнике непосредственно контрагенту.

Потенциальные направления дальнейших исследований

Это предложение о Privacy Pools даёт определённое представление о том, как протоколы повышения конфиденциальности на основе zkSNARK могут быть адаптированы к регулируемой среде. Но авторы выделяют и несколько областей, требующих дальнейшего изучения.

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

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

В более тонком примере ограничения из различных доказательств участия могут быть использованы для извлечения информации и установления потенциальной связи между депозитами и выводами с более или менее высокой вероятностью. Комбинирование этой информации с метаданными ончейн-транзакций может нарушать в некоторых случаях конфиденциальность протокола.

Наконец, недобросовестный провайдер ассоциированного сета может намеренно формировать предлагаемые анонимные множества таким образом, чтобы максимизировать извлекаемую информацию, либо искусственно завышать воспринимаемую анонимность путём добавления в сет депозитов с установленными получателями транзакций вывода.

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

Наконец, юристы могли бы внести свою лепту в части описания конкретных требований к раскрытию информации. Авторы отмечают, что описанное в статье предложение является весьма адаптируемым, и мнение специалистов в области права может помочь в адаптации протокола и экосистемы вокруг него к требованиям комплаенса в различных правовых юрисдикциях.

Подписывайтесь на BitNovosti в Telegram!
Делитесь вашим мнением об этой статье в комментариях ниже.

На основе источников: