После Pectra пришёл Fusaka: самый важный шаг Ethereum к «бесконечному масштабированию»

Хардфорк Fusaka, запланированный к активации 3 декабря 2025 года, станет очередным крупным обновлением сети Ethereum после Pectra и ознаменует новый важный шаг этого криптогиганта к масштабированию.

EIP обновления Pectra сосредоточены на повышении производительности, безопасности и инструментов для разработчиков. EIP обновления Fusaka делают акцент на масштабировании, обновлении опкодов и безопасности исполнения.

PeerDAS (EIP-7594) повышает доступность данных, позволяя узлам верифицировать Blob без необходимости скачивать все данные. Несколько обновлений также усиливают безопасность исполнения, включая ограничение ModExp (EIP-7823), ограничение лимита Gas для транзакций (EIP-7825), а также обновление стоимости Gas для ModExp (EIP-7883). Обновление Fusaka также улучшает генерацию блоков с помощью механизма детерминированного предсказания предложителя (EIP-7917) и поддерживает стабильность стоимости Blob за счет установки "резервной цены", привязанной к стоимости исполнения (EIP-7918).

Другие улучшения включают ограничение размера блока в формате RLP (EIP-7934), добавление нового опкода CLZ для ускорения битовых операций (EIP-7939), а также внедрение предварительной компиляции secp256r1 (EIP-7951) для лучшей совместимости с современной криптографией и аппаратными ключами безопасности.

Fusaka — это комбинация Fulu (исполнительный уровень) и Osaka (уровень консенсуса). Это очередной шаг Ethereum к высокомасштабируемому и насыщенному данными будущему, в котором Layer 2 Rollup смогут работать быстрее и дешевле.

В этой статье подробно разбираются 9 ключевых EIP-х Fusaka hard fork.

EIP-7594: PeerDAS — выборочная доступность данных для узлов

Ethereum нуждается в этом предложении, поскольку сеть стремится обеспечить пользователям (особенно пользователям Rollup) более высокую доступность данных.

Однако в текущем дизайне EIP-4844 каждый узел всё ещё должен скачивать большой объем данных blob, чтобы проверить, были ли они опубликованы. Это создает проблемы масштабируемости, поскольку если все узлы обязаны скачивать все данные, требования к пропускной способности и аппаратному обеспечению сети возрастают, а уровень децентрализации снижается. Для решения этой проблемы Ethereum необходим способ, позволяющий узлам удостоверяться в доступности данных без необходимости скачивать их полностью.

Выборочная доступность данных (DAS) решает эту задачу, позволяя узлам проверять лишь небольшое случайное количество данных.

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

PeerDAS — это сетевая система, позволяющая узлам скачивать лишь небольшие фрагменты данных для проверки того, что все данные были опубликованы. Узлам не нужно скачивать все данные, они используют обычную gossip-сеть для обмена данными, определяют, какие узлы хранят определённые части данных, и запрашивают только необходимые небольшие выборки. Основная идея — скачивая лишь случайные небольшие части данных, узлы всё равно могут быть уверены в наличии всего фрагмента. Например, узел может скачать только около 1/8 данных вместо полного 256 КБ блока — но поскольку многие узлы берут разные части, любые пропущенные данные быстро обнаруживаются.

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

Blob превращается в "строку", содержащую исходные данные и дополнительный код, чтобы впоследствии можно было восстановить данные. Затем эта строка разбивается на множество небольших блоков, называемых "ячейками" — минимальными единицами проверки, связанными с KZG-коммитментом. Все "строки" затем реорганизуются в "столбцы", каждый из которых содержит ячейки с одинаковой позицией из всех строк. Каждый столбец закрепляется за определённой gossip-подсетью.

Узел отвечает за хранение определённых столбцов в зависимости от своего ID и в каждом слоте делает выборку некоторых столбцов у пиров. Если узел соберёт хотя бы 50% столбцов, он сможет полностью восстановить данные. Если столбцов меньше 50%, он запрашивает недостающие у пиров. Это гарантирует, что если данные действительно опубликованы, их всегда можно восстановить. Проще говоря, если всего 64 столбца, узлу нужно около 32, чтобы восстановить весь blob. Он хранит часть столбцов сам и скачивает часть у пиров. Пока в сети есть половина столбцов, узел может восстановить всё, даже если некоторые столбцы отсутствуют.

Кроме того, EIP-7594 вводит важное правило: ни одна транзакция не может содержать более 6 blob. Это ограничение должно строго соблюдаться при валидации транзакций, распространении по gossip, создании и обработке блоков. Это помогает снизить риск перегрузки системы blob одной транзакцией.

