Автор оригинала: Виталик Бутерин
Перевод и редакция: DeFi 之道
Отдельная благодарность Ben DiFrancesco, Matt Solomon, Toni Wahrstätter и Antonio Sanso за обратную связь и рецензирование.
Одна из ключевых нерешённых задач в экосистеме Ethereum — обеспечение конфиденциальности. По умолчанию любые данные, попадающие в публичный блокчейн, становятся доступны всем. Сегодня это касается не только денежных и финансовых транзакций, но и доменных имён ENS, POAP, NFT, токенов, привязанных к личности (soulbound tokens), и многого другого. На практике использование всего спектра приложений Ethereum означает публикацию важных аспектов вашей жизни для всеобщего просмотра и анализа.
Вопрос о том, как это исправить, признаётся важным повсеместно. Однако до сих пор дискуссии о повышении конфиденциальности в основном сосредоточены на одном конкретном сценарии: приватных переводах ETH и основных токенов ERC-20 (чаще всего — переводы самому себе). В этой статье рассматриваются механизмы и сценарии использования другого класса инструментов, которые могут улучшить приватность в Ethereum во множестве других случаев: скрытые адреса (stealth addresses).
Что такое система скрытых адресов?
Предположим, Алиса хочет отправить Бобу какой-либо актив. Это может быть определённая сумма криптовалюты (например, 1 ETH или 500 RAI) или NFT. Когда Боб получает актив, он не хочет, чтобы об этом узнал весь мир. Скрыть сам факт перевода невозможно, особенно если речь идёт об уникальном NFT в блокчейне, но скрыть личность получателя — вполне реально. Кроме того, Алиса и Боб хотят простоты: им нужна система, процесс оплаты в которой полностью совпадает с нынешним. Боб отправляет Алисе (или регистрирует в ENS) некий «адрес», который кодирует способ оплаты ему, и этой единственной информации достаточно, чтобы Алиса (или любой другой человек) могла отправить ему актив.
Обратите внимание, что это отличается от конфиденциальности, которую обеспечивают такие инструменты, как Tornado Cash. Tornado Cash может скрывать переводы основных взаимозаменяемых активов, таких как ETH или популярные токены ERC-20 (хотя проще всего его использовать для приватных переводов самому себе), однако он плохо подходит для обеспечения конфиденциальности при переводах малоизвестных токенов ERC-20 и вообще не способен скрыть переводы NFT.
Типичный процесс оплаты криптовалютой. Мы хотим повысить конфиденциальность (никто не должен знать, что актив получил Боб), сохранив при этом текущий процесс без изменений.
Скрытые адреса предлагают именно такое решение. Скрытый адрес — это адрес, который может сгенерировать как Алиса, так и Боб, но контролировать его может только Боб. Боб генерирует и хранит в секрете ключ для расходования средств и использует его для создания мета-адреса. Затем он передаёт этот мета-адрес Алисе (или регистрирует его в ENS). Алиса может выполнить вычисления на основе этого мета-адреса, чтобы сгенерировать скрытый адрес, принадлежащий Бобу. После этого она может отправить на этот адрес любой актив, и Боб будет полностью контролировать эти средства. При переводе она публикует в блокчейне дополнительные зашифрованные данные (временный открытый ключ), которые помогают Бобу определить, что этот адрес принадлежит ему.
Проще говоря, скрытые адреса обеспечивают тот же уровень конфиденциальности, что и генерация нового адреса для каждой транзакции, но без необходимости какого-либо взаимодействия со стороны Боба.
Полный процесс работы системы скрытых адресов выглядит следующим образом:
1. Боб генерирует свой корневой ключ трат (m) и скрытый метаадрес (M).
2. Боб добавляет запись в ENS, чтобы зарегистрировать M в качестве скрытого метаадреса для домена bob.eth.
3. Допустим, Алиса знает, что Боб — это bob.eth. Она ищет его скрытый метаадрес M в ENS.
4. Алиса генерирует одноразовый временный ключ, который знает только она и который используется для создания именно этого конкретного скрытого адреса.
5. Алиса применяет алгоритм, который комбинирует её временный ключ с метаадресом Боба, чтобы сгенерировать скрытый адрес. Теперь она может отправить активы на этот адрес.
6. Алиса также генерирует свой временный публичный ключ и публикует его в реестре временных публичных ключей (это можно сделать в той же транзакции, которой активы отправляются на сгенерированный скрытый адрес).
7. Чтобы обнаружить принадлежащие ему скрытые адреса, Боб сканирует реестр временных публичных ключей и получает полный список всех таких ключей, опубликованных кем-либо с момента его последней проверки.
8. Для каждого временного публичного ключа Боб пытается скомбинировать его со своим корневым ключом трат, чтобы сгенерировать скрытый адрес, и проверяет наличие на нём активов. Если активы есть, Боб вычисляет ключ трат для этого адреса и сохраняет его.
Вся эта схема основана на двух криптографических приёмах. Во-первых, нужна пара алгоритмов для генерации общего секрета: один использует секрет Алисы (её временный ключ) и публичное значение Боба (его метаадрес), а второй — секрет Боба (его корневой ключ трат) и публичное значение Алисы (её временный публичный ключ). Это можно реализовать разными способами; обмен ключами по Диффи-Хеллману — одно из фундаментальных достижений криптографии, которое как раз и предоставляет такую возможность.
Однако одного общего секрета недостаточно. Если просто сгенерировать приватный ключ из общего секрета, то и Алиса, и Боб смогут тратить средства с этого адреса. Можно было бы на этом остановиться и позволить Бобу перевести средства на новый адрес, но это неэффективно и излишне снижает безопасность. Поэтому добавляется механизм маскировки ключа: пара алгоритмов, позволяющих Бобу скомбинировать общий секрет со своим корневым ключом трат, а Алисе — общий секрет с метаадресом Боба. В результате Алиса может сгенерировать скрытый адрес, а Боб — соответствующий ключ трат для этого адреса, при этом не создавая публичной связи между скрытым адресом и метаадресом Боба (или между разными скрытыми адресами).
Скрытые адреса на эллиптической криптографии
Скрытые адреса на основе эллиптической криптографии впервые предложил Питер Тодд в 2014 году в контексте Bitcoin. Принцип их работы следующий (предполагается базовое понимание эллиптической криптографии; учебные материалы можно найти здесь, здесь и здесь):
• Боб генерирует ключ m и вычисляет M = G * m, где G — заранее определённая генераторная точка эллиптической кривой. Скрытый метаадрес — это закодированное значение M.
• Алиса генерирует временный ключ r и публикует временный публичный ключ R = G * r.
• Алиса может вычислить общий секрет S = M * r, а Боб — тот же общий секрет S = m * R.
• В Bitcoin и Ethereum (включая правильно спроектированные аккаунты ERC-4337) адрес обычно представляет собой хеш публичного ключа, который используется для подписи исходящих транзакций. Следовательно, зная публичный ключ, можно вычислить адрес. Для вычисления публичного ключа Алиса или Боб могут использовать формулу P = M + G * hash(S).
• Чтобы вычислить приватный ключ для этого адреса, Боб (и только он) может использовать формулу p = m + hash(S). Это удовлетворяет всем нашим требованиям и при этом невероятно просто!
Уже существует EIP, предлагающий стандарт для скрытых адресов в Ethereum. Он поддерживает описанный метод и одновременно оставляет пространство для других подходов (например, использование Бобом отдельных ключей для трат и просмотра или применение постквантовой криптографии). Сейчас вы можете подумать: «Скрытые адреса не так уж сложны, теория проработана, осталось лишь реализовать». Однако эффективная реализация требует решения ряда важных технических деталей.
Скрытые адреса и оплата комиссий за транзакции
Представьте, что кто-то отправляет вам NFT. Чтобы сохранить вашу приватность, отправитель использует скрытый адрес, который находится под вашим контролем. Ваш кошелёк, просканировав эфемерный публичный ключ в блокчейне, автоматически обнаружит этот адрес. После этого вы сможете подтвердить владение NFT или передать его кому-то ещё. Но возникает проблема: на этом аккаунте нет ETH, а значит, нечем оплатить комиссию за транзакцию. Механизм оплаты через ERC-4337 здесь не поможет, так как он работает только с взаимозаменяемыми токенами ERC-20. Перевести ETH с основного кошелька тоже не вариант — это создаст публичную связь между адресами.
Есть «простое» решение: использовать ZK-SNARKs для перевода средств на оплату комиссий. Однако этот метод требует огромного количества газа — десятки тысяч дополнительных единиц на одну транзакцию.
Более изящный подход предполагает доверие специализированным агрегаторам транзакций (их также называют «поисковиками» в контексте MEV). Пользователи могут заранее купить пакет «билетов» для оплаты транзакций в блокчейне. Когда нужно потратить NFT с пустого скрытого адреса, пользователь предоставляет один такой билет агрегатору, используя схему слепой подписи Чаума (Chaumian blind signing) — оригинальный протокол, который применялся в приватных системах электронных денег ещё в 1980-х и 1990-х годах. Поисковик принимает «билет» и бесплатно включает транзакцию в свои пакеты до тех пор, пока она не попадёт в блок. Поскольку суммы в таких операциях невелики и предназначены исключительно для оплаты комиссий, вопросы доверия и регулирования здесь стоят менее остро, чем в полноценных системах приватных электронных денег.
Скрытые адреса и разделение ключей: траты и просмотр
Допустим, у Боба нет единого корневого ключа для всех операций. Вместо этого он хочет разделить ключи: корневой ключ для трат и отдельный ключ для просмотра. Ключ просмотра позволяет видеть все скрытые адреса Боба, но не даёт права тратить с них средства.
В мире эллиптических кривых эта задача решается простым криптографическим приёмом:
• Мета-адрес Боба M теперь выглядит как (K, V) и кодируется как G * k и G * v, где k — ключ для трат, а v — ключ для просмотра.
• Общий секрет вычисляется как S = V * r = v * R, где r — эфемерный приватный ключ Алисы, а R — её опубликованный эфемерный публичный ключ.
• Публичный ключ скрытого адреса: P = K + G * hash(S). Соответствующий приватный ключ: p = k + hash(S).
Обратите внимание: первый шаг (генерация общего секрета) использует ключ просмотра, а второй шаг (создание скрытого адреса и его приватного ключа) — корневой ключ для трат.
У этого решения много практических применений. Например, Боб может предоставить ключ просмотра своему POAP-кошельку (или даже менее защищённому веб-интерфейсу), чтобы тот сканировал блокчейн и отображал все его POAP, не имея при этом возможности их потратить.
Скрытые адреса и оптимизация сканирования
Чтобы упростить ска��ирование множества эфемерных публичных ключей, к каждому такому ключу добавляется метка просмотра (view tag). Например, в описанном механизме в качестве метки можно использовать один байт общего секрета (скажем, x-координату S mod 256 или первый байт hash(S)).
Таким образом, Бобу нужно выполнить лишь одно умножение на эллиптической кривой для каждого эфемерного публичного ключа, чтобы вычислить общий секрет. Более сложные вычисления для генерации и проверки полного адреса потребуются только в 1 из 256 случаев.
Скрытые адреса и квантовая устойчивость
Описанный механизм основан на эллиптических кривых, что, с одной стороны, хорошо, но с другой — делает его уязвимым для атак с помощью квантовых компьютеров. Если квантовые компьютеры станут реальной угрозой, придётся переходить на квантово-устойчивые алгоритмы. Два основных кандидата на замену — изогении эллиптических кривых и решётки (lattices).
Изогении эллиптических кривых — это совершенно иной математический подход, основанный на линейных свойствах этих кривых. Он позволяет применять криптографические методы, схожие с описанными выше, но при этом элегантно обходит необходимость в циклических группах, уязвимых для квантовых атак на задачу дискретного логарифмирования.
Главный недостаток криптографии на изогениях — чрезвычайно сложный математический аппарат и риск скрытых уязвимостей в этой сложности. В прошлом году некоторые протоколы на изогениях были взломаны, хотя другие остаются безопасными. Ключевое преимущество — относительно небольшой размер ключей и возможность прямого переноса многих методов, разработанных для эллиптических кривых.
3-изогения в CSIDH. Источник.
Решётки (Lattices) — это принципиально другая криптографическая структура. Её математическая основа значительно проще, чем у изогений эллиптических кривых, при этом она способна решать мощные задачи, такие как полностью гомоморфное шифрование (FHE). Скрытые адреса также можно реализовать на основе решёток, хотя поиск оптимальных схем остаётся открытой проблемой. Однако решёточные структуры, как правило, требуют гораздо большего размера ключей.
Полностью гомоморфное шифрование — одно из применений решёток. FHE также можно использовать для поддержки протоколов скрытых адресов другим способом: оно позволяет Бобу делегировать проверку наличия средств на своих скрытых адресах по всей цепочке, не раскрывая ключ просмотра.
Третий подход — построение схемы скрытых адресов на основе универсальных «чёрных ящиков» — базовых примитивов, которые уже нужны многим приложениям по другим причинам. Часть схемы, отвечающая за генерацию общего секрета, напрямую соответствует обмену ключами — ключевому компоненту асимметричного шифрования. Более сложная задача — создать параллельные алгоритмы, позволяющие Алисе генерировать только скрытый адрес (но не ключ для траты), а Бобу — генерировать ключ для траты.
К сожалению, невозможно построить скрытые адреса, используя примитивы проще тех, что требуются для асимметричного шифрования. Простое доказательство: саму схему асимметричного шифрования можно построить на основе скрытых адресов. Если Алиса хочет зашифровать сообщение для Боба, она может отправить N транзакций, каждая из которых направлена либо на один из скрытых адресов Боба, либо на её собственный. Боб, определив, какие транзакции он получил, сможет прочитать сообщение. Это важно, поскольку математически доказано, что асимметричное шифрование нельзя построить только на хэшах, в то время как доказательства с нулевым разглашением (ZK) — можно. Следовательно, скрытые адреса также нельзя реализовать исключительно на хэшах.
Существует рабочий подход, использующий относительно простые примитивы: доказательства с нулевым разглашением, которые можно построить на основе хэшей и асимметричного шифрования (скрывающего ключи). Мета-адрес Боба состоит из открытого ключа шифрования и хэша h = hash(x), а его ключ для траты — из соответствующего закрытого ключа и значения x. Чтобы создать скрытый адрес, Алиса генерирует значение c и публикует его в зашифрованном ��иде (читаемом только Бобом) в качестве временного открытого ключа. Сам адрес представляет собой аккаунт ERC-4337, код которого проверяет транзакции, требуя ZK-доказательство владения значениями x и c, удовлетворяющими условию k = hash(hash(x), c) (где k — код аккаунта). Зная x и c, Боб может самостоятельно восстановить адрес и его код.
Зашифрованное значение c не раскрывает никакой информации никому, кроме Боба, а k — это просто хэш, который почти ничего не говорит о c. Код кошелька содержит только k, в то время как c остаётся приватным, что делает невозможным установление связи между k и h.
Однако этот подход требует использования STARK, которые имеют большой размер. В конечном счёте, я считаю, что постквантовый Ethereum, скорее всего, будет включать множество приложений, использующих STARK. Поэтому я выступаю за агрегирующие протоколы, подобные описанному здесь, которые объединяют все эти STARK в один рекурсивный STARK для экономии места.
Скрытые адреса, социальное восстановление и мульти-L2 кошельки
Я давно поддерживаю идею кошельков с социальным восстановлением. Это кошельки с механизмом многофакторной подписи, где ключи распределены между организациями, вашими другими устройствами и доверенными лицами так, что большинство из них может восстановить доступ к аккаунту в случае потери основного приватного ключа.
Однако кошельки социального восстановления плохо сочетаются со скрытыми адресами. Если вам нужно восстановить аккаунт (то есть сменить управляющий им приватный ключ), вам также придётся обновить логику проверки для всех N ваших скрытых кошельков. Это потребует N транзакций, что приведёт к высоким затратам, неудобству и потенциальному снижению приватности.
Аналогичные сложности возникают при взаимодействии механизмов социального восстановления с несколькими протоколами второго уровня. Представьте: у вас есть аккаунты в Optimism, Arbitrum, Starknet, Scroll и Polygon. Из-за вопросов масштабирования у вас могут быть десятки параллельных экземпляров в некоторых из этих роллапов, и для каждого — отдельный аккаунт. В такой ситуации смена ключей превращается в невероятно трудоёмкую операцию.
Обновить ключи сразу для множества аккаунтов в разных сетях — задача колоссального масштаба.
Первый подход — просто смириться с тем, что восстановление происходит редко, а его высокая стоимость и неудобства приемлемы. Можно, например, использовать автоматизированный софт для перевода активов на новый стелс-адрес со случайными интервалами в течение двух недель, чтобы снизить эффективность временной корреляции. Но это решение далеко от идеала. Другой вариант — хранить корневой ключ как общий секрет между опекунами, а не использовать для восстановления смарт-контракт. Однако в этом случае опекуны не смогут выйти из процесса восстановления вашего аккаунта, что создаёт долгосрочные риски.
Более изощрённый подход предполагает использование доказательств с нулевым разглашением (zero-knowledge proofs, ZKP). Рассмотрим упомянутую ZKP-схему, но изменим её логику: вместо прямого хранения значения k = hash(hash(x), c) аккаунт хранит (скрытое) обязательство относительно позиции k в цепочке. Чтобы провести транзакцию с этого аккаунта, нужно предоставить ZK-доказательство, которое подтверждает: (i) вы знаете позицию в цепочке, соответствующую этому обязательству, и (ii) объект на этой позиции содержит некоторое значение k (которое вы не раскрываете), причём существуют такие x и c, что выполняется равенство k = hash(hash(x), c).
Это позволяет управлять множеством аккаунтов — даже в разных L2-протоколах — с помощью единого значения k. Смена одного этого значения достаточна для изменения прав собственности на все аккаунты, при этом связь между ними остаётся скрытой.
Заключение
Базовые стелс-адреса можно внедрить уже сегодня, и они значительно повысят реальную приватность пользователей Ethereum. Однако для их поддержки кошелькам потребуется приложить определённые усилия. Впрочем, я считаю, что кошелькам в любом случае стоит переходить к более «родной» модели работы с несколькими адресами — например, создавать новый адрес для каждого приложения, с которым вы взаимодействуете. Это обосновано не только приватностью, но и другими причинами.
Тем не менее, стелс-адреса действительно создают долгосрочные проблемы с удобством использования, например, усложняют социальное восстановление. Пока что эти проблемы можно просто принять как данность: согласиться с тем, что социальное восстановление будет сопровождаться потерей приватности или двухнедельной задержкой, в течение которой транзакции восстановления для разных активов будут медленно публиковаться (это может делать сторонний сервис). В долгосрочной перспективе эти проблемы решаемы, но экосистема стелс-адресов во многом зависит от доказательств с нулевым разглашением.