Последняя статья Бутерина: Как протокол пула конфиденциальности защищает конфиденциальность пользователей и соответствует требованиям соответствия?

原文:《Конфиденциальность блокчейна и соответствие нормативным требованиям: на пути к практическому равновесию

Докладчики: Виталик Бутерин, Джейкоб Иллум, Маттиас Надлер, Фабиан Шар и Амин Сулеймани

Подборка: How Odaily Planet Daily Husband

Сегодня Бутерин и другие совместно написали исследовательскую работу по протоколам конфиденциальности под названием «Конфиденциальность блокчейна и соответствие нормативным требованиям: на пути к практическому равновесию».

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

Odaily Planet Daily теперь резюмирует суть статьи следующим образом.

Введение

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

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

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

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

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

**Ключевая проблема Tornado Cash — размытая грань между законными пользователями и преступными пользователями. **Поэтому Tornado Cash предлагает функцию соответствия, которая позволяет пользователям создать подтверждение того, с какого депозита был произведен данный вывод средств. Хотя этот механизм действительно позволяет людям доказывать свою невиновность, он делает это ценой необходимости доверять централизованному посреднику и создавать информационную асимметрию. В конечном итоге механизмом воспользовались немногие пользователи.

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

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

2. Техническая информация

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

1. Конфиденциальность блокчейна до ZK-SNARK

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

С появлением современных инструментов кластеризации и анализа такая защита конфиденциальности стала недостаточной. Для улучшения конфиденциальности публичных блокчейнов были внедрены более мощные технологии, такие как Token Join и Monero. Однако эти технологии по-прежнему несут в себе риск утечки данных. **

Затем появилось появление универсальных технологий доказательства с нулевым разглашением, таких как Zcash и Tornado Cash, которые могут сделать набор анонимности каждой транзакции равным всему набору всех предыдущих транзакций. Эту методику часто называют ЗК-СНАРК.

2、 ЗК-СНАРК

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

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

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

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

«Утверждение» доказательства ZK-SNARKs можно рассматривать как тип программы, называемой «схемой», которая вычисляет результат функции f(x, w) с общедоступными и частными входными данными, а затем доказывает, что для данного общедоступный ввод x, существует частный ввод w, для которого результат f(x, w) равен True.

###3. Применение ZK-SNARK в таких системах, как Zcash и Tornado Cash.

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

Токены состоят из секретов, хранящихся их владельцами. Из s можно получить два значения:

Идентификатор публичного токена L = хэш(s + 1).

обнулительU = хэш(s + 2).

Среди них хэш относится к хэш-функции пароля, например SHA 256. Учитывая s, можно вычислить идентификатор токена и обнулитель. Однако, учитывая набор обнулителей и общедоступный идентификатор токена, псевдослучайное поведение хэш-функции гарантирует, что вы не сможете определить, какой обнулятор связан с каким идентификатором токена, если вы не знаете секретные значения, которые сгенерировали оба.

Блокчейн отслеживает все идентификаторы токенов, которые были «созданы», и все нуллификаторы, которые были «израсходованы». Оба набора постоянно растут (если только протокол не хочет указать, когда токены должны быть потрачены).

Коллекция идентификаторов токенов хранится в структуре данных, называемой деревом Меркла: если дерево содержит N элементов, то каждый соседний элемент хешируется (в результате получается ⌈ N/2 ⌉ хешей), а каждый соседний элемент хэшируется снова (в результате в ⌈ N/4 ⌉ хэшах) и так далее, пока все данные не будут зафиксированы в одном «корневом хэше».

Учитывая определенное значение в дереве и корневой хеш, можно предоставить ветвь Меркла: «сестринское значение», которое хэшируется на каждом этапе пути от этого значения к корню. Эта ветвь Меркла полезна, поскольку представляет собой небольшой фрагмент данных (хеш-значения log 2(N)), который можно использовать для доказательства того, что какое-либо конкретное значение действительно находится в дереве. На рисунке ниже показан пример дерева Меркла высотой 4.

Последний документ Бога: Как протокол пула конфиденциальности защищает конфиденциальность пользователей и соответствует требованиям соответствия

Когда пользователи отправляют монеты другим, они предоставляют следующее:

● Сумма, которую вы хотите потратить.

● Идентификатор токена L' нового токена, который необходимо создать (получателя просят предоставить его).

● ЗК-СНАРК.

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

● секреты пользователя

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

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

● U — обнулитель расходуемого токена.

● R, корневой хэш, против которого направлены доказательства Меркла.

ZK-SNARK подтверждает два свойства:

● U = хэш(s + 2)

● Ветка Меркла действительна.

Помимо ZK-SNARK, протокол также проверяет следующее:

● R — текущий или исторический корневой хеш дерева идентификаторов токенов.

● U не входит в набор потраченных нуллификаторов.

Последний документ Бога: Как протокол пула конфиденциальности защищает конфиденциальность пользователей и соответствует требованиям соответствия

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

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

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

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

4. ZK-SNARK в приватном пуле

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

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

