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

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

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

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

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

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

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

• Боб генерирует свой spending key (m) и скрытый мета-адрес (M).

• Боб добавляет запись ENS, чтобы зарегистрировать M как скрытый мета-адрес для bob.eth.

• Предполагается, что Алиса знает, что Боб - это bob.eth. Алиса ищет его скрытый мета-адрес M на ENS.

• Алиса генерирует временный ключ, который знает только она, и который она использует только один раз (чтобы сгенерировать конкретный скрытый адрес).

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

• Алиса также генерирует свой временный открытый ключ и публикует его в реестре временных открытых ключей (это может быть сделано в той же транзакции).

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

• Для каждого временного открытого ключа Боб пытается объединить его со своим root spending key, чтобы сгенерировать скрытый адрес, и проверяет, есть ли в нем какие-либо активы. Если есть, Боб рассчитывает spending key для этого адреса и запоминает его.

Все это основано на двух криптографических хитростях. Сначала нам нужны два алгоритма для генерации общего секрета (shared secret) (общий секрет представляет собой часть данных, известную только участвующим сторонам в защищенной связи): один алгоритм, который использует секретное вещество Алисы (ее временный ключ) и публичное вещество Боба (его мета-адрес), и другой алгоритм, который использует секретное вещество Боба (его root spending key) и публичное вещество Алисы (ее временный открытый ключ). Это может достигаться разными способами; Ключевой обмен Diffie-Hellman’а был одним из способов, которые основали область современной криптографии и он добивается именно этого.

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

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

• Боб генерирует ключ 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. Осознавая вашу конфиденциальность, кто-то отправляет его на скрытый адрес, который вы контролируете. После сканирования ephemeral pubkeys на блокчейне, ваш кошелек автоматически обнаруживает этот адрес. Теперь вы можете доказать владение NFT или передать его кому-то еще. Но есть проблема! Проблема в том, что на этом аккаунте 0 ETH и поэтому нет возможности оплатить комиссию за транзу. Даже ERC-4337 токены не смогут работать, потому что они работают только с токенами ERC20. И вы не можете отправить ETH на него со своего основного кошелька, потому что тогда вы создадите общедоступную связь.

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

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

Предположим, что вместо того, чтобы у Боба был единственный master “root spending key", который может все сделать, Боб захотел отдельный root spending key и viewing key. Viewing key может видеть все скрытые адреса Боба, но не может c них ничего отправлять.

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

• Мета-адрес Боба M теперь имеет форму (K, V), кодируемый G * k и G * v, где k - это spending key, а v - viewing key.

• Общий секрет (shared secret) теперь S = V * r = v * R, где r все еще является временным ключом Алисы и R все еще является временным открытым ключом, который Алиса опубликовывает.

• Открытый ключ скрытого адреса - это P = K + G * hash(S), а закрытый ключ - это p = k + hash(S).

Обратите внимание, что первый криптографический шаг (генерация общего секрета) использует viewing key, а второй (параллельные алгоритмы Алисы и Боба для генерации скрытого адреса и его приватного ключа) использует root spending key.

Тут есть множество применений. Например, если Боб хочет получать POAP, то он может дать свой POAP кошелек (или не очень безопасный способ - доступ к веб-интерфейсу) свой viewing key, чтобы сканировать цепочку и видеть все его POAP, не давая этому интерфейсу возможности перемещать их.

Чтобы сделать процесс сканирования всего набора ephemeral public keys проще, одним из способов является добавление метки просмотра к каждому ephemeral public key’ю. Один из способов реализовать это в вышеуказанном механизме - это сделать метку просмотра размером в один байт от общего секрета (например, по первому байту hash(S)).

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

Вышеуказанная схема зависит от эллиптических кривых, которые неплохи, но к сожалению, уязвимы для квантовых компьютеров. Если квантовые компьютеры станут проблемой, нам придется перейти на алгоритмы, стойкие к квантовой атаке. Есть два естественных кандидата на это: изогении эллиптических кривых и криптография на решетках (Криптография на решётках — подход к построению алгоритмов асимметричного шифрования с использованием задач теории решёток, то есть задач оптимизации на дискретных аддитивных подгруппах, заданных на множестве \mathbb {R} ^{n}).

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

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

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

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

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

Один из подходов, который использует относительно простые “ингредиенты”, - это zero-knowledge proofs, которые могут быть созданы из хешей, и (скрытых ключей) публичного ключевого шифрования. Мета-адрес Боба это публичный ключ шифрования плюс хеш h=hash(x), а его spending key это соответствующий ключ расшифровки плюс 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 в один рекурсивный, для экономии места.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Боб генерирует свой spending key (m) и скрытый мета-адрес (M).

