Стек приватности Эфириума: приватные чтения, сети и скрытая утечка

Выступление Энди Гузмана (Andy Guzman), руководителя команды Privacy Stewards of Ethereum (PSE) в Фонде Ethereum, на EthBoulder 2026. Он раскрывает главное слепое пятно в приватности Эфириума: даже пользователи, которые никогда не подписывают транзакции, допускают утечку подробных поведенческих данных через повседневные запросы. Он представляет стек приватности Эфириума, охватывающий приватные чтения (PIR), приватность трафика (луковая маршрутизация и микснеты), а также работу над производительностью, такую как унифицированные бинарные деревья и состояние, верифицируемое с помощью доказательств с нулевым разглашением (ZK).

Эта расшифровка является доступной копией оригинальной расшифровки видео (открывается в новой вкладке), опубликованной EthBoulder. Она была слегка отредактирована для удобства чтения.

Вымышленное письмо от RPC-провайдера (0:12)

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

Позвольте мне начать с письма, которое кто-то написал вам.

«Дорогой ценный пользователь, спасибо за 847 запросов, которые вы сделали в этом месяце. Нам очень понравилось узнавать вас. Мы знаем, что вы храните ETH на трех разных кошельках. Мы знаем, что в прошлый вторник вы проверяли цену ETH 94 раза. Это был очень тяжелый день для всех, так что мы вас не осуждаем. Вы также проверяли цену BTC, что интересно, потому что у вас нет Биткоина. Думаете о диверсификации? Это останется между нами и, конечно же, нашими партнерами по аналитике. Вы также очень внимательно следите за двумя пулами Юнисвоп и на прошлой неделе 14 раз проверяли свой фактор здоровья в Aave. Возможно, вам стоит расслабиться или просто добавить немного залога. В четверг вы проверили его три раза за 12 минут и были очень обеспокоены. Вы просматривали четыре разных имени ENS, так что либо вы начинаете новый проект, либо у вас кризис идентичности. И вы всегда затихаете между 23:00 и 7:00 по горному времени».

Как происходит утечка данных без подписания транзакций (1:34)

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

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

Приватные записи против приватных чтений (2:07)

Так что же на самом деле происходит сейчас в мире приватности? Я вижу, что мы уделяем много внимания ончейн-приватности, или тому, что мы в PSE называем приватными записями: всем действиям, которые вы совершаете ончейн. И это логично, не так ли? Эти действия записываются навсегда и передаются по всему миру, поэтому действительно имеет смысл не раскрывать свой адрес при выполнении определенного действия. Мы также уделяем большое внимание инструментарию: источникам данных, доказательствам, предметно-ориентированным языкам (DSL) и языкам программирования, которые мы можем использовать, чтобы дать разработчикам больше инструментов для выражения и создания более надежных приложений с большей ончейн-приватностью.

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

Если говорить чуть более техническим языком: все RPC-вызовы, такие как eth_getBalance, eth_call и eth_getLogs, представляют собой запросы в виде открытого текста, которые отправляются RPC-провайдерам и сопоставляются с вашим IP-адресом.

Почему большая активность увеличивает риск профилирования (3:20)

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

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

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

Представление стека приватности Эфириума (4:43)

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

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

Уровень за уровнем: где происходит утечка (5:41)

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

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

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

И есть еще одна вертикаль, которую мы называем сетью, она является сквозной и пересекает все эти уровни. Например: прямо сейчас вы посещаете веб-сайт, и сервер знает ваш IP-адрес. Но что, если бы вы посетили этот веб-сайт через Tor или другую анонимную сеть? Вы бы знали IP-адрес веб-сайта, но они бы не знали ваш. А что, если этот веб-сайт размещен в стране, которая недавно начала подвергать цензуре все, что связано с криптовалютой? Этот веб-сайт и компания также захотели бы скрыть свой IP-адрес и спрятать свой домен за onion-доменом.

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

Приватные чтения и приватные сети (8:24)

Итак, у нас есть стек приватности Эфириума. На чем нам следует сосредоточиться? В этой презентации я хочу поговорить об этих двух областях. Приватные чтения: всякий раз, когда вы получаете доступ к состоянию ончейн, вы затрагиваете все эти уровни, от приложения (скажем, я хочу запросить цену ETH), до кошелька, шлюзов, узла, на котором работает Эфириум и EVM, и затем обратно. По сути, RPC-провайдера или индексатора. И приватные сети, то есть все действия, которые происходят на сетевом уровне. Именно их мы и хотим усилить.

