Введение

Одной из основных проблем для пользователей криптовалюты web3 является отсутствие конфиденциальности. Тот факт, что все транзакции видны в общедоступном реестре, и, что все чаще: связаны с одним четким именем ENS, является демотивирующим фактором для пользователей выполнять определенные действия или заставляет их выполнять эти действия способами, которые приводят к увеличению трения в UX. Одним из примеров является простое перевод средств с горячего кошелька на холодный или наоборот. Пользователи могут не хотеть, чтобы один кошелек был связан с другим, так как им может не хотеться, чтобы их баланс холодного кошелька был виден. В настоящее время адреса Ethereum не работают как частные банковские счета, потому что каждый может видеть ваш кошелек, и все чаще видят вашу социальную активность (SBT, удостоверения, действия на различных dapps и т.д.). Именно по этим причинам Виталик назвал конфиденциальность одной изтри крупных технических переходачто Ethereum должен пройти, чтобы быть полезным для обычных пользователей.

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

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

Пользовательский спрос на конфиденциальность

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

1. Опрос, который был проведен в 2022 году и опубликован Симин Гесмати и др. в статье под названием: Воспринимаемая пользователем конфиденциальность в блокчейне, заявил, что «половина опрошенных указала, что конфиденциальность транзакций им очень важна». Хотя эта исследование было больше связано с Bitcoin, чем с Ethereum, вероятно, у пользователей Ethereum также есть похожие отношения. Однако, выборка для этого исследования была довольно маленькой (14 участников).
2. Ещё одна интересная исследовательская работа из 2022 года, опубликованная в Границы, с названием Политические, экономические и управленческие взгляды пользователей блокчейнаболее всесторонний, с опросом 3 710 пользователей криптовалюты. Результаты показали, что около четверти опрошенных указали, что конфиденциальность является «самой важной функцией блокчейна и криптовалюты».

1. В общем, в отношении отношения к конфиденциальности, Consensysопубликовано исследование под названиемВеб3 и криптовалютный глобальный опрос 2023, в ходе которого было опрошено 15 158 человек онлайн в 15 странах по различным вопросам, касающимся интернета, а не только криптовалюты. Опрос показал, что 83% респондентов считают, что конфиденциальность данных важна, в то время как только 45% респондентов заявили, что они доверяют тому, как текущие интернет-сервисы используют их данные и личную информацию.
2. A опрос, проведенный Финансовой компенсационной схемой Великобритании, опубликованный в апреле 2023 года, подчеркнул, что 9% опрошенных указали "желание анонимности/приватности" как свою причину инвестирования в криптовалюту.

Внедрение протоколов скрытых транзакций

Рельсовая пушкаимеет впечатляющие показатели, причем использование протокола, похоже, постоянно растет с течением времени, достигая пика более 70 миллионов долларов TVL и 2 миллиарда долларов объема к ноябрю 2024 года.

TVL (USD) Railgun на Ethereum main - источник: ​​Рейлган — ДефиЛлама

Umbraтакже прочел растущее количество людей, использующих его протокол (людей, регистрирующих скрытый адрес в своей ENS), насчитывающих почти 77 тыс. к ноябрю 2024 года:

Накопленные зарегистрированные участники Umbra (Cross Chain) — source: dune.com

Если мы посмотрим на самый известный (и теперь, к сожалению, печально известный) протокол конфиденциальности в Ethereum, который называется Tornado cash, то мы увидим, что он все еще активно используется, несмотря на то, что адреса контрактов технически находятся в списке SDN OFAC.

Диаграмма ниже показывает TVL Tornado Cash со временем. Мы можем наблюдать, что первое значительное снижение TVL с его пика примерно в октябре 2021 года совпало с более широкой продажей на крипто-рынках, второе значительное снижение в августе 2022 года соответствовало включению Tornado Cash в список SDN OFAC, а третье значительное снижение соответствовало пересмотру OFAC в ноябре 2022 года. Однако с тех пор Tornado Cash продолжает набирать обороты, несмотря на санкции, достигнув почти 600 млн долларов в TVL. Это довольно веский доказательство того, что существует спрос на базовую конфиденциальность транзакций в Ethereum.

