Вступ

Основною больовою точкою для користувачів криптовалют web3 є відсутність конфіденційності. Той факт, що всі транзакції відображаються в загальнодоступному реєстрі, і все частіше: пов'язані з одним розбірливим ім'ям ENS, є стримуючим фактором для користувачів виконувати певну діяльність або змушує їх виконувати ці дії таким чином, що призводить до збільшення тертя в UX. Одним із прикладів є простий переказ коштів з гарячого гаманця на холодний гаманець або навпаки. Користувачі можуть не захотіти, щоб один гаманець був пов'язаний з іншим, оскільки вони можуть не хотіти, щоб баланс їхнього холодного гаманця був помічений. Наразі адреси Ethereum не працюють як приватні банківські рахунки, тому що всі можуть бачити ваш гаманець, а все частіше і вашу соціальну активність (SBT, атестації, активність у різних децентралізованих програмах тощо). Саме з цих причин Віталік назвав приватність однією з три великі технічні переходищо Ethereum повинен пройти, щоб бути корисним для звичайних користувачів.

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

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

Потреба користувача в приватності

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

1. Опитування, яке було проведено в 2022 році і опубліковане Сіміном Ґесматі та ін. у статті під назвою: Користувацька концепція конфіденційності в блокчейні, заявив, що "половина опитаних вказали, що конфіденційність транзакцій для них дуже важлива". Хоча це дослідження було більше пов'язане з Bitcoin, ніж з Ethereum, ймовірно, у користувачів Ethereum також є подібні настанови. Однак розмір вибірки для цього дослідження був досить малим (14 учасників).
2. Ще одне цікаве дослідження з 2022 року, опубліковане в Фронтири, затитульований Політичні, економічні та управлінські установки користувачів блокчейну, більш комплексний, з опитанням 3 710 користувачів криптовалют. Результати показали, що близько чверті респондентів вказали, що конфіденційність є «найважливішою функцією блокчейну та криптовалют».

1. Стосовно загального ставлення до приватності, Consensys опубліковані дослідження з назвою Опитування Web3 та криптовалютного світу 2023 року, в ході якого опитували 15 158 осіб онлайн у 15 країнах на різноманітні теми, що стосуються Інтернету, а не лише криптовалют. В опитуванні виявилося, що 83% респондентів вважають, що конфіденційність даних є важливою, тоді як лише 45% респондентів заявили, що довіряють тому, як поточні Інтернет-сервіси використовують їх дані та особисту інформацію.
2. A опитування, проведене Схемою компенсації фінансових послуг Великої Британії, опублікована у квітні 2023 року, підкреслила, що 9% респондентів вказали «бажання анонімності / конфіденційності» як причину інвестування в криптовалюту.

Прийняття протоколів Stealth Transaction

Railgun має вражаючі цифри, при цьому використання протоколу, схоже, також неухильно зростає з часом, досягнувши піку в понад 70 мільйонів доларів TVL і 2 мільярди доларів США обсягу станом на листопад 2024 року.

TVL (USD) Railgun на основній мережі Ethereum — джерело: ​​Railgun — DefiLlama

Тіньтакож помітив стійкий приріст людей, які використовують їх протокол (люди реєструють приховану адресу на свій ENS), майже 77 тис. на листопад 2024 року:

Умбра Кумулятивних Реєстрантів (Крос-Ланцюжок) — джерело: dune.com

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

Діаграма нижче показує TVL Tornado Cash з часом. Ми можемо спостерігати, що перший значний спад TVL з його піку близько жовтня 2021 року співпав з більш широким продажем на криптовалютних ринках, другий значний спад у серпні 2022 року відповідає розміщенню Tornado Cash в списку SDN OFAC, а третій значний спад відповідає переприсвоєнню OFAC у листопаді 2022 року. З того часу, однак, Tornado Cash бачить стійкий ріст, незважаючи на санкції, майже досягнувши $600M у TVL. Це досить сильний доказ того, що існує попит на основну конфіденційність транзакцій в Ethereum.

TVL (USD) Tornado Cash на Ethereum main — джерело: Tornado Cash - DefiLlama

Ландшафт прихованої адреси

Дане дослідження виявило 4 основних рішення для EVM-ланцюгів, що знаходяться у виробництві на сьогоднішній день, а саме:

• Fluidkey
• Umbra
• Лабіринт
• Рейлган

Як Fluidkey, так і Umbra ґрунтуються на стандартах Ethereum, які є:

• ERC-5564: Протокол Stealth Address
• ERC-6538: Реєстр прихованих мета-адрес

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

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

Стандарт erc-5564 визначає механізм, за допомогою якого одержувач може опублікувати приховану мета-адресу, з якої можна похідно отримати нові адреси Ethereum. Будь-хто, хто бажає надіслати кошти одержувачу, може генерувати нові адреси з прихованої мета-адреси і дозволити одержувачу дізнатися про ці кошти без будь-якого прямого спілкування. Усі реалізації прихованих адрес працюють на цій основній передумові.

Як працюють Stealth-адреси

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

st:eth:0x036ffa94a70a5b9608aca693e12da815fe0295f3739c7b22b0284c6d85c464ba4a02c0521b6fe31714b2ca0efa159402574355b754e0b50406b0b5fb33128eec3507

Для простоти цю приховану адресу можна пов'язати зі звичайною адресою Ethereum (і, отже, ENS), що полегшує надсилання коштів власнику стелс-адреси. Щоб відправити кошти, відправник повинен визначити вищевказану адресу і, використовуючи стандарт EIP-5564, створити ефемерний відкритий ключ, з якого потім виводиться прихована адреса. Відправник надсилає кошти на нову приховану адресу, як правило, через контракт singleton, який усі одержувачі стелс-адрес прослуховують для подій. Цей контракт імітує подію "Оголошення", на яку підписуються одержувачі. Щоразу, коли відбувається подія оголошення, одержувачі перевіряють ефемерний публічний ключ в оголошенні, об'єднують його з приватним ключем перегляду та визначають, чи мають вони можливість витратити кошти, надіслані на приховану адресу. Якщо вони це зроблять, гаманець / клієнт, який вони використовують, запам'ятає приховану адресу та відповідні кошти, додавши їх до відображеного балансу користувача. Щоб фактично витратити кошти, вони можуть підписати транзакцію за допомогою приватного ключа витрат.

Наступна діаграма зображує весь процес від початку до кінця, сподіваюся, трохи чіткіше:

Запам'ятайте, що цей процес відбувається повністю нероздільно, що означає, що відправник і одержувач ніколи не мають жодної прямої комунікації, що означає, що фактично не існує жодного зв'язку між відправником і одержувачем, який може бути помічений будь-яким третім боком.

Однак, щоб це працювало в першу чергу, одержувач повинен повідомити відправнику (відправникам) свою приховану адресу. Один з способів зробити це - використовувати eip-6538 Stealth Meta-Address Registry. Це однотонний контракт, який дозволяє користувачам реєструвати стелс-мета-адресу на звичайну адресу Ethereum, яку відправники потім можуть знайти. Це дозволяє відправникам визначити звичайну адресу з ENS, а потім шукати пов'язану приховану метаадресу з реєстру.

Ця схема розриває зв'язок між відправником і одержувачем, надаючи їм обом конфіденційність, щоб весь світ не знав їх справи. Є кілька застережень:

