Перейти к основному содержанию

Последнее обновление страницы: 23 февраля 2026 г.

Fusaka

Долгожданное обновление Ethereum Fusaka было запущено 3 декабря 2025 года

Обновление сети Fusaka следует за обновлением Pectra и привносит больше новых функций, а также улучшает опыт каждого пользователя и разработчика Ethereum. Название состоит из названия обновления уровня исполнения Osaka и версии уровня консенсуса, названной в честь звезды Фулу. Обе части Ethereum получают обновление, которое выводит масштабирование, безопасность и пользовательский опыт Ethereum в будущее.

Улучшения в Fusaka

Масштабирование blob-объектов

PeerDAS

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

Благодаря выборке доступности данных (data availability sampling) (opens in a new tab) вместо хранения всех данных blob-объектов каждый узел будет отвечать за их часть. Blob-объекты равномерно и случайным образом распределяются по узлам сети, при этом каждый полный узел хранит только 1/8 часть данных, что теоретически позволяет масштабироваться до 8 раз. Для обеспечения доступности данных любая их часть может быть восстановлена из любых существующих 50% от целого с помощью методов, которые снижают вероятность неверных или отсутствующих данных до криптографически незначимого уровня (~ от одного из 1020 до одного из 1024).

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

Узнайте больше о PeerDAS

Ресурсы:

Форки, изменяющие только параметры blob-объектов

Решения второго уровня масштабируют Ethereum — по мере роста их сетей им необходимо публиковать больше данных в Ethereum. Это означает, что со временем Ethereum потребуется увеличить количество доступных для них blob-объектов. Хотя PeerDAS позволяет масштабировать данные blob-объектов, это необходимо делать постепенно и безопасно.

Поскольку Ethereum — это код, работающий на тысячах независимых узлов, которым требуется соглашение об одинаковых правилах, мы не можем просто вносить изменения, такие как увеличение количества blob-объектов, так же, как вы развертываете обновление веб-сайта. Любое изменение правил должно быть скоординированным обновлением, при котором программное обеспечение каждого узла, клиента и валидатора обновляется до одного и того же заранее определенного блока.

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

Форки, изменяющие только параметры blob-объектов, могут устанавливаться клиентами, подобно другим конфигурациям, таким как лимит газа. Между крупными обновлениями Ethereum клиенты могут договориться об увеличении целевого и максимального количества blob-объектов, например, до 9 и 12, а затем операторы узлов обновятся, чтобы принять участие в этом небольшом форке. Эти форки, изменяющие только параметры blob-объектов, можно настраивать в любое время.

Когда blob-объекты были впервые добавлены в сеть в обновлении Dencun, целевое значение было равно 3. Это значение было увеличено до 6 в Pectra, а после Fusaka его можно будет увеличивать с устойчивой скоростью независимо от этих крупных обновлений сети.

Диаграмма, показывающая среднее количество blob-объектов на блок и увеличение целевых показателей с обновлениями

Источник графика: Ethereum Blobs — @hildobby, Dune Analytics (opens in a new tab)

Ресурсы: Техническая спецификация EIP-7892 (opens in a new tab)

Базовая комиссия за blob-объекты, ограниченная затратами на исполнение

Решения второго уровня при публикации данных оплачивают два счета: комиссию за blob-объекты и газ за исполнение, необходимый для их проверки. Если газ за исполнение доминирует, аукцион комиссий за blob-объекты может упасть до 1 wei и перестать быть ценовым сигналом.

EIP-7918 устанавливает пропорциональную резервную цену для каждого blob-объекта. Когда резерв выше номинальной базовой комиссии за blob-объект, алгоритм корректировки комиссии рассматривает блок как превышающий целевой показатель, прекращает снижать комиссию и позволяет ей нормально расти. В результате:

  • рынок комиссий за blob-объекты всегда реагирует на перегрузку
  • решения второго уровня оплачивают как минимум значительную часть вычислений, которые они навязывают узлам
  • скачки базовой комиссии на уровне исполнения (EL) больше не могут удерживать комиссию за blob-объекты на уровне 1 wei

Ресурсы:

Масштабирование L1

Истечение срока хранения истории и упрощенные квитанции

В июле 2025 года клиенты исполнения Ethereum начали поддерживать частичное истечение срока хранения истории (opens in a new tab). Это позволило удалить историю, предшествующую Слиянию (The Merge) (opens in a new tab), чтобы уменьшить дисковое пространство, необходимое операторам узлов по мере роста Ethereum.