• Боб добавляет запись ENS, чтобы зарегистрировать M как скрытый мета-адрес для bob.eth.

• Предполагается, что Алиса знает, что Боб - это bob.eth. Алиса ищет его скрытый мета-адрес M на ENS.

• Алиса генерирует временный ключ, который знает только она, и который она использует только один раз (чтобы сгенерировать конкретный скрытый адрес).

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

• Алиса также генерирует свой временный открытый ключ и публикует его в реестре временных открытых ключей (это может быть сделано в той же транзакции).

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

• Для каждого временного открытого ключа Боб пытается объединить его со своим root spending key, чтобы сгенерировать скрытый адрес, и проверяет, есть ли в нем какие-либо активы. Если есть, Боб рассчитывает spending key для этого адреса и запоминает его.

Все это основано на двух криптографических хитростях. Сначала нам нужны два алгоритма для генерации общего секрета (shared secret) (общий секрет представляет собой часть данных, известную только участвующим сторонам в защищенной связи): один алгоритм, который использует секретное вещество Алисы (ее временный ключ) и публичное вещество Боба (его мета-адрес), и другой алгоритм, который использует секретное вещество Боба (его root spending key) и публичное вещество Алисы (ее временный открытый ключ). Это может достигаться разными способами; Ключевой обмен Diffie-Hellman’а был одним из способов, которые основали область современной криптографии и он добивается именно этого.

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

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

• Боб генерирует ключ 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. Осознавая вашу конфиденциальность, кто-то отправляет его на скрытый адрес, который вы контролируете. После сканирования ephemeral pubkeys на блокчейне, ваш кошелек автоматически обнаруживает этот адрес. Теперь вы можете доказать владение NFT или передать его кому-то еще. Но есть проблема! Проблема в том, что на этом аккаунте 0 ETH и поэтому нет возможности оплатить комиссию за транзу. Даже ERC-4337 токены не смогут работать, потому что они работают только с токенами ERC20. И вы не можете отправить ETH на него со своего основного кошелька, потому что тогда вы создадите общедоступную связь.

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

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

Предположим, что вместо того, чтобы у Боба был единственный master “root spending key", который может все сделать, Боб захотел отдельный root spending key и viewing key. Viewing key может видеть все скрытые адреса Боба, но не может c них ничего отправлять.

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

• Мета-адрес Боба M теперь имеет форму (K, V), кодируемый G * k и G * v, где k - это spending key, а v - viewing key.

• Общий секрет (shared secret) теперь S = V * r = v * R, где r все еще является временным ключом Алисы и R все еще является временным открытым ключом, который Алиса опубликовывает.

• Открытый ключ скрытого адреса - это P = K + G * hash(S), а закрытый ключ - это p = k + hash(S).

Обратите внимание, что первый криптографический шаг (генерация общего секрета) использует viewing key, а второй (параллельные алгоритмы Алисы и Боба для генерации скрытого адреса и его приватного ключа) использует root spending key.

Тут есть множество применений. Например, если Боб хочет получать POAP, то он может дать свой POAP кошелек (или не очень безопасный способ - доступ к веб-интерфейсу) свой viewing key, чтобы сканировать цепочку и видеть все его POAP, не давая этому интерфейсу возможности перемещать их.

Чтобы сделать процесс сканирования всего набора ephemeral public keys проще, одним из способов является добавление метки просмотра к каждому ephemeral public key’ю. Один из способов реализовать это в вышеуказанном механизме - это сделать метку просмотра размером в один байт от общего секрета (например, по первому байту hash(S)).

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

Вышеуказанная схема зависит от эллиптических кривых, которые неплохи, но к сожалению, уязвимы для квантовых компьютеров. Если квантовые компьютеры станут проблемой, нам придется перейти на алгоритмы, стойкие к квантовой атаке. Есть два естественных кандидата на это: изогении эллиптических кривых и криптография на решетках (Криптография на решётках — подход к построению алгоритмов асимметричного шифрования с использованием задач теории решёток, то есть задач оптимизации на дискретных аддитивных подгруппах, заданных на множестве \mathbb {R} ^{n}).

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

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

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

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

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

Один из подходов, который использует относительно простые “ингредиенты”, - это zero-knowledge proofs, которые могут быть созданы из хешей, и (скрытых ключей) публичного ключевого шифрования. Мета-адрес Боба это публичный ключ шифрования плюс хеш h=hash(x), а его spending key это соответствующий ключ расшифровки плюс 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 в один рекурсивный, для экономии места.

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

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

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

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

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

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

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

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