ERC-5564 Stealth Addresses: приватные получатели в Ethereum без взаимодействия

Ключевые понятия ERC-5564

Stealth meta-address. Пара (иногда единичка) публичных ключей, из которой любой отправитель может вычислить одноразовый stealth-адрес для конкретного получателя. Формат для Ethereum: st:eth:0x Если указан один ключ, он используется и как *spending*, и как *viewing*.

Spending / viewing ключи. *Spending key* — приватный ключ, которым тратятся средства, пришедшие на stealth-адрес. *Viewing key* — приватный ключ «наблюдателя»: по нему получатель находит свои stealth-поступления, не раскрывая трат.

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

View-tag (байтовая метка просмотра). Однобайтовый «фильтр» из хэша общего секрета. Позволяет в ~255 из 256 случаев мгновенно отсеять «чужие» события без дорогих операций. Это ускоряет сканирование в кошельках почти в 6 раз при мизерной потере криптографического запаса.

ERC5564Announcer (singleton). Контракт-ретранслятор, в котором интеграторы публикуют событие Announcement(schemeId, stealthAddress, caller, ephemeralPubKey, metadata). Получатель слушает эти события и ищет «своё».

schemeId. Идентификатор криптосхемы. Базовая реализация стандарта описывает schemeId = 1 для secp256k1 + view-tags (расширяемо для альтернатив).

Как «рождается» stealth-адрес (высокоуровневый поток)

1) Получатель публикует meta-address. Кошелёк генерирует пару ключей (*spending/viewing*), выводит соответствующие публичные ключи и формирует строку st:eth:…. Её можно показать QR-кодом, поместить в профиль/сайт, а также зарегистрировать в реестре (см. ERC-6538).

2) Отправитель считывает meta-address и локально вычисляет stealth-адрес.

• Генерируется эфемерный приватный ключ и публичный ключ P_ephemeral.
• Вычисляется общий секрет с viewing-публичным ключом получателя (ECDH), хэшируется, из старшего байта берётся view-tag.
• К общему секрету «прибавляется» spending-публичный ключ получателя → получается stealth-публичный ключ и одноразовый stealth-адрес.

3) Отправитель переводит активы на stealth-адрес и публикует анонс. В контракте ERC5564Announcer вызывается announce(...) с schemeId, stealthAddress, ephemeralPubKey и metadata, где первый байт — view-tag, а далее — нормализованные поля о типе актива и сумме (для ETH и для токенов структура метаданных различается).

4) Получатель находит перевод и извлекает ключ для траты. Кошелёк получает поток Announcement-событий, по view-tag быстро отбрасывает «чужие», а для подходящих событий:

• рекомпьютит общий секрет по viewingKey × ephemeralPubKey;
• восстанавливает stealth-публичный/адрес и сверяет его с stealthAddress из события;
• при совпадении вычисляет stealth-приватный ключ: p_stealth = p_spend + H(shared_secret) и получает полный контроль над средствами на stealth-адресе.

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

Формат событий и метаданных

Событие Announcement содержит:

• schemeId — идентификатор криптосхемы;
• stealthAddress — рассчитанный адрес получателя;
• caller — интегратор/контракт, вызвавший анонс (для аудита);
• ephemeralPubKey — эфемерный публичный ключ отправителя;
• metadata — произвольные данные, первый байт обязательно = view-tag.

Рекомендуемая структура metadata:

• Для ETH: байт 1 — view-tag; байты 2-5 — константа-идентификатор ETH; 6-25 — адрес 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE; 26-57 — сумма.
• Для ERC-20/721: байт 1 — view-tag; 2-5 — function selector действия (например, transfer); 6-25 — адрес токена; 26-57 — сумма (FT) или tokenId (NFT).

Стандартизованный формат облегчает индексаторам и кошелькам понимание «что именно пришло на stealth-адрес», без лишних эвристик.

Стелс-мета-адреса и реестр ERC-6538