Три столпа: данные, трафик, производительность (9:05)

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

Сокрытие данных: от прокси до PIR (9:39)

Итак, данные. Что именно мы хотим защитить? Мы хотим скрыть, какую информацию вы запрашиваете у этих серверов, и мы хотим скрыть паттерны того, как вы получаете доступ к этим данным. Не только содержимое, но и паттерны.

Существуют разные уровни методов. Первый — это ничего: вы просто раскрываете все. Всякий раз, когда вы подключаете свой кошелек, вы привязываете свой IP-адрес к контракту, который вы запрашиваете, к конкретному eth_getBalance для конкретного адреса, и на этом все. Даже если вы используете протокол приватности, скажем, Tornado Cash, и хотите запросить состояние дерева Меркла, вам придется либо загрузить все дерево целиком, что не очень производительно, либо вы раскроете, какой путь и листья вы запрашиваете, уменьшая свой набор анонимности. Поэтому даже использования надежного протокола приватности, такого как Tornado Cash, недостаточно, если вы не защищаете свою сеть и паттерны доступа к данным.

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

Затем у вас есть доверенные среды выполнения (TEE), которые являются шагом вперед, и именно здесь некоторые команды и компании предлагают свои услуги. Я думаю, что это хороший шаг вперед, но этого недостаточно, опять же потому, что стоимость атаки и взлома TEE сильно падает. Для некоторых критически важных сценариев использования этого недостаточно; для многих повседневных — вполне может быть.

Есть и другие команды, работающие над OMAP (скрытыми паттернами доступа к картам) и ORAM (скрытой оперативной памятью). Это похожие методы, которые пытаются запутать, к каким частям набора данных вы пытаетесь получить доступ. Вместо того чтобы сказать: «Я хочу узнать баланс этого адреса ETH», вы случайным образом обращаетесь к разным вещам, поэтому сервер ничего не знает.

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

Объяснение приватного извлечения информации (12:03)

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

Состояние Эфириума огромно и очень разнообразно. Журналы, как я узнал вчера, работают только на добавление, но модель аккаунтов отличается: некоторое состояние обновляется очень часто, некоторое — нет. В зависимости от того, как вы это структурируете, у вас могут быть мегабайты, гигабайты или терабайты данных с совершенно разными паттернами доступа.

Многоагентная архитектура PIR (12:48)

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

Что, если у нас будет сервис, который запускает эту многоагентную архитектуру и, в зависимости от типа запросов и того, где они могут находиться в состоянии Эфириума, запускает ту или иную схему? Это уже очень приближает нас к чему-то осуществимому, готовому к производству и тому, что можно предложить экосистеме. Для этого потребуется что-то вроде унифицированного API, чтобы кошелькам, индексаторам, пользователям и разработчикам децентрализованных приложений (dapp) не нужно было беспокоиться о том, какая схема используется и как ее вызывать. У вас просто есть стандартный API, а о деталях реализации беспокоится кто-то другой.

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

Вот несколько цифр о различных схемах PIR: пропускная способность, накладные расходы на связь и так далее. Это сложно, потому что разные приложения имеют разные паттерны доступа. Некоторые обращаются к большому количеству квитанций, некоторые хотят получить доступ к большей части состояния, как Rotki, а некоторые обращаются к большему количеству транзакций, как Helios. Серебряной пули не существует, и, скорее всего, будет полезна смешанная архитектура. Мы также проводим систематизацию знаний, поэтому, если вам это интересно, мы можем поделиться. И вот лишь некоторые из команд, работающих в этих областях. Простите меня, если вы являетесь частью команды, а я вас не включил; если кто-то посмотрит запись и не найдет себя, пожалуйста, дайте мне знать, и я смогу начать добавлять вас.

Сокрытие трафика: луковая маршрутизация и Tor (15:22)

Мы рассмотрели данные. Другой большой блок — это трафик. Как нам скрыть трафик и что мы хотим скрыть? Говоря очень простым языком, мы хотим скрыть IP-адреса клиента и сервера друг от друга, а также от остального мира, который может следить за трафиком. У нас есть разные методы: onion-сервисы, микснеты, VPN, DC-сети, и могут быть другие классификации. Я собираюсь поговорить только о первых двух.

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