PeerDAS добавляет функцию, называемую "cell KZG proof". Доказательство cell KZG подтверждает, что KZG-коммитмент действительно соответствует определённой ячейке blob (маленькой части). Это позволяет узлу скачивать только те ячейки, которые он хочет проверить. Получая целостность данных, узел может восстановить весь blob, что критически важно для выборочной доступности данных.

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

Именно поэтому для gossip-транзакций (PooledTransactions) теперь используется модифицированная обёртка:

rlp([tx_payload_body, wrapper_version, blobs, commitments, cell_proofs])

В новой обёртке cell_proofs — это просто список всех доказательств для каждой ячейки каждого blob (например: [cell_proof_0, cell_proof_1, ...]). Остальные поля tx_payload_body, blobs и commitments идентичны EIP-4844. Отличие в том, что старое поле "proofs" удалено и заменено новым списком cell_proofs, а также добавлено поле wrapper_version для указания формата обёртки.

PeerDAS позволяет Ethereum повысить доступность данных без увеличения нагрузки на узлы. Сейчас узлу нужно проверять только около 1/8 всех данных. В будущем эта доля может снизиться до 1/16 или 1/32, что повысит масштабируемость Ethereum. Система работает эффективно, поскольку у каждого узла много пиров, и если один не может предоставить нужные данные, узел может обратиться к другим. Это естественно создает избыточность и повышает безопасность, а узлы могут хранить больше данных, чем требуется, что ещё больше укрепляет сеть.

Валидаторы несут большую ответственность, чем обычные полные узлы. Поскольку валидаторы используют более мощное оборудование, PeerDAS распределяет среди них соответствующую нагрузку по хранению данных в зависимости от их общего количества. Это гарантирует наличие стабильной группы узлов для хранения и распространения больших объёмов данных, повышая надёжность сети. Проще говоря, если есть 900 000 валидаторов, каждому может быть назначена небольшая часть всех данных для хранения и обслуживания. Поскольку валидаторы обладают мощными машинами, сеть может доверять им обеспечение доступности данных.

PeerDAS использует выборку по столбцам, а не по строкам, потому что это значительно упрощает восстановление данных. Если узел делает выборку по строкам (всему blob), необходимо создавать дополнительные "расширенные blob", которых изначально не существует, что замедляет производителей блоков.

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

EIP-7594 полностью совместим с EIP-4844 и не нарушает никакие существующие функции Ethereum. Все тесты и подробные правила включены в спецификации консенсуса и исполнения.

Основной риск безопасности любой DAS-системы — "атака сокрытия данных", когда производитель блока притворяется, что данные доступны, но на самом деле скрывает часть данных. PeerDAS предотвращает это с помощью случайной выборки: узлы проверяют случайные части данных. Чем больше узлов делает выборку, тем сложнее атакующему обмануть систему. EIP-7594 даже предоставляет формулу для расчёта вероятности успешной атаки в зависимости от общего числа узлов (n), общего числа выборок (m) и числа выборок на узел (k). В основной сети Ethereum с примерно 10 000 узлов вероятность успеха атаки крайне мала, поэтому PeerDAS считается безопасным.

EIP-7823: Установка лимита 1024 байта для MODEXP

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

Поскольку каждый узел должен обрабатывать все входные данные транзакции, отсутствие лимита делает MODEXP сложнее для тестирования, более подверженным ошибкам и более вероятным для различного поведения на разных клиентах. Слишком большие входные данные также затрудняют прогнозирование стоимости Gas, поскольку при неограниченном росте данных сложно установить цену. Эти проблемы также затрудняют будущую замену MODEXP на уровне EVM с помощью инструментов типа EVMMAX, поскольку без фиксированных ограничений разработчики не могут создать безопасный и оптимизированный путь исполнения.

Для снижения этих проблем и повышения стабильности Ethereum EIP-7823 вводит строгий лимит на объём входных данных для MODEXP, делая предварительную компиляцию более безопасной, удобной для тестирования и предсказуемой.

EIP-7823 вводит простое правило: все три поля длины, используемые в MODEXP (основание, показатель и модуль), должны быть не больше 8192 бит, то есть 1024 байта. Входные данные MODEXP соответствуют формату, определённому в EIP-198: <len(BASE)> <len(EXPONENT)> <len(MODULUS)> <BASE> <EXPONENT> <MODULUS>, поэтому EIP ограничивает только значения длины. Если любая длина превышает 1024 байта, предварительная компиляция немедленно прекращается, возвращает ошибку и расходует весь Gas.

Например, если кто-то попытается передать основание длиной 2000 байт, вызов завершится неудачей до начала выполнения. Эти ограничения по-прежнему покрывают все реальные сценарии использования. Проверка RSA обычно использует ключи длиной 1024, 2048 или 4096 бит, что укладывается в новый лимит. Операции с эллиптическими кривыми используют ещё меньшие размеры, обычно менее 384 бит, и также не затрагиваются.

