Исследователи разработчика Ethereum-клиента Nethermind опубликовали бенчмарк, изучающий, насколько может вырасти бюджет валидации, определяемый параметром MAX_VERIFY_GAS в EIP-8141, прежде чем узлы Ethereum окажутся подвержены DoS-атакам на мемпул. Главный вывод исследования: защита на уровне клиента — приостановка валидации мемпула во время обработки блока — это то, что отличает жизнеспособный лимит в 300 000 газа от конфигурации, исчерпывающей ресурсы узла под постоянным атакующим потоком.

Что призван ограничить бюджет валидации EIP-8141

EIP-8141 — это черновик основного предложения (Draft Standards Track Core) под названием «Frame Transaction». Согласно заявленной цели, предложение добавляет уровень абстракции фрейма для валидации, исполнения и оплаты газа транзакций, позволяя транзакциям нести пользовательскую логику валидации до их допуска в мемпул и последующего включения в блок. Текст предложения доступен в репозитории EIP Ethereum. Мемпул — это очередь, в которой узлы хранят прошедшие валидацию транзакции в ожидании включения в блок, поэтому именно вычисления на этапе допуска являются центральным объектом обсуждаемой здесь проблемы DoS.

Бюджет валидации — определяемый параметром MAX_VERIFY_GAS — задаёт объём вычислений, который узел должен выполнить для допуска одной frame-транзакции. При 100 000 газа на транзакцию текущий черновой лимит слишком низок для реальных сценариев использования: одиночная приватная транзакция Groth16 требует 211 828 газа на валидацию, а варианты подписи SPHINCS+ — до 276 000 газа. Следовательно, лимит должен вырасти, чтобы стать практичным, но каждое повышение расширяет поверхность атаки для противников, готовых наводнять узлы дорогими невалидными транзакциями.

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

EIP-8141 остаётся черновым предложением и не активирован ни в одной действующей сети Ethereum. Результаты бенчмарка — это исследовательский вклад в обсуждение дизайна, а не описание развёрнутой конфигурации.

Как бенчмарк измеряет подверженность мемпула DoS-рискам

Исследователи Nethermind наводнили невалидными транзакциями узел Nethermind с одним ядром на трёх машинах разной производительности, тестируя лимиты MAX_VERIFY_GAS от 100 000 до 500 000 газа. Ключевой метрикой было то, удерживает ли накладная нагрузка валидации задержку импорта блоков в пределах бюджета 25 мс — порога, ниже которого обычная обработка блоков считается незатронутой параллельной нагрузкой мемпула. Полный отчёт опубликован на форуме Ethereum Research.

Без защиты на стороне клиента результаты были ограничивающими. На самом медленном профиле полной ноды узел удерживался в бюджете задержки импорта 25 мс лишь при примерно 15 миллионах газа валидации в секунду. При потоке из 100 невалидных транзакций в секунду этот потолок пропускной способности оставлял в рамках бюджета только лимит в 100 000 газа — то есть любое повышение лимита, открывающее возможность реальной криптографической валидации, создавало бы и жизнеспособный вектор DoS-атаки на оборудовании, типичном для домашних операторов узлов.

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

Механизм защиты и его остаточная стоимость

Предложенная защита в клиенте проста: приостановить валидацию мемпула, пока узел обрабатывает входящий блок. Это разделяет две рабочие нагрузки, конкурирующие за одно ядро CPU, не позволяя потоку валидации съедать временной бюджет, необходимый для импорта блоков. При активной защите, по данным бенчмарка, задержка импорта упала примерно до 2 мс и менее на каждой протестированной машине, позволяя лимиту в 300 000 газа при потоке в 100 транзакций в секунду оставаться в рамках бюджета обработки блоков 25 мс. У Nethermind есть открытый pull request, реализующий такое приоритизирующее поведение.

Механизм приостановки решает проблему импорта блоков, но не решает проблему справедливости допуска. При потоке в 100 транзакций в секунду и лимите в 300 000 газа самая медленная протестированная машина приняла лишь 12% честных frame-транзакций. Когда узел приостанавливает валидацию для обработки блоков, атакующий поток заполняет очередь валидации в промежутках, и честные транзакции вытесняются. Бюджет обработки блоков в 25 мс сохраняется, но полезность мемпула для легитимных отправителей frame-транзакций резко деградирует под постоянным атакующим давлением.