TVL (USD) Tornado Cash на основной сети Ethereum - источник: Tornado Cash — DefiLlama

Ландшафт скрытого адреса

Это исследование выявило 4 основные решения для цепей EVM в производстве на сегодняшний день, это:

• Fluidkey
• Umbra
• Лабиринт
• Railgun

Оба Fluidkey и Umbra основаны на стандартах Ethereum, которые включают в себя:

• ERC-5564: Протокол скрытых адресов
• ERC-6538: Stealth Meta-Address Registry

Labyrinth и Railgun основаны напротокол zerocash (который zcashтакже основан на), который использует защищенный пул, в который пользователи вносят средства. Zerocash использует концепцию «заметок», которые являются криптографическими представлениями значения, которые обеспечивают частные транзакции. Каждая заметка включает скрытое значение, ключ владельца и уникальный номер (нулевой элемент), при этом zk-SNARKs используются для проверки владения без раскрытия деталей и, следовательно, для передачи значения в заметках. Когда заметка тратится, ее нулевой элемент раскрывается, чтобы предотвратить двойные траты, в то время как новые заметки создаются для получателей, образуя систему UTXO внутри защищенного пула.

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

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

Как работают скрытые адреса

Скрытый мета-адрес по сути является конкатенацией 2 сжатых открытых ключей, называемых «ключом траты» и «ключом просмотра». Скрытый мета-адрес использует формат адреса, специфичный для цепочки EIP-3770, с добавлением префикса «st:». Вот пример скрытого адреса:

st:eth:0x036ffa94a70a5b9608aca693e12da815fe0295f3739c7b22b0284c6d85c464ba4a02c0521b6fe31714b2ca0efa159402574355b754e0b50406b0b5fb33128eec3507

Для простоты этот стелс-адрес может быть связан с обычным адресом Ethereum (и, следовательно, ENS), что упрощает отправку средств владельцу стелс-адреса. Чтобы отправить средства, отправитель должен разрешить вышеуказанный адрес и, используя стандарт EIP-5564, создать эфемерный открытый ключ, из которого он затем извлекает скрытый адрес. Отправитель отправляет средства на новый скрытый адрес, как правило, через одноэлементный контракт, который прослушивают все скрытые адреса. Этот контракт генерирует событие "Объявление", на которое подписываются получатели. Каждый раз, когда генерируется событие объявления, получатели проверяют временный открытый ключ в объявлении, объединяют его со своим закрытым ключом просмотра и определяют, есть ли у них возможность потратить средства, отправленные на скрытый адрес. Если они это сделают, кошелек / клиент, который они используют, запомнит скрытый адрес и соответствующие средства, добавив их к отображаемому балансу пользователя. Чтобы фактически потратить средства, они могут подписать транзакцию с помощью закрытого ключа расходов.

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

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

Однако, чтобы это сработало в первую очередь, получатель должен сделать свой скрытый адрес известным отправителю (ам). Один из способов сделать это - использоватьРеестр скрытых мета-адресов EIP-6538. Это одноэлементный контракт, который позволяет пользователям зарегистрировать скрытый мета-адрес для обычного адреса Ethereum, который затем отправители могут найти. Это позволяет отправителям получить обычный адрес из ENS, а затем найти связанный скрытый мета-адрес из реестра.

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