Эти новые ограничения также способствуют будущим обновлениям. Если в будущем MODEXP будет переписан на EVM-код с помощью EVMMAX, разработчики смогут добавить оптимизированные пути для часто используемых размеров (например, 256, 381 или 2048 бит) и использовать медленный резервный вариант для редких случаев. Благодаря фиксированному максимальному размеру входных данных можно даже добавить особую обработку для самых популярных модулей. Ранее, из-за отсутствия ограничений, пространство решений было слишком велико и сложно для безопасного управления, поэтому такие улучшения были невозможны.

Чтобы убедиться, что это изменение не нарушит прошлые транзакции, авторы проанализировали все использования MODEXP с блока 5,472,266 (20 апреля 2018) по блок 21,550,926 (4 января 2025). Результаты показали, что ни один успешный вызов MODEXP в истории не использовал входные данные длиннее 513 байт, что значительно меньше нового лимита в 1024 байта. Большинство реальных вызовов использовали ещё меньшие размеры, например 32, 128 или 256 байт.

Существуют некоторые невалидные или повреждённые вызовы, например с пустыми входными данными, заполненными повторяющимися байтами, или с очень большими, но невалидными входными данными. Эти вызовы также останутся невалидными при новом лимите, поскольку они изначально некорректны. Таким образом, хотя EIP-7823 технически является крупным изменением, на практике он не изменит результаты ни одной прошлой транзакции.

С точки зрения безопасности, уменьшение допустимого размера входных данных не создаёт новых рисков. Напротив, оно устраняет ненужные крайние случаи, которые ранее приводили к ошибкам и несогласованности между клиентами. Ограничив входные данные MODEXP разумными размерами, EIP-7823 делает систему более предсказуемой, снижает количество странных крайних случаев и уменьшает вероятность ошибок между разными реализациями. Эти ограничения также помогают подготовиться к будущим обновлениям (например, EVMMAX), если они введут оптимизированные пути исполнения, обеспечивая более плавный переход.

EIP-7825: Лимит Gas для транзакции — 16,7 миллиона

Ethereum действительно нуждается в этом предложении, поскольку сейчас одна транзакция может практически использовать весь лимит Gas блока.

Это вызывает несколько проблем: одна транзакция может потребить большую часть ресурсов блока, вызывая задержки, похожие на DoS-атаки; операции с большим расходом Gas слишком быстро увеличивают обновление состояния Ethereum; скорость проверки блоков снижается, и узлам становится сложно поддерживать актуальность.

Если пользователь отправляет транзакцию, почти полностью расходующую Gas блока (например, в блоке с лимитом 40 миллионов Gas транзакция расходует 38 миллионов), другие обычные транзакции не могут попасть в этот блок, а каждый узел тратит дополнительное время на его проверку. Это угрожает стабильности и децентрализации сети, поскольку замедление проверки означает, что менее производительные узлы будут отставать. Для решения этой проблемы Ethereum необходим безопасный лимит Gas, ограничивающий количество Gas, которое может использовать одна транзакция, чтобы сделать нагрузку на блоки более предсказуемой, снизить риск DoS-атак и сбалансировать нагрузку на узлы.

EIP-7825 вводит жёсткое правило: ни одна транзакция не может расходовать более 16,777,216 (2²⁴) Gas. Это становится лимитом на уровне протокола и применяется на всех этапах: при отправке пользователем, проверке в пуле транзакций и включении валидатором в блок. Если кто-то указывает лимит Gas выше этого значения, клиент должен немедленно отклонить такую транзакцию и вернуть ошибку типа MAX_GAS_LIMIT_EXCEEDED.

Этот лимит полностью независим от лимита Gas блока. Например, даже если лимит блока — 40 миллионов, ни одна транзакция не может расходовать более 16,7 миллиона. Цель — гарантировать, что в каждом блоке будет несколько транзакций, а не одна, занимающая весь блок.

Для лучшего понимания: если блок вмещает 40 миллионов Gas, без этого лимита кто-то может отправить транзакцию на 35–40 миллионов Gas. Такая транзакция монополизирует блок, не оставляя места другим, словно кто-то занял весь автобус, и остальные не могут сесть. Новый лимит в 16,7 миллиона Gas позволит блоку естественно вмещать несколько транзакций и предотвратит подобные злоупотребления.

В предложении также указаны требования к клиентам по проверке транзакций. Если Gas превышает 16,777,216, пул транзакций должен отклонить такую транзакцию, то есть она даже не попадёт в очередь. При проверке блока, если он содержит транзакцию выше лимита, сам блок должен быть отклонён.

