Анонимные транзакции в Эфире: Виталик Бутерин представил "скрытые адреса" (stealth addresses) в блокчейне Ethereum

Виталик Бутерин представил концепт скрытых или невидимых адресов, который решает проблему анонимности пользователей криптовалют. Новая разработка анонимизирует одноранговые транзакции, трансферы NFT и регистрацию имён в сервисе Ethereum Name Service (ENS).

Если коротко, то это работает следующим образом:

Если не коротко, то ниже — полный перевод статьи Виталика, который погрузит вас в детали. Приятного чтения!

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

Особая благодарность Бену ДиФранческо, Мэтту Соломону, Тони Вахрштеттеру и Антонио Сансо за отзывы и рецензии

Одна из самых больших проблем в экосистеме Ethereum — это конфиденциальность. По умолчанию все, что попадает в публичный блокчейн, является публичным. Все чаще это означает не только деньги и финансовые транзакции, но и имена ENS, POAP, NFT, токены soulbound и многое другое. На практике использование всего набора приложений Ethereum подразумевает обнародование значительной части вашей жизни для всеобщего обозрения и анализа.

Улучшение такого положения дел является важной проблемой, и это широко признается. Однако до сих пор дискуссии об улучшении приватности в основном велись вокруг одного конкретного случая использования: сохраняющих приватность переводов (и, как правило, самопереводов) ETH и основных токенов ERC20. В этом посте мы опишем механику и примеры использования другой категории инструментов, которые могут улучшить состояние приватности в Ethereum в ряде других контекстов: стелс-адреса.

Предположим, что Алиса хочет отправить Бобу актив. Это может быть какое-то количество криптовалюты (например, 1 ETH, 500 RAI) , или это может быть NFT. Когда Боб получает актив, он не хочет, чтобы весь мир знал, что именно он его получил. Скрыть факт передачи невозможно, особенно если это NFT, у которого есть только одна копия в блокчейне, но скрыть, кто является получателем, может быть гораздо более реальным. Алиса и Боб ленивы: они хотят систему, в которой процесс оплаты точно такой же, как и сегодня. Боб посылает Алисе (или регистрируется в ENS) некий «адрес», кодирующий, как кто-то может ему заплатить, и одной этой информации достаточно, чтобы Алиса (или любой другой человек) отправила ему актив.

Обратите внимание, что это другой вид конфиденциальности, нежели тот, который обеспечивает, например, Tornado Cash. Tornado Cash может скрыть переводы основных взаимозаменяемых активов, таких как ETH или основные токены ERC20 (хотя он наиболее удобен для приватной отправки самому себе), но он очень слаб в добавлении конфиденциальности к переводам непопулярных ERC20, и он вообще не может добавить конфиденциальности к переводам NFT.

Скрытые адреса обеспечивают такую схему. Скрытый адрес — это адрес, который может быть сгенерирован как Алисой, так и Бобом, но контролировать который может только Боб. Боб генерирует и хранит в секрете spending key и использует этот ключ для генерации скрытого мета-адреса. Он передает этот мета-адрес Алисе (или регистрирует его в ENS). Алиса может произвести вычисления на этом мета-адресе, чтобы сгенерировать скрытый адрес, принадлежащий Бобу. Затем она может отправить любые активы, которые она хочет отправить на этот адрес, и Боб будет иметь полный контроль над ними. Вместе с передачей она публикует в цепочке некоторые дополнительные криптографические данные (ephemeral pubkey) , которые помогают Бобу обнаружить, что этот адрес принадлежит ему.

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

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

Все это основано на двух видах криптографической хитрости. Во-первых, нам нужна пара алгоритмов для создания shared secret: один алгоритм, который использует секрет Алисы (её ephemeral public key) и открытый ключ Боба (его мета-адрес) , и другой алгоритм, который использует секрет Боба (его корневой ключ траты) и открытый ключ Алисы (её ephemeral public key) . Это можно сделать многими способами; обмен ключами Диффи-Хеллмана был одним из методов, на которых основана область современной криптографии, и он достигает именно этого.