Проблема «где хранить meta-address». Если держать его только на визитке/сайте, интеграторам неудобно. ERC-6538 описывает реестр (Registry) для публикации и получения stealth meta-address по обычному адресу/идентификатору получателя. Регистрация может происходить как самим владельцем, так и «по доверенности» (подписанный EIP-712/EIP-1271 запрос).

Что это даёт:

• кошельки и dApp’ы могут автоматически находить meta-address контрагента;
• получатель явно сигнализирует «готовность» принимать stealth-платежи;
• один стандартный источник правды сокращает UX-трение и ошибки.

Приватность и её пределы

Что скрывается:

• Связь «основной идентичности» получателя с конкретным платежом;
• Граф входных переводов на «основной» адрес (если аккуратно расходовать stealth-UTXO/балансы);
• Дополнительные метаданные получателя (если использовать blinded рутину комм-каналов в dApp’ах).

Что не скрывается:

• Сумма и актив — они видны на L1/L2;
• Связь «stealth-адрес ↔ получатель» известна отправителю;
• Во многих сценариях заметны тайминги (паттерны публикации событий, эхом видны ретраи).

Практические выводы:

• Для «самофинансирования газа» на stealth-адрес лучше использовать внешние источники (спонсор, релейер) — перевод с «основного» адреса может деанонимизировать связь;
• Делайте новый stealth-адрес на каждый платёж (так и задумано стандартом);
• В UI полезно явно предупреждать о «утечках по суммам/таймингу».

Сочетайте с базовыми практиками приватности и, при необходимости, с доказуемыми схемами (например, ZK-доказательства) на уровне приложений.

Взаимодействие с L2 и Account Abstraction

Роллапсы и комиссии. На роллапсах (L2) дешевле публиковать анонсы и обслуживать входящие переводы. Логика ERC-5564 полностью совместима: событие Announcement эмитится на целевой сети, кошельки слушают нужный эндпоинт.

Account Abstraction (AA). В связке с AA получатель может автоматизировать:

• сканирование событий и «подъем» средств на «основной» аккаунт;
• спонсирование газа (paymaster), чтобы тратить из stealth-адреса без самофинансирования;
• батч-операции (claim → swap → отправка), сохраняя приватность «кто получатель».

Сценарии использования

1) Пожертвования и донаты. Публикуете один meta-address в профиле — любой желающий отправляет активы, не раскрывая ваш основной адрес. Для разных сетей (st:eth:…, st:…) можно держать отдельные строки.

2) Корпоративные выплаты/зарплаты. Поставщики/сотрудники сообщают meta-address; бухгалтерия платит на stealth-адреса → аудитор видит выплаты, но не может связать их с публичными адресами сотрудников. Контрагент при необходимости доказывает принадлежность перевода по viewing-ключу.

3) NFT-подарки и POAP. Отправляете NFT на stealth-адрес — получатель остаётся приватным до момента раскрытия/перевыпуска.

4) Airdrop без «охоты на адреса». Проекты могут предлагать «заявки» через meta-address; начисление идёт на stealth-адреса, уменьшая токсичность повторного анализа.

Производительность сканирования: роль view-tag

Сканирование «в лоб» требует на каждое событие несколько EC-операций и хэшей. View-tag (1 байт из хэша общего секрета) позволяет с вероятностью 255/256 сразу отбросить «не мои» события: кошелёк делает одну ecMUL + HASH, проверяет байт-совпадение — и только затем (при совпадении) продолжает тяжёлые шаги (ecADD, повторный HASH). В итоге в 6 раз меньше работы на поток событий при минимальном ослаблении (124-битный запас вместо 128-битного на приватную часть секрета).

Разработчикам: как интегрировать ERC-5564

Архитектура кошелька:

• храните spending/viewing пары (seed-деривация рекомендована);
• поддержите формат st:eth:… и импорт из реестра ERC-6538;
• реализуйте быстрый фильтр по view-tag и парсер Announcement;
• обеспечьте вычисление stealth-ключа и безопасный «claim» (подписание/расходование).