• Когда получатель собирается потратить средства, каждый, кому он передает эти средства, увидит, что они происходят от исходного отправителя (т.е. они могут увидеть адрес, с которого были переданы средства, и кто ранее отправлял средства на этот адрес). Это означает, что цепочка передач остается целой и отслеживаемой, но они просто не связаны с получателем вопроса (если только получатель не сделает что-то вроде отправки средств на один из своих известных нескрытых адресов). Обратите внимание, что это относится только к реализациям erc-5564, а не к Railgun или Labyrinth.
• Одним из побочных эффектов вышеуказанной проблемы является то, что для поддержания оптимальной конфиденциальности пользователю, вероятно, придется оставлять средства на скрытых адресах, на которые они изначально были отправлены, пока он действительно не понадобится, вместо того, чтобы объединять их под одним адресом. Это означает дополнительные затраты на запоминание адресов и последующее расходование средств на этих адресах, поскольку сумма, которую вы хотите перевести, должна быть получена из комбинации средств с различных других адресов.
• Чтобы перевести средства с этого адреса, получатель должен пополнить адрес некоторым количеством ETH для оплаты газа, и это может потенциально деанонимизировать получателя. Это известная проблема скрытых адресов и одна из причин, почему несколько реализаций внедрили поддержку eip-4337 и платежного агента.
• Одним из недостатков схемы скрытых адресов является то, что получателям необходимо следить за событиями объявления в блокчейне и проверять каждое объявление, чтобы определить, были ли им отправлены средства. Очевидно, что это непрактичные накладные расходы для большинства пользователей, особенно когда речь идет о получении средств в нескольких сетях. Для того, чтобы сделать этот процесс более эффективным, стандарт определяет «тег просмотра», который представляет собой усеченный хэш, производный от общего секрета, и может быть использован для быстрого отбрасывания транзакций, которые определенно не предназначены для них. Благодаря использованию тегов представлений производительность не так уж плоха на настольных компьютерах, однако она может быть несколько заметнее на мобильных устройствах. Единственный случай, когда снижение производительности действительно заметно, это если кошелек восстанавливается, и в этом случае кошельку нужно будет сканировать каждый адрес с момента развертывания ончейн-контракта, что отнимает много времени.
• Чтобы обойти это, пользователи могут по желанию делиться приватным ключом просмотра с доверенной третьей стороной. Этот сервис третьей стороны может отслеживать различные сети и уведомлять пользователей, когда они получают средства. Конечно, это сопряжено с компромиссом: хотя третья сторона фактически не может тратить средства пользователя (у них нет приватного ключа траты), они могут видеть все средства, отправленные определенному получателю, что означает, что пользователь должен доверять им своей конфиденциальностью. Fluidkey делает это по умолчанию.
• Стандартный протокол скрытого адреса, т.е. ERC-5564, разработан для обеспечения конфиденциальных переводов, однако другие нефинансовые случаи использования, такие как вызов произвольных функций смарт-контракта, требуют немного больше инженерии и обычно зависят от реализации.

Матрица сравнения

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

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

На рисунке ниже показано, как протоколы, которые мы рассматриваем в этом посте, сравниваются между собой по этим двум важным аспектам сравнения.

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

1. Полная конфиденциальность от начала до конца (только отправитель и получатель видят платеж)
2. Предварительная секретность. Отправка средств, полученных через скрытые транзакции, не позволяет второму получателю узнать, откуда происходят средства.
3. Следует стандартам erc-5564 и erc-6538
4. Реализует расширяемую модульную архитектуру, позволяющую интеграцию с децентрализованными приложениями сторонних разработчиков
5. Предлагает ли реализация SDK, которое разработчики могут использовать для интеграции?
6. Предоставляет ли решение уровень соответствия путем поддержки деанонимизации?
7. Поддерживает ли дизайн затруднение определения суммы / значения, которые передаются?

| Протокол | Конфиденциальность от точки до точки | Передовая секретность | Открытый стандарт | Модульная архитектура | SDK | Поддержка деанонимизации | Скрытие сумм |

|—————-|——————-|————————-|————————|———————————|———|—————————————|————————|

| Umbra | ✅ | ⛔️ | ✅ | ⛔️ | ⛔️ | ⛔️ | ⛔️ |

| Fluidkey | ⛔️ | ⛔️ | ✅ | ✅ | скоро | ✅ | ⛔️ |

| Лабиринт | ✅ | ✅ | ⛔️ | ✅ | ✅ | ✅ | ✅ |

| Railgun | ✅ | ✅ | ⛔️ | ✅ | ✅ | добровольный | ✅ |

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

Например: в Fluidkey: все переводы направляются непосредственно на скрытые адреса в цепочке, с Umbra: только ETH направляется на скрытые адреса в цепочке, тогда как токены направляются в центральный контракт, а с Railgun и Labyrinth все транзакции направляются в основные контракты, а не непосредственно на скрытые адреса в цепочке.

Глубокое погружение в реализации скрытого адреса

Fluidkey