Число 16,777,216 (2²⁴) выбрано потому, что это чётная степень двойки, что упрощает реализацию, и оно всё ещё достаточно велико для большинства реальных транзакций. Например, для деплоя смарт-контрактов, сложных DeFi-взаимодействий или многошаговых вызовов контрактов. Это значение примерно вдвое меньше типичного размера блока, что позволяет даже самым сложным транзакциям легко укладываться в лимит.

Этот EIP также сохраняет совместимость с существующим механизмом Gas. Большинство пользователей не заметят изменений, поскольку почти все существующие транзакции расходуют гораздо меньше 16 миллионов Gas. Валидаторы и создатели блоков по-прежнему могут создавать блоки с общим расходом Gas выше 16,7 миллиона, если каждая транзакция соблюдает новый лимит.

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

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

В целом, EIP-7825 направлен на усиление защиты сети от злоупотреблений, сохранение разумных требований к узлам, повышение справедливости использования пространства блока и обеспечение быстрой и стабильной работы блокчейна при увеличении лимита Gas.

EIP-7883: Повышение стоимости Gas для ModExp

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

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

Для решения этой проблемы Ethereum необходимо скорректировать формулу ценообразования ModExp, чтобы расход Gas отражал реальную вычислительную нагрузку клиента. EIP-7883 вводит новые правила, повышая минимальную стоимость Gas, увеличивая общую стоимость Gas и делая операции с большими входными данными (особенно с показателем, основанием или модулем более 32 байт) значительно дороже, чтобы стоимость Gas соответствовала реальным затратам.

Предложение повышает стоимость несколькими способами, изменяя исходный алгоритм ценообразования ModExp из EIP-2565.

Во-первых, минимальный расход Gas увеличен с 200 до 500, а общая стоимость Gas больше не делится на 3, что фактически увеличивает её втрое. Например, если раньше вызов ModExp требовал 1200 Gas, по новой формуле потребуется около 3600 Gas.

Во-вторых, стоимость операций с показателем более 32 байт удваивается: множитель увеличен с 8 до 16. Например, если показатель — 40 байт, EIP-2565 увеличивал число итераций на 8 × (40 − 32) = 64, а EIP-7883 — на 16 × (40 − 32) = 128, то есть вдвое больше.

В-третьих, теперь стоимость рассчитывается исходя из минимального размера основания/модуля в 32 байта, а при превышении этого значения вычислительная сложность резко возрастает. Например, если модуль — 64 байта, новая формула применяет двойную сложность (2 × words²), а не прежнюю простую формулу, что отражает реальные затраты на работу с большими числами. Эти изменения гарантируют, что за небольшие операции ModExp взимается разумная минимальная плата, а за крупные и сложные — адекватная стоимость.

В предложении определена новая функция расчёта Gas, обновлены правила сложности и числа итераций. Сложность умножения теперь для оснований/модулей до 32 байт по умолчанию равна 16, а для больших входных данных применяется формула 2 × words², где "words" — число 8-байтных блоков. Число итераций также обновлено: для показателей до 32 байт используется длина в битах, а для больших показателей применяется более высокая Gas-нагрузка.

Это гарантирует, что операции с очень большими показателями теперь будут стоить значительно дороже. Важно, что минимальная стоимость Gas теперь жёстко установлена на уровне 500, а не 200, что делает даже самые простые вызовы ModExp более справедливыми.

Мотивация повышения цен основана на бенчмарках, показавших, что во многих случаях стоимость ModExp была явно занижена. Обновлённая формула увеличивает стоимость Gas для небольших операций на 150%, для типичных — примерно на 200%, а для крупных или несимметричных — в разы, иногда более чем в 80 раз, в зависимости от размера показателя, основания или модуля.

Цель этого шага — не изменить принцип работы ModExp, а гарантировать, что даже в самых ресурсоёмких случаях он не будет угрожать стабильности сети или мешать будущему увеличению лимита Gas блока. Поскольку EIP-7883 меняет количество Gas, необходимое для ModExp, он несовместим с прошлым, но перерасчёт Gas уже неоднократно происходил в Ethereum и хорошо изучен.

Тесты показывают, что повышение стоимости Gas весьма существенно. Около 99,69% исторических вызовов ModExp теперь требуют либо 500 Gas (ранее 200), либо втрое больше прежней цены. Но для некоторых тестовых случаев с высокой нагрузкой рост стоимости ещё выше. Например, в "интенсивном" тесте по возведению в степень расход Gas вырос с 215 до 16,624 — примерно в 76 раз, потому что теперь стоимость больших показателей стала более справедливой.

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