Этот EIP находится в отдельном разделе от «Основных EIP», потому что форк на самом деле не вносит никаких изменений — это уведомление о том, что команды клиентов должны обеспечить поддержку истечения срока хранения истории к моменту обновления Fusaka. На практике клиенты могут реализовать это в любое время, но добавление этого в обновление конкретно включило его в их список задач и позволило им тестировать изменения Fusaka в сочетании с этой функцией.

Ресурсы: Техническая спецификация EIP-7642 (opens in a new tab)

Установка верхних границ для MODEXP

До сих пор прекомпиляция MODEXP принимала числа практически любого размера. Это затрудняло тестирование, облегчало злоупотребление и создавало риск для стабильности клиентов. EIP-7823 устанавливает четкое ограничение: каждое входное число может иметь длину не более 8192 бит (1024 байта). Все, что больше, отклоняется, газ транзакции сжигается, и никаких изменений состояния не происходит. Это с большим запасом покрывает реальные потребности, устраняя при этом крайние случаи, которые усложняли планирование лимита газа и проверки безопасности. Это изменение обеспечивает большую безопасность и защиту от DoS-атак, не влияя на опыт пользователей или разработчиков.

Ресурсы: Техническая спецификация EIP-7823 (opens in a new tab)

Ограничение лимита газа для транзакций

EIP-7825 (opens in a new tab) добавляет ограничение в 16 777 216 (2^24) единиц газа на транзакцию. Это проактивное усиление защиты от DoS-атак путем ограничения максимальной стоимости любой отдельной транзакции по мере увеличения лимита газа для блока. Это упрощает моделирование валидации и распространения, что позволяет нам решать проблему масштабирования путем повышения лимита газа.

Почему именно 2^24 газа? Это значение значительно меньше сегодняшнего лимита газа, достаточно велико для реального развертывания контрактов и тяжелых прекомпиляций, а степень двойки упрощает реализацию на разных клиентах. Этот новый максимальный размер транзакции сопоставим со средним размером блока до обновления Pectra, что делает его разумным ограничением для любой операции в Ethereum.

Ресурсы: Техническая спецификация EIP-7825 (opens in a new tab)

Увеличение стоимости газа для MODEXP

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

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

Этот EIP изменяет ценообразование, чтобы оно соответствовало реальным вычислительным затратам, путем:

  • повышения минимальной платы с 200 до 500 газа и отмены скидки в одну треть из EIP-2565 при общем расчете стоимости
  • более резкого увеличения стоимости, когда входной показатель степени очень длинный. если показатель степени (число «степени», которое вы передаете в качестве второго аргумента) длиннее 32 байт / 256 бит, плата за газ растет намного быстрее за каждый дополнительный байт
  • взимания дополнительной платы за большое основание или модуль. Предполагается, что два других числа (основание и модуль) имеют длину не менее 32 байт — если одно из них больше, стоимость возрастает пропорционально его размеру

Благодаря лучшему соответствию затрат фактическому времени обработки, MODEXP больше не может приводить к тому, что проверка блока занимает слишком много времени. Это изменение — одно из нескольких, направленных на то, чтобы сделать безопасным увеличение лимита газа для блока Ethereum в будущем.

Ресурсы: Техническая спецификация EIP-7883 (opens in a new tab)

Ограничение размера исполняемого блока RLP

Это создает потолок для размера блока — это ограничение на то, что отправляется по сети, и оно отделено от лимита газа, который ограничивает работу внутри блока. Ограничение размера блока составляет 10 МиБ, с небольшим запасом (2 МиБ), зарезервированным для данных консенсуса, чтобы все помещалось и распространялось без проблем. Если появляется блок большего размера, клиенты его отклоняют. Это необходимо, потому что очень большие блоки дольше распространяются и проверяются по сети и могут создавать проблемы с консенсусом или использоваться как вектор DoS-атаки. Кроме того, протокол gossip на уровне консенсуса уже не пересылает блоки размером более ~10 МиБ, поэтому согласование уровня исполнения с этим ограничением позволяет избежать странных ситуаций, когда «одни видят, а другие отбрасывают».

Суть в том, что это ограничение на размер исполняемого блока, закодированного с помощью RLP. Всего 10 МиБ, с запасом безопасности в 2 МиБ, зарезервированным для обрамления блоков Beacon Chain. На практике клиенты определяют

MAX_BLOCK_SIZE = 10,485,760 байт и

SAFETY_MARGIN = 2,097,152 байт,

и отклоняют любой исполняемый блок, полезная нагрузка RLP которого превышает

MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE − SAFETY_MARGIN

Цель состоит в том, чтобы ограничить время распространения/проверки в худшем случае и согласовать поведение с протоколом gossip на уровне консенсуса, снижая риск реорганизации/DoS-атак без изменения учета газа.

