Реализация анонимных транзакций в Ethereum | Разбор Stealth адресов

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

Почему приватность важна в Ethereum

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

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

• ENS-имена, привязанные к адресам и аккаунтам в социальных сетях
• NFT, POAP и soulbound-токены
• история взаимодействия с протоколами
• паттерны финансовой активности и движения средств

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

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

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

Существует несколько подходов к приватности в Ethereum. Сегодня мы поговорим про стелс-адреса.

Стелс-адреса позволяют получать средства, не раскрывая основной адрес получателя.
Это защищает чувствительную информацию и при этом полностью совместимо с инфраструктурой Ethereum.

Как решить проблему приватности операций в публичном блокчейне

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

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

Стелс-адреса уже имеют подтвержденные стандарты: ERC-5564 и ERC-6538, причем ERC-6538 добавляет расширенные возможности. О них мы поговорим позже, сначала давайте посмотрим на ключевые принципы работы стелс-адресов, чтобы понять, как они обеспечивают приватность переводов и решают проблему linkability в Ethereum.

Что такое стелс-адреса

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

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

• видны в блокчейне как отдельные аккаунты
• доступны и управляемы только вами

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

Цель стелс-адресов

Что должна обеспечивать система стелс-адресов?

1. Приватность получателя — никто не сможет определить, кто получил средства.
2. Простота перевода — отправителю нужен только один идентификатор (адрес или ENS), остальное система производит автоматически.

В обычной системе переводов вы делитесь адресом или ENS-доменом, и на него можно отправлять средства. Стелс-адреса добавляют приватность, но процесс перевода остается неизменным.

Основы криптографии для стелс-адресов

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

• Точка-генератор G — базовая точка, из которой получают все остальные точки группы через скалярное умножение.
• Скалярное умножение — повторное сложение точки с самой собой.

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

M=m⋅G

где:

• m — приватный ключ (скаляр),
• M — публичный ключ (точка на кривой),
• G — точка-генератор.

Безопасность системы обеспечивается тем, что практически невозможно восстановить m, имея только M и G. Это основано на проблеме дискретного логарифмирования на эллиптической кривой.

Как работают стелс-адреса на Ethereum: пошаговый разбор

Рассмотрим пример: Алиса хочет отправить средства на стелс-адрес Боба. Разберем, что делает каждая сторона и как криптография обеспечивает приватность транзакции.

Шаг 1. Генерация закрытого ключа (spending key)

Боб хочет получать средства на стелс-адреса (их несколько — набор одноразовых адресов). Для этого он генерирует приватный ключ m, называемый spending key.

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

Шаг 2. Создание мета-стелс-адреса

Далее spending key используется для генерации мета-стелс-адреса M, который является публичным ключом для всех будущих одноразовых стелс-адресов:

M = m * G

Где G — точка-генератор на эллиптической кривой. Мета-стелс-адрес служит отправной точкой для вычисления уникальных адресов, на которые будут поступать средства.

Шаг 3. Регистрация мета-стелс-адреса

Чтобы отправители могли находить Боба, он регистрирует мета-стелс-адрес в специальном контракте ERC-6538. Этот контракт — реестр всех мета-адресов.

Теперь, если Алиса знает обычный Ethereum-адрес или ENS-домен Боба, она может найти его мета-стелс-адрес и использовать его для генерации одноразового стелс-адреса.

Шаг 4. Генерация одноразового ключа отправителя (ephemeral key)

Алиса генерирует одноразовый приватный ключ r, называемый ephemeral key, чтобы создать стелс-адрес:

R = r * G

Публичную часть R необходимо опубликовать. Стандарт ERC-5564 описывает, как и где это делать, чтобы отправитель и получатель могли корректно взаимодействовать.

Шаг 5. Вычисление общего секрета (shared secret)

Алиса и Боб независимо вычисляют общий секрет S:

• Алиса: S = r * M
• Боб: S = m * R

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

Шаг 6. Генерация одноразового стелс-адреса

Алиса создает одноразовый стелс-адрес для перевода средств:

P = M + G * hash(S)

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

Шаг 7. Получение средств с одноразового стелс-адреса

Чтобы потратить средства, Боб вычисляет приватный ключ одноразового адреса:

