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

Фусака 🦓

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

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

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

Джерело графіка: Ethereum Blobs - @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 МіБ, зарезервованим для формування сигнального блоку. Практично, клієнти визначають

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, на їхніх каналах у Discord (opens in a new tab), у Discord 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?

Форки лише з параметрами блобів (BPO) забезпечують механізм постійного збільшення кількості блобів (як цільової, так і максимальної) після активації 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