• Коли одержувач витрачає кошти, той, кому вони передаються, бачить, що вони походять від початкового відправника (тобто вони можуть побачити адресу, з якої були переказані кошти, і хто раніше надсилали кошти на цю адресу). Це означає, що ланцюжок переказів залишається незмінним і слідованим, але він просто не пов'язаний з одержувачем питання (якщо одержувач не робить щось подібне, як відправка коштів на одну зі своїх відомих непомітних адрес). Зверніть увагу, що це стосується лише реалізацій erc-5564, а не Railgun або Labyrinth.
• Ще один побічний ефект вищезазначеної проблеми полягає в тому, що для збереження оптимальної конфіденційності користувачу, ймовірно, доведеться залишити кошти на прихованих адресах, куди вони спочатку були відправлені, до того моменту, коли їм дійсно знадобиться, а не об'єднувати їх під одну адресу. Це означає додаткове навантаження на пам'ять адрес, а також витрачання коштів на цих адресах, оскільки суму, яку ви хочете переказати, доведеться отримати з комбінації коштів з різних інших адрес.
• Для переказу коштів з цієї адреси отримувачеві потрібно буде поповнити адресу деякою кількістю ETH для оплати газу, і це може потенційно деанонімізувати отримувача. Це відома проблема з прихованими адресами, одна з причин, чому кілька реалізацій впровадили підтримку eip-4337 та пеймастера.
• Одним з недоліків схеми прихованих адрес є те, що отримувачам потрібно відслідковувати блокчейн для подій Announcement та перевіряти кожне оголошення, щоб визначити, чи були відправлені їм кошти. Це очевидно є практичною надмірністю для більшості користувачів, особливо коли йдеться про отримання коштів на кількох мережах. Щоб зробити цей процес більш ефективним, стандарт передбачає «тег для перегляду», який є скороченим хешем, отриманим від спільного секрету, та може використовуватися для швидкого відкидання транзакцій, які точно не призначені для них. За допомогою тегів для перегляду продуктивність настільних комп'ютерів не дуже погана, проте на мобільних пристроях вона може бути помітною. Єдиний раз, коли зменшення продуктивності дійсно помітно, - це коли гаманець відновлюється, в цьому випадку гаманець повинен просканувати кожну адресу з моменту розгортання контракту on-chain, що є часомозатратним.
• Для обходу цього користувачі можуть вибірково поділитися приватним ключем перегляду з надійною стороною. Цей сервіс третьої сторони може моніторити різні мережі і повідомляти користувачів, коли вони отримали кошти. Звичайно, це супроводжується компромісом: хоча третя сторона не може фактично витрачати кошти користувачів (вони не мають приватного ключа витрат для цього), вони можуть бачити усі кошти, відправлені певному одержувачу, що означає, що користувач повинен довіряти їм своєю конфіденційністю. 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 є те, що він розгортає обліковий запис розумного контракту для кожної нової прихованої адреси. Це відбувається контрафактивно лише тоді, коли кошти з прихованої адреси витрачаються. Розумний обліковий запис - це обліковий запис Safe 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 offchain вирішувач (також відомий як erc-3668: CCIP Read), щоб повернути приховані адреси. Щоразу, коли запитується офчейн-резольвер, він генерує та повертає нову приховану адресу для відповідного імені ENS. Це приємна функція, оскільки вона дозволяє користувачеві мати одне зрозуміле ім'я ENS, зберігаючи при цьому конфіденційність прихованих адрес, оскільки згенеровані приховані адреси не можуть бути пов'язані з ім'ям ENS ретроспективно.

Вартість

Fluidkey безкоштовний у використанні та не стягує комісію. Є вартість розгортання контракту Safe на кожну адресу, на якій є кошти, коли ви хочете витратити ці кошти. Однак, хоча це відносно дорого на mainnet, на L2s це дійсно досить незначно, зазвичай менше 1 цента, навіть коли комбінуються кілька прихованих адрес у один трансфер.

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

Umbra Cash

Тінь - це реалізація eip-5564 + eip6538 від ScopeliftКоли користувач увійшов до додатка Umbra, він проходить фазу налаштування, під час якої він підписує повідомлення, з якого виводяться ключі витрат та перегляду, а також відповідна прихована мета-адреса. Потім вони реєструють цю приховану мета-адресу на своїй основній адресі гаманця в реєстрі на ланцюжку блоків. Тут і відбувається відмінність від Fluidkey.

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

Коли хтось хоче надіслати коштів користувачеві, він зазвичай використовує для цього додаток Umbra. По суті, додаток Umbra шукатиме приховану мета-адресу, зареєстровану на ім'я / адресу гаманця ENS, і генеруватиме приховану адресу. Одержувачі можуть увійти в додаток Umbra і відсканувати будь-які кошти, які були відправлені на приховані адреси, що належать їм з моменту останнього входу в систему. Завдяки розумному кешуванню це займає лише 10–15 секунд для щотижневого сканування, хоча користувачі також можуть за бажанням вказати діапазон блоків, щоб звузити сканування. Umbra v2 включатиме використання viewtags, що ще більше прискорить процес.

Релеер