p = m + hash(S)

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

‍

Процесс, который мы только что разобрали, отражает основную идею стелс-адресов, предложенную Виталиком Бутериным. Далее рассмотрим один из ключевых принципов, который делает всю систему работоспособной — неинтерактивность, и стандарт, который обеспечивает это требование.

Как работает обнаружение стелс‑адресов в Ethereum (ERC‑5564)

Один из ключевых требований приватных транзакций через стелс‑адреса — отсутствие прямого взаимодействия между отправителем и получателем.

Мы уже разобрали, как Алиса находит мета‑стелс‑адрес Боба через единый реестр (ERC‑6538). При регистрации мета‑адреса Боб раскрывает лишь то, что он может получать средства на стелс‑адреса — но не раскрывает, на какие именно.

Отправитель узнает конкретный стелс‑адрес только в момент генерации транзакции.

Возникает логичный вопрос:

как Боб понимает, на какой из бесконечного множества стелс‑адресов ему пришли средства?

Для этого ему нужен shared secret, а чтобы вычислить shared secret — эфемерный публичный ключ Алисы (ephemeral public key). Этот ключ Алиса должна где‑то опубликовать.

Эту задачу и решает стандарт ERC‑5564.

ERC‑5564: стандартный механизм анонса стелс‑транзакций

ERC‑5564 описывает контракт с единственным методом — announce.

Этот метод используется для публикации:

• эфемерного публичного ключа отправителя
• параметров, необходимых для восстановления стелс‑адреса

Отправитель вызывает announce, передает данные, а контракт эмитит событие (event) с этими параметрами.

Таким образом появляется единая точка, где публикуются все события создания стелс‑адресов.

Важно:
сами события не содержат информации о получателе. Они полностью обезличены.

Именно это обеспечивает приватность.

Как получатель находит свои средства

Теперь переходим к Бобу.

У него есть одно стандартизированное место, которое нужно мониторить — события announce контракта ERC‑5564.

Но:

• никто не знает, какое событие относится к какому получателю
• все анонсы выглядят одинаково

Поэтому Боб вынужден:

1. Сканировать все события announce
2. Для каждого события брать опубликованный эфемерный публичный ключ
3. Вычислять shared secret, используя приватный ключ своего мета‑адреса
4. На основе shared secret получать потенциальный стелс‑адрес
5. Проверять, есть ли на нем средства
6. Если есть — вычислять приватный ключ и забирать их

Иными словами:

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

Звучит очень трудозатратно. Надо что-то с этим делать.

Оптимизация вычислений стелс-адресов

Мы уже поняли, что поиск стелс‑адресов слишком ресурсоемкий, и нам нужна оптимизация.

Логичное решение — делегировать эту работу внешнему сервису. Но для этого пришлось бы передать приватный ключ, что недопустимо.

ERC‑5564 предлагает другой подход.

Что такое ERC‑5564?

ERC‑5564 — это стандарт для стелс-адресов в Ethereum, который позволяет получать средства на анонимные одноразовые адреса и при этом делегировать работу по их обнаружению внешнему сервису, не раскрывая приватный ключ.

В этом стандарте мета‑адрес больше не является одним ключом. Теперь это пара:

M = (K, V)

В этом стандарте мета‑адрес больше не является одним ключом. Теперь это пара:

Где:

• M — мета-адрес,
• K — публичный ключ траты (spending key),
• V — публичный ключ просмотра (viewing key),
• соответствующие приватные ключи — k и v.

Изначально мета-адрес представлял только spending key. Теперь добавляется viewing key.

Как viewing key меняет процесс обнаружения стелс‑адресов?

Общий секрет вычисляется через viewing key:

S = V * r

S = v * R

Сам стелс‑адрес строится на spending key:

P = K + G * hash(S)

Приватный ключ для него:

p = k + hash(S)

Это позволяет передать сервису только приватный viewing key.

Сервис может:

• вычислять shared secret
• находить все стелс‑адреса пользователя
• отслеживать поступления

Но он не может тратить средства, так как не имеет доступа к spending key.

Таким образом, вся работа по обнаружению стелс‑адресов выносится наружу, а контроль над средствами остаётся у владельца.