Ресурсы: Техническая спецификация EIP-7934 (opens in a new tab)

Установить лимит газа по умолчанию на 60 миллионов

До повышения лимита газа с 30 до 36 миллионов в феврале 2025 года (и впоследствии до 45 миллионов), это значение не менялось со времен Слияния (сентябрь 2022 года). Этот EIP направлен на то, чтобы сделать последовательное масштабирование приоритетом.

EIP-7935 координирует команды клиентов EL для повышения лимита газа по умолчанию выше сегодняшних 45 миллионов для Fusaka. Это информационный EIP, но он явно просит клиентов тестировать более высокие лимиты в devnets, прийти к безопасному значению и включить это число в свои релизы Fusaka.

Планирование Devnet нацелено на стресс-тестирование с ~60 миллионами (полные блоки с синтетической нагрузкой) и итеративные повышения; исследования показывают, что патологии с размером блока в худшем случае не должны проявляться ниже ~150 миллионов. Развертывание должно сопровождаться ограничением лимита газа для транзакций (EIP-7825), чтобы ни одна отдельная транзакция не могла доминировать по мере роста лимитов.

Ресурсы: Техническая спецификация EIP-7935 (opens in a new tab)

Улучшение UX

Детерминированный просмотр будущих создателей блоков

С EIP-7917 Beacon Chain будет знать о предстоящих создателях блоков на следующую эпоху. Наличие детерминированного представления о том, какие валидаторы будут предлагать будущие блоки, может обеспечить предварительные подтверждения (preconfirmations) (opens in a new tab) — обязательство с будущим создателем блока, которое гарантирует, что транзакция пользователя будет включена в его блок, не дожидаясь фактического блока.

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

Ресурсы: Техническая спецификация EIP-7917 (opens in a new tab)

Опкод подсчета ведущих нулей (CLZ)

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

Ресурсы: Техническая спецификация EIP-7939 (opens in a new tab)

Прекомпиляция для поддержки кривой secp256r1

Вводит встроенную проверку подписи secp256r1 (P-256) в стиле passkey по фиксированному адресу 0x100 с использованием того же формата вызова, который уже принят многими L2, и исправляет крайние случаи, чтобы контракты, написанные для этих сред, работали на L1 без изменений.

Улучшение UX! Для пользователей это открывает возможность использования нативных подписей устройств и passkeys. Кошельки могут напрямую использовать Apple Secure Enclave, Android Keystore, аппаратные модули безопасности (HSM) и FIDO2/WebAuthn — без сид-фразы, с более плавной регистрацией и многофакторными потоками, которые ощущаются как современные приложения. Это приводит к лучшему UX, более простому восстановлению и шаблонам абстракции учетных записей, которые соответствуют тому, что уже делают миллиарды устройств.

Для разработчиков он принимает 160-байтовый ввод и возвращает 32-байтовый вывод, что упрощает перенос существующих библиотек и контрактов L2. Под капотом он включает проверки точки на бесконечности и модульного сравнения, чтобы устранить сложные крайние случаи, не нарушая работу валидных вызывающих сторон.

Ресурсы:

Мета

Метод JSON-RPC eth_config

Это вызов JSON-RPC, который позволяет вам запросить у вашего узла, какие настройки форка вы используете. Он возвращает три снимка: current, next и last, чтобы валидаторы и инструменты мониторинга могли проверить, что клиенты готовы к предстоящему форку.

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

Снимки включают: chainId, forkId, запланированное время активации форка, какие прекомпиляции активны, адреса прекомпиляций, зависимости системных контрактов и расписание blob-объектов форка.

Этот EIP находится в отдельном разделе от «Основных EIP», потому что форк на самом деле не вносит никаких изменений — это уведомление о том, что команды клиентов должны реализовать этот метод JSON-RPC к моменту обновления Fusaka.

Ресурсы: Техническая спецификация EIP-7910 (opens in a new tab)

Часто задаваемые вопросы

Повлияет ли этот апгрейд на все узлы и валидаторы Ethereum?

Да, обновление Fusaka требует обновлений как клиентов исполнения, так и клиентов консенсуса. Все основные клиенты Ethereum выпустят версии, поддерживающие хард-форк, отмеченный как высокоприоритетный. Вы можете следить за тем, когда эти релизы будут доступны в репозиториях клиентов на Github, их каналах Discord (opens in a new tab), Discord-канале EthStaker (opens in a new tab) или подписавшись на блог Ethereum для получения обновлений протокола. Чтобы обеспечить синхронизацию с сетью Ethereum после обновления, операторы узлов должны убедиться, что используют поддерживаемую версию клиента. Обратите внимание, что со временем информация о выпусках клиентов теряет актуальность, поэтому пользователям рекомендуется ознакомиться с последним обновлениям, чтобы оставаться в курсе.

Как конвертировать ETH после хард-форка?

  • Для вашего ETH никаких действий не требуется. После обновления Ethereum Fusaka нет необходимости конвертировать или обновлять ETH. Балансы ваших счетов останутся прежними, а ETH, который вы сейчас держите, останется доступным в существующей форме после хард-форка.
  • Остерегайтесь мошенничества! Любой, кто поручает вам «обновить» ваш ETH, пытается вас обмануть. Вам не нужно ничего делать в связи с этим апгрейдом. Он никак не затронет ваши активы. Помните, что оставаться в курсе новостей — лучшая защита от мошенничества.

Подробнее о распознавании и предотвращении мошенничества

При чем здесь зебры?

Зебра — это «маскот», выбранный разработчиками для Fusaka, потому что ее полосы отражают выборку доступности данных на основе столбцов в PeerDAS, где узлы хранят определенные подсети столбцов и берут образцы из нескольких других столбцов из слота каждого пира, чтобы проверить доступность данных blob-объектов.

Слияние в 2022 году использовало панду (opens in a new tab) в качестве своего маскота, чтобы обозначить объединение уровней исполнения и консенсуса. С тех пор для каждого форка неофициально выбираются маскоты, которые появляются в виде ASCII-арта в логах клиентов во время обновления. Это просто забавный способ отпраздновать.

Какие улучшения включены для масштабирования L2?

PeerDAS — главная особенность форка. Он реализует выборку доступности данных (DAS), которая открывает больше возможностей для масштабирования роллапов, теоретически увеличивая пространство для blob-объектов до 8 раз по сравнению с текущим размером. Рынок комиссий за blob-объекты также будет улучшен, чтобы эффективно реагировать на перегрузки и гарантировать, что L2 платят значимую комиссию за вычисления и пространство, которые blob-объекты налагают на узлы.

Чем отличаются BPO-форки?

Форки, изменяющие только параметры blob-объектов (BPO), предоставляют механизм для непрерывного увеличения количества blob-объектов (как целевого, так и максимального) после активации PeerDAS, без необходимости ждать полного скоординированного обновления. Каждое увеличение жестко закодировано и предварительно настроено в релизах клиентов, поддерживающих Fusaka.

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

Каково расписание BPO?

Точное расписание обновлений BPO будет определено с релизами Fusaka. Следите за анонсами протокола (opens in a new tab) и примечаниями к релизам ваших клиентов.

Пример того, как это может выглядеть:

  • До Fusaka: цель 6, макс. 9
  • При активации Fusaka: цель 6, макс. 9
  • BPO1, через несколько недель после активации Fusaka: цель 10, макс. 15, увеличение на две трети
  • BPO2, через несколько недель после BPO1: цель 14, макс. 21

Снизит ли это комиссии в Ethereum (уровень 1)

Это обновление не снижает комиссии за газ на L1, по крайней мере, не напрямую. Основное внимание уделяется увеличению пространства для данных роллапов в виде blob-объектов, что, следовательно, снижает комиссии на уровне 2. Это может иметь некоторые побочные эффекты на рынке комиссий L1, но значительных изменений не ожидается.

Как стейкеру, что мне нужно сделать для обновления?

Как и при каждом обновлении сети, убедитесь, что вы обновили свои клиенты до последних версий с поддержкой Fusaka. Следите за обновлениями в списке рассылки и анонсами протокола в блоге EF (opens in a new tab), чтобы быть в курсе релизов. Чтобы проверить свою настройку до активации Fusaka в основной сети, вы можете запустить валидатора в тестовых сетях. Fusaka активируется раньше в тестовых сетях (opens in a new tab), что дает вам больше времени, чтобы убедиться, что все работает, и сообщать об ошибках. О форках в тестовых сетях также сообщается в списке рассылки и в блоге.

Влияет ли «детерминированный просмотр будущих создателей блоков» (EIP-7917) на валидаторов?

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

Как Fusaka влияет на требования к пропускной способности для узлов и валидаторов?

PeerDAS вносит значительные изменения в способ передачи данных blob-объектов узлами. Все данные разделены на части, называемые столбцами, по 128 подсетям, при этом узлы подписываются только на некоторые из них. Количество столбцов подсети, которые узлы должны хранить, зависит от их конфигурации и количества подключенных валидаторов. Фактические требования к пропускной способности будут зависеть от количества разрешенных blob-объектов в сети и типа узла. В момент активации Fusaka целевое количество blob-объектов остается прежним, но с PeerDAS операторы узлов могут заметить снижение использования диска для blob-объектов и сетевого трафика. По мере того как BPO будут настраивать большее количество blob-объектов в сети, необходимая пропускная способность будет увеличиваться с каждым BPO.

Требования к узлам остаются в пределах рекомендуемых значений (opens in a new tab) даже после BPO в Fusaka.

Полные узлы

Обычные узлы без валидаторов будут подписываться только на 4 подсети, обеспечивая хранение 1/8 исходных данных. Это означает, что при том же объеме данных blob-объектов пропускная способность узла для их загрузки будет в восемь (8) раз меньше. Использование диска и пропускная способность для загрузки blob-объектов для обычного полного узла может уменьшиться примерно на 80%, до нескольких Мб.

Соло-стейкеры

Если узел используется для клиента-валидатора, он должен хранить больше столбцов и, следовательно, обрабатывать больше данных. При добавлении валидатора узел подписывается как минимум на 8 подсетей столбцов и, следовательно, обрабатывает в два раза больше данных, чем обычный узел, но все же меньше, чем до Fusaka. Если баланс валидатора превышает 287 ETH, будет подписываться все больше и больше подсетей.

Для соло-стейкера это означает, что использование диска и пропускная способность для загрузки уменьшатся примерно на 50%. Однако для локального создания блоков и загрузки всех blob-объектов в сеть требуется большая пропускная способность для выгрузки. Локальным сборщикам блоков потребуется в 2-3 раза большая пропускная способность для выгрузки, чем раньше, во время Fusaka, а с целевым показателем BPO2 в 15/21 blob-объектов, окончательная необходимая пропускная способность для выгрузки должна будет быть примерно в 5 раз выше, на уровне 100 Мбит/с.

Крупные валидаторы

Количество подписанных подсетей растет с увеличением баланса и добавлением валидаторов к узлу. Например, при балансе около 800 ETH узел хранит 25 столбцов и ему потребуется примерно на 30% больше пропускной способности для загрузки, чем раньше. Необходимая пропускная способность для выгрузки растет аналогично обычным узлам, и требуется не менее 100 Мбит/с.

При 4096 ETH, 2 валидаторах с максимальным балансом, узел становится «суперузлом», который хранит все столбцы, следовательно, загружает и хранит все. Эти узлы активно восстанавливают сеть, возвращая недостающие данные, но также требуют гораздо большей пропускной способности и хранилища. Поскольку конечная цель по blob-объектам в 6 раз выше, чем раньше, суперузлам придется хранить около 600 ГБ дополнительных данных blob-объектов и иметь более высокую устойчивую пропускную способность для загрузки около 20 Мбит/с.

Узнайте больше подробностей об ожидаемых требованиях. (opens in a new tab)

Какие изменения в EVM реализованы?

Fusaka укрепляет EVM новыми незначительными изменениями и функциями.

Как новый лимит газа в 16 миллионов влияет на разработчиков контрактов?

Fusaka вводит ограничение на максимальный размер одной транзакции в 16,7 миллиона (opens in a new tab) (2^24) единиц газа. Это примерно соответствует предыдущему размеру среднего блока, что делает его достаточно большим для размещения сложных транзакций, которые могли бы занять целый блок. Этот лимит создает защиту для клиентов, предотвращая потенциальные DoS-атаки в будущем при более высоком лимите газа для блока. Цель масштабирования — позволить большему количеству транзакций попадать в блокчейн без того, чтобы одна транзакция занимала весь блок.

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

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

Что CLZ означает для разработчиков?

Компиляторы EVM, такие как Solidity, будут реализовывать и использовать новую функцию для подсчета нулей «под капотом». Новые контракты могут выиграть от экономии газа, если они полагаются на подобные операции. Следите за релизами и анонсами функций языка смарт-контрактов для получения документации о потенциальной экономии.

Есть ли какие-либо изменения для моих существующих смарт-контрактов?

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

С увеличением стоимости прекомпиляции ModExp (opens in a new tab) контракты, которые зависят от нее, будут потреблять больше газа для исполнения. Если ваш контракт сильно зависит от этого и становится более дорогим для пользователей, пересмотрите способ его использования.

Учитывайте новый лимит в 16,7 миллиона (opens in a new tab), если транзакции, исполняющие ваши контракты, могут достигать сопоставимого размера.

Дополнительные материалы

Последнее обновление страницы: 23 февраля 2026 г.

mnelsonBTm (opens in a new tab)
konopkjak (opens in a new tab)
architr4a (opens in a new tab)
+5

Была ли эта статья полезной?