Fluidkeyявляется реализацией erc-5564, которая позволяет пользователям отправлять, получать, менять и мостить ETH и токены erc-20. На момент написания, Fluidkey развернут на Base, Optimism, Arbitrum, Polygon, Gnosis и главной сети Ethereum.

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

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

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

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

Пользователи также могут свободно либо экспортировать свои транзакции, либо делиться своими ключами просмотра с третьими лицами (например, со своим бухгалтером), что может быть чрезвычайно полезно, особенно для бизнеса. Однако стоит иметь в виду, что в спецификации erc-5564 совместное использование открытого ключа — это «все или ничего», что означает, что он не может раскрывать изолированные отдельные транзакции сами по себе. Кроме того, как и во всех реализациях erc-5564, трассируемость не нарушена — только возможность привязки к пользователю — что означает, что история транзакций каждого скрытого адреса доступна тому, у кого есть ключ просмотра. Одной из не очень известных функций Fluidkey, которая помогает смягчить эти компромиссы, является возможность ротации клавиш просмотра, что позволит пользователю использовать новый ключ просмотра каждый месяц и делиться доступом к просмотру только с определенной стороной.

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

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

Абстракция адреса

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

Разрешение ENS

Fluidkey требует, чтобы пользователи создавали имена ENS, специфические для Fluidkey. Эти статические имена имеют 2 формы: username.fkey.id и username.fkey.eth, одно из которых является URL-адресом веб-интерфейса для отправки средств кому-то, а другое - стандартным именем ENS, которое можно использовать с кошельками.

Установка ENS использует ENS внешний разрешитель (aka erc-3668: Чтение CCIP) чтобы вернуть скрытые адреса. Каждый раз, когда запрашивается внешний разрешитель, он генерирует и возвращает новый скрытый адрес для соответствующего имени ENS. Это хорошая функция, поскольку она позволяет пользователю иметь одно человекочитаемое имя ENS, сохраняя при этом конфиденциальность скрытых адресов, поскольку сгенерированные скрытые адреса не могут быть связаны с именем ENS в ретроспективе.

Стоимость

Fluidkey бесплатно и не взимает комиссию. Существует стоимость развертывания контракта Safe для каждого адреса, у которого есть средства, когда вы хотите потратить эти средства. Однако, хотя на mainnet это относительно дорого, на L2s это действительно незначительно, обычно менее 1 цента, даже при объединении нескольких скрытых адресов в одну транзакцию.

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

Umbra Cash

Umbra - это реализация eip-5564 + eip6538 от Scopelift. Когда пользователь входит в приложение Umbra, он проходит этап настройки, в котором подписывает сообщение, из которого получаются ключи расхода и просмотра, а также соответствующий скрытый мета-адрес. Затем он регистрирует этот скрытый мета-адрес в своем основном кошельке в реестре на цепи. Здесь реализация отличается от Fluidkey.

Реализация Umbra erc-5564 наиболее соответствует спецификации, поскольку они не имеют доступа к ключам пользователя. Это означает, что Umbra (или кто-либо другой) не может видеть средства пользователей, но это также означает, что для отправки средств отправитель должен иметь кошелек, совместимый с erc-5564 (или приложение Umbra), чтобы сгенерировать свой скрытый мета-адрес.

Когда кто-то хочет отправитьобычно пользователи используют приложение Umbra для отправки средств другому пользователю. В основном приложение Umbra будет искать мета-адрес скрытого адреса, зарегистрированного на имя ENS / адрес кошелька и генерировать скрытый адрес. Получатели могут войти в приложение Umbra и проверить, были ли отправлены им средства на скрытые адреса с момента последнего входа. Благодаря умному кэшированию это занимает всего 10-15 секунд для еженедельного сканирования, хотя пользователи также могут указать диапазон блоков для узкого сканирования. В Umbra v2 будет использоваться viewtags, что еще больше ускорит процесс.

Релеер

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

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

Стоимость

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

Поддерживаемые сети

Umbra в настоящее время развернута на основной сети Ethereum, а также на Optimism, Polygon, Gnosis Chain и Arbitrum.