Один з проблем з прихованими адресами, про який ми раніше згадували, полягає в тому, що для того, щоб отримувач міг витратити кошти, які були відправлені на прихований адрес, цей адрес потрібно мати ETH або інший необхідний токен для оплати комісій за транзакції. На більшості мереж, якщо спочатку на прихований адрес було відправлено ETH, це, як правило, не становить проблеми. Однак, якщо на прихований адрес було відправлено ерц-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, яка є складним рішенням, що дозволяє деанонімізувати певні операції для конкретних авторизованих учасників, тобто правоохоронних органів, таких як Інтерпол і т.д., зберігаючи при цьому прозорість та відкритість.

Основні розумні контракти, які використовує Labyrinth, включають багатотранзакційний та багатоактивний пул, який дозволяє користувачеві трансакціонувати кілька активів у одній транзакції. Щоб витратити активи, користувач сканує мережу і отримує зашифровані дані нотаток, розшифровує нотатки та фільтрує активи, які він хоче витратити. В подальшому, користувач створює ZKP, який включає транзакції та підпис від підписного ключа, пов'язаного з транзакціями, з яких користувач хоче витратити активи.

Частиною основних контрактів Labrynth є контракт конвертера, який взаємодіє з модульними контрактами-проксі, які фактично є проксі до зовнішніх контрактів. Наприклад, якщо користувач хоче використовувати Labrynth для взаємодії з Uniswap, користувач створив би транзакцію, яка використовувала б контракт конвертера для виклику операції обміну на пулі Uniswap через проксі-контракт Uniswap.

Протокол zkFi Labyrinth використовує «notes» для відстеження балансів та переказів. Note - це, по суті, структура даних, яка описує певну кількість якогось активу та до якої адреси він належить. Клієнт зберігає інформацію, необхідну для відтворення note, і використовує це для витрати активів. Зобов'язання перед note (хеш ідентифікатора активу, власника та значення) зберігається в мерклевому дереві на ланцюжку. Насправді, Labyrinth використовує два мерклевих дерева, одне для notes та одне для кореневих адрес.

Структура даних нотатки містить наступне:

• assetId: Ідентифікатор активу (ETH, WBTC, MATIC, тощо), який представляє цю нотуцію вартості.
• value: Вартість або сума, яку представляє нотатка.
• leafIndex: Індекс листа дерева зобов'язань Меркла, куди буде вставлено цю замітку.
• сліпуче: Випадковий сліпучий фактор.
• rootAddress: Коренева адреса користувача, який має повноваження витрачати її.
• відкликач: Обраний публічний ключ точки відкликача.

Ви помітите, що структура даних вище не містить жодних посилань на власника активів, що дивно, оскільки зобов'язання, яке записане в дереві меркла нотаток, є хешем ідентифікатора активу, вартості та власника. Фактично власник обчислюється з кореневого адресу, скасовувача та випадкового фактору засліплення, тому для зовнішніх спостерігачів власником є фактично новостворена адреса для кожної нової транзакції.

Захищений басейн

Що дійсно цікаво в Labyrinth, що також трохи відрізняється від протоколів на основі адреси заборони, це те, що активний пул фактично є захищеним пулом, який використовує концепцію нот, щоб створити свого роду захищений пул UTXO, який надає можливість захисту від впередньої секретності для транзакцій. Нагадаємо, що з реалізацією eip-5564 сутність, якій користувач передає кошти, зможе побачити, звідки ці кошти прийшли. Іншими словами, Еліс переказує Бобу кошти, Боб переказує Чарлі, тому тепер Чарлі може побачити, що спочатку Боб отримав кошти від Еліс, і так далі. Це не відбувається з захищеним пулом Labyrinth.

Щоб зрозуміти, як працює цей захищений пул, нам потрібно розглянути, як кошти перекладаються всередині протоколу:

Баланси користувача в захищеному пулі є сумою нот відповідних активів. Щоб витратити ці ноти, користувач повинен розкрити «нульові значення» цих нот. Нульове значення є унікальним для ноти, і як тільки ця нота витрачена, нульове значення позначається для запобігання подвійних витрат, і з цієї витраченої ноти створюється нова нота. Кілька нот того ж активу можуть бути об'єднані, і можна створити кілька нових нот. Нульове значення просто є хешем (𝑙, 𝑐, 𝛿), де 𝑙 - це індекс забезпеченості ноти в дереві меркла нот, а 𝑐 - забезпеченість, а 𝛿 - випадковий елемент, також відомий як фактор засліплення.