Этот коллапс допуска структурно схож с динамикой спама в мемпуле, затрагивавшей Ethereum в периоды дорогих минтов NFT или активности арбитражных ботов. Однако EIP-8141 делает атаку дешевле в поддержании: противнику нужно лишь генерировать транзакции, доходящие до валидации, а не транзакции, включаемые в цепочку. Поскольку транзакции не проходят валидацию, они не несут для атакующего затрат на включение сверх газа, потреблённого на каждую валидацию — то есть именно того ресурса, который протокол пытается ограничить.

Что результаты могут значить для клиентов Ethereum и операторов узлов

Бенчмарк обозначает реалистичный путь к лимиту в 300 000 газа — достаточно высокого для приватных транзакций Groth16, но не для самых дорогих вариантов SPHINCS+ — при условии, что каждый крупный Ethereum-клиент реализует защиту с приоритетом обработки блоков. Это требование координации, а не правило протокола: сам EIP не предписывает поведение клиента, а лишь задаёт потолок газа. Если меньшинство узлов выйдет без этой защиты, такие узлы станут непропорциональными целями при атаке. Эта нагрузка по координации усиливается мультиклиентской архитектурой Ethereum, где несколько независимых команд поддерживают ПО узлов, а поведение всей сети зависит от того, что каждая реализация提供 эквивалентные protections.

Для операторов узлов на оборудовании из нижней части протестированного диапазона — одноядерной машины с ограниченной пропускной способностью памяти — результат в 12% допущенных честных транзакций при потоке означает, что frame-транзакции могут стать фактически ненадёжными в периоды атакующей перегрузки, даже на полностью обновлённом клиенте. Это наиболее важно для приложений, зависящих от быстрого допуска в мемпул, таких как чувствительные ко времени приватные потоки транзакций или протоколы координации пороговых подписей. Разработчикам протоколов поверх EIP-8141 следует учитывать условия атакующего мемпула в допущениях о живучести — подобно тому, как DeFi-протоколы вроде Aave рассматривают риск задержки ликвидаций как функцию загруженности сети, а не константу.

Бенчмарк не признаёт лимиты выше 300 000 газа жизнеспособными при текущем дизайне защиты и потоке в 100 невалидных транзакций в секунду. Достижение потолка в 500 000 газа — который позволил бы поддержать самые тяжёлые варианты SPHINCS+ — потребовало бы более жёсткого ограничения скорости на уровне распространения транзакций, спам-фильтрации на основе стейкинга или предположения о более низком базовом уровне потока. Каждый из этих вариантов влечёт дополнительную сложность протокола и межклиентскую координацию сверх того, что определено текущим черновиком EIP-8141.

Статус черновика и открытые вопросы

EIP-8141 всё ещё имеет статус черновика, и результаты бенчмарка напрямую питают текущую дискуссию о параметрах, не разрешая её. По процессу EIP предложения на стадии Draft проходят ещё Review и Last Call, прежде чем достичь статуса Final, что оставляет такие параметры, как MAX_VERIFY_GAS, открытыми для пересмотра на основе именно такого рода исследовательских данных. Разработчикам клиентов и авторам EIP предстоит взвесить стоимость допуска честных транзакций при лимите в 300 000 газа против криптографических сценариев, требующих больших бюджетов, и определить, достаточно ли защиты с приоритетом обработки блоков как самостоятельной меры или в основное предложение следует добавить дополнительные механизмы защиты от спама.

Цифра в 12% допуска на самой медленной машине, вероятно, станет фокусом этой дискуссии: протокол, допускающий менее одной из восьми честных транзакций при умеренном потоке, предлагает заметно более слабые гарантии живучести, чем текущий мемпул, даже если сама финализация блоков не затронута. Тема на форуме Ethereum Research и открытый pull request Nethermind — два задокументированных места, где эта оценка будет продолжаться.