Но общего секрета самого по себе недостаточно: если мы просто сгенерируем закрытый ключ из общего секрета, то и Алиса, и Боб смогут тратить с этого адреса. Мы могли бы оставить все как есть, предоставив Бобу самому переводить средства на новый адрес, но это неэффективно и без необходимости снижает безопасность. Поэтому мы также добавляем механизм "ослепления" ключей: пару алгоритмов, в которых Боб может объединить общий секрет со своим корневым ключом трат, а Алиса может объединить общий секрет с мета-адресом Боба таким образом, что Алиса может сгенерировать скрытый адрес, а Боб может сгенерировать ключ трат для этого скрытого адреса, и все это без создания открытой связи между скрытым адресом и мета-адресом Боба (или между одним скрытым адресом и другим) .

Скрытые адреса с использованием криптографии эллиптических кривых были первоначально представлены в контексте Биткойна Питером Тоддом в 2014 году. Эта техника работает следующим образом (это предполагает предварительное знание основ криптографии эллиптических кривых).

Боб генерирует ключ m и вычисляет M = G * m, где G — общепринятая точка генератора для эллиптической кривой. Скрытый мета-адрес является кодировкой M. Алиса генерирует ephemeral public key r и публикует ephemeral public key R = G * r. Алиса может вычислить shared secret S = M * r, а Боб может вычислить такой же shared secret S = m * R. В общем, и в Bitcoin, и в Ethereum (включая правильно разработанные счета ERC-4337) адрес — это хэш, содержащий открытый ключ, используемый для проверки транзакций с этого адреса. Таким образом, вы можете вычислить адрес, если вычислите открытый ключ. Чтобы вычислить открытый ключ, Алиса или Боб могут вычислить P = M + G * hash(S). Чтобы вычислить закрытый ключ для этого адреса, Боб (и только Боб) может вычислить p = m + hash(S). Это удовлетворяет всем нашим требованиям, изложенным выше, и является удивительно простым!

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

Предположим, что кто-то отправляет вам NFT. Памятуя о вашей конфиденциальности, они отправляют его на скрытый адрес, который вы контролируете. После сканирования ephemeral public keys on-chain ваш кошелек автоматически обнаруживает этот адрес. Теперь вы можете свободно подтвердить право собственности на NFT или передать его кому-то другому. Но есть проблема! На этом счете 0 ETH, и поэтому нет возможности оплатить комиссию за транзакцию. Даже платежные системы для токенов ERC-4337 не работают, потому что они работают только для взаимозаменяемых токенов ERC20. И вы не можете отправить ETH на него со своего основного кошелька, потому что тогда вы создадите публично видимую ссылку.

Есть один «легкий» способ решить проблему: просто использовать ZK-SNARKS для перевода средств, чтобы оплатить комиссии! Но это стоит много газа, дополнительные сотни тысяч газа только для одного перевода.

Другой умный подход предполагает доверие к специализированным агрегаторам транзакций ("searchers" на жаргоне MEV). Эти агрегаторы позволят пользователям заплатить один раз, чтобы приобрести набор "билетов", которые можно использовать для оплаты транзакций на цепочке. Когда пользователю нужно потратить NFT на скрытый адрес, не содержащий ничего другого, он предоставляет агрегатору один из билетов, закодированный с помощью схемы ослепления Чаумиана. Это оригинальный протокол, который использовался в централизованных схемах электронной наличности с сохранением конфиденциальности, предложенных в 1980-х и 1990-х годах. Искатель принимает билет и неоднократно бесплатно включает транзакцию в свою связку, пока транзакция не будет успешно принята в блокчейне. Поскольку количество задействованных средств невелико, и они могут быть использованы только для оплаты транзакций, вопросы доверия и регулирования гораздо ниже, чем при "полной» реализации такого рода централизованной электронной наличности с сохранением конфиденциальности.