Отримувач прихованої транзакції визначає трансфер за такими ж засобами, як і eip-5564, наскільки вони слухають події, що випромінюються з основних контрактів, та визначають, з яких прихованих адрес вони зможуть відправити кошти, записуючи їх локально. Виявлення вхідних коштів також прискорюється за допомогою використання тегів перегляду та локального кешування та асинхронної синхронізації нотаток протягом життєвого циклу програми.

Тривають дослідження щодо того, щоб прискорити процес виявлення отриманих коштів, візьмемо, наприклад, цю пропозицію від Aztec: Запит пропозицій: Протокол виявлення нот — Aztec.

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

Бандлер і конвертер

Labyrinth пропонує кілька цікавих функцій, які вирішують деякі проблеми зміни транзакцій. Транзакції, відправлені на основні контракти Лабіринту, надсилаються як користувацькі операції через зв'язувальники erc-4337. Це дозволяє витрачати нотатки без ETH або потребує газових токенів для транзакцій, оскільки користувач може скористатися платником erc-4337, щоб оплатити газ від їх імені, що додає ще один рівень конфіденційності. Єдиним винятком є початковий депозит, який не подається як userop. Це використання платника er-4337 також має додаткову перевагу у змозі оплатити газ за допомогою переказуваних активів, навіть якщо вони є токенами erc-20, і для цього Лабіринт використовує API оракула ціни на газ.

Ще одна дуже приємна функція, яку має Labyrinth, — це модульна архітектура, яка дозволяє контрактам конвертерів діяти як проксі-сервер для сторонніх децентралізованих програм. Це дозволяє користувачам не просто переказувати кошти за допомогою прихованих транзакцій, але й взаємодіяти зі сторонніми децентралізованими програмами, такими як DEX (наприклад, Uniswap, Aave, Lido тощо). Ці проксі-контракти «конвертера», по суті, реалізують функцію, яка приймає певну кількість активу та певну кількість активу, при цьому основна логіка полягає в контракті з третьою стороною.

Рішення щодо дотримання вимог

Labyrinth забезпечує виконання вимог щодо дотримання вимог і регуляторних норм через рамки, відомі як Selective De-Anonymization (SeDe).

Нагадаємо, що структура даних нотатки містить поле, яке називається «відкликач». Відкликач - це адреса певної сутності, яка може ініціювати процес деанонімізації. Користувач повинен вибрати щонайменше одного відкликача з передбаченого списку. Відкликач не несе повної відповідальності за виявлення потенційно незаконної діяльності, але може реагувати на запити від правоохоронних органів.

Скасувальники не мають односторонньої можливості деанонімізувати транзакції безпосередньо, але вони відповідальні за ініціювання запитів на деанонімізацію. Ці запити публікуються публічно для опікунів, які є комітетом сутностей, що контролюють приватність та відповідність. Опікуни повинні відповісти на запит, проголосувавши за те, чи надавати дозвіл на деанонімізацію транзакцій. Якщо опікуни зможуть досягти кворуму та проголосувати за, тоді скасувальник може розшифрувати дані транзакції, дозволяючи їм зв'язати дану транзакцію з попередніми транзакціями, поки ланцюжок транзакцій не буде повністю деанонімізований.

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

Railgun

РЕЛЬСОТРОН - це система конфіденційних транзакцій, розгорнута на Ethereum, BSC, Polygon та Arbitrum. Протокол схожий у деяких аспектах на Labyrinth, оскільки він базується на нотах, які зберігаються у дереві Меркла як комітменти і формують набір UTXO, тобто ноти можуть бути витрачені шляхом створення нових нот для інших отримувачів. Щоб витратити ноту, до стану цієї ноти додається нульіфікатор, що запобігає подвійним витратам. Тільки власник ноти може обчислити її нульіфікатор, який базується на хеші ключа витрати та індексу нот на дереві Меркла, що означає, що тільки власник ноти може її витратити (і може витратити її лише один раз).