EIP-7917: Точное предсказание следующего предложителя

Ethereum нуждается в этом предложении, потому что расписание предложителей следующей эпохи в сети невозможно полностью предсказать. Даже если на N-й эпохе известен seed RANDAO для N+1-й эпохи, фактический список предложителей может измениться из-за обновлений эффективного баланса (EB) в течение N-й эпохи.

Эти изменения EB могут быть вызваны штрафами, наказаниями, наградами свыше 1 ETH, объединением валидаторов или новыми депозитами, особенно после EIP-7251, который увеличил максимальный эффективный баланс выше 32 ETH. Такая неопределённость создаёт проблемы для систем, которым нужно заранее знать следующего предложителя (например, для протоколов с предварительным подтверждением), поскольку им требуется стабильное и предсказуемое расписание. Валидаторы даже могут пытаться "накручивать" или манипулировать своим EB, чтобы повлиять на список предложителей следующей эпохи.

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

Для этого EIP-7917 вводит детерминированный механизм предсказания предложителей: в начале каждой эпохи заранее вычисляется и сохраняется расписание предложителей на MIN_SEED_LOOKAHEAD + 1 эпоху вперёд. Проще говоря, состояние Beacon теперь содержит список `prosoperer_lookahead`, который всегда охватывает два полных цикла предложителей (всего 64 слота).

Например, когда начинается эпоха N, список уже содержит предложителей для эпох N и N+1 для каждого слота. Затем, когда сеть переходит к эпохе N+1, список сдвигается: записи эпохи N удаляются, записи эпохи N+1 перемещаются в начало, а в конец добавляются новые записи для эпохи N+2. Это делает расписание фиксированным, предсказуемым и доступным для чтения клиентами без необходимости пересчитывать предложителей для каждого слота.

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

Допустим, в каждой эпохе 8 слотов, а не 32 (для простоты). Без этого EIP в эпоху 5, хотя известен seed для эпохи 6, если валидатор будет оштрафован или получит награду, изменяющую его EB в эпохе 5, фактический предложитель для слота 2 эпохи 6 может измениться. С EIP-7917 Ethereum заранее вычисляет всех предложителей для эпох 5, 6 и 7 и хранит их в `prosopers_lookahead`. Тогда даже если баланс изменится в конце эпохи 5, список предложителей для эпохи 6 останется фиксированным и предсказуемым.

EIP-7917 исправляет давний недостаток дизайна Beacon Chain. Он гарантирует, что после появления seed предыдущей эпохи выбор валидаторов для будущих эпох нельзя изменить. Это также предотвращает "накрутку EB", когда валидатор после просмотра seed пытается изменить свой баланс, чтобы повлиять на список предложителей следующей эпохи. Детерминированный механизм предсказания устраняет этот вектор атаки и упрощает анализ безопасности. Он также позволяет клиентам консенсуса заранее знать, кто будет предлагать следующий блок, что облегчает реализацию и позволяет приложениям легко проверять расписание предложителей через Merkle-доказательства Beacon Root.

До этого предложения клиенты вычисляли предложителя только для текущего слота. С EIP-7917 они теперь вычисляют список предложителей для всех слотов следующей эпохи при каждом переходе эпохи. Это добавляет немного работы, но вычисление индексов предложителей очень лёгкое и в основном сводится к выборке из списка валидаторов по seed. Тем не менее, клиентам стоит провести бенчмарки, чтобы убедиться, что дополнительная нагрузка не вызовет проблем с производительностью.

EIP-7918: Базовая стоимость Blob ограничена стоимостью исполнения

Ethereum нуждается в этом предложении, потому что текущая система стоимости Blob (из EIP-4844) перестаёт работать, когда основная часть расходов Rollup приходится на Gas исполнения.

В настоящее время большинство Rollup платят за Gas исполнения (стоимость включения blob-транзакции в блок) гораздо больше, чем за сам Blob. Это создаёт проблему: даже если Ethereum продолжает снижать базовую стоимость Blob, общие расходы Rollup практически не меняются, поскольку основная часть затрат — это Gas исполнения. В результате базовая стоимость Blob продолжает снижаться до минимального значения (1 wei), после чего протокол больше не может использовать стоимость Blob для управления спросом. Затем, когда использование Blob резко возрастает, требуется много блоков, чтобы стоимость вернулась к нормальному уровню. Это делает цены нестабильными и непредсказуемыми для пользователей.

Например, если Rollup хочет опубликовать свои данные: он должен заплатить около 25,000,000 gwei за Gas исполнения (примерно 1,000,000 Gas по 25 gwei), а стоимость Blob — всего около 200 gwei. Общие расходы — примерно 25,000,200 gwei, из которых почти всё — это Gas исполнения, а не Blob. Если Ethereum продолжит снижать стоимость Blob, например с 200 до 50, потом до 10, и наконец до 1 gwei, общие расходы почти не изменятся и останутся около 25,000,000 gwei.