Контракт реестра Umbra имеет интересный дизайн. Метод развертывания использует create2 и стандартный развертыватель create2, а адрес смарт-контракта на любой сети остается тем же. Это означает, что если контракт существует на определенной сети, то клиент может быть уверен, что это правильный контракт. Клиент может быть настроен на добавление сетей, и любой может развернуть его на любой сети. Они канонизировали байткод, и контракт не имеет владельца, что позволяет развертывать реестры и контракты объявлений без разрешения на любой цепи любым лицом.

Umbra v2

Scopelift в настоящее время разрабатываетверсия 2 Umbra, который представляет новую модульную архитектуру, позволяющую расширять основные контракты для поддержки новых стандартов токенов или применений, не связанных с платежами. С использованием этой новой архитектуры сторонние разработчики могут создавать модули для любого типа стандарта токена, например, erc-1155, erc-7621, поддержка erc-4337 платежных систем или чего-либо еще, о чем вы можете подумать. В настоящее время ядро Umbra поддерживает два сценария: один для ETH и один для erc-20. V2 будет поддерживать множество различных сценариев.

Лабиринт

Лабиринт — это протокол, который не основан на EIP-5564 + EIP6538, а вместо этого использует доказательства с нулевым разглашением для повышения анонимности и конфиденциальности транзакций. В техническом документе Labyrinth он описывается как промежуточное ПО "zkFi": "zkFi предлагает пакетное решение, которое действует как промежуточное ПО конфиденциальности со встроенным соответствием". Встроенный комплаенс относится к «выборочной деанонимизации» Labyrinth, которая представляет собой сложное решение, позволяющее деанонимизировать определенные транзакции конкретным уполномоченным субъектам, т.е. юридическим органам, таким как Интерпол и т. д., сохраняя при этом прозрачность и открытость.

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

Основными контрактами Labrynth являются контракты конвертера, которые взаимодействуют с модульными прокси-контрактами, которые, по сути, являются прокси для внешних контрактов. Так, например, если пользователь хочет использовать Labyrinth для взаимодействия с Uniswap, пользователь создаст транзакцию, которая будет использовать контракт конвертера для вызова операции обмена в пуле Uniswap через прокси-контракт Uniswap.

Протокол zkFi Labyrinth использует «заметки» для отслеживания балансов и переводов. Заметка по сути является структурой данных, которая описывает определенное количество определенного актива и адрес, к которому он принадлежит. Клиент сохраняет информацию, необходимую для воссоздания заметки, и использует ее для расходования активов. Обязательство по заметке (хеш идентификатора актива, владельца и значения) хранится в дереве Меркля на цепи. Фактически, Labyrinth использует два дерева Меркля: одно для заметок и одно для корневых адресов.

Структура данных заметки содержит следующее:

• assetId: Идентификатор актива (ETH, WBTC, MATIC и т. д.), который представляет значение этой заметки.
• value: Значение или сумма, которую представляет записка.
• leafIndex: Конечный индекс дерева Меркла обязательств, в которое будет вставлена эта заметка.
• Ослепляющий: Случайный ослепляющий фактор.
• rootAddress: Корневой адрес пользователя, имеющего полномочия на его расходование.
• revoker: Публичная ключевая точка выбранного отзывщика.

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

Скрытый пул

Что действительно интересно в Labyrinth, который также немного отличается от ванильных протоколов, основанных на скрытых адресах, так это то, что пул активов на самом деле является экранированным пулом, который использует концепцию нот для создания своего рода экранированного пула UTXO, который обеспечивает прямую секретность транзакций. Напомним, что с реализациями eip-5564 организация, которой пользователь переводит средства, сможет увидеть, откуда эти средства поступили. Другими словами, Алиса платит Бобу, используя скрытый адрес, Боб платит Чарли, так что теперь Чарли может видеть, что Боб изначально получил средства от Алисы, и так далее. Это не относится к экранированному бассейну Лабиринта.

Для понимания того, как работает этот защищенный пул, нам нужно посмотреть, как средства передаются внутри протокола:

Балансы пользователя в защищенном пуле являются суммой записей соответствующих активов. Чтобы потратить эти записи, пользователь должен раскрыть «аннулирующие элементы» этих записей. Аннулирующий элемент уникален для записи, и после того, как эта запись потрачена, аннулирующий элемент помечается, чтобы предотвратить двойные траты, и из этой потраченной записи создается новая запись. Несколько записей одного и того же актива могут быть объединены, и можно создать несколько новых записей. Аннулирующий элемент просто является хэшем (𝑙,𝑐,𝛿), где 𝑙 - это индекс привязки записи в дереве привязок записей, а 𝑐 - привязка, а 𝛿 - случайный элемент, также называемый фактором затемнения.

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

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

Для того чтобы потратить средства, пользователь также должен сгенерировать zk-доказательство, в отличие от реализаций erc-6654, которые по сути являются обычными адресами Ethereum. Для генерации доказательства требуется совместимый кошелек, производительность которого довольно хорошая, занимая примерно 20 секунд на устройстве среднего уровня на базе Android.

Сборщик и конвертер

Labyrinth предлагает несколько интересных функций, которые решают некоторые проблемы скрытых транзакций. Транзакции, отправленные в ядро контрактов Labyrinth, отправляются как пользовательские операции через пакеты erc-4337. Эта настройка позволяет тратить заметки без ETH или требовать газовых токенов для транзакций, поскольку пользователь может использовать paymaster erc-4337 для оплаты газа от их имени, что добавляет еще один уровень конфиденциальности. Единственным исключением является первоначальный депозит, который не представлен в виде пользовательской операции. Это использование paymaster er-4337 также имеет дополнительное преимущество в том, что можно оплатить газ с помощью передаваемых активов, даже если они являются токенами erc-20, и для этого Labyrinth предоставляет API оракула цены газа.

Еще одна очень приятная особенность Labyrinth - это модульная архитектура, которая позволяет контрактам конвертеров выступать в качестве прокси для сторонних dapps. Это позволяет пользователям не только переводить средства с помощью скрытых транзакций, но и взаимодействовать со сторонними децентрализованными приложениями, такими как DEX (например, Uniswap, Aave, Lido и т. д.). Эти прокси-контракты-«конвертеры», по сути, реализуют функцию, которая принимает некоторую сумму актива, и некоторое количество актива выходит, с базовой логикой, находящейся в некотором стороннем контракте.

Решение по соответствию

Labyrinth обеспечивает соблюдение требований и регулирование путем использования фреймворка, называемого Selective De-Anonymization (SeDe).

Напомним, что структура данных заметки содержит поле с именем «revoker». Revoker - это адрес конкретного субъекта, который может инициировать процесс деанонимизации. Пользователь должен выбрать хотя бы одного revoker из предопределенного списка. Revoker не несет полной ответственности за выявление потенциально незаконной или незаконной деятельности, но может реагировать на запросы правоохранительных органов.

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

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

Railgun

RAILGUN - это система конфиденциальных транзакций, развернутая на Ethereum, BSC, Polygon и Arbitrum. Протокол в некотором смысле похож на Labyrinth, поскольку он основан на заметках, которые хранятся в дереве Меркла в виде коммитов и формируют набор UTXO, то есть заметки могут быть потрачены, создавая новые заметки для других получателей. Чтобы потратить заметку, для этой заметки добавляется нулевой фиксатор в состояние, предотвращающий двойные траты. Только владелец заметки может рассчитать ее нулевой фиксатор, который основан на хэше ключа траты и индексе заметок в дереве Меркла, что означает, что только владелец заметки может потратить ее (и может потратить ее только один раз).

В Railgun скрытые мета-адреса используют префикс "0zk", и, как и в eip-5564, это конкатенация открытого ключа просмотра и открытого ключа расходования. Однако Railgun использует ключи Ed25519 на кривой BabyJubJub вместо ECDSA & secp256k1. Так же, как и в eip-5564, пользователи сканируют все сгенерированные события из контрактов Railgun и используют свой ключ просмотра, чтобы определить, какие события представляют собой переводы на их кошелек.

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

Railgun имеет модульную архитектуру, которая позволяет ему взаимодействовать с внешними умными контрактами, обеспечивая функциональность, превышающую простые переводы. Он делает это через контракт AdaptRelay, который защищает и разблокирует токены до и после взаимодействия с внешним контрактом, например, разблокировать токен A, обменять на токен B на каком-то AMM, заблокировать токен B обратно владельцу.