Введите ветвь Меркла корня R общего набора идентификаторов монет

Введите ветвь Merkle предоставленного корневого RA набора ассоциаций.

Последний документ Бога: Как протокол пула конфиденциальности защищает конфиденциальность пользователей и соответствует требованиям соответствия

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

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

3. Практические соображения и варианты использования

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

1. Варианты использования связанных коллекций

Чтобы проиллюстрировать ценность этой программы в правоохранительной среде, приведем пример:

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

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

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

Последний документ Бога: Как протокол пула конфиденциальности защищает конфиденциальность пользователей и соответствует требованиям соответствия

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

2. Построение связанных коллекций

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

● **Включение (или членство): **Определяет конкретный набор депозитов, которые, по нашему мнению, имеют низкий риск, и создает связанный набор, включающий только эти депозиты.

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

Последний документ Бога: Как протокол пула конфиденциальности защищает конфиденциальность пользователей и соответствует требованиям соответствия

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

Мы настоятельно рекомендуем публиковать в цепочке как минимум корень Merkle коллекции ассоциаций; это исключает возможность злонамеренных ASP выполнять определенные типы атак на пользователей (например, предоставление разным пользователям разных коллекций ассоциаций в попытке деанонимизировать их). . Вся коллекция должна быть доступна через API или, в идеале, через недорогую децентрализованную систему хранения, такую как IPFS.

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

Вот как ASP могут быть структурированы на практике:

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

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

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

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

4. Дальнейшее техническое описание

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

1. Поддержите любую конфессию

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

Последний документ Бога: Как протокол пула конфиденциальности защищает конфиденциальность пользователей и соответствует требованиям соответствия

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

Естественный вопрос заключается в том, как расширить этот дизайн для поддержки пулов конфиденциальности. Вставка его без изменений в пул конфиденциальности не идеальна, поскольку график транзакций не соответствует тому, что мы интуитивно ожидаем: если пользователь вносит 10 токенов, а затем тратит 1+2+3+4 в четырех последовательных токенах вывода средств, мы хотим обработать каждый из них. эти четыре вывода являются источником первоначального депозита в 10 токенов. Но фактический результат показан на рисунке ниже: источником первого вывода является депозит в размере 10 токенов, а затем источником второго вывода является выход изменения 9 токенов, созданный в результате первого вывода, и так далее по аналогии. На практике это вызывает проблемы, поскольку ASP требует проверки промежуточного депозита и добавления его в связанную коллекцию.

Последний документ Бога: Как протокол пула конфиденциальности защищает конфиденциальность пользователей и соответствует требованиям соответствия

Чтобы все четыре вывода в этом примере имели первоначальный депозит в 10 монет в качестве источника, нам необходимо решить две проблемы:

Убедитесь, что каждый частичный вывод не связан публично с другими выводами

Разрешить каждому частичному снятию средств включать депозит в связанный набор

Если мы поддерживаем только частичный вывод средств, а не более сложные транзакции MIMO, и обеспечиваем, чтобы каждый вывод имел один определенный соответствующий «исходный депозит», существует несколько способов добиться этого напрямую. Естественный и масштабируемый подход — распространять некоторую информацию посредством транзакций. Например, мы можем потребовать, чтобы транзакция содержала хэш обязательства (coinID+hash®), добавить случайное значение r, чтобы обеспечить маскировку, и потребовать от ZK-SNARK доказать, что обязательство в транзакции такое же, как и его родительская транзакция. Если родительская транзакция сама по себе является снятием средств, обязательство совпадает с идентификатором монеты исходного депозита, а если родительская транзакция является депозитом, обязательство совпадает с идентификатором монеты исходного депозита. Следовательно, каждая транзакция в цепочке должна содержать обязательство по исходному идентификатору монеты депозита и должна доказать, что это значение находится в связанном наборе, предоставленном транзакцией.

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

2. Особые обстоятельства

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

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

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

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

5. Подробнее

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

● Стремление к конфиденциальности

** ● Желание не вызывать подозрений **

1. Социальный консенсус и сбор ассоциаций

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

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

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

2. Атрибуты связанных коллекций

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

3. Практические соображения и конкуренция

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

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

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

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

● **Альянсы коммерческих банков могут создавать связанные коллекции, содержащие только депозиты их клиентов. **Это гарантирует, что доказательства любых снятий средств, созданных для коллекции, прошли процедуры «Знай своего клиента» (KYC) и борьбы с отмыванием денег (AML) в одном из участвующих банков, но не показывает, какой вывод принадлежит какому клиенту.

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

4. Варианты дизайна и альтернативы

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

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

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

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

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

Кроме того, атаки внутри или за пределами организации или ошибки со стороны централизованного объекта могут иметь далеко идущие последствия. Мы считаем, что следует предотвратить создание таких централизованных точек отказа.

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

5. Направление углубленных исследований

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

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

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

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

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

6. Заключение

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

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

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

Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
  • Награда
  • комментарий
  • Поделиться
комментарий
0/400
Нет комментариев
  • Закрепить