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

Page last updated: 23 лютого 2026 р.

Fusaka

Довгоочікуване оновлення Ethereum Fusaka було активовано 3 грудня 2025 року

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

Покращення в Fusaka

Масштабування блобів

PeerDAS

Це головна новинка форку Fusaka — ключова функція, додана в цьому оновленні. Наразі мережі другого рівня (L2) розміщують свої дані в Ethereum у вигляді блобів, тимчасового типу даних, створеного спеціально для L2. До оновлення Fusaka кожен повний вузол мав зберігати кожен блоб, щоб гарантувати наявність даних. Із збільшенням пропускної здатності блобів завантаження всіх цих даних стає неприпустимо ресурсомістким.

Завдяки вибірковій перевірці доступності даних (opens in a new tab) замість того, щоб зберігати всі блоби, кожен вузол відповідатиме лише за їхню підмножину. Блоби рівномірно та випадково розподіляються між вузлами мережі, і кожен повний вузол зберігає лише 1/8 усіх даних, що теоретично дозволяє масштабування до 8 разів. Щоб забезпечити доступність даних, будь-яку їхню частину можна відновити з будь-яких наявних 50% цілого за допомогою методів, які зводять імовірність помилок або втрати даних до криптографічно незначного рівня (~один до 1020 – один до 1024).

Це дозволяє зберігати прийнятні вимоги до обладнання та пропускної здатності вузлів, одночасно забезпечуючи масштабування блобів, що призводить до більшого масштабу та нижчих комісій для мереж другого рівня L2.

Дізнатися більше про PeerDAS

Ресурси:

Форки лише з параметрами блобів

Мережі другого рівня L2 масштабують Ethereum — і зі зростанням їхніх мереж їм потрібно розміщувати більше даних у Ethereum. Це означає, що з часом Ethereum доведеться збільшувати кількість доступних блобів. Хоча PeerDAS дозволяє масштабувати блоб-дані, робити це потрібно поступово та безпечно.

Оскільки Ethereum — це код, що працює на тисячах незалежних вузлів, які повинні дотримуватися однакових правил, ми не можемо просто впровадити зміни, наприклад збільшити кількість блобів, так само, як розгортають оновлення вебсайту. Будь-яка зміна правил має бути координованим оновленням, при якому кожен вузол, клієнт і програмне забезпечення валідатора оновлюються до одного й того самого заздалегідь визначеного блоку.

Такі координовані оновлення зазвичай включають багато змін, потребують ретельного тестування, і це займає час. Щоб швидше адаптуватися до змінних потреб L2 у блобах, форки лише з параметрами блобів вводять механізм збільшення кількості блобів без необхідності чекати на графік основного оновлення.

Форки лише з параметрами блобів можуть встановлюватися клієнтами, подібно до інших налаштувань, як-от ліміт газу. Між основними оновленнями Ethereum клієнти можуть домовитися про збільшення target та max блобів, наприклад, до 9 і 12, після чого оператори вузлів оновлюються, щоб брати участь у цьому невеликому форку. Такі форки лише з параметрами блобів можна налаштовувати в будь-який час.

Коли блоби були вперше додані до мережі в оновленні Dencun, їхня цільова кількість становила 3. В оновленні Pectra її було збільшено до 6, а після Fusaka її можна збільшувати стабільними темпами незалежно від цих великих оновлень мережі.

Діаграма, що показує середню кількість блобів на блок і зростання цільових показників з оновленнями

Джерело графіка: Ethereum Blobs - @hildobby, Dune Analytics (opens in a new tab)

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

Базова плата за блоб обмежена витратами на виконання

Мережі другого рівня (L2) сплачують два типи платежів при розміщенні даних: плату за блоб та газ за виконання, необхідний для перевірки цих блобів. Якщо витрати на газ за виконання переважають, аукціон плати за блоб може знизитися до 1 wei і перестати виконувати роль цінового сигналу.

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

  • ринок плати за блоби завжди реагує на перевантаження
  • мережі другого рівня L2 сплачують принаймні значну частину обчислювальних ресурсів, які вони змушують використовувати вузли
  • різкі стрибки базової плати на рівні виконання EL більше не можуть застрягати плату за блоб на рівні 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 встановлює обмеження у 16 777 216 (2²⁴) газу на транзакцію. Це проактивне посилення захисту від 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 млн), це значення не змінювалося з часу Merge у вересні 2022 року. Ця EIP має на меті зробити послідовне масштабування пріоритетом.

EIP-7935 координує команди EL-клієнтів для підвищення типового ліміту газу вище нинішніх 45 млн для Fusaka. Це інформаційна EIP, але вона прямо закликає клієнтів протестувати вищі ліміти на devnet-мережах, визначити безпечне значення та включити його до своїх релізів для Fusaka.

Планування devnet передбачає стрес-навантаження на рівні приблизно 60 млн (повні блоки зі штучним навантаженням) та поступове підвищення ліміту; дослідження показують, що найгірші патології розміру блоків не повинні ставати обмежувальним фактором нижче приблизно 150 млн. Впровадження має супроводжуватися обмеженням газ-ліміту для транзакцій (EIP-7825), щоб жодна окрема транзакція не могла домінувати у блоці зі зростанням загальних лімітів.

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

Покращення UX

«Детермінований прогноз вибору пропозера»

З EIP-7917 ланцюг Beacon стане обізнаним про майбутніх пропозерів блоків для наступної епохи. Маючи детермінований прогноз того, які валідатори будуть пропонувати майбутні блоки, можна реалізувати передпідтвердження (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, щоб валідатори та інструменти моніторингу могли перевірити, чи готові клієнти до майбутнього форку.

Практично кажучи, це зроблено для усунення недоліку, виявленого на початку 2025 року, коли форк Pectra запрацював у тестовій мережі Holesky з незначними помилками конфігурації, що призвело до стану без фіналізації. Це допомагає командам тестування та розробникам переконатися, що великі форки будуть поводитися як очікувалося при переході з devnets до testnets, і з testnets до Mainnet.

Знімки містять: chainId, forkId, запланований час активації форку, інформацію про активні прекомпіляції, адреси прекомпіляцій, залежності системних контрактів та графік блобів форку.

Цей 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, де вузли зберігають певні підмережі стовпців і вибірково перевіряють кілька інших стовпців з кожного слота пірів, щоб переконатися, що дані блоба доступні.

The Merge у 2022 році використовував панду (opens in a new tab) як свій талісман, щоб позначити об'єднання рівнів виконання та консенсусу. Відтоді талісмани неофіційно обираються для кожного форку і з'являються у вигляді ASCII-арту в логах клієнта під час оновлення. Це просто веселий спосіб святкування.

Які покращення включені для масштабування L2?

PeerDAS — головна особливість цього форку. Він реалізує вибірку доступності даних (DAS), що відкриває більше можливостей масштабованості для ролапів, теоретично збільшуючи простір для блобів у 8 разів порівняно з поточним розміром. Ринок комісій за блоби також буде покращено для ефективного реагування на перевантаження та гарантування того, що L2 платять значущу комісію за обчислення та простір, які блоби займають на вузлах.

Чим відрізняються форки BPO?

Форки лише з параметрами блобів надають механізм для постійного збільшення кількості блобів (як цільової, так і максимальної) після активації 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, принаймні не безпосередньо. Основна увага приділяється збільшенню простору для блобів для даних ролапів, що призведе до зниження комісій на рівні 2. Це може мати деякі побічні ефекти на ринок комісій L1, але значних змін не очікується.

Як стейкеру, що мені потрібно зробити для оновлення?

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

Чи впливає "Детермінований прогноз пропонента" (EIP-7917) на валідаторів?

Ця зміна не змінює функціонування вашого клієнта-валідатора, однак вона надасть більше інформації про майбутні обов'язки вашого валідатора. Переконайтеся, що ви оновили свої інструменти моніторингу, щоб бути в курсі нових функцій.

Як Fusaka впливає на вимоги до пропускної здатності для вузлів і валідаторів?

PeerDAS суттєво змінює спосіб передачі даних блобів вузлами. Усі дані діляться на частини, що називаються стовпцями, у 128 підмережах, причому вузли підписуються лише на деякі з них. Кількість стовпців підмереж, які вузли повинні зберігати, залежить від їхньої конфігурації та кількості підключених валідаторів. Фактичні вимоги до пропускної здатності залежатимуть від кількості блобів, дозволених у мережі, та типу вузла. На момент активації Fusaka цільова кількість блобів залишається такою ж, як і раніше, але з PeerDAS оператори вузлів можуть помітити зменшення використання дискового простору для блобів і мережевого трафіку. Оскільки BPO налаштовують більшу кількість блобів у мережі, необхідна пропускна здатність зростатиме з кожним BPO.

Вимоги до вузлів все ще знаходяться в рекомендованих межах (opens in a new tab) навіть після BPO Fusaka.

Повні вузли

Звичайні вузли без валідаторів підписуватимуться лише на 4 підмережі, забезпечуючи зберігання 1/8 початкових даних. Це означає, що при тій самій кількості даних блобів пропускна здатність вузла для їх завантаження буде меншою у вісім (8) разів. Використання диска та пропускна здатність завантаження блобів для звичайного повного вузла можуть зменшитися приблизно на 80%, до кількох Мб.

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

Якщо вузол використовується для клієнта-валідатора, він повинен зберігати більше стовпців і, отже, обробляти більше даних. З додаванням валідатора вузол підписується щонайменше на 8 підмереж стовпців і, отже, обробляє вдвічі більше даних, ніж звичайний вузол, але все одно менше, ніж до Fusaka. Якщо баланс валідатора перевищує 287 ETH, підписуватиметься все більше підмереж.

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

Великі валідатори

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

При 4096 ETH, 2 валідатори з максимальним балансом, вузол стає «супервузлом», який зберігає всі стовпці, отже, завантажує та зберігає все. Ці вузли активно відновлюють мережу, повертаючи відсутні дані, але також потребують набагато більшої пропускної здатності та сховища. З кінцевою ціллю для блобів, що в 6 разів вища, ніж раніше, супервузлам доведеться зберігати близько 600 ГБ додаткових даних блобів і мати вищу стабільну пропускну здатність завантаження на рівні близько 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 р.

architr4a (opens in a new tab)
JoeChenJJ (opens in a new tab)
corwintinesc (opens in a new tab)
+5

Чи була ця стаття корисною?