EIP-7918 решает эту проблему, вводя минимальную "резервную цену" для Blob, основанную на стоимости Gas исполнения, чтобы предотвратить слишком низкие цены на Blob и сделать ценообразование для Rollup более стабильным и предсказуемым.

Основная идея EIP-7918 проста: цена Blob никогда не должна быть ниже определённого количества стоимости Gas исполнения (называемого BLOB_BASE_COST). Значение calc_excess_blob_gas() установлено на 2¹³, и механизм реализуется через небольшое изменение функции calc_excess_blob_gas().

Обычно эта функция увеличивает или уменьшает базовую стоимость Blob в зависимости от того, превышает ли blob gas в блоке целевое значение. Согласно этому предложению, если стоимость Blob становится "слишком низкой" относительно Gas исполнения, функция перестаёт уменьшать целевой blob gas. Это ускоряет рост избыточного blob gas и не позволяет базовой стоимости Blob падать ещё ниже. Таким образом, теперь есть минимальное значение базовой стоимости Blob, равное BLOB_BASE_COST × base_fee_per_gas ÷ GAS_PER_BLOB.

Чтобы понять, зачем это нужно, рассмотрим спрос на Blob. Rollup интересует общая сумма расходов: стоимость исполнения плюс стоимость Blob. Если Gas исполнения очень дорогой, например 20 gwei, то даже если стоимость Blob снизится с 2 до 0,2 gwei, общие расходы почти не изменятся. Это означает, что снижение базовой стоимости Blob практически не влияет на спрос. В экономике это называется "отсутствием эластичности цены". Кривая спроса становится почти вертикальной: снижение цены не увеличивает спрос.

В такой ситуации механизм базовой стоимости Blob становится "слепым" — даже если спрос не реагирует, он продолжает снижать цену. Именно поэтому стоимость Blob часто падает до 1 gwei. Затем, когда спрос возрастает, протоколу требуется час или больше почти полностью заполненных блоков, чтобы вернуть цену к нормальному уровню. EIP-7918 решает эту проблему, устанавливая резервную цену, привязанную к Gas исполнения, чтобы даже при доминировании расходов на исполнение стоимость Blob оставалась значимой.

Ещё одна причина добавить резервную цену — узлы должны выполнять много дополнительной работы для проверки KZG-доказательств данных Blob. Эти доказательства гарантируют соответствие данных Blob их коммитменту. В EIP-4844 узлы проверяют только одно доказательство на Blob, что дёшево. Но в EIP-7918 узлы должны проверять гораздо больше доказательств. Всё это связано с тем, что в EIP-7594 (PeerDAS) blob разбивается на множество ячеек, каждая из которых имеет своё доказательство, что значительно увеличивает объём проверки.

В долгосрочной перспективе EIP-7918 также помогает Ethereum готовиться к будущему. По мере развития технологий стоимость хранения и распространения данных будет снижаться, и Ethereum планирует со временем разрешать хранить больше данных Blob. При увеличении ёмкости Blob их стоимость (в ETH) естественным образом снизится. Это предложение поддерживает такой сценарий, поскольку резервная цена привязана к стоимости Gas исполнения, а не к фиксированному значению, и может корректироваться по мере роста сети.

По мере расширения пространства Blob и пространства исполнения их ценовое соотношение останется сбалансированным. Только в редких случаях, если Ethereum резко увеличит ёмкость Blob, но не увеличит лимит Gas исполнения, резервная цена может оказаться слишком высокой. В этом случае стоимость Blob может превысить реальную потребность. Но Ethereum не планирует расширяться таким образом — пространство Blob и исполнение будут расти синхронно. Поэтому выбранное значение (BLOB_BASE_COST = 2¹³) считается безопасным и сбалансированным.

Когда стоимость Gas исполнения резко возрастает, есть один нюанс. Поскольку цена Blob зависит от базовой стоимости исполнения, резкий скачок стоимости исполнения может временно сделать стоимость Blob зависимой от исполнения. Например, если стоимость Gas исполнения в одном блоке внезапно вырастет с 20 до 60 gwei, цена Blob не сможет опуститься ниже нового уровня. Если Blob продолжает использоваться, его стоимость будет расти как обычно, но протокол не позволит ей снизиться, пока она не догонит новую стоимость исполнения. Это означает, что в течение нескольких блоков рост стоимости Blob может быть медленнее, чем рост стоимости исполнения. Такая кратковременная задержка не опасна — наоборот, она предотвращает резкие скачки цен и делает систему более стабильной.