Стелс-метаадреси в Railgun використовують префікс «0zk» і, подібно до eip-5564, є конкатенацією публічного ключа перегляду та публічного ключа витрат. Однак Railgun використовує ключі Ed25519 на кривій BabyJubJub замість ECDSA і secp256k1. Так само, як у випадку з eip-5564, користувачі сканують всі випущені події від договорів Railgun та використовують свій ключ перегляду, щоб визначити, які події представляють перекази на їх гаманець.

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

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

З версією 3 Railgun планує використовувати eip-4337, а також підтримувати спадкові мета-транзакції. Вони сподіваються, що, зберігаючи присвячений eip-4337 userop mempool для Railgun, незалежні розв'язувачі зможуть брати участь як транслятори. Зараз вони співпрацюють з Umbra над дослідженням цього питання та виявленням крайових випадків та способів їх вирішення, див. розділ Railgun v3 нижче для отримання додаткової інформації.

Витрати

Протокол Railgun бере комісію 0.25% за внесення та виведення коштів. Ці комісії надсилаються до скарбниці DAO, і ці комісії виплачуються стейкерам токена управління RAIL з часом. Крім комісії за внесення та виведення 0.25%, транслятори, як правило, також застосовують власну комісію, яка, як правило, становить приблизно 10% від суми комісії за газ для фактичної транзакції на ланцюжку.

Управління

Railgun має систему управління, яка дозволяє подавати пропозиції в будь-якій формі, і жодні зміни в будь-якому з основних контрактів (включаючи контракти казначейства та управління) не можуть відбутися без пропозиції DAO. Незвично, що окремі екземпляри Railgun мають своє власне управління. Наприклад, Railgun на Ethereum, Polygon і Binance Chain мають свої окремі системи управління і токени.

SDK та Кулінарна книга

Railgun пропонує всеосяжний та добре задокументований набір інструментів розробника SDK, який розробники гаманців або додатків можуть використовувати для побудови функціональності Stealth Address за допомогою підтримки Railgun. Railgun також має спільноту, що підтримуєкулiнарна книгаз “рецептами”, які дозволяють розробникам додатків надавати модулі для Railgun, які дозволяють користувачам взаємодіяти зі своїм додатком, використовуючи Railgun. Наприклад, розробник може написати рецепт для DEX, який дозволяє користувачам з балансами токенів в Railgun обмінювати токени конфіденційно.

RailGun v3

Наступна ітерація Railgun зробить транзакції приблизно на 50% — 60% дешевше. Інші зміни в версії 3 - це перехід до підтримки користувацьких операцій eip-4337 через відведений мемпул. Крім того, v3 буде надавати підтримку для архітектури на основі намірів, яка дозволить розв'язувальникам конкурувати за краще виконання, хоча деталі наразі дуже загальні. Наразі вони працюють з CowSwapна це і планують використовувати попередні та післязагальні гачки для того, щоб дозволити розв'язникам отримати доступ до коштів.

Railgun Connect

Можна сказати, що найцікавішою зміною, яка пропонується, є щось під назвою Railgun Connect. Це описується як схожий інструмент до WalletConnect, оскільки він дозволяє 0zk адресам підключатися до більшості фронтендів для приватного використання, не вимагаючи від цих додатків конкретної інтеграції з Railgun за допомогою спеціальних модулів.

Railgun Connect — це розширення для браузера, і те, що воно робить, — це фактично розгалужує стан ланцюга локально за допомогою HardHat під капотом і впроваджує власного web3-провайдера в децентралізовану програму з RPC-кінцевою точкою локальної версії ланцюга HardHat. Потім це дозволяє вам здійснювати взаємодію з контрактами децентралізованих програм, як зазвичай, записує транзакції, потім групує їх, створює доказ снарка та надсилає це фактичним контрактам Railgun у реальному ланцюжку. Хоча цей опис дещо спрощений, він передає загальну ідею. Це дозволяє вам фактично взаємодіяти практично з будь-якою децентралізованою програмою (з деякими крайніми випадками для децентралізованих програм, які виконують додаткову обробку поза мережею). Нюанс полягає в тому, що збереження стану ланцюга локально є важкою операцією, але після цього це означає, що ви можете взаємодіяти з децентралізованими програмами, використовуючи стелс-адреси Railgun, не бачачи жодної різниці з використанням звичайного гаманця.

Висновок

