Сетевые уязвимости децентрализованной системы Ethereum
Александр Подобных, 26/09/25
Даже самые надежные криптографические механизмы не дают абсолютной защиты, если сама сетевая архитектура оставляет лазейки для анализа трафика. Уязвимость нередко кроется не в алгоритмах, а в оптимизациях протоколов, где статистика и пассивное наблюдение способны разрушить иллюзию анонимности. Именно это демонстрирует свежий кейс из мира блокчейна Ethereum.
Автор: Александр Подобных, криптоаналитик аналитического агентства “Opus Magnum”, руководитель комитета по безопасности цифровых активов и противодействию мошенничеству АРСИБ, судебный эксперт (компьютерно-техническая экспертиза)
Ethereum как платформа смарт-контрактов и децентрализованных приложений давно стал примером сложной распределенной системы, в которой криптографические методы тесно переплетены с сетевой архитектурой. Завершенный в 2022 г. переход на механизм консенсуса Proof-of-Stake (взамен Proof-of-Work) рассматривался как шаг к большей энергоэффективности и устойчивости. В этой модели безопасность сети обеспечивается тысячами валидаторов – программных сущностей, которые запускаются на узлах сети и отвечают за предложение и подтверждение новых блоков.
В официальной доктрине Ethereum валидаторы должны оставаться анонимными: их публичные ключи выступают лишь идентификаторами в протоколе, не связанными напрямую с конкретными устройствами или IP-адресами. Однако исследование, опубликованное в 2024 г., показало, что эта анонимность во многом иллюзорна. Экспериментальная методология позволила связать идентификаторы валидаторов с IP-адресами узлов, на которых они размещены, и тем самым раскрыла скрытые зависимости в распределенной системе.
Теоретические предпосылки
Proof-of-Stake в Ethereum базируется на регулярной аттестации блоков. Валидаторы группируются в комитеты, каждый из которых отвечает за проверку блока в конкретном временном интервале. Чтобы сеть могла масштабироваться, сообщения не транслируются всем узлам, а распространяются в пределах ограниченного числа подсетей. Для этого используется протокол GossipSub, основанный на вероятностной широковещательной модели.
Разделение валидаторов на комитеты и ограничение числа подсетей, куда они транслируют свои сообщения, – это хорошая оптимизация всей системы, она действительно снижает сетевую нагрузку, но при этом создает предсказуемые паттерны. Узлы по умолчанию подписаны лишь на две подсети и ретранслируют только часть сообщений. Поэтому если узел пересылает сообщение вне своих обязательных подсетей, высока вероятность, что оно создано его собственным валидатором. При многократных наблюдениях формируется достаточно устойчивая картина для сопоставления конкретного валидатора с конкретным узлом.
Экспериментальная проверка
Ключевая часть работы опирается на исследование "Deanonymizing Ethereum Validators: The P2P Network Has a Privacy Issue" [1]. Авторы показали, что для раскрытия связи между идентификатором валидатора и IP-адресом узла достаточно простого наблюдения за сетевым трафиком. Не требуется атак, внедрения в протокол или дорогостоящей инфраструктуры: достаточно пассивно слушать сообщения аттестации и выявлять закономерности. Чтобы подтвердить гипотезу, они развернули собственные узлы в реальной сети Ethereum и несколько дней фиксировали все сетевые события.
Для эксперимента был модифицирован один из популярных консенсус-клиентов – Prysm. В версии исследователей, получившей название Rainbow, узел вел себя как обычный Prysm, но дополнительно собирал и протоколировал все аттестации, статические подписки на подсети и параметры соединений. Главное отличие заключалось в том, что Rainbow подписывался сразу на все подсети, а не на две, как стандартный клиент. Это дало возможность видеть максимально широкий спектр сообщений. Чтобы снизить искажения, дубликаты аттестаций отбрасывались: учитывалась только первая копия.
Rainbow был развернут в четырех точках. Три экземпляра работали в облаке Amazon (регионы США, Европа и Азия), а четвертый – на физическом сервере в Цюрихе. Такой выбор позволил сравнивать результаты по географическим регионам и типам инфраструктуры. Сбор данных продолжался с 7 по 10 мая 2024 г. За это время было зафиксировано около 700 ГБ сетевых журналов, которые затем загрузили в базу для анализа.
Чтобы понять, насколько наблюдения отражают всю сеть, параллельно был запущен краулер уровня Beacon. Он использовал протокол обнаружения узлов (discv5) и проходил по одноранговой таблице, извлекая ENR-записи – своеобразные визитные карточки узлов. Краулер ежедневно фиксировал около 16,5 тыс. уникальных IP-адресов, а за три дня в общей сложности – свыше 20 тыс. Примерно половина из них оказалась доступной для подключения, и именно с этими узлами Rainbow поддерживал достаточно долгие сеансы, чтобы проводить анализ.
Главный инструмент анализа – эвристика, отделяющая собственные аттестации пира от ретранслированных. Смысл в том, что если узел передает слишком много сообщений, не относящихся к его обязательным подсетям, это указывает на наличие валидатора. Чтобы исключить ложные срабатывания, применялось несколько условий: узел не должен быть подписан на все 64 подсети; наблюдатель должен получать не менее 10% ожидаемых аттестаций; и число аттестаций должно заметно выделяться среди среднего потока. Пороговые значения выбраны консервативно, чтобы минимизировать риск ошибок.
Результаты оказались показательными. С четырех узлов за три дня удалось привязать к IP-адресам более 235 тыс. валидаторов – примерно четверть всего их числа в сети на тот момент. После исключения сервисных ретрансляторов, чьи данные нельзя трактовать однозначно, осталось более 154 тыс. уникальных соответствий, то есть свыше 15% всей сети. Небольшая доля валидаторов (около 10%) наблюдалась через несколько IP-адресов, что объясняется практикой крупных операторов запускать дублирующие узлы для отказоустойчивости.
Для проверки достоверности использовалось перекрестное сопоставление: если один и тот же пир был подключен к нескольким Rainbow-узлам, совпадали ли наборы валидаторов? В 95,8% случаев совпадение было полным, а средний уровень пересечения составил 99%. Это подтвердило, что методика воспроизводима и устойчива к шуму.
Любопытные выводы дал и географический аспект. Большая часть деанонимизированных валидаторов оказалась размещена у облачных провайдеров, однако швейцарский узел, который работал не в облаке, сумел выявить значительную долю валидаторов именно в дата-центрах Amazon. Это показывает, что наблюдатель не обязан находиться внутри того же облака, чтобы видеть концентрацию. Иными словами, эффект деанонимизации связан не с конкретной площадкой или клиентом, а с фундаментальными особенностями протокола распространения аттестаций.
В целом эксперимент был построен с расчетом на минимальное вмешательство в протокол, статистический консерватизм и географическую диверсификацию. Именно эта комбинация позволила убедительно показать: анонимность валидаторов в Ethereum не абсолютна и зависит от деталей сетевой реализации. При текущих параметрах достаточно нескольких дней пассивных наблюдений, чтобы вскрыть значимую часть реальной топологии сети.
Возможные атаки
Полученная информация открывает возможность целого ряда атак. Наиболее очевидной является целевой DoS против валидатора, которому назначено предложить блок. Поскольку распределение ролей известно заранее, атакующему достаточно на короткий промежуток времени (около четырех секунд) нарушить соединение жертвы, чтобы блок оказался не предложен. В этом случае следующая очередь переходит к другому валидатору, который может извлечь максимальное вознаграждение, включая дополнительную прибыль от манипуляций с порядком транзакций (так называемое MEV).
Более масштабные атаки могут быть направлены на подрыв финализации блоков. Если одновременно вывести из строя значительное число узлов-валидаторов, механизм консенсуса не сможет собрать кворум, необходимый для подтверждения состояния блокчейна. Это приведет к задержкам и нестабильности, а в крайних случаях – к остановке сети.
Наконец, выявленные зависимости между пулами стейкинга и операторами создают угрозу системного характера. В случае сбоя у крупного облачного провайдера или конкретного оператора одновременно может оказаться недоступной критическая доля валидаторов.
Важно подчеркнуть, что исследование не использовало скрытых или недокументированных возможностей протокола. Методика базировалась исключительно на пассивном наблюдении за потоками аттестаций и на особенностях реализации GossipSub. Таким образом, атака может быть воспроизведена любым участником сети без значительных ресурсов.
Возможные меры защиты
Авторы исследования предложили несколько способов, которые могут затруднить деанонимизацию валидаторов и повысить устойчивость сети. Все они связаны с изменением того, как узлы участвуют в передаче аттестаций и взаимодействуют друг с другом.
Один из простых приемов – увеличить число подсетей, на которые по умолчанию подписывается узел. Сейчас большинство клиентов работает только с двумя, что делает картину предсказуемой и позволяет отличить собственные сообщения от ретранслированных. Если бы узлы были подписаны на большее количество подсетей, различать эти два типа сообщений стало бы значительно труднее. Минус в том, что с ростом числа подписок возрастает и нагрузка на сеть, что противоречит самой идее оптимизации.
Другой вариант – развести роли валидатора по разным узлам. Сейчас один и тот же клиент может и предлагать блоки, и рассылать аттестации. Если эти функции разнести – например, один узел будет заниматься аттестациями, а другой только предложением блоков, – атакующему станет сложнее деанонимизировать и вовремя отключить нужного участника.
Отдельный класс мер связан с использованием распределенной валидации (DVT). В этой модели приватный ключ валидатора разбивается на части и хранится на нескольких клиентах. Подпись формируется совместно, даже если часть клиентов временно недоступна. Такая схема делает DoS-атаку на одного узла бессмысленной: чтобы вывести валидатора из игры, придется атаковать сразу несколько точек.
Есть и более радикальные идеи. Например, протоколы "тайного выбора лидера" позволяют скрывать личность того, кто должен предложить блок, вплоть до самого момента публикации. Это резко снижает риск целевых атак, потому что злоумышленник просто не знает заранее, кто будет следующим. Пока эти протоколы остаются в стадии разработки, но именно их называют наиболее перспективным направлением.
Наконец, можно использовать приватные пиринговые соглашения между доверенными узлами. В таком случае аттестации передаются внутри ограниченного круга, и снаружи уже не видно, какой конкретно валидатор стоит за сообщением. Это повышает анонимность, но имеет и свои издержки: чем меньше открытых связей, тем выше риск централизации и зависимости от небольшого числа партнеров.
Все эти меры имеют одну общую особенность: они усложняют жизнь атакующему, но одновременно повышают требования к ресурсам и администрированию. Чем больше избыточности и защитных механизмов закладывается, тем выше нагрузка на сеть и тем труднее одиночным операторам поддерживать валидаторов. Это, кстати, создает любопытный парадокс: борьба за анонимность и безопасность влечет риск обратного процесса – усиления централизации.
Заключение
Рассмотренный эксперимент показал, что даже в системах, построенных на криптографически безупречных принципах, уязвимости могут возникнуть на уровне сетевых оптимизаций. Децентрализация, задекларированная в протоколе, на практике оказывается ограниченной зависимостью от крупных провайдеров и операторов. Анонимность валидаторов – не абсолютная, и при достаточно длительном наблюдении их можно связать с конкретными IP-адресами.
Полученные результаты поднимают более общий вопрос: насколько устойчивыми являются современные децентрализованные архитектуры к пассивному наблюдателю и статистическому анализу? Иными словами, уязвимость Ethereum – это не только проблема конкретной блокчейн-сети, но и показатель того, как скрытая централизация и сетевые закономерности способны подорвать предполагаемую анонимность и равноправие участников.