Снижение вычислительной нагрузки с помощью view tag

Даже после делегирования проблема объема вычислений остается.

Для этого ERC‑5564 вводит механизм view tag.

View tag — это первый байт хэша общего секрета.

При сканировании Announce‑событий сервис делает следующее:

1. вычисляет shared secret
2. берет первый байт его хэша
3. сравнивает с view tag из события

Если байты не совпадают — событие пропускается.

Если совпадают — выполняются остальные вычисления.

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

Проблема газа при использовании стелс‑адресов

Помимо вычислительной нагрузки у стелс‑адресов есть еще одна системная проблема — газ.

Стелс‑адрес — это новый пустой адрес. Если на него приходят токены или любые активы кроме нативного ETH, у него нет баланса для оплаты газа. Значит, средства оказываются заблокированными.

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

Один из способов решить эту задачу — использовать account abstraction вместе с paymaster.

Логика следующая:

Когда Алиса генерирует стелс‑адрес, она может обратиться к account factory и вызвать view‑метод, который сопоставляет обычный адрес с будущим смарт‑аккаунтом. Даже если этот аккаунт еще не создан, его адрес уже детерминирован.

Алиса отправляет средства сразу на этот смарт‑аккаунт.

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

Таким образом:

• стелс‑адрес не требует отдельного funding
• приватность сохраняется
• получатель может сразу работать с активами

Это один из возможных подходов к решению gas‑проблемы в архитектуре стелс‑адресов.

Какие проекты используют технологию стелс-адресов на Ethereum?

В заключение рассмотрим примеры проектов, которые имплементируют концепцию стелс-адресов. Два заметных проекта — Fluidkey и Umbra. Хотя оба следуют одному EIP, их реализация отличается подходами и техническими деталями.

Как реализован стелс-адрес в Fluidkey?

У Fluidkey есть веб-версия и мобильные приложения. Основная логика находится в fluidkey-stealth-account-kit на GitHub. В ней реализованы все вычисления, которые мы обсуждали ранее:

• генерация мета-адресов
• создание эфемерных адресов
• вычисление стелс-адресов

Также есть пример скриптов, показывающий правильную последовательность вызова методов кита.

Чем примечательна реализация Fluidkey?

1. Детерминированная генерация ключей

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

• Метод generateFluidkeyMessage берет адрес кошелька и PIN, конкатенирует их, хэширует и создаёт сообщение для подписи.
• После подписи вызывается generateKeysFromSignature, которая делит подпись пополам:
  
  • первая половина → spending key
  • вторая половина → viewing key

Такой подход позволяет не хранить ключи в приложении — их можно всегда восстановить детерминированно по адресу кошелька и PIN. При этом код open-source, что обеспечивает независимый доступ к средствам.

2. Работа с пустыми стелс-адресами

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

3. Связь мета-адресов с доменами

Fluidkey не использует глобальный реестр мета-адресов, как предлагает стандарт. Вместо этого:

• Зарегистрирован поддомен fkey.eth.
• При первом входе создается аккаунт вида username.fkey.eth.
• Через контракт OffchainResolver (по EIP-3668) предоставляются данные для совместимых кошельков и Etherscan.

Например, формируется URL типа https://username.fkey.id, который можно сканировать через QR-код или подключить кошелек для отправки средств. При обновлении страницы адреса стелс-адресов автоматически меняются, обеспечивая приватность.

4. Пользовательский опыт

Для пользователя Fluidkey выглядит как обычный кошелек:

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

Как Umbra реализует стелс-адреса?

Umbra — это старейший проект в области стелс-адресов и один из первопроходцев стандарта ERC‑5564. Их реализация отличается от Fluidkey и строго следует стандарту.

Какие контракты использует Umbra?

1. Контракт-реестр для мета-адресов
Umbra создала собственный контракт-реестр для регистрации мета-адресов пользователей.

2. Контракт для объявления о стелс-адресах и отправки средств
Второй контракт нужен для публикации события о создании стелс-адреса (Announce). Umbra объединила здесь две функции:

• создание стелс-адреса
• отправку средств

То есть, чтобы отправить средства пользователю, вы вызываете один метод, который одновременно создает стелс-адрес, отправляет средства и публикует Announce с эфемерным ключом.

Как Umbra работает с ETH и токенами?

• ETH: переводится сразу на стелс-адрес.
• Токены: остаются на контракте Umbra, для получения их нужно вызвать withdraw со стороны получателя (через стелс-адрес).

Как решается проблема пустого кошелька?

В Umbra есть несколько вариантов:

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

Эта схема накладывает ограничения:

• минимальный порог на переводы
• ограниченное множество токенов для отправки

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

Вывод по реализации Umbra

Umbra показывает другой подход к реализации ERC‑5564:

• единый контракт для создания стелс-адресов и отправки средств
• строгий контроль над балансом и токенами
• встроенные меры против спама

В целом, Fluidkey и Umbra — два разных пути реализации одного стандарта: один ориентирован на удобство пользователя (Fluidkey), другой — на строгое соблюдение стандарта и безопасность (Umbra).

Заключение

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

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

О Rock’n’Block

Rock’n’Block — студия Web3 разработки. Мы создаем блокчейн-инфраструктуру и децентрализованные приложения.

Что мы делаем:

• Разрабатываем кастомные L1 сети, DeFi-протоколы и DEX
• Создаём кошельки и DeFi платформы с оптимизацией приватности и транзакций
• Разрабатываем инфраструктуру для стриминга real time и исторических блокчейн-данных
• Реализуем chain-agnostic финансовые инструменты и платежные решения

С почти десятилетним опытом команда поддержала продукты для 71М+ пользователей DeFi, достигла $2,5B в рыночной капитализации и помогла партнёрам привлечь $167M.

Основные выводы

В чем суть стелс-адресов?

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

Почему это важно?

Ethereum по умолчанию прозрачный: все транзакции, владение ENS, NFT, SBT или участие в стекинге видны публично.
Как только адрес привязан к пользователю, вся его история становится открытой.
Стелс-адреса разрывают прямую связь между транзакциями, оставаясь совместимыми с существующей Ethereum‑стеком.

Как работают стелс-адреса на Ethereum?

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

Краткий алгоритм:

1. Отправитель получает meta-stealth-адрес получателя.
2. Генерирует эфемерную пару ключей.
3. Отправитель и получатель вычисляют общий секрет.
4. Отправитель создаёт одноразовый адрес получателя.
5. Получатель обнаруживает транзакцию и тратит средства через свой spending key.

Какие стандарты нужно знать?

• ERC‑5564 — объявления стелс-адресов, view tags и логика обнаружения.
• ERC‑6538 — реестр для meta-stealth-адресов (для поиска отправителем).

Что такое EIP-5564?

EIP‑5564 описывает механизм публикации стелс-адресов на Ethereum.

Включает:

• Формат события объявления (Announcement event)
• Требования к эфемерным ключам
• Структуру view tag
• Ожидаемое поведение кошельков при сканировании

Примеры реализации в протоколах

Fluidkey

• Детеминированная генерация ключей (PIN + адрес кошелька)
• Gnosis Safe для решения проблемы нулевого баланса
• Сопоставление meta-адресов через домены (username.fkey.eth)
• Пользовательский интерфейс скрывает сложность — все операции объединяются в одну транзакцию

Umbra

• Собственный контракт-реестр для meta-адресов
• Контракт для создания стелс-адресов + отправки средств с публикацией Announce
• Разделение методов для ETH и токенов (токены требуют withdraw)
• Решение вопроса пустого кошелька через комиссию и минимальный порог перевода
• Защита от спама при дешевых транзакциях

Когда стоит использовать стелс-адреса?

• Кошельки с приватными входящими переводами
• Приложения с аккаунтами, привязанными к идентичности (ENS, SBT, DID)
• Сценарии, где привязка адреса раскрывает личные данные
• Любые продукты, где on-chain получатели не должны раскрывать основной адрес пользователя

Могут ли адреса Ethereum быть приватными?

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

• Стелс-адреса (EIP‑5564 / ERC‑6538)
• Системы с нулевым разглашением (zkSync, Aztec)
• Миксеры или батчинг транзакций
• Мемпулы с приватными намерениями

Стелс-адреса позволяют разорвать связь между транзакциями, не меняя базовый протокол Ethereum.

‍