Вкратце: что, если бы весь трафик экосистемы Эфириума мог маршрутизироваться через сеть Tor, так сказать? Есть и другие варианты. Мы бы помогли защитить IP-адрес отправителя: данные вашего телефона или ноутбука не утекли бы при отправке транзакций или запросе информации. И, конечно же, мы бы также защитили получателя, сервер. Представьте, что в Иране, Китае, Северной Корее или Венесуэле кто-то пытается разместить DeFi-протокол или сервис, и он подвергается цензуре со стороны их страны. Это вариант, который мог бы защитить их жизни. Он обходит цензуру, а также скрывает трафик от интернет-провайдеров (ISP), которые, как мы все знаем, прослушиваются спецслужбами, сующими свой нос во все дела.

Цель состоит в том, чтобы иметь готовую замену: SDK, чтобы кошелькам, разработчикам dapp и поставщикам инфраструктуры не нужно было беспокоиться о деталях реализации. Они просто знают, что если они используют этот SDK, трафик становится «луковым», шифруется и усиливается.

Я хочу отметить команду Brume Wallet, которая запустила Echalote, реализацию Tor для интернета с открытым исходным кодом. Это существует прямо сейчас: есть клиенты Tor, но они написаны на C, и их нужно запускать в специальном браузере. Что, если я хочу добавить это в МетаМаск, или в кошелек Kohaku, или в Ambire, Rabby и все остальные? Нам нужны SDK на JavaScript, и именно это начал Echalote.

Кроме того, у Tor Project разрабатывается новая реализация под названием Arti, следующее поколение их клиента. Но нам нужен встроенный Arti. Arti основан на Rust, и его нужно скомпилировать в WASM, чтобы он мог работать в вашем браузере, и вы могли бы очень легко его импортировать. По сути, мы сотрудничаем с командой Tor: созваниваемся каждую неделю, ведем совместные проекты и партнерства.

Микснеты для Эфириума (18:16)

Что касается микснетов, я хочу отметить несколько команд, которые занимаются этим: команду Nym; HOPR, также одних из первых; VPN, такие как Gnosis VPN; и пару других, которые были для меня в новинку, например, Anyone Protocol, и я думаю, что кто-то из этой команды должен быть здесь, в Денвере, плюс некоторые другие новые проекты. Есть много команд, работающих над микснетами, VPN и другими подходами.

Мы хотим посмотреть: что, если мы создадим специально разработанный микснет для Эфириума, через который мы сможем маршрутизировать RPC-трафик? Микснеты имеют строгие гарантии, но они добавляют большую задержку. Для некоторых сценариев использования это нормально: не имеет значения, если это займет немного больше времени, главное, чтобы у вас была приватность. Но для таких вещей, как DeFi и трейдинг, крайне маловероятно, что они будут приняты, если добавят задержку. Итак, насколько быстро мы можем работать с самыми высокими гарантиями приватности? Опять же, выражаю признательность некоторым из этих команд, и если кто-то работает в этих областях, а я вас не добавил, я был бы рад пообщаться.

Производительность: унифицированные бинарные деревья и ускорение на GPU (19:28)

Последнее, о чем я хочу поговорить, третий столп, позволяющий воплотить это в реальность, — это производительность. Мы хотим, чтобы эти вещи работали быстро и дешево. У меня есть принцип: эти вещи не будут приняты, если затраты превышают выгоду. Затраты означают пользовательский опыт, время и усилия для пользователя, а также затраты для разработчиков и инфраструктуры: очень ли дорого это запускать? Нам нужно максимально снизить затраты, и есть две высокоуровневые инициативы, о которых я могу рассказать.

Одна из них — UBT (унифицированные бинарные деревья). В зависимости от того, насколько вы вовлечены в предложения (EIP) Протокола, вы, возможно, слышали об этом. Прямо сейчас у нас есть префиксное дерево Меркла-Патриции, которое полезно, но не очень полезно для ZK и других типов криптографии. Существует предложение, EIP-7864, о переходе не на деревья Веркла, а на унифицированные бинарные деревья. Это намного эффективнее для запроса состояния и последующего выполнения криптографических операций, таких как ZK, поверх него.

У нас есть проект, создающий верифицируемое UBT: вы добавляете сайдкар к любому клиенту Эфириума, который вместо базы данных MPT имеет базу данных состояния UBT, а затем вы доказываете, что это преобразование из MPT в UBT является действительным, используя zkVM. Это уже очень мощно. Как только нам удастся это сделать, легкие клиенты смогут использовать это для повышения своей производительности, а такие вещи, как PIR, смогут работать намного быстрее.

