Перейти к основному контенту

Фусака 🦓

Редактировать страницу (opens in a new tab)

Долгожданное обновление Эфириума Фусака было запущено 3 декабря 2025 года

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

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

Ethereum's latest upgrade: Fusaka

A short overview of Ethereum's Fusaka upgrade featuring Ethereum Foundation contributors and ecosystem builders.

Смотреть с расшифровкой 

Улучшения в Фусака

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

PeerDAS

Это главное событие форка Фусака, основная функция, добавленная в этом обновлении. Уровни 2 (l2) в настоящее время публикуют свои данные в Эфириуме в виде блобов — эфемерного типа данных, созданного специально для уровня 2 (l2). До Фусака каждый полный узел должен был хранить каждый блоб, чтобы гарантировать существование данных. По мере роста пропускной способности блобов необходимость загружать все эти данные становится непомерно ресурсоемкой.

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

Это позволяет поддерживать приемлемые требования к оборудованию и пропускной способности для узлов, одновременно обеспечивая масштабирование блобов, что приводит к большему масштабу с меньшими комиссиями для уровня 2 (l2).

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

Ресурсы:

Форки только с параметрами блобов (Blob-Parameter-Only)

Уровни 2 (l2) масштабируют Эфириум — по мере роста их сетей им нужно публиковать больше данных в Эфириуме. Это означает, что со временем Эфириуму потребуется увеличить количество доступных для них блобов. Хотя PeerDAS позволяет масштабировать данные блобов, это нужно делать постепенно и безопасно.

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

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

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

Когда блобы были впервые добавлены в сеть в обновлении Dencun, целевое значение было 3. Оно было увеличено до 6 в Пектра, и после Фусака теперь может увеличиваться устойчивыми темпами независимо от этих крупных обновлений сети.

Chart showing average blob count per block and increasing targets with upgrades

Источник графика: Блобы Эфириума - @hildobby, Dune Analytics (opens in a new tab)

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

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

Уровни 2 (l2) оплачивают два счета при публикации данных: комиссию за блоб и газ за исполнение, необходимый для проверки этих блобов. Если газ за исполнение доминирует, аукцион комиссий за блобы может опуститься до 1 Wei и перестать быть ценовым сигналом.

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

  • рынок комиссий за блобы всегда реагирует на перегрузку
  • уровни 2 (l2) оплачивают по крайней мере значимую часть вычислений, которые они возлагают на узлы
  • скачки базовой комиссии на уровне исполнения больше не могут удерживать комиссию за блоб на уровне 1 Wei

Ресурсы:

Масштабирование уровня 1 (l1)

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

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

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

Ресурсы: Техническая спецификация 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 газа? Это комфортно меньше сегодняшнего лимита газа, достаточно велико для развертывания реальных контрактов и тяжелых прекомпилированных контрактов, а степень двойки упрощает реализацию в различных клиентах. Этот новый максимальный размер транзакции аналогичен среднему размеру блока до Пектра, что делает его разумным пределом для любой операции в Эфириуме.

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

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

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

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

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

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

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

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

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

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

Суть: это ограничение на размер блока исполнения, закодированного в RLP. Всего 10 МиБ, с запасом прочности в 2 МиБ, зарезервированным для кадрирования сигнального блока (beacon block). Практически клиенты определяют

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 координирует команды клиентов уровня исполнения для повышения лимита газа по умолчанию выше сегодняшних 45 млн для Фусака. Это информационный EIP, но он явно просит клиентов протестировать более высокие лимиты в сетях для разработчиков, сойтись на безопасном значении и включить это число в свои релизы Фусака.

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

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

Улучшение пользовательского опыта (UX)

Детерминированное предвидение предлагающего

С EIP-7917 сигнальная цепочка будет знать о предстоящих предлагающих блоки на следующую эпоху. Наличие детерминированного представления о том, какие валидаторы будут предлагать будущие блоки, может обеспечить предварительные подтверждения (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) в стиле ключей доступа по фиксированному адресу 0x100, используя тот же формат вызова, который уже принят многими уровнями 2 (l2), и исправляя крайние случаи, чтобы контракты, написанные для этих сред, работали на уровне 1 (l1) без изменений.

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

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

Ресурсы:

Мета

Метод JSON-RPC eth_config

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

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

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

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

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

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

Влияет ли это обновление на все узлы и валидаторы Эфириума?

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

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

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

Подробнее о том, как распознать и избежать мошенничества

При чем тут зебры?

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

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

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

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

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

Форки только с параметрами блобов (Blob Only Parameter) предоставляют механизм для непрерывного увеличения количества блобов (как целевого, так и максимального) после активации PeerDAS, без необходимости ждать полного скоординированного обновления. Каждое увеличение жестко закодировано для предварительной настройки в релизах клиентов, поддерживающих Фусака.

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

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

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

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

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

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

Это обновление не снижает комиссии за газ на уровне 1 (l1), по крайней мере, напрямую. Основное внимание уделяется увеличению пространства блобов для данных роллапов, что снижает комиссии на уровне 2 (l2). Это может иметь некоторые побочные эффекты на рынке комиссий уровня 1 (l1), но существенных изменений не ожидается.

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

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

Влияет ли «Детерминированное предвидение предлагающего» (EIP-7917) на валидаторов?

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

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

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

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

Полные узлы

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

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

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

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

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

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

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

Подробнее об ожидаемых требованиях. (opens in a new tab)

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

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

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

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

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

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

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

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

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

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

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

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

Дополнительная литература

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

UaittU (opens in a new tab)
architr4a (opens in a new tab)
JoeChenJJ (opens in a new tab)
+6