Предположим, что вместо того, чтобы у Боба был один главный «root spending key», который может делать все, Боб хочет иметь отдельный корневой ключ траты и ключ просмотра. Ключ просмотра может видеть все скрытые адреса Боба, но не может тратить с них.

В мире эллиптических кривых это можно решить с помощью очень простого криптографического трюка:

Мета-адрес Боба M теперь имеет форму (K, V), кодирующую G * k и G * v, где k — ключ траты, а v — ключ просмотра. Общий секрет теперь S = V * r = v * R, где r по-прежнему является ephemeral public key Алисы, а R по-прежнему является ephemeral public key, который Алиса публикует. Открытый ключ скрытого адреса — P = K + G * hash(S), а закрытый ключ — p = k + hash(S). Обратите внимание, что первый умный криптографический шаг (генерация общего секрета) использует ключ просмотра, а второй умный криптографический шаг (параллельные алгоритмы Алисы и Боба для генерации скрытого адреса и его закрытого ключа) использует root spending key.

Это имеет множество вариантов использования. Например, если Боб хочет получать POAP, то Боб может дать своему POAP-кошельку (или даже не очень безопасному веб-интерфейсу) ключ просмотра для сканирования блокчейна и просмотра всех своих POAP, не давая этому интерфейсу полномочий тратить эти POAP.

Чтобы облегчить сканирование всего набора эфемерных открытых ключей, один из методов — добавить тег просмотра к каждому эфемерному открытому ключу. Один из способов сделать это в приведенном выше механизме — сделать так, чтобы меткой просмотра был один байт общего секрета (например, x-координата S по модулю 256 или первый байт hash(S)).

Таким образом, Бобу нужно выполнить только одно умножение эллиптической кривой для каждого ephemeral public key, чтобы вычислить общий секрет, и только в 1/256 случаев Бобу придется выполнять более сложные вычисления, чтобы сгенерировать и проверить полный адрес.

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

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

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

Lattices — это совершенно другая криптографическая конструкция, которая опирается на гораздо более простую математику, чем изогении эллиптических кривых, и способна на некоторые очень мощные вещи (например, полностью гомоморфное шифрование). На решетках могут быть построены схемы скрытых адресов, хотя разработка лучшей из них является открытой проблемой. Однако конструкции на основе решеток, как правило, имеют гораздо большие размеры ключей.

Третий подход заключается в построении схемы скрытого адреса из общих примитивов "черного ящика": базовых компонентов, которые нужны многим людям по другим причинам. Часть схемы, связанная с генерацией общего секрета, напрямую связана с обменом ключами — важным компонентом в системах шифрования с открытым ключом. Самая сложная часть — это параллельные алгоритмы, которые позволяют Алисе генерировать только скрытый адрес (но не ключ расходов) и позволяют Бобу генерировать spending key.

К сожалению, нельзя построить стелс-адреса из ингредиентов, более простых, чем те, которые требуются для создания системы шифрования с открытым ключом. Существует простое доказательство этого: вы можете построить систему шифрования с открытым ключом из схемы скрытых адресов. Если Алиса хочет зашифровать сообщение Бобу, она может послать N транзакций, каждая из которых направляется либо на скрытый адрес, принадлежащий Бобу, либо на скрытый адрес, принадлежащий ей самой, а Боб может посмотреть, какие транзакции он получил, чтобы прочитать сообщение. Это важно, потому что существуют математические доказательства того, что вы не можете выполнить шифрование с открытым ключом, используя только хэши, в то время как вы можете выполнить zero-knowledge proof, используя только хэши — следовательно, скрытые адреса не могут быть выполнены с использованием только хэшей.

Вот один подход, который использует относительно простые ингредиенты: zero-knowledge proofs, которые можно сделать из хэшей, и (скрывающее ключ) шифрование с открытым ключом. Мета-адрес Боба — это открытый ключ шифрования плюс хэш h = hash(x), а его расходный ключ — это соответствующий ключ расшифровки плюс x. Чтобы создать скрытый адрес, Алиса генерирует значение c и публикует в качестве своего эфемерного открытого ключа шифрование c, доступное для чтения Бобу. Сам адрес представляет собой счет ERC-4337, код которого проверяет транзакции, требуя, чтобы они сопровождались zero-knowledge proof, подтверждающим владение значениями x и c, такими, что k = hash(hash(x), c) (где k является частью кода счета). Зная x и c, Боб может самостоятельно восстановить адрес и его код.