Другой аспект — ускорение на GPU. Мы можем запускать эти вещи намного быстрее, если оптимизируем нижние уровни стека: GPU — один из них, или ускорение на CPU. Эти вещи, вероятно, будут работать на серверах, а не на телефонах, поэтому также очень ценно начать изучать, как мы можем создать эти низкоуровневые библиотеки, чтобы они работали намного быстрее.

Подводя итог: у нас есть эти пять уровней, и мы хотим охватить эти сценарии использования. Есть три столпа: данные, трафик и производительность. Для данных у нас есть прокси, TEE, ORAM, OMAP и PIR. Для трафика у нас есть микснеты, луковая маршрутизация и другие. Для производительности у нас есть UBT и ускорение на GPU. Если вы хотите узнать больше, по крайней мере, о вкладе, который вносит PSE, вы можете перейти на pse.dev/research.

Измерение успеха (22:15)

Так что же такое успех и как мы можем его измерить? Возвращаясь к этим уровням: если я хочу иметь возможность заявить, что Эфириум — самая приватная цепь, какова конечная цель? Мне нужно быть уверенным, что все эти уровни максимально защищены. Как бы я это измерил? Я бы ожидал, что больше веб-сайтов и фронтендов dapp будут размещаться за onion-доменами. Мне бы очень хотелось, чтобы кошельки изначально использовали анонимную маршрутизацию, а также шлюзы, RPC-провайдеры и индексаторы. И я бы измерял это в процентах.

Вопрос в следующем: сколько из текущих фронтендов экосистемы Эфириума размещено за onion-доменом? Я бы сказал, крайне мало, 1%, если вообще есть. Чтобы я чувствовал себя хорошо и мог сказать, что мы это сделали, нам, вероятно, потребовалось бы более 80% на всех этих уровнях. Сколько кошельков прямо сейчас маршрутизируют трафик с помощью методов анонимной маршрутизации? Очень, очень мало. То же самое с RPC-провайдерами: предлагают ли эти провайдеры PIR? Нет. Поэтому для меня заявление об успехе означает, что участники на всех этих уровнях внедряют подобные технологии, по крайней мере 80% команд, трафика или запросов.

Сравнение с onion-узлами Биткоина (23:39)

Это то, в чем мы можем позавидовать Биткоину. Несмотря на всю критику в их адрес, вот картина за ноябрь прошлого года: 64% их доступных полных узлов скрыты за onion-доменами.

Можем ли мы сделать это сами? Это приватность более низкого уровня, уровня консенсуса, но можем ли мы сказать, что наши полные узлы и узлы валидаторов находятся за onion-сетью или микснетами? Я определенно считаю, что мы должны, а сейчас мы, вероятно, находимся на уровне менее 1%. У нас есть другие проблемы, которых нет у них: мы работаем намного быстрее, и наш консенсус отличается. Но я бы очень хотел иметь подобные дашборды и говорить, что более 80% кошельков внедрили эти типы технологий, а также RPC-провайдеры, обозреватели, фронтенды, балансировщики нагрузки и SDK. Я бы очень хотел, чтобы этот список рос.

Сравнение Эфириума с Monero и Zcash (24:55)

Вчера и позавчера вечером я взял на себя смелость начать изучать, как через призму этих уровней экосистема Эфириума соотносится с такими проектами, как Solana, Биткоин, Zcash и Monero. Желтым цветом выделены методы, требующие согласия (opt-in), и я думаю, что здесь мы очень хороши. Синим цветом выделены предложения, некоторые из них — предложения Протокола. Зеленым цветом выделено то, что применяется на уровне Протокола.

Из-за нашей 10-летней истории в качестве публичной цепи, я думаю, будет сложно догнать Monero и Zcash в том, чтобы сделать приватность встроенной. Но я думаю, что мы можем проделать действительно хорошую работу по внедрению методов по выбору (opt-in), а также культурно и социально влиять на команды и пользователей, чтобы они чаще применяли эти методы. У Биткоина и Solana есть свои собственные проблемы, и я думаю, что они будут отставать еще больше, по крайней мере, в вопросах приватности.

Вызов: самая приватная программируемая экосистема (25:50)

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

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

Мы не можем сосредотачиваться только на ончейн-элементах. Нам нужно сосредоточиться на всех этих уровнях.

Поэтому, если вы работаете над приватными чтениями, сетями, реализациями PIR, ускорением на GPU, структурами данных, UBT, инфраструктурой или валидаторами, я был бы рад пообщаться с вами после выступления. Большое спасибо. Эфириум — для приватности.