С версией 3 Railgun планирует использовать eip-4337, а также поддерживать устаревшие мета-транзакции. Они надеются, что, поддерживая выделенный пользовательский мемпул eip-4337 для Railgun, независимые решатели смогут участвовать как вещатели. В настоящее время они сотрудничают с Umbra по исследованию этого вопроса, выявлению граничных случаев и способов их решения, см. раздел Railgun v3 ниже для получения более подробной информации.

Комиссии

Протокол Railgun взимает комиссию в размере 0,25% за ввод и вывод средств. Эти сборы отправляются в казначейство DAO, и эти сборы со временем выплачиваются стейкерам токена управления RAIL. Помимо комиссии за ввод и вывод средств в размере 0,25%, вещатели, как правило, также взимают свою собственную комиссию, которая обычно составляет примерно 10% от комиссии за газ за фактическую транзакцию в сети.

Управление

У Railgun есть система управления, которая позволяет представлять любую форму предложения, и никакие изменения в любом из основных контрактов (включая контракты казначейства и управления) не могут произойти без предложения DAO. Необычно, у разных экземпляров Railgun есть своя собственная система управления. Например, Railgun на Ethereum, Polygon и Binance Chain имеют свои собственные системы управления и токены.

SDK и Кулинарная книга

Railgun предлагает полноценный и хорошо задокументированный SDK, который разработчики кошельков или dapp могут использовать для создания функциональности скрытого адреса с поддержкой Railgun. Railgun также имеет поддержку сообщества.книга рецептовс помощью «рецептов», которые позволяют разработчикам dapp предоставлять модули для Railgun, позволяющие пользователям взаимодействовать с их dapp с использованием Railgun. Например, разработчик может написать рецепт для DEX, который позволяет пользователям с балансами токенов в Railgun обменивать токены конфиденциально.

RailGun v3

Следующая версия Railgun сделает транзакции дешевле на 50% — 60%. Другие изменения в версии 3 - переход к поддержке eip-4337 userops через выделенный mempool. Кроме того, v3 будет поддерживать архитектуру на основе намерений, которая позволит решателям конкурировать за лучшее выполнение, хотя детали находятся на очень высоком уровне на момент написания. В настоящее время они сотрудничают с КороваСвопна этом и планирую использовать предварительные и последующие хуки, чтобы позволить решателям получить доступ к средствам.

Railgun Connect

Можно сказать, что самое интересное изменение, которое предлагается, - это так называемое подключение Railgun, которое описывается как аналогичный инструмент WalletConnect, который позволяет адресам 0zk подключаться к большинству фронтендов для частного использования, не требуя от этих dapps специальной явной интеграции с Railgun через настраиваемые модули.

Railgun Connect - это расширение для браузера, которое фактически разветвляет состояние цепочки локально с использованием HardHat, и внедряет свой собственный поставщик web3 в dapp с RPC-конечной точкой локальной версии цепочки HardHat. Это позволяет вам выполнять взаимодействия с контрактами dapp, как обычно, записывает транзакции, затем группирует их и создает доказательство snark, и отправляет его в фактические контракты Railgun на реальной цепочке. Хотя эта описание немного упрощено, оно передает общую идею. Это позволяет вам взаимодействовать с практически любым dapp (с некоторыми исключениями для dapps, которые выполняют дополнительную внеланцетную обработку). Однако следует иметь в виду, что сохранение состояния цепочки локально является ресурсоемкой операцией, но после ее завершения вы сможете взаимодействовать с dapp, используя скрытые адреса Railgun, не замечая никакой разницы по сравнению с обычным кошельком.

Заключение

Существуют интересные предложения по закреплению скрытых адресов в протоколе Ethereum. Например, ИнкоInco использует идею "обертки" erc-20, которая оборачивает обычный контракт erc-20 и шифрует все балансы. Переводы и утверждения осуществляются в зашифрованном состоянии с помощью полностью гомоморфного шифрования. Inco полагается на предварительные вычисления, которые в настоящее время существуют только в его собственной сети, но могут когда-нибудь попасть на Ethereum.