Авторы также провели эмпирический анализ реальных блоков с ноября 2024 по март 2025, применяя правило резервной цены. В периоды высоких расходов на исполнение (в среднем около 16 gwei) резервный порог значительно увеличивал базовую стоимость блока по сравнению со старым механизмом. В периоды низких расходов (в среднем около 1,3 gwei) стоимость блока почти не менялась, если только вычисленная стоимость не была ниже резервной цены. Сравнив тысячи блоков, авторы показали, что новый механизм обеспечивает более стабильное ценообразование при сохранении естественной реакции на спрос. Гистограмма стоимости блоков за четыре месяца показывает, что резервная цена предотвращает падение стоимости до 1 gwei, снижая экстремальные колебания.

С точки зрения безопасности это изменение не создаёт никаких рисков. Базовая стоимость блока всегда будет равна или выше стоимости Gas исполнения за BLOB_BASE_COST единиц. Это безопасно, поскольку механизм только увеличивает минимальную стоимость, а установка нижнего порога не влияет на корректность протокола. Это просто обеспечивает здоровую экономику.

EIP-7934: Ограничение размера блока RLP для исполнения

До EIP-7934 в Ethereum не было строгого лимита на размер блока исполнения, закодированного в RLP. Теоретически, если блок содержит много транзакций или очень сложные данные, его размер может быть очень большим. Это приводит к двум основным проблемам: нестабильности сети и риску атак типа отказ в обслуживании (DoS).

Если блок слишком велик, узлам требуется больше времени на его скачивание и проверку, что замедляет распространение блока и увеличивает вероятность временных форков. Ещё хуже, злоумышленник может намеренно создать очень большой блок, чтобы перегрузить узлы, вызвать задержки или даже вывести их из строя — типичная DoS-атака. Кроме того, протокол Gossip консенсусного уровня (CL) уже отказывается распространять блоки больше 10 МБ, что означает, что слишком большие блоки исполнения могут не распространяться по сети, вызывая фрагментацию цепи или расхождение между узлами. С учётом этих рисков Ethereum необходим чёткий протокольный лимит, предотвращающий создание слишком больших блоков и обеспечивающий стабильность и безопасность сети.

EIP-7934 решает эту проблему, вводя протокольный лимит на размер блока исполнения в RLP: максимальный размер блока (MAX_BLOCK_SIZE) установлен на 10 MiB (10,485,760 байт), но с учётом того, что блок Beacon также занимает часть пространства (SAFETY_MARGIN), Ethereum добавляет ещё 2 MiB (2,097,152 байта).

Это означает, что фактический максимальный размер блока исполнения в RLP равен MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE - SAFETY_MARGIN. Если закодированный блок превышает этот лимит, он считается невалидным, и узел должен его отклонить. Теперь производители блоков должны проверять размер каждого блока, а валидаторы — проверять лимит при валидации блока. Этот лимит независим от лимита Gas, то есть даже если блок "ниже лимита Gas", но слишком велик по размеру, он будет отклонён. Это гарантирует соблюдение как лимита Gas, так и ограничения по байтам.

Лимит в 10 MiB выбран намеренно, поскольку он совпадает с существующим ограничением в протоколе gossip консенсусного уровня. Любые данные больше 10 MiB не будут распространяться по сети, поэтому этот EIP согласует лимиты исполнения и консенсуса. Это обеспечивает согласованность всех компонентов и предотвращает ситуацию, когда валидный блок исполнения "невидим" из-за отказа CL его распространять.

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

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

EIP-7939: Опкод для подсчёта ведущих нулей (CLZ)

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

Это большая проблема, поскольку такие реализации медленные, дорогие и увеличивают размер байткода, повышая расход Gas. Для систем доказательств с нулевым разглашением (ZK) стоимость ещё выше, поскольку операции сдвига вправо очень дороги для доказательства, и такие функции, как CLZ, значительно замедляют работу ZK-цепей. Поскольку CLZ — очень распространённая низкоуровневая функция, используемая в математических библиотеках, алгоритмах сжатия, битовых массивах, схемах подписей и многих криптографических и обработочных задачах, Ethereum нужен более быстрый и экономичный способ вычисления.

EIP-7939 решает эту проблему, вводя новый опкод CLZ (0x1e). Этот опкод берёт 256-битное значение со стека и возвращает число ведущих нулей. Если входное число равно нулю, опкод возвращает 256, поскольку у 256-битного нуля 256 ведущих нулей.