Існують деякі цікаві пропозиції щодо закріплення прихованих адрес в протоколі Ethereum. Наприклад, Incoвикористовує ідею «обгортки» erc-20, яка обгортає звичайний контракт erc-20 і шифрує всі баланси. Перекази та затвердження здійснюються на зашифрованому стані за допомогою повністю гомоморфного шифрування. Inco покладається на попередні компіляції, які наразі існують лише в її власній мережі, але можуть дещо змінитися в Ethereum.

Існує ще одне пропозиція під назвою EIP-7503: Нульові знання Червоні діри який заснований на дизайні під назвою «proof-of-burn», хоча це, здається, не набуває великої популярності, ймовірно, тому, що вимагає оновлення EVM, без якого його дійсно можна реалізувати лише на рівні токенів, використовуючи дизайн ERC-20, який підтримує конкретно eip-7503 (або якщо L2 вирішить додати підтримку до своїх кодів операцій EVM).

Ацтекможливо, найскладніша технологія конфіденційності, але вона вимагає, щоб користувачі перекинули кошти на Aztec, щоб користуватися нею, що, можливо, є неприйнятним для більшості користувачів UX. Однак, якщо попит на базову приватність транзакцій зростатиме серед користувачів Ethereum, то Aztec може мати унікальну пропозицію цінності, що робить його дуже цінним L2, коли dapps і користувачі мігрують на платформу, яка забезпечує конфіденційність за замовчуванням.

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

Підтримка гаманця

Поки ми спостерігаємо зростання популярності протоколів прихованих адрес, що є обіцяючим, залишається кілька викликів. Найважливішим викликом є те, що їх ще не повністю підтримують у популярних гаманцях Ethereum (поки що). У гаманцях мають бути кілька варіантів вибору, якщо вони збираються надати підтримку для прихованих адрес. Деякі з цих варіантів включають:

• Чи вони нададуть обґрунтовану підтримку для однієї реалізації, чи побудують і будуть підтримувати якийсь вид загального агрегатора через кілька протоколів? Останнє, ймовірно, буде надто дорогим у відношенні до розробки та обслуговування.
• Чи будуть регуляторні врахування, і чи потрібно буде зайняти позицію стосовно ступеня та механізму селективної деанонімізації (тобто, як у Лабіринта)?
• Адреси Stealth вимагають компонента на ланцюжку відповідно до контракту реєстру (за винятком Fluidkey), тому це означає, що кожну мережу EVM необхідно підтримувати явно кошельком (хоча дизайн Umbra сприяє бездозвільному розгортанню реєстру).
• Стелс-адреси роблять існуючі інтеграції з блок-експлорерами (наприклад, Etherscan) більш складними. Наприклад, кнопка «Переглянути в Explorer» не буде працювати для стелс-мета-адреси, де гаманець показує загальний баланс. Ця проблема може існувати і для переказів. Різноманітні крайні випадки, такі як цей, потрібно буде обдумати.
• Залежно від базової реалізації користувач зможе ефективно використовувати приховану адресу лише з певним набором додатків (dapps), а саме тих, які підтримуються базовим протоколом. Це буде можливо завдяки модульним архітектурам прихованих адрес. Однак, не всі додатки (dapps) будуть підтримуватися, і це потрібно буде якось сповістити користувачеві. З eip-5506 це трохи простіше, але все ж має свої ускладнення та граничні випадки, і це часто може просочуватися в інтерфейс гаманця.

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

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

Велике визнання всім командам, які відділили час і великий труд на дослідження та створення інфраструктури невидимої адреси, включаючи чотири протоколи, про які я говорив у цьому пості. Їх велика праця і наполегливість зроблять велику різницю для Ethereum!

Відмова від відповідальності:

1. Цю статтю перепринтовано з [Середній]. Усі права на авторські права належать оригінальному автору [Саймон Браун]. Якщо є заперечення стосовно цього перепублікування, будь ласка, зв'яжіться з Ворота Навчаннякоманда, і вони швидко з цим справляться.
2. Відмова від відповідальності: Думки та погляди, висловлені в цій статті, належать виключно автору і не становлять жодної інвестиційної поради.
3. Команда Gate Learn перекладає статті на інші мови. Якщо не зазначено, копіювання, розповсюдження або плагіат перекладених статей заборонено.