ТЭ , запланированный для активации на , является следующим крупным обновлением сети Ethereum после Pectra, и это означает еще один масштабирующий шаг, предпринятый криптовалютным гигантом. Фусака Hard Fork December 3, 2025 Фусака Hard Fork Повышение эффективности, эффективности и эффективности системы управления персоналом, системы управления персоналом ( ) makes data availability more efficient by letting nodes verify blobs without downloading everything. Several upgrades tighten execution safety, including limits on ModExp ( , ограничение на транзакционные газы ( , а также обновленная стоимость газа ModExp ( Кроме того, ультрафиолетовый диоксид способствует повышению концентрации глюкозы в крови ( ) and keeps blob fees stable with bounds tied to execution costs ( Дополнительные усовершенствования включают ограничение размера блоков в формате RLP ( , добавляя новый опкод CLZ для более быстрых битных операций ( , и вводить secp256r1 предварительный компилятор ( Для лучшей совместимости с современными ключами безопасности криптографии и аппаратного обеспечения. EIP-7594 EIP-7823 EIP-7825 EIP-7883 EIP-7917 EIP-7918 EIP-7934 EIP-7939 EIP-7951 Точно так же, как Пектра объединил «Прагу» и «Электру», Фусака является объединенным именем и . It represents Ethereum’s next leap toward a highly scalable, data-rich future where Layer 2 rollups can operate cheaper and faster. Fulu (execution layer) Osaka (consensus layer) В этом блоге мы разберем основные особенности жесткого форка Fusaka, объясним, как PeerDAS работает на практике, и пройдем через реальные требования к сети для домашних стакеров, сверхнодов и полных узлов — поддерживаемых данными devnet. Key Changes Introduced In Fusaka Hard Fork Key Changes Introduced In Fusaka Hard Fork : PeerDAS - Peer Data Availability Sampling EIP-7594 ЭИП-7594 Ethereum нуждался в этом предложении, потому что сеть хочет обеспечить больше доступности данных для пользователей и особенно для роллов, но с текущим Каждый узел по-прежнему должен загружать слишком много Blob-данных, чтобы проверить, действительно ли они были опубликованы. Это создает проблему масштабирования, потому что если все узлы должны загружать все, то требования к пропускной способности и аппаратному обеспечению сети повышаются, а децентрализация может пострадать. Чтобы исправить это, Ethereum нуждается в способе для узлов, чтобы подтвердить, что данные доступны, не загружая все это. Data Availability Sampling (DAS) решает это, позволяя узлам проверять только небольшие случайные куски данных. Но Ethereum также нуждается в методе DAS, который хорошо сочетается с существующей сетью слухов и не добавляет тяжелых вычислений к производителям блоков. PeerDAS был создан, чтобы удовлетворить EIP-4844 PeerDAS - это сетевая система, которая позволяет узлам загружать только небольшие кусочки Blob-данных, чтобы проверить, что полные данные были на самом деле опубликованы. Вместо того чтобы загружать все, узлы используют обычную сеть для обмена данными, обнаружить, какие сверстники хранят определенные части, и запросить только небольшие образцы, которые им нужны. Основная идея заключается в том, что, загружая только небольшие, случайные части Blob, узлы все еще могут быть уверены, что весь Blob существует. Чтобы сделать выборку работы, PeerDAS расширяет каждый блок из Используя один из основных типов кодирования. — аналогично тому, как вы можете закончить головоломку, даже если несколько частей потеряны. Блоб становится «сводом», который содержит первоначальные данные плюс некоторые дополнительные кодированные данные, которые позволяют его перестроить позже. Этот ряд затем разделяется на много небольших частей, называемых клетками, которые являются самыми маленькими проверенными единицами, связанными с обязательством KZG. Все строки затем реорганизуются в «колоны», где каждая колонка содержит клетку в том же положении с каждого ряда. Каждая колонка присваивается конкретной подсети. Узлы отвечают за хранение определенных колонк на основе их идентификатора узла и за выборку нескольких колонк из каждого слота. Если узел собирает по крайней мере EIP-4844 Erasure coding is a technique that adds extra redundant data so that the original data can be recovered even if some pieces are missing Кроме того, в ЕИП вводится важное правило: Этот предел должен применяться во время проверки транзакций, слухов, создания блоков и обработки блоков.Это помогает уменьшить экстремальные случаи, когда одна транзакция перегружает систему блоков. no transaction can contain more than 6 blobs PeerDAS добавляет что-то называемое Доказательство KZG ячейки показывает, что обязательство KZG действительно соответствует одной конкретной ячейке (одному маленькому кусочку) блока. Это позволяет узлу загружать только те ячейки, которые он хочет пробовать, вместо полного блока, гарантируя при этом целостность данных. cell KZG proofs But generating all these cell proofs is expensive. A block producer would need to compute them again and again for many blobs, which is too slow. Proof verification, however, is very cheap. So the EIP requires генерировать все клеточные доказательства заранее и включать их в транзакционную оболочку. the blob transaction sender Из-за этого транзакционная шутка (PooledTransactions) теперь использует модифицированную оболочку: rlp([tx_payload_body, wrapper_version, blobs, commitments, cell_proofs]) Inside the new wrapper, is just a list that contains every proof for every cell of every blob (for example: В остальных областях — , , and — они точно такие же, как в EIP-4844.Разница в том, что старое поле «доказательств» удаляется и заменяется этим новым список, и новое поле под названием добавляется, чтобы показать, какой формат оболочки используется. cell_proofs [cell_proof_0, cell_proof_1, ...] tx_payload_body blobs commitments cell_proofs wrapper_version ТЭ является одним байтом, и в этом предложении всегда устанавливается • The field contains all of the cell proofs for each blob, including the proofs for the extra extension cells created during erasure coding. Because of the erasure coding, each blob corresponds to cell proofs. Even though the list contains proofs for the extension cells, the blobs themselves are still sent in their normal (non-extended) form. A blob only includes its original half—the receiving node can compute the extension half on its own, so there’s no need to send unnecessary data. wrapper_version 1 cell_proofs CELLS_PER_EXT_BLOB More formally, является доказательством j-й ячейки i-го блоба после запуска , который производит как оригинальные, так и расширительные клетки. cell_proofs[i * CELLS_PER_EXT_BLOB + j] compute_cells(blobs[i]) Когда узел получает эту оболочку, он должен подтвердить транзакцию и проверить, что все правильно. он должен проверить, что количество версионных хеш, блобов и обязательств все совпадают. он также должен подтвердить, что contains exactly proofs. Every commitment must hash to its matching versioned hash ( ). Finally, the node must check that each commitment actually matches the blob and its proofs. To do this, it computes the extension cells locally using , а затем проверяет все доказательства клеток — проверка партий позволяет сделать это быстрее. cell_proofs CELLS_PER_EXT_BLOB * number_of_blobs kzg_to_versioned_hash(commitments[i]) == tx_payload_body.blob_versioned_hashes[i] compute_cells : Представьте, что блоб разделен на после удаления кода ( Оригинальный блок содержит , и получающий узел будет вычислять отсутствующие itself. But the sender must include В . Example 8 cells CELLS_PER_EXT_BLOB = 8 4 cells 4 extension cells all 8 proofs cell_proofs So for 1 blob, the transaction wrapper contains: blobs = [blob_0] (только оригинальные 4 ячейки) commitments = [commitment_0] cell_proofs = [proof_0, proof_1, ..., proof_7] (доказательство для каждой из 8 ячеек) When a node samples, it might request only cell 2 or cell 5, and it can verify them instantly using the matching proofs, without ever downloading the full blob. PeerDAS позволяет Ethereum увеличить доступность данных, не затрудняя работу узлов. В будущем это может даже снизиться до , что позволило бы Ethereum масштабировать больше. Система работает хорошо, потому что каждый узел имеет много сверстников. Так что если один сверстник не дает необходимых данных, узел может просто попросить другого сверстника. Это создает естественную избыточность и улучшает безопасность. данные, чем требуется, что еще больше укрепляет сеть — даже без каких-либо изменений протокола. 1/8 of the total blob data 1/16 or 1/32 more Валидаторы имеют немного больше ответственности, чем обычные полные узлы. Поскольку валидаторы уже работают более мощным оборудованием, PeerDAS дает им нагрузку на хранение данных, которая соответствует общему количеству валидаторов. Это гарантирует, что стабильная группа узлов всегда доступна для хранения и обмена большей информацией, что делает сеть более надежной. Короче говоря, если есть 900 000 валидаторов, каждому валидатору может быть присвоена крошечная часть общих данных blob для хранения и обслуживания. Поскольку валидаторы имеют лучшие машины, сеть может доверять им, чтобы держать эти данные доступными. Пьера использует Если узлы пробовали полные строки (целые блоки), им нужно было бы создать дополнительные «блобы расширения», которые естественно не существуют, что замедлило бы производителей блоков. Imagine a blob is a 4×4 grid of cells. Row sampling would mean taking all 4 cells from one row, but some extension rows aren’t ready yet, so the block producer would have to generate them on the spot. Column sampling means taking one cell from each row (a column). The extra cells needed for reconstruction can be prepared ahead of time, so nodes can verify the data without slowing down block production. column sampling Example: works fully with , so it doesn’t break anything already on Ethereum. All tests and detailed rules are in the consensus and execution specs. EIP-7594 EIP-4844 The main security risk in any DAS system is a “data withholding attack,” where a block producer pretends that data is available but actually hides some of it. PeerDAS prevents this by using random sampling: nodes check random parts of the data. The more nodes that are sampled, the harder it is for an attacker to cheat. The EIP even provides a formula to calculate how likely such an attack could succeed, based on the total number of nodes (n), total samples (m), and samples per node (k). On the Ethereum mainnet, with about 10,000 nodes, the chance of a successful attack is extremely small, so PeerDAS is considered safe. Таблица показывает, что шансы на успешную атаку падают до незначительного уровня, поэтому PeerDAS считается безопасным против атак, удерживающих данные. . blog : Set upper bounds for MODEXP EIP-7823 EIP-7823 Это предложение необходимо, потому что текущий прекомпилятор MODEXP в Ethereum вызвал много ошибок консенсуса на протяжении многих лет. Большинство этих ошибок произошло, потому что MODEXP позволяет чрезвычайно большие и нереалистичные размеры ввода, что создает бесконечные, необычные случаи, с которыми клиенты должны иметь дело. Поскольку каждый узел должен обрабатывать любой ввод, который предоставляет транзакция, не имея верхнего предела делает MODEXP сложнее тестировать, легче нарушать, и более вероятно, чтобы вести себя по-разному между различными клиентами. Очень большие входы также делают формулу затрат на газ трудно предсказать, потому что это трудно оценить что-то, когда ее размер может расти без ограничения. Эти проблемы также затрудняют замену MODEXP с буду EIP-7823 introduces a simple rule: all three length fields used by MODEXP—the size of the BASE, the EXPONENT, and the MODULUS—must be , что составляет 1024 байта. Входы MODEXP следуют формату Как определено в , so this EIP only restricts the length values. If any length exceeds 1024 bytes, the precompile immediately stops, returns an error, and burns all gas. For example, if someone tries to provide a BASE that is 2000 bytes long, the call will fail before any work happens. These limits still support all real use cases. RSA verification typically uses key sizes like 1024, 2048, or 4096 bits, all well within the new limit. Elliptic curve operations use even smaller sizes, often under 384 bits, so they are also unaffected. 8192 bits or less <len(BASE)> <len(EXPONENT)> <len(MODULUS)> <BASE> <EXPONENT> <MODULUS> EIP-198 Эти новые ограничения также помогают в будущих обновлениях.Если MODEXP когда-либо переписывается в EVM-коде с использованием EVMMAX, разработчики могли бы добавить оптимизированные пути для общих размеров ввода, таких как 256 битов, 381 битов или 2048 битов, и использовать более медленное падение для более редких случаев.С фиксированными максимальными размерами, разработчики могут даже добавить специальное управление для очень общих значений модуля.Ничто из этого не было реалистичным до этого, потому что неограниченные размеры ввода делали пространство дизайна слишком большим для безопасного управления. Чтобы подтвердить, что это изменение не нарушит прошлых транзакций, авторы проанализировали все использование MODEXP от блока 5,472,266 (20 апреля 2018 года) до блока 21,550,926 (4 января 2025 года). Большинство реальных вызовов использовали небольшие длины, такие как 32 байта, 128 байта или 256 байта. Было несколько недействительных или сломанных вызовов, таких как пустые входы, входы, заполненные повторяющимися байтами, такие как , и один чрезвычайно большой, но недействительный ввод.Эти будут вести себя одинаково под новыми ограничениями, потому что они уже были недействительными.Так, хотя EIP технически является переломным изменением, на практике он не изменил бы исход какой-либо прошлой транзакции. 513 bytes 0x9e5faafc С точки зрения безопасности, уменьшение разрешенных размеров ввода не создает новых рисков. Вместо этого он устраняет ненужные экстремальные случаи, которые ранее вызывали ошибки и несоответствия между клиентами. Ограничив входы MODEXP до реалистичных размеров, этот EIP делает систему более предсказуемой, уменьшает странные случаи угла и снижает вероятность ошибок между различными реализациями. Эти ограничения также помогают подготовить систему к более плавному переходу, если будущие обновления, такие как EVMMAX, вводят оптимизированные пути исполнения. : Transaction Gas Limit Cap EIP-7825 ЕГЭ 7825 Это создает несколько проблем: одна транзакция может потреблять большую часть ресурсов блока и вызвать замедление в стиле DoS, большие газовые операции могут слишком быстро увеличить состояние Ethereum, а валидация блоков становится медленнее и труднее для узлов. Если один пользователь подает огромную транзакцию, которая использует почти весь газ (например, транзакция, которая потребляет 38 миллионов газа в 40 млн-газовом блоке), то другие нормальные транзакции не могут вписываться в блок, и каждый узел должен тратить дополнительное время на проверку этого блока. Это угрожает стабильности сети и децентрализации, потому что более медленная верификация означает более слабые узлы. EIP-7825 introduces a hard rule that no transaction can use more than . This becomes a protocol-level cap, meaning it applies everywhere: when a user sends a transaction, when the txpool checks it, and when validators include it in a block. If someone sends a transaction with a gasLimit higher than this number, the client must reject it immediately with an error such as Например, даже если предел газа блока составляет 40 миллионов, ни одна транзакция не может использовать более 16,7 миллионов газа. 16,777,216 gas (2²⁴) MAX_GAS_LIMIT_EXCEDED ВЫШЕ MAX_GAS_LIMIT_EXCEEDED To understand this better, imagine a block has space for 40 million gas. Without this cap, someone could send a single transaction that consumes 35–40 million gas. That transaction would monopolize the block and leave no room for others, similar to one person renting out an entire bus so no one else can board. With the new 16.7M limit, the block will naturally hold multiple transactions and avoid this kind of abuse. Предложение также добавляет конкретные требования к тому, как клиенты проверяют транзакции. txpool должен отклонить транзакцию, если ее gasLimit превышает 16,777,216, что означает, что такая транзакция никогда не входит в очередь. Во время блок-валификации, если блок содержит транзакцию, которая превышает лимит, сам блок должен быть отклонен. Внутри, реализация клиента будет ограничивать параметр GAS_LIMIT для всех транзакций при этом значении. Номер was chosen because it is a clean power-of-two boundary, making it easier to implement, and it is still large enough to handle most real-world transactions such as smart contract deployments, complex DeFi interactions, or multi-step contract calls. This value is roughly half of the typical block size, meaning even the most complex transactions should still fit comfortably within this limit. 16,777,216 (2²⁴) Этот EIP также поддерживает совместимость с текущей газовой механикой. Большинство пользователей никогда не заметят изменения, потому что почти все существующие транзакции уже потребляют гораздо меньше 16 миллионов газа. Валидаторы и строители блоков по-прежнему могут создавать блоки, которые превышают 16,7 миллиона общих газов, при условии, что каждая отдельная транзакция соблюдает новую границу. Единственные затрагиваемые транзакции являются чрезвычайно большими, которые ранее пытались использовать больше, чем новый лимит. С точки зрения безопасности, газовое покрытие делает Ethereum более устойчивым к атакам DoS на основе газа, потому что злоумышленники больше не могут заставить валидаторов обрабатывать чрезвычайно большие транзакции. Это также помогает держать сроки проверки блоков предсказуемыми, чтобы узлы могли оставаться в синхронизации более легко. Overall, EIP-7825 is designed to strengthen the network against abuse, keep node requirements reasonable, improve fairness in block space usage, and ensure the chain remains fast and stable as gas limits continue to increase over time. : ModExp Gas Cost Increase EIP-7883 ИП-7883 The reason Ethereum needs this proposal is that the ModExp precompile (used for modular exponentiation) has been В некоторых ситуациях операции ModExp требуют гораздо большего вычисления, чем то, за что в настоящее время платят пользователи.Это несоответствие создает риск: если сложные звонки ModExp остаются слишком дешевыми, они могут стать Чтобы исправить это, Ethereum должен скорректировать формулу ценообразования ModExp так, чтобы используемый газ правильно отражал реальную работу клиента.Это почему EIP-7883 вводит новые правила, которые повышают минимальную стоимость, повышают общую стоимость и делают операции с большими входами (особенно экспонентами, базой или модулем свыше 32 байтов) дороже, поэтому ценообразование газа соответствует истинному расчету. underpriced bottleneck This proposal modifies the ModExp pricing algorithm originally defined in EIP-2565 by increasing the cost in several important ways. First, the с 200 до 500, а общая формула больше не делится на 3, то есть общая стоимость фактически становится . For example, if a ModExp call previously cost 1,200 gas, it will now cost around 3,600 gas under the new formula. Second, the cost of operations with is doubled by increasing the multiplier from 8 to 16. To illustrate this: if the exponent length was 40 bytes, EIP-2565 would add to the iteration count, while EIP-7883 now uses , making it twice as expensive. Third, the pricing now assumes a В случае, если размер модуля превышает 32 байта, в новом правиле применяется удвоенная сложность ( Вместе эти изменения гарантируют, что малые операции ModExp платят справедливую минимальную плату, а большие, тяжелые операции масштабируют свои затраты должным образом с размером. minimum gas cost three times higher exponents larger than 32 bytes 8 × (40 − 32) = 64 16 × (40 − 32) = 128 minimum base/modulus size of 32 bytes 2 × words² Предложение определяет новую функцию вычисления газов, которая обновляет правила сложности и повторения.Сложность умножения теперь использует стандартное значение 16 для длины базы/модуля до 32 байтов, а для больших входов переходит на более тяжелую формулу , where “words” is the number of 8-byte chunks. The iteration count is also updated so that exponents of 32 bytes or smaller use their bit length to determine complexity, but exponents larger than 32 bytes add a much larger penalty. This ensures that very large exponents, which are computationally expensive in practice, now have a much higher gas cost. Importantly, the minimum returned gas cost is enforced as 500 instead of the earlier 200, making even the simplest ModExp calls more realistically priced. 2 × words² Мотивация, лежащая в основе этих повышений цен, исходит из показателей, показывающих много ситуаций, когда прекомпиляция ModExp была значительно недооценена. Типичные операции вокруг , and very large or unbalanced operations by much larger factors—sometimes more than Цель состоит не в том, чтобы изменить то, как работает ModExp, а в том, чтобы убедиться, что даже в самых ресурсоемких случаях он больше не угрожает стабильности сети или предотвращает будущие увеличения до границы блока газа. , но перерасчет газа произошел много раз раньше в Ethereum и хорошо известен. 150% 200% 80× backward-incompatible Test results show how significant the increases can be. About теперь будет стоить либо 500 газа (вверх от 200) или в три раза их прежняя цена. но некоторые тяжелые испытательные случаи видят огромные увеличения. Например, в одном «exp-тяжелом» тесте стоимость скачется с 215 газа до 16 624 газа — примерно В другом случае, связанном с базовой тяжелой операцией, стоимость идет от 1,026 до 94,448 газа, что отражает, как масштабируется умножение больших чисел на самом деле. 99.69% of historical ModExp calls 76× more В плане безопасности, это предложение не создает новых векторов атаки или делает любую операцию дешевле. Вместо этого, он фокусируется на предотвращении важного риска: недооцененные операции ModExp могли бы позволить злоумышленникам заполнить блоки чрезвычайно тяжелыми вычислениями за очень низкую стоимость. Единственный возможный недостаток заключается в том, что некоторые операции ModExp могут теперь стать завышенными, но это считается гораздо лучшим результатом, чем текущая проблема недооценивания. Test Case EIP-2565 Pricing EIP-7883 Pricing Increase modexp_nagydani_1_square 200 500 150% modexp_nagydani_1_qube 200 500 150% modexp_nagydani_1_pow0x10001 341 2048 501% modexp_nagydani_2_square 200 512 156% modexp_nagydani_2_qube 200 512 156% modexp_nagydani_2_pow0x10001 1365 8192 501% modexp_nagydani_3_square 341 2048 501% modexp_nagydani_3_qube 341 2048 501% modexp_nagydani_3_pow0x10001 5461 32768 500% modexp_nagydani_4_square 1365 8192 501% modexp_nagydani_4_qube 1365 8192 501% modexp_nagydani_4_pow0x10001 21845 131072 500% modexp_nagydani_5_square 5461 32768 500% modexp_nagydani_5_qube 5461 32768 500% modexp_nagydani_5_pow0x10001 87381 524288 500% modexp_marius_1_even 2057 45296 2102% modexp_guido_1_even 2298 51136 2125% modexp_guido_2_even 2300 51152 2124% modexp_guido_3_even 5400 32400 500% modexp_guido_4_even 1026 94448 9105% modexp_marcin_1_base_heavy 200 1152 476% modexp_marcin_1_exp_heavy 215 16624 7632% modexp_marcin_1_balanced 200 1200 500% modexp_marcin_2_base_heavy 867 5202 500% modexp_marcin_2_exp_heavy 852 16368 1821% modexp_marcin_2_balanced 996 5978 500% modexp_marcin_3_base_heavy 677 2032 200% modexp_marcin_3_exp_heavy 765 4080 433% modexp_marcin_3_balanced 1360 4080 200% modexp_универсал_1_квадрат 200 500 150% modexp_универсал_1_куба 200 500 150 % Модификация modexp_nagydani_1_pow0x10001 341 2048 501% modexp_nagydani_2_square 200 512 156 % modexp_nagydani_2_qube 200 512 156 % Модификация modexp_nagydani_2_pow0x10001 1365 8192 501% modexp_nagydani_3_square 341 2048 501% modexp_nagydani_3_qube 341 2048 501% Модификация: modexp_nagydani_3_pow0x10001 5461 32768 500% modexp_nagydani_4_square 1365 8192 501 % modexp_nagydani_4_qube 1365 8192 501% modexp_nagydani_4_pow0x10001 21845 131072 500 процентов modexp_универсал_5_квадрат 5461 32768 500 процентов modexp_nagydani_5_qube 5461 32768 500 процентов Модификация modexp_nagydani_5_pow0x10001 87381 524288 500% modexp_marius_1_even 2057 45296 2102% modexp_guido_1_even 2298 51136 2125 процентов modexp_guido_2_even 2300 51152 2124% modexp_guido_3_ещё 5400 32400 500% modexp_guido_4_even 1026 94448 9105 % modexp_marcin_1_base_heavy 200 1152 476 % modexp_marcin_1_exp_heavy 215 16624 7632% modexp_marcin_1_balanced 200 1200 500 процентов modexp_marcin_2_base_тяжелый 867 5202 500% modexp_marcin_2_exp_heavy 852 16368 1821 % modexp_marcin_2_balanced 996 5978 500% modexp_marcin_3_base_тяжелый 677 2032 200% modexp_marcin_3_exp_heavy 765 4080 433% modexp_marcin_3 сбалансированный 1360 4080 200% *source: https://eips.ethereum.org/EIPS/eip-7883#test-cases* : Determine proposer lookahead EIP-7917 ИП-7917 Ethereum needed this proposal because the network’s proposer schedule for the next epoch was not fully predictable. Even though the RANDAO seed for epoch is known during epoch , the actual proposer list could still change due to effective balance (EB) updates happening inside epoch . These EB changes can come from slashings, penalties, rewards above 1 ETH, validator consolidations, or new deposits—especially after EIP-7251 raised the maximum effective balance beyond 32 ETH. This uncertainty creates issues for systems that rely on knowing the next proposer in advance, such as based preconfirmation protocols, which need a stable and predictable schedule to operate smoothly. A validator could even try to “grind” or manipulate their effective balance to influence who becomes the proposer next epoch. Because of these problems, Ethereum needed a way to make the proposer schedule fully deterministic several epochs ahead so it cannot be changed by last-minute EB updates and can be easily accessed by the application layer. N+1 N N To implement this, the EIP introduces a deterministic proposer lookahead by pre-computing and storing the proposer schedule for the next MIN_SEED_LOOKAHEAD + 1 epochs at the start of every epoch. In simple terms, the beacon state now contains a list called that always covers two full epochs of proposers - 64 slots in total. For example, when epoch N begins, this list already includes the proposer for every slot in epoch N and epoch N+1. Then, when the network moves to epoch N+1, the list is shifted forward: the proposer entries for epoch N are removed, the entries for epoch N+1 move to the front, and new proposer entries for epoch N+2 are added at the end. This makes the schedule fixed, predictable, and easy for clients to read directly, instead of recomputing proposers every slot. proposer_lookahead To keep this updated, the list shifts forward at every epoch boundary: the data for the past epoch is removed, and a new set of proposer indices for the next future epoch is computed and appended. The process uses the same seed and effective balance rules as before, but now the schedule is calculated earlier, removing the possibility of EB changes affecting it after the seed is known. The very first block after the fork also fills this entire lookahead range so that all future epochs have properly initialized schedules. Imagine each epoch has 8 slots instead of 32 (just for simplicity). Without this EIP, during epoch 5, you know the seed for epoch 6, but the actual proposer for slot 2 of epoch 6 could still change if a validator gets slashed or earns enough rewards to change their effective balance inside epoch 5. With EIP-7917, at the Ethereum предварительно рассчитывает все предложения для эпох 5, 6 и 7 и хранит их в порядке внутри . Now, even if balances change later in epoch 5, the proposer list for epoch 6 stays fixed and predictable. старт proposer_lookahead Этот EIP фиксирует долгосрочный надзор в дизайне цепочки маяков. Он гарантирует, что как только RANDAO из более ранних эпох становится доступным, выбор валидатора для будущих эпох не может быть изменен. Это также предотвращает «эффективное измельчение баланса», где валидатор пытается скорректировать свой баланс после того, как увидел RANDAO, чтобы повлиять на список предложений следующей эпохи. С детерминистическим взглядом весь вектор атаки устраняется, что делает анализ безопасности намного проще. Это также дает клиентам раннюю видимость консенсуса о том, кто будет предлагать предстоящие блоки, что помогает реализации и позволяет графику предложений легко проверить слоем приложения через доказательство Merkle из корня маяка. The authors considered alternatives, such as caching the effective balances at the start of an epoch, but that would require extra storage and would not expose the schedule to the EVM. They also checked compatibility with future features like Single Secret Leader Election (SSLE). The current design remains compatible because the lookahead could one day store encrypted proposer IDs, or possibly be disabled entirely if SSLE removes lookahead, without breaking anything. До этого предложения клиенты рассчитывали только предложение для текущего слота. С EIP-7917 они теперь рассчитывают список предложений для всех слотов в следующую эпоху сразу во время каждого перехода эпохи. Это добавляет небольшое количество работы, но вычисление индексов предложений очень легко и в основном включает выборку списков валидаторов с использованием семян. This EIP does not change how the RANDAO delay works. The proposer lookahead for epoch is still derived from the RANDAO of epoch . The only change is that effective balances are now aligned with the same delay, so validators cannot modify their EB after seeing the RANDAO result. This removes a potential manipulation strategy, even though no attack had been discovered yet. The deterministic lookahead therefore, strengthens security and prevents malicious alteration of proposer schedules. N N − MIN_SEED_LOOKAHEAD − 1 : Blob base fee bounded by execution cost EIP-7918 EIP-7918 Ethereum needs this proposal because the current blob fee system (from В настоящее время большинство роллов платят гораздо больше за исполнение газа (стоимость включения их транзакции в блок), чем они платят за фактическую плату за плату за плату за плату за плату. Это создает проблему: даже если Ethereum продолжает снижать плату за плату за плату за плату снова и снова, общая стоимость платы за плату не меняется, потому что дорогая часть все еще является платой за плату. Из-за этого плату за плату за плату за плату за плату продолжает падать, пока она не достигнет абсолютного минимума (1 wei), и протокол больше не может использовать плату за плату за плату для контроля спроса. EIP-4844 Например, представьте, что сборочная компания хочет опубликовать свои данные: она платит около 25 000 000 вей в исполнении газа (25 вей за газ для примерно 1 000 000 газа), в то время как плата за блоб составляет только около 200 вей. Это означает, что общая стоимость составляет примерно 25 000 200 вей, где почти вся стоимость происходит от исполнения газа, а не от платы за блоб. Если Ethereum продолжает снижать плату за блоб — скажем, от 200 вей до 50 вей, затем до 10 вей, а затем до 1 вей — общая стоимость едва меняется вообще, оставаясь почти точно 25 000 000 вей. Поскольку пользователи не чувствуют никакой разницы, они не меняют свое поведение, поэтому протокол продолжает толкать платы за блоб, пока они не достигнут fixes this by introducing a minimum “reserve price” for blob fees that depends on the execution base fee, preventing blob prices from falling unrealistically low and keeping blob pricing much more stable and predictable for rollups. ИП-7918 Основная идея EIP-7918 проста: цена блоба никогда не должна быть дешевле, чем стоимость определенного количества газа для исполнения (так называемого ). In the EIP, this constant is set to . The mechanism works through a small change inside the функция. Обычно эта функция увеличивает или уменьшает базовую плату за блок в зависимости от того, используют ли блоки больше или меньше блокбазового газа, чем цель. С этим предложением, если блок становится «слишком дешевым» по сравнению с газом исполнения, функция прекращает вычитать целевой блокбазовый газ. Это делает избыток блокбазового газа расти быстрее, что предотвращает дальнейшее падение блокбазового сбора. . BLOB_BASE_COST 2¹³ calc_excess_blob_gas() BLOB_BASE_COST × base_fee_per_gas ÷ GAS_PER_BLOB To understand why this is needed, it helps to look at blob demand. A rollup cares about the total price it pays: execution cost plus blob cost. If execution gas fee is very high—for example, 20 gwei—then even if the blob fee drops from 2 gwei to 0.2 gwei, the total cost barely changes. This means reducing the blob base fee has almost no impact on demand. In economics, this is called “ .” It creates a situation where the demand curve is almost vertical: lowering price does not increase demand. When this happens, the blob base fee mechanism becomes blind—it keeps lowering the price even though demand does not react. That is why the blob base fee often slides down to 1 wei. Then, when real demand increases later, the protocol needs an hour or more of nearly full blocks to raise the fee back up to a reasonable level. EIP-7918 fixes this by establishing a reserve price tied to execution gas so that blob fees remain meaningful even when execution costs dominate. fee inelasticity Another reason for adding this reserve price is that nodes have to do a lot of extra work to verify the KZG proofs for blob data. These proofs are what guarantee that the data inside a blob actually matches its commitment. Under , a node only had to verify one proof per blob, which was cheap. But with (PeerDAS), blobs are broken into many small pieces called cells, and every cell has its own proof. This makes verification much heavier. For example, the execution layer now has to batch-verify 128 proofs for every single blob before a transaction can even enter the mempool—this is about fifteen times more expensive than the normal KZG proof verification that smart contracts pay for. On top of that, full nodes, supernodes, and validators must verify even more proofs depending on how many columns they store or sample. A typical full node must verify proofs for all blobs in the mempool, plus eight sampled columns every slot, plus four columns it permanently custodies. All of this uses real CPU time, and it isn’t free for node operators. If blob fees drop too low, users would get this expensive compute work from the network essentially for free. By linking the blob reserve price to execution gas fees, EIP-7918 makes sure blob users always pay at least a fair minimum amount for the load they put on nodes. EIP-4844 EIP-7594 In the long run, EIP-7918 also helps prepare Ethereum for the future. As technology improves, the cost of storing and sharing data naturally gets cheaper, and Ethereum is expected to allow more blob data over time. When blob capacity increases, blob fees (in ETH) should naturally go down. This proposal supports that because the reserve price is tied to execution gas prices, not a fixed number, so it can adjust as the network grows. As both blobspace and execution blockspace expand, their price relationship stays balanced. The only time the reserve price might become too high is in a very unlikely future where Ethereum increases blob capacity a lot but does not increase execution gas capacity. In that case, blob fees might end up higher than needed. But Ethereum is not planning to scale in that way—both blobspace and execution blockspace are expected to grow together. Because of this, the chosen value ( ) is considered safe and well-balanced. BLOB_BASE_COST = 2¹³ There is one small detail to understand when execution gas fees suddenly jump. Because the blob reserve price depends on the execution base fee, a sudden rise in execution costs can temporarily push blob fees into a state where execution fees are guiding them. For example, imagine execution gas suddenly jumps from 20 gwei to 60 gwei in one block. Since the reserve price for blobs is tied to that number, blob fees cannot drop below the new higher level. Blob fees will still increase normally if blobs are being used, but the protocol will not allow them to decrease until they have risen enough to match the higher execution cost. This means blob fees may climb more slowly than execution fees for a few blocks. This small delay is not harmful — it actually prevents sharp, sudden swings in blob prices and keeps the system smoother and more stable. The authors also performed empirical analysis by applying the reserve price rule to real blob activity from and . During high-execution-fee periods (around ), the reserve threshold significantly increased the blob base fee compared to the old mechanism. During low-execution-fee periods (around ), the blob fee remained almost unchanged except when the calculated blob base fee dropped below the reserve price. By comparing thousands of blocks, the authors show that the new mechanism creates more stable pricing while still responding naturally to demand. A histogram of four months of blob fees shows that the reserve price prevents blob fees from collapsing toward 1 wei, which reduces extreme volatility. November 2024 March 2025 16 gwei average 1.3 gwei average С точки зрения безопасности, изменение не влечет за собой никаких рисков. Базовая плата блоба всегда будет рассчитываться в размере или выше стоимости units of execution gas. This is safe because the mechanism only raises the minimum fee, and setting a lower bound on pricing does not interfere with protocol correctness. It simply ensures healthy economics. BLOB_BASE_COST : RLP Execution Block Size Limit EIP-7934 EIP-7934 До EIP-7934, Ethereum сделал have a strict upper limit on how large an RLP-encoded execution block could be. In theory, a block could become extremely large if it contained many transactions or very complex data. This created two major problems: and . If a block was too large, it would take longer for nodes to download and verify it, which slowed block propagation and increased the chance of temporary blockchain forks. Worse, an attacker could deliberately create a very large block to overload nodes, causing delays or even knocking them offline — a classic denial-of-service scenario. At the same time, Ethereum’s consensus layer (CL) gossip protocol already refused to propagate any block over , meaning oversized execution blocks could fail to spread across the network, creating fragmentation or nodes disagreeing on the chain. Because of these risks, Ethereum needed a clear, protocol-level rule to prevent oversized blocks and keep the network stable and secure. not network instability DoS attack risks 10 MB EIP-7934 solves this by introducing a Максимально допустимый размер блока ( ) is set to , but because beacon blocks also consume some space ( Ethereum добавляет A Это означает, что фактический максимальный размер блоки исполнения, кодированного RLP, разрешен. . If the encoded block is larger than this limit, the block is considered and nodes must reject it. With this rule in place, block producers must check the encoded size of every block they build, and validators must verify this limit during block validation. This size cap applies газовых лимитов – то есть даже если блок Он все еще может быть отклонен, если его кодированный размер слишком большой.Это обеспечивает соблюдение как использования газа, так и реальных ограничений по размеру байт. protocol-level cap MAX_BLOCK_SIZE 10 MiB (10,485,760 bytes) SAFETY_MARGIN 2 MiB (2,097,152 bytes) MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE - SAFETY_MARGIN invalid independently under the gas limit, Выбираем а Это было преднамеренно, потому что оно соответствует существующему ограничению в протоколе шутки слоя консенсуса. Все, что больше 10 МиБ, в любом случае не будет транслироваться по сети, поэтому этот EIP приводит слой исполнения в соответствие с границами слоя консенсуса. Это создает последовательность во всех компонентах и предотвращает ситуации, когда действительный блок исполнения становится «невидимым», потому что CL отказывается его шутить. 10 MiB cap This change is with blocks larger than the new limit, meaning miners and validators must update their clients to respect the rule. However, since oversized blocks were already problematic and not normal in real operation, the impact is minimal. In terms of security, this EIP significantly strengthens Ethereum against targeted block-size DoS attacks by ensuring no participant can create blocks that overwhelm the network. Overall, EIP-7934 adds an important safety boundary, improves stability, aligns EL and CL behavior, and prevents several classes of attacks related to oversized block creation and propagation. not backward-compatible : Count leading zeros (CLZ) opcode EIP-7939 EIP-7939 До этого EIP Ethereum имел to count the number of leading zero bits in a 256-bit number. Developers had to implement CLZ manually in Solidity using many bit-shift operations and comparisons. This was a big problem because the custom implementations were , and Для систем, доказывающих нулевое знание, стоимость была еще выше — правильные сдвиги чрезвычайно дороги для доказательства, поэтому операции, такие как CLZ, значительно замедлили циклы ZK. Поскольку CLZ является очень распространенной функцией низкого уровня, используемой в математических библиотеках, алгоритмах сжатия, битовых картах, схемах подписи и многих криптографических или задачах обработки данных, Ethereum нуждался в более быстром и дешевом способе его вычисления. no built-in opcode slow, expensive used a lot of bytecode EIP-7939 решает этот вопрос путем введения . This opcode takes a 256-bit value from the stack and returns the number of leading zero bits. If the input number is zero, the opcode returns , because a 256-bit zero has 256 leading zero bits. This matches how CLZ works in many CPU architectures like ARM and x86, where this operation is native. Adding CLZ makes many algorithms significantly cheaper: operations like , , , various math functions, byte-string comparisons, bitmap scanning, calldata compression/decompression, and post-quantum signature schemes all benefit from faster leading-zero detection. new opcode called CLZ (0x1e) 256 lnWad powWad LambertW , similar to an , and slightly raised from the old MUL price to avoid underpricing the opcode and causing DoS risks. Benchmarks show that CLZ uses roughly the same compute effort as ADD, and in the SP1 rv32im proving environment, CLZ is actually , reducing ZK proving costs. The EIP also explains why they chose CLZ instead of : you can compute CTZ from CLZ using , but you reliably implement CLZ using CTZ, so CLZ is more fundamental. The gas cost for CLZ is set to 5 ADD cheaper to prove than ADD CTZ (count trailing zeros) x & -x cannot Настоящая МСФО полностью совместима с обратной связью, поскольку она вводит opcode and does not modify any existing behavior. It also covers edge cases clearly: for example, the opcode returns 256 when the input is zero, and several test cases show inputs like all-zero, top-bit-set, and fully-nonzero values. Since CLZ has predictable and low gas cost, no memory growth, and no state changes, it is safe from denial-of-service issues. new Overall, EIP-7939 makes Ethereum faster, cheaper, and more developer-friendly by adding a simple, efficient primitive that modern CPUs already support — cutting gas, reducing bytecode size, and lowering ZK proving costs for many common operations. : Precompile for secp256r1 Curve Support EIP-7951 EIP-7951 Before this EIP, Ethereum did иметь безопасный, естественный способ проверки цифровых подписей, созданных с помощью . This curve is the standard used in modern devices like Из-за этой отсутствующей поддержки приложения и кошельки не могли легко использовать защиту аппаратного обеспечения на уровне устройства для подписания. связанные с обработкой точки до бесконечности и неправильным сравнением подписей. Эти проблемы могут вызвать неправильную проверку или даже риски сбоев консенсуса. not secp256r1 (P-256) curve Apple Secure Enclave, Android Keystore, HSMs, TEEs, and FIDO2/WebAuthn security keys two serious security vulnerabilities EIP-7951 fixes those security problems and introduces a safe, native precompile so Ethereum can finally support signatures from modern hardware securely and efficiently. EIP-7951 adds a new по адресу called , which performs ECDSA signature verification using the secp256r1 curve. This makes signature verification fast and cheap compared to implementing the algorithm directly in Solidity. The precompile uses the official curve parameters defined by NIST, including the field modulus, curve equation, base point, and subgroup order, ensuring strong cryptographic security. Points and scalars are encoded in strict 32-byte big-endian format, and a 64-byte all-zero value is used to represent the point at infinity. The precompile expects exactly — хаш, подпись (r, s) и координаты публичного ключа (qx, qy) — и он возвращает for success or for failure. precompiled contract 0x100 P256VERIFY 160 bytes of input 32 bytes of 1 empty output Кроме того, ЕАЭС строго . It checks that r and s are within valid ranges, that the public key lies on the curve, and that it is not the point at infinity. If anything is invalid, the precompile returns failure without reverting and consumes the same gas as a successful call. The verification algorithm follows standard ECDSA: it computes s⁻¹ mod n, rebuilds the signing point R’, rejects if R’ is infinity, and finally checks whether the x-coordinate of R’ matches r (mod n). This corrects the mistake in RIP-7212, which compared r’ directly instead of reducing it mod n. input validation rules The secp256r1 curve is fully defined by the following set of parameters: Base field modulus = p = 0xffffffff00000001000000000000000000000000ffffffffffffffffffffffff Curve equation: y^2 = x^3 + ax + b (mod p) Curve coefficient a = 0xffffffff00000001000000000000000000000000fffffffffffffffffffffffc Curve coefficient b = 0x5ac635d8aa3a93e7b3ebbd55769886bc651d06b0cc53b0f63bce3c3e27d2604b Base point G: Gx = 0x6b17d1f2e12c4247f8bce6e563a440f277037d812deb33a0f4a13945d898c296 Gy = 0x4fe342e2fe1a7f9b8ee7eb4a7c0f9e162bce33576b315ececbb6406837bf51f5 Subgroup order = n = 0xffffffff00000000ffffffffffffffffbce6faada7179e84f3b9cac2fc632551 Cofactor = h = 0x1 Эти параметры стандартизированы NIST в SP 800-1861. The gas cost for the operation is set to , which is higher than the RIP-7212 version, but matches actual performance benchmarks for secp256r1 verification. Importantly, the interface remains fully compatible with Layer 2 networks that already deployed RIP-7212—same address, same input/output format—so existing smart contracts will continue to work with no changes. The only difference is the corrected behavior and higher gas cost. 6900 gas Input: P256VERIFY call excepts 160 Bytes as input that is interpreted as byte concatenation of: 32 bytes ----> message hash (h) 32 bytes ----> signature component (r) 32 bytes ----> signature component (s) 32 bytes ----> public key x-coordinate (qx) 32 bytes ----> public key y-coordinate (qy) Output: will be 32 bytes on successfull verification and 0 bytes on failure Input Validation: The precompile MUST perform the following validation checks and return `` (failure) if any check fails: 1. Input length: Input MUST be exactly 160 bytes 2. Signature component bounds: Both r and s MUST satisfy 0 < r < n and 0 < s < n 3. Public key bounds: Both qx and qy MUST satisfy 0 ≤ qx < p and 0 ≤ qy < p 4. Point validity: The point (qx, qy) MUST satisfy the curve equation qy^2 ≡ qx^3 + a*qx + b (mod p) 5. Point not at infinity: The point (qx, qy) MUST NOT be the point at infinity (represented as (0, 0)) С точки зрения безопасности, EIP восстанавливает правильное поведение ECDSA, устраняет опасения по поводу моделируемости на уровне предварительной компиляции (оставляя дополнительные проверки для приложений) и уточняет, что постоянное время исполнения не требуется для предварительной компиляции. кривая secp256r1 обеспечивает 128-битовую безопасность и широко доверяется и анализируется, что делает ее безопасной для принятия Ethereum. In short, , fix the security issues of the earlier proposal, and provide a reliable, standardized way to verify P-256 signatures across the entire ecosystem. EIP-7951 is needed to safely bring modern hardware-backed authentication to Ethereum Ниже приведенная таблица обобщает, какие клиенты Ethereum должны внедрять изменения для каждого Fusaka EIP. указывает, что EIP требует обновлений для клиентов консенсусного уровня, в то время как отметка ниже shows that the change affects execution-layer clients. Some EIPs require updates in both layers, while others are specific to just one. Consensus Client Execution Client EIP Number EIP Name Consensus Client Execution Client EIP-7594 PeerDAS - Peer Data Availability Sampling ✅ ✅ EIP-7823 Set upper bounds for MODEXP ✅ EIP-7825 Transaction Gas Limit Cap ✅ EIP-7883 ModExp Gas Cost Increase ✅ EIP-7917 Deterministic proposer lookahead ✅ EIP-7918 Blob base fee bounded by execution cost ✅ EIP-7934 RLP Execution Block Size Limit ✅ EIP-7939 Count leading zeros (CLZ) opcode ✅ EIP-7951 Precompile for secp256r1 Curve Support ✅ EIP-7594 PeerDAS - Peer Data Availability Sampling ✅ ✅ EIP-7823 Set upper bounds for MODEXP ✅ EIP-7825 Transaction Gas Limit Cap ✅ ИП-7883 ModExp Gas Cost Increase ✅ ИП-7917 Детерминистские предложения Lookahead ✅ ИП-7918 Blob base fee bounded by execution cost ✅ ИП-7934 RLP Execution Block Size Limit ✅ EIP-7939 Count leading zeros (CLZ) опкод ✅ ИП-7951 Precompile for secp256r1 Curve Support ✅ В резюме, это ключевые EIP, включенные в жесткий форк Fusaka.Хотя несколько улучшений касаются как консенсуса, так и клиентов исполнения — начиная от корректировок газа и обновлений опкода до новых предварительных компиляций — , который вводит выборку доступности peer-to-peer данных, что позволяет более эффективно и децентрализованно обрабатывать blob-данные по всей сети. major change of this upgrade is PeerDAS