Шифрование c ничего не сообщает никому, кроме Боба, а k — это хэш, поэтому он почти ничего не раскрывает о c. Сам код кошелька содержит только k, а закрытость c означает, что k нельзя отследить до h.

Однако для этого требуется STARK, а STARK велики. В конечном итоге, я считаю вероятным, что в мире Ethereum после квантования будет множество приложений, использующих множество STARK, и поэтому я бы выступал за протокол агрегации, чтобы объединить все эти STARK в один рекурсивный STARK для экономии места.

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

Однако кошельки с социальным восстановлением не очень хорошо сочетаются со стелс-адресами: если вам нужно восстановить свой счет (то есть, изменить, какой закрытый ключ его контролирует) , вам также придется выполнить определенный шаг, чтобы изменить логику проверки счета на N стелс-кошельках, а это потребует N транзакций, что потребует высокой стоимости комиссии, удобства и конфиденциальности.

Аналогичная проблема существует при взаимодействии социального восстановления и мира с несколькими протоколами второго уровня: если у вас есть аккаунт на Optimism, и на Arbitrum, и на Starknet, и на Scroll, и на Polygon, и, возможно, некоторые из этих роллапов имеют дюжину параллельных сущностей по причинам масштабирования, и у вас есть аккаунт на каждом из них, то смена ключей может быть действительно сложной операцией.

Один из подходов заключается в том, чтобы смириться с тем, что восстановление происходит редко, и это нормально, если оно будет дорогостоящим и болезненным. Возможно, для снижения эффективности привязки по времени вы можете использовать автоматизированное программное обеспечение, которое будет переводить активы на новые скрытые адреса через случайные промежутки времени в течение двух недель. Но это далеко не идеальный вариант. Другой подход заключается в секретном обмене корневым ключом между хранителями вместо использования восстановления смарт-контракта. Однако это лишает guardian возможности деактивировать свои полномочия, чтобы помочь восстановить аккаунт, и поэтому в долгосрочной перспективе является рискованным.

Более сложный подход предполагает использование zero-knowledge proof. Рассмотрим схему на основе ZKP, описанную выше, но изменим логику следующим образом. Вместо того чтобы счет напрямую хранил k = hash(hash(x) , c) , он будет хранить (скрывая) обязательство о местоположении k в цепочке. Трата средств с этого счета потребует предоставления zero-knowledge proof, что (i) вы знаете место на цепочке, соответствующее этому обязательству, и (ii) объект в этом месте содержит некоторое значение k (которое вы не раскрываете) , и что у вас есть некоторые значения x и c, которые удовлетворяют k = hash(hash(x) , c) .

Это позволяет многим учетным записям, даже во многих L2-протоколах, контролироваться одним значением k где-то (на основной сети или на каком-то L2) , где изменение этого одного значения достаточно, чтобы изменить права собственности всех ваших учетных записей, и все это без раскрытия связи между вашими учетными записями и друг другом.

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

Однако стелс-адреса создают некоторые долгосрочные проблемы, связанные с удобством использования, например, сложность социального восстановления. Возможно, пока можно просто принять эти проблемы, например, смириться с тем, что социальное восстановление будет связано либо с потерей конфиденциальности, либо с двухнедельной задержкой для медленного совершения транзакций по восстановлению различных активов (что может быть обработано сторонней службой). В долгосрочной перспективе эти проблемы могут быть решены, но экосистема стелс-адресов в долгосрочной перспективе выглядит как экосистема, которая будет очень сильно зависеть от zero-knowledge proofs.

Источник: An incomplete guide to stealth addresses.

#blockchain #ethereum #crypto #cryptocurrency #блокчейн #эфир #криптовалюта #крипта