Также есть еще одно предложение, называемое EIP-7503: Нулевые криптографические червоточиныкоторый основан на дизайне, называемом "доказательство сжигания", хотя, кажется, это не получает много упора, возможно, потому что для этого требуется обновление EVM, без которого его действительно можно реализовать только на уровне токена, используя дизайн erc-20, который поддерживает eip-7503 специально (или если L2 решит добавить поддержку своим EVM операциям).

АцтекВозможно, Aztec - самая сложная технология конфиденциальности, но для ее использования пользователям необходимо связать средства с Aztec, что может быть неприемлемым для большинства пользователей. Однако, если спрос на базовую конфиденциальность транзакций растет среди пользователей Ethereum, то Aztec может предложить уникальное предложение, которое делает его очень ценным L2, поскольку dApps и пользователи мигрируют на платформу, которая обеспечивает конфиденциальность по умолчанию.

Аналогично, Intmax — это Ethereum L2 (основанный на дизайне Plasma), который ориентирован на конфиденциальность, а также соответствует нормативным требованиям, проверяя легитимность отдельных средств с помощью доказательств AML на основе ZKP и налагая ограничения на суммы транзакций. Intmax ограничен с точки зрения обеспечения конфиденциальности переводов, в то время как операции со смарт-контрактами EVM не являются частными. Однако, в отличие от Aztec, смарт-контракты могут быть написаны на Solidity, который некоторые разработчики могут предпочесть (в зависимости от варианта использования).

Поддержка кошелька

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

• Предоставят ли они мнение настойчивую поддержку для одной реализации или создадут и поддерживают своего рода всеобъемлющий агрегатор по нескольким протоколам? Второй вариант, вероятно, будет слишком дорогим с точки зрения разработки и поддержки.
• Будут ли учитываться регуляторные аспекты, и будет ли им необходимо занять позицию относительно степени и механизма селективной деанонимизации (т.е. подобной Labyrinth’s)?
• Скрытые адреса требуют наличия онлайн-компонента по сравнению с реестровым контрактом (за исключением Fluidkey), поэтому это означает, что каждая сеть EVM должна быть явно поддержана кошельком (хотя дизайн Umbra облегчает безразрешную развертку реестра).
• Скрытые адреса делают существующую интеграцию с исследователями блоков (например, Etherscan) более сложной. Например, кнопка «Просмотр в исследователе» не будет работать для скрытого мета-адреса, где кошелек показывает совокупный баланс. Эта проблема может существовать и для переводов. Подобные случаи, как этот, нужно будет обдумать.
• В зависимости от базовой реализации пользователь сможет эффективно использовать скрытый адрес только с определенным набором dapps, а именно тех, которые поддерживаются базовым протоколом. Это будет возможно с модульными архитектурами скрытых адресов. Однако не все dapps будут поддерживаться, и это нужно будет как-то сообщить пользователю. Это немного проще с eip-5506, но у него все еще есть свои осложнения и крайние случаи, и это часто может просачиваться через UX кошелька.

Также существует потенциал для улучшения предотвращения неправильной конфиденциальности пользователей, см. эту статью: “Анализ анонимности схемы Umbra Stealth Address на Ethereum» за то, как авторы успешно деанонимизировали 48,5% скрытых транзакций в основной сети Ethereum. Эвристики, которые они использовали для этого, не имели ничего общего с протоколами, а скорее касались гигиены конфиденциальности, например, пользователь отправляет средства на скрытый адрес, который он контролирует, а затем отправляет эти средства обратно на адрес, с которого он их первоначально отправил, ошибочно полагая, что отслеживаемость нарушена. В целом, авторы определили 6 различных эвристик, которые могут быть использованы для деанонимизации транзакций скрытых адресов, в основном все они основаны на неследовании передовой практике. Тем не менее, это критические проблемы UX, которые необходимо решать.

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

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

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

1. Эта статья перепечатана с [Medium]. Все авторские права принадлежат оригинальному автору [Саймон Браун]. Если есть возражения против этой публикации, пожалуйста, свяжитесь со Gate Learnкоманда и они обработают его незамедлительно.
2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, являются исключительно мнениями автора и не являются инвестиционным советом.
3. Команда Gate Learn переводит статьи на другие языки. Если не указано обратное, копирование, распространение или плагиат переведенных статей запрещены.