Это соответствует работе CLZ на многих архитектурах CPU, таких как ARM и x86, где операция CLZ поддерживается на аппаратном уровне. Добавление CLZ значительно снижает издержки многих алгоритмов: lnWad, powWad, LambertW, различные математические функции, сравнение байтовых строк, сканирование битовых карт, сжатие/распаковка calldata и постквантовые схемы подписей выигрывают от более быстрой проверки ведущих нулей.

Стоимость Gas для CLZ установлена на уровне 5, как у ADD, и немного выше, чем у MUL, чтобы избежать заниженной цены и риска DoS-атак. Бенчмарки показывают, что вычислительная нагрузка CLZ сопоставима с ADD, а в среде доказательств SP1 rv32im стоимость доказательства для CLZ даже ниже, чем для ADD, что снижает издержки ZK-доказательств.

EIP-7939 полностью совместим с прошлым, поскольку добавляет новый опкод и не меняет существующее поведение.

В целом, EIP-7939 делает Ethereum быстрее, дешевле и удобнее для разработчиков, добавляя простую и эффективную примитивную операцию, уже поддерживаемую современными CPU — снижая расходы Gas, уменьшая размер байткода и снижая стоимость ZK-доказательств для многих распространённых операций.

EIP-7951: Поддержка подписей современного оборудования

До этого EIP в Ethereum не было безопасного, нативного способа проверки цифровых подписей, созданных на кривой secp256r1 (P-256).

Эта кривая является стандартом для современных устройств, таких как Apple Secure Enclave, Android Keystore, HSM, TEE и аппаратные ключи безопасности FIDO2/WebAuthn. Из-за отсутствия поддержки приложения и кошельки не могли легко использовать аппаратную безопасность для подписей. Ранее была попытка (RIP-7212), но она содержала две серьёзные уязвимости, связанные с обработкой точки на бесконечности и некорректным сравнением подписей. Эти проблемы могли привести к ошибкам проверки или даже к сбоям консенсуса. EIP-7951 устраняет эти уязвимости и вводит безопасную, нативную предварительную компиляцию, позволяя Ethereum наконец-то безопасно и эффективно поддерживать подписи с современного оборудования.

EIP-7951 добавляет новую предварительную компиляцию P256VERIFY по адресу 0x100, которая выполняет проверку подписи ECDSA на кривой secp256r1. Это делает проверку подписей быстрее и дешевле по сравнению с реализацией алгоритма на Solidity.

EIP-7951 также определяет строгие правила проверки входных данных. При любой невалидной ситуации предварительная компиляция возвращает неудачу без отката, а расход Gas такой же, как при успешном вызове. Алгоритм проверки соответствует стандарту ECDSA: вычисляется s⁻¹ mod n, восстанавливается точка подписи R', если R' — точка на бесконечности, подпись отклоняется, затем проверяется, совпадает ли x-координата R' с r (mod n). Это исправляет ошибку RIP-7212, где сравнивалось r', а не r' mod n.

Стоимость Gas для этой операции установлена на уровне 6900, что выше, чем в версии RIP-7212, но соответствует реальным показателям производительности для проверки secp256r1. Важно, что интерфейс полностью совместим с уже внедрённым RIP-7212 на Layer 2 (тот же адрес, тот же формат входа/выхода), поэтому существующие смарт-контракты продолжат работать без изменений. Единственное отличие — исправленное поведение и более высокая стоимость Gas.

С точки зрения безопасности EIP-7951 восстанавливает корректное поведение ECDSA, устраняет проблему пластичности на уровне предварительной компиляции (оставляя дополнительные проверки на усмотрение приложений) и явно указывает, что предварительная компиляция не обязана работать в постоянное время. Кривая secp256r1 обеспечивает 128-битную безопасность и широко признана и проанализирована, поэтому её безопасно использовать в Ethereum.

Вкратце, EIP-7951 призван безопасно внедрить аутентификацию с поддержкой современного оборудования в Ethereum, исправить уязвимости ранних предложений и предоставить надёжный, стандартизированный способ проверки подписей P-256 во всей экосистеме.

Резюме

В таблице ниже показано, какие клиенты Ethereum должны быть обновлены для различных EIP Fusaka. Галочка в столбце клиента консенсуса означает, что EIP требует обновления клиента консенсуса, а галочка в столбце клиента исполнения — что обновление затрагивает клиента исполнения. Некоторые EIP требуют обновления обоих уровней, другие — только одного.

В целом, это ключевые EIP, включённые в хардфорк Fusaka. Хотя обновление затрагивает множество улучшений как для клиентов консенсуса, так и исполнения — от корректировки Gas и обновления опкодов до новых предварительных компиляций — ядром обновления остаётся PeerDAS, который внедряет выборочную доступность данных на уровне peer-to-peer, позволяя более эффективно и децентрализованно обрабатывать данные blob по всей сети.