Отправка платежа:

• вычислите stealthAddress по meta-address;
• оформите перевод (ETH/ERC-20/721) на stealth-адрес;
• вызовите announce(schemeId, stealthAddress, ephemeralPubKey, metadata) в ERC5564Announcer;
• логируйте caller (ваш контракт/бэк-энд) для аудита.

Поддержка токенов:

• для FT указывайте в метаданных function selector (transfer/transferFrom) + адрес токена + количество;
• для NFT — selector + адрес токена + tokenId;
• для ETH придерживайтесь рекомендованного шаблона метаданных.

Безопасность ключей:

• *Viewing key* можно хранить в «тёплой» зоне (он не даёт тратить);
• *Spending key* — под полной защитой (HSM/secure enclave);
• для UX: поддержите «watch-only» режим (только сканирование).

Схемы и совместимость:

• соблюдайте schemeId;
• при необходимости реализуйте альтернативные криптосхемы (стандарт расширяем);
• проверяйте, что первый байт metadata = view-tag.

Риски и меры предосторожности

Газ и самофинансирование. Чтобы потратить с stealth-адреса, на нём должны быть ETH для газа. Перевод с «основного» адреса может раскрыть связь; используйте paymaster/релэй или «чужие» источники газа.

Адресное «отравление». Злоумышленник может отправлять на ваши известные адреса «пыль», чтобы мешать анализу. На стороне stealth-адресов это менее критично, но кошельки всё равно должны уметь скрывать/чернить подозрительные поступления.

Корреляция по времени/суммам. Большие «круглые» суммы и синхронные анонсы облегчают эвристику. Практика — распределять крупные начисления, использовать разные окна публикации событий.

Отправитель знает связь. Скрывается только получатель от публики. Если критично скрывать и отправителя, потребуется отдельный уровень приватности в приложении (миксинг маршрутов, приватные месседжи и т.п.).

Контракты vs EOAs. Stealth-адрес — обычный EOA. Для интеракций со смарт-контрактами используйте AA/абстракцию аккаунтов, мультиколлы и спонсирование газа.

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

Лучшие практики для внедрения

• Публикуйте meta-address в проверяемых источниках (ENS-текст-рекорды, сайт, соцсети) и/или в ERC-6538 Registry.
• Для UX храните QR с st:eth:… и кнопку «Скопировать» в один тап.
• В кошельке включайте watch-only режим (по viewing-ключу) и уведомления о новых анонсах.
• Реализуйте paymaster/relayer для трат со stealth-адреса без самофинансирования газа.
• Ведите журнал анонсов (caller, schemeId, metadata) для аудита.
• Делайте фолбэки: если анонс не эмитирован (сбой), повторяйте с RBF/ретраями.
• Обучайте пользователя: суммы видны, приватность — про «кто получатель», а не про «сколько».

FAQ

Нужно ли согласование с получателем? Нет. Достаточно его meta-address — отправитель сам производит вычисления и публикует анонс.

Можно ли переиспользовать один stealth-адрес? Не рекомендуется. Смысл — одноразовость. Для каждого платежа вычисляется новый stealth-адрес.

Что если анонс не опубликован? Получатель не увидит перевод. Интеграторам важно публиковать Announcement перед или сразу после отправки средств и ретраить при сбоях.

Скрываются ли суммы? Нет. Сумма и актив публичны. Скрывается связь с основным адресом получателя.

Как связать stealth-платёж с человеком/компанией? Через проверяемую публикацию meta-address (сайт, ENS) или регистрацию в ERC-6538. Для бухгалтерии можно хранить сопоставление «инвойс → анонс».

Совместимо ли с L2? Да. События-анонсы излучаются в той сети, где идёт перевод (L1/L2), кошельки слушают нужный RPC.

См. также

• Ethereum
• Приватность в блокчейне
• ZK-доказательства
• Rollups (L2)
• Транзакция
• Кошелёк
• Адрес
• Gas