Программируемая конфиденциальность: как она может быть более дружественной к соблюдению требований в мир Web3

В Оле мы полностью согласны с утверждением a16z в их статье " Достижение конфиденциальности криптовалют и соответствие нормативным требованиям " о веб3:

«Развитие и регулирование веб3 – эволюция Интернета, основанная на криптовалюте – должна достичь двух целей, которые часто находятся в противоречии. Цель 1: Сохранить конфиденциальность потребителей, несмотря на прозрачную природу блокчейнов по умолчанию . Цель 2: Снизить риск незаконного финансирования в интересах национальной безопасности».

Это видение совпадает с тем, что Ола описал в статье « Ола – создайте свое собственное путешествие по Web3 Кроме того, упор на высокую пропускную способность — это функция, над реализацией которой Ола в настоящее время усердно работает.

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

Статья Олы " Технический обзор Sin7y (35): Гибридный накопительный пакет – инфраструктура следующего поколения – HackMD », описывает различия между этими тремя решениями.

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

1. Обеспечьте встроенную защиту конфиденциальности для защиты информации пользователя.

   
   

2. Обеспечьте соблюдение нормативных требований для отслеживания незаконной деятельности.

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

Подходя к этому с точки зрения решения реальных проблем, давайте сначала рассмотрим проблемы, с которыми сталкиваются различные проекты конфиденциальности с точки зрения соблюдения нормативных требований. Как описано в главе «Принудительная выборочная деанонимизация» из статьи « Решения по защите конфиденциальности с использованием доказательств с нулевым разглашением: полная статья - a16z crypto », главный вопрос заключается в следующем: « Кто хранит закрытый ключ для обеспечения возможности отслеживания?» "

Зачем нам нужен закрытый ключ для разблокировки отслеживания?

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

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

В статье " Sin7y Tech Review (33): Принципы частных транзакций и вопросы соблюдения нормативных требований - HackMD «, вы можете найти принципы проектирования, лежащие в основе частных транзакций. Мы кратко объясним, как обеспечивается конфиденциальность в рамках этой конструкции и как она решает проблемы регулирования:

1. Скрытие инициатора транзакции или отправителя : это достигается с помощью одноразовой подписи, как подробно описано в разделе 4.1.7.1 документа. протокол zcash-sapling .

   
   

2. Скрытие получателя транзакции или получателя : это разделено на два сценария:

   
   

ⅰ. Сокрытие от третьих лиц достигается за счет шифрования информации о транзакции с использованием публичного адреса получателя. См. раздел 4.19.1 протокол zcash-sapling . Затем получатель анализирует транзакции, используя закрытый ключ (известный как входящий ключ просмотра), чтобы расшифровать и отфильтровать отправленные ему транзакции, как описано в разделе 4.19.2 документа. протокол zcash-sapling . Само содержимое транзакции не содержит никакой информации о получателе.

ⅱ. Сокрытие от одного и того же отправителя осуществляется с использованием одноразового публичного адреса.

3. Для сокрытия информации о транзакциях : Этот подход предполагает использование доказательств с нулевым разглашением и схем общего секрета. См. разделы 4.17 и 4.19 руководства. протокол zcash-sapling .

   
   

4. Для реализации неотслеживаемости : подход основан на разработке дерева обязательств (далее называемого «CM») и дерева обнулителя (далее называемого «NF»). Данная конструкция служит следующим целям:

   
   

ⅰ. Каждый UTXO (выход неизрасходованных транзакций) соответствует одному CM и одному NF, но между ними нет прямой связи.

ⅱ. И дерево CM, и дерево NF являются деревьями, допускающими только добавление.

ⅲ. Дерево CM используется для доказательства достоверности UTXO, а дерево NF предотвращает двойное расходование UTXO.

На основе описанной выше схемы обеспечения конфиденциальности пользователи могут воспользоваться следующими функциями защиты конфиденциальности:

1. Каждая транзакция остается невидимой для внешних сторон.

   
   

2. Связи между транзакциями не отслеживаются.

   
   

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

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

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

Однако этот ключ просмотра хранится у пользователя, что делает его недоступным напрямую для регулирующих органов. Это связано с проблемами, описанными в разделах 13/14 «Добровольная выборочная деанонимизация» и «Принудительная выборочная деанонимизация» статьи « Нормативные решения по защите конфиденциальности с использованием доказательств с нулевым разглашением: полная статья — a16z crypto. "

Давайте углубимся. Почему ключ просмотра настолько чувствителен, что пользователи не решаются предоставить его регулирующим органам?

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

   
   

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

   
   

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

   
   

Основываясь на приведенном выше анализе, идеальное решение для обеспечения конфиденциальности должно :

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

   
   

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

Это видение, к которому стремится Ола: программируемая конфиденциальность, которая изначально включает в себя отслеживаемость!

Как Ola внедряет встроенную отслеживаемость программируемой конфиденциальности?

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

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

   
   

2. Оставшееся дерево обязательств переводится из исходного режима только для добавления в обновляемый путем введения дополнительных операторов подтверждения для предотвращения атак двойного расходования на одно и то же обязательство. Это показано на рисунке 2:

   
   

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

   
   

zkDID/zkKYC эффективно балансируют конфиденциальность и регулирование

Децентрализованные идентификаторы с нулевым разглашением (zkDID) играют решающую роль в платформах конфиденциальности. У них есть возможность преобразовать юридическую личность пользователя (Legal ID) в zkDID. Например, в проекте PSE Анон Аадхаар , люди с картой Aadhaar могут создать zkDID.

Для других zkDID является анонимным и не раскрывает реальную идентификационную информацию пользователя. Эта двойная характеристика представляет собой мощный инструмент защиты конфиденциальности.

Что касается уровней реализации zkDID, то это может происходить на разных уровнях, в зависимости от конструкции и требований платформы:

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

   
   

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

   
   

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

   
   

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

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

1. Прослеживаемость : на основе информации CM в транзакции любая третья сторона может проследить путь потока CM, как показано на рисунке 2.

   
   

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

   
   

3. Эффективность : за счет поддержки меньшего количества деревьев накладные расходы на систему zk-proof уменьшаются.

   
   

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

   
   

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

   
   

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

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

Помимо этих технических преимуществ, Ola все еще может интегрироваться с такими газетами, как « Достижение конфиденциальности криптовалют и соответствие нормативным требованиям - a16z crypto " и " Конфиденциальность блокчейна и соблюдение нормативных требований: на пути к практическому равновесию «чтобы включить механизмы черного списка и другие ограничения на ранней стадии, усовершенствовав дизайн всей программируемой системы конфиденциальности.

Также опубликовано здесь