# Stealth addresses

**Published by:** [hunterrr](https://paragraph.com/@popa/)
**Published on:** 2024-12-05
**URL:** https://paragraph.com/@popa/stealth-addresses

## Content

Короткий гайд по прихованим адресамСьогодні ми розбиратимемо те, як у EVM можуть підвищити рівень конфіденційності.ВступОднією з найбільших проблем, які досі зашились в екосистемі Ethereum - конфіденційність. За умовчанням все, що потрапляє до публічного блокчейну, залишається публічним назавжди. Найчастіше це означає не тільки гроші та фінансові транзакції, але й домени ENS, POAP, NFT, токени soulbound та багато іншого. На практиці використання всього набору програм Ethereum передбачає оприлюднення значної частини вашого життя для загального огляду та аналізу. У цій статті ми опишемо механіку та приклади використання іншої категорії інструментів, які можуть покращити приватність у Ethereum.Що таке система прихованих адрес?Припустимо, Аліса хоче відправити Бобу актив. Це може бути деяка кількість криптовалюти (наприклад, 1 ETH, 500 RAI), або це може бути NFT. Коли Боб отримує актив, він не хоче, щоб увесь світ знав, що саме він його отримав. Приховати факт передачі неможливо, особливо якщо це NFT, який має лише одну копію на блокчейні, але можливість приховування того, хто є одержувачем, може бути набагато життєздатнішою. Аліса і Боб також ліниві: вони хочуть систему, в якій процес оплати точно такий ж самий, як і сьогодні. Боб посилає Алісі (або реєструє в ENS) "адресу", який кодує, як хтось може йому заплатити, і однієї цієї інформації достатньо, щоб Аліса (або будь-яка інша людина) відправила йому актив. Зауважте, що це інший вид конфіденційності, ніж той, який забезпечує, наприклад, Tornado Cash. Tornado Cash може приховати переклади основних взаємозамінних активів, таких як ETH або основні ERC20 (хоча він найбільш зручний для приватної відправки самому собі), і він взагалі не може додати конфіденційності до переводів NFT. !https://img2.teletype.in/files/54/d8/54d86402-180f-459c-bc50-ec24ebaca316.png Звичайний робочий процес здійснення платежу за допомогою криптовалюти. Ми хочемо додати конфіденційності (ніхто не зможе сказати, що саме Боб отримав актив), але зберегти колишній процес. Приховані адреси забезпечують таку схему. Прихована адреса - це адреса, яка може бути згенерована як Алісою, так і Бобом, але контролювати яку може тільки Боб. Боб генерує та зберігає в секреті ключ для витрачання коштів та використовує цей ключ для генерації прихованої мета-адреси. Він передає цю мета-адресу Алісі (або реєструє її в ENS). Аліса може зробити обчислення на цій мета-адресі, щоб згенерувати приховану адресу, що належить Бобу. Потім вона може відправити будь-які активи на цю адресу і Боб матиме повний контроль над ними. Разом із передачею вона публікує у блокчейні деякі додаткові криптографічні дані (ефемерний публічний ключ), які допомагають Бобу виявити, що ця адреса належить йому. Інший спосіб подивитися на це так: стелс-адреси забезпечують ті ж властивості конфіденційності, що і генерування Бобом свіжої адреси для кожної транзакції, але не вимагають жодної взаємодії з боку Боба. Повний робочий процес схеми прихованих адрес можна представити таким чином: !https://img4.teletype.in/files/3f/89/3f892c38-3591-4ecf-a441-82ad0bc93a1a.pngБоб генерує свій кореневий ключ витрат (m) і приховану мета-адресу (M)Боб додає запис ENS для реєстрації M як приховану мета-адресу для bob.ethМи припускаємо, що Аліса знає, що Боб – це bob.eth. Аліса шукає його приховану мета-адресу M в ENSАліса генерує ефемерний ключ, який відомий тільки їй і який вона використовує лише один раз (для генерації цієї конкретної прихованої адреси)Аліса використовує алгоритм, який поєднує її ефемерний ключ і мета-адресу Боба для створення прихованої адреси. Тепер вона може надсилати активи на цю адресуАліса також генерує свій ефемерний відкритий ключ і публікує його в реєстрі ефемерних відкритих ключів (це може бути зроблено в тій же транзакції, що і перша транзакція з відправки активів на цю стелс-адресу)Щоб Боб виявив приховані адреси, що належать йому, Бобу необхідно просканувати реєстр ефемерних відкритих ключів на предмет всього списку ефемерних відкритих ключів, опублікованих будь-ким з будь-якої причини з моменту останнього скануванняДля кожного ефемерного відкритого ключа, Боб намагається об'єднати його зі своїм кореневим ключем витрат для створення прихованої адреси і перевіряє, чи є в цій адресі активи. Якщо є, Боб обчислює ключ витрат для цієї адреси та запам'ятовує йогоВсе це ґрунтується на двох видах криптографічної хитрості. По-перше, нам потрібна пара алгоритмів для створення спільного секрету: один алгоритм, який використовує секретну річ Аліси (її ефемерний ключ) та відкритий ключ Боба (його мета-адресу), та інший алгоритм, який використовує секретну річ Боба (його кореневий ключ) та відкритий ключ Аліси (її ефемерний відкритий ключ). Це можна зробити багатьма способами, наприклад, обмін ключами Діффі-Хеллмана. Але загального секрету самого по собі недостатньо: якщо ми просто згенеруємо закритий ключ із загального секрету, то і Аліса, і Боб зможуть витрачати з цієї адреси. Ми могли б залишити все як є, надавши Бобові можливість самому переказувати кошти на нову адресу, але це неефективно і без потреби знижує безпеку. Тому ми також додаємо механізм засліплення ключів (key blinding mechanism): пару алгоритмів, в яких Боб може об'єднати спільний секрет зі своїм кореневим ключем витрат, а Аліса може об'єднати спільний секрет з мета-адресою Боба таким чином, що Аліса може згенерувати приховану адресу, а Боб може згенерувати ключ витрат для цієї прихованої адреси, і все це без створення відкритого зв'язку між прихованою адресою і мета-адресою Боба (або між однією прихованою адресою та іншою).Приховані адреси з використанням криптографії еліптичної кривоїПриховані адреси з використанням криптографії еліптичних кривих спочатку були представлені в контексті Bitcoin Пітером Тоддом у 2014 році. Цей спосіб працює наступним чином (це передбачає попереднє знання основ криптографії на еліптичних кривих):Боб генерує ключ m та обчислює M = G * m, де G – загальноприйнята точка генератора для еліптичної кривої. Прихована мета-адреса є кодуванням MАліса генерує ефемерний ключ r та публікує ефемерний відкритий ключ R = G * rАліса може обчислити загальний секрет S = M * r, а Боб може обчислити такий самий загальний секрет S = m * RЗагалом, і в Bitcoin, і Ethereum адреса - це хеш, що містить відкритий ключ, який використовується для перевірки транзакцій з цієї адреси. Таким чином, ви можете обчислити адресу, якщо ви обчислите відкритий ключ. Щоб обчислити відкритий ключ, Аліса або Боб можуть обчислити P = M + G * hash(S)Щоб обчислити закритий ключ для цієї адреси, Боб (і тільки Боб) може обчислити p = m + hash(S)Це відповідає всім нашим вимогам, викладеним вище, і напрочуд просто! Сьогодні навіть існує EIP, який намагається визначити стандарт прихованих адрес для Ethereum, який одночасно підтримує цей підхід і дає можливість користувачам розробляти інші підходи (наприклад, які підтримують наявність у Боба окремих ключів витрати і перегляду, або використовують іншу криптографію для квантово-стійкої безпеки). Тепер ви можете подумати: приховані адреси не такі вже й складні, теорія вже опрацьована, і їх прийняття - це лише деталь реалізації. Проблема, однак, у тому, що є кілька досить великих деталей реалізації.Приховані адреси та оплата комісії за транзакціїПрипустимо, що хтось надсилає вам NFT. Пам'ятаючи про вашу конфіденційність, вони відправляють його на приховану адресу, яку ви контролюєте. Після сканування ефемерних публічних ключів on-chain, ваш гаманець автоматично виявляє цю адресу. Тепер ви можете вільно підтвердити право власності на NFT або передати його іншому. Але ж є проблема! На цьому обліковому записі 0 ETH, і тому немає можливості сплатити комісію за транзакцію. Ви не можете надіслати ETH на нього зі свого основного гаманця, тому що тоді ви створите публічно видиме посилання. Є один "легкий" спосіб вирішити проблему: просто використовувати ZK-SNARKs для переказу коштів, щоб сплатити комісію! Але це коштує багато газу, додаткові сотні тисяч газу лише для одного переказу. Інший розумний підхід передбачає довіру до спеціалізованих агрегаторів транзакцій ("шукачів" на жаргоні MEV). Ці агрегатори дозволять користувачам заплатити один раз, щоб придбати набір "квитків", які можна використовувати для оплати транзакцій у блокчейні. Коли користувачеві потрібно відправити NFT з прихованої адреси, що не містить нічого іншого, він надає агрегатору один із квитків, закодований за допомогою схеми засліплення Чауміана. Це оригінальний протокол, який використовувався у централізованих схемах електронних грошей із збереженням конфіденційності, запропонованих у 1980-х та 1990-х роках. Шукач приймає квиток і неодноразово безкоштовно включає транзакцію до свого бандлу, доки транзакція не буде успішно прийнята в блокчейні. Оскільки кількість задіяних коштів невелика, і вони можуть бути використані тільки для оплати транзакцій, питання довіри та регулювання набагато нижчі, ніж при "повній" реалізації такого роду централізованої електронної готівки зі збереженням конфіденційності.Приховані адреси та спрощене скануванняЩоб полегшити сканування всього набору ефемерних відкритих ключів, було додано теги перегляду кожного ефемерного відкритого ключа. Один із способів зробити це у наведеному вище механізмі - зробити так, щоб міткою перегляду був один байт загального секрету (наприклад, x-координата S за модулем 256 або перший байт hash(S)) . Таким чином, Бобу потрібно виконати лише одне множення еліптичної кривої для кожного ефемерного відкритого ключа, щоб обчислити загальний секрет, і тільки в 1/256 випадків Бобу доведеться виконувати складніші обчислення для генерації та перевірки повної адреси.ВисновокБазові стелс-адреси можуть бути реалізовані досить швидко вже сьогодні і можуть стати важливим ступенем розвитку практичної конфіденційності користувачів Ethereum. Щоправда, для їхньої підтримки потрібна певна робота з боку гаманця. Тим не менш, Віталік Бутерін вважає, що гаманці повинні почати рухатися до більш природної багатоадресної моделі (наприклад, створення нової адреси для кожної програми, з якою ви взаємодієте, може бути одним із варіантів) та з інших причин, пов'язаних із конфіденційністю.

## Publication Information

- [hunterrr](https://paragraph.com/@popa/): Publication homepage
- [All Posts](https://paragraph.com/@popa/): More posts from this publication
- [RSS Feed](https://api.paragraph.com/blogs/rss/@popa): Subscribe to updates