Ethereum тестує важливе оновлення перед запуском Fusaka

Ethereum незабаром перетне вирішальну межу у своїй технічній модернізації. Оскільки розгортання Fusaka наближається, мережа вступає у фінальну фазу тестування ключового оновлення. За цим непомітним зміною лежить стратегічний поворотний момент: закладення основ для паралельного виконання, яке очікується у 2026 році. Більше ніж просто приріст продуктивності, Ethereum ініціює структурну трансформацію, розраховану на сталу підтримку свого масштабування в умовах зростаючих викликів масштабованості.

У короткому викладі

• Оновлення Fusaka входить у фінальну фазу тестування перед його розгортанням в основній мережі, запланованим на 3 грудня 2025 року.
• Вводиться межа газу на одну транзакцію, встановлена на рівні 16.78 мільйонів одиниць, щоб запобігти монополізації цілого блоку однією транзакцією.
• Ліміт транзакцій дозволяє краще розподіляти ресурси, зменшує ризики DoS та покращує передбачуваність блоків.
• Це оновлення готує прихід паралельного виконання транзакцій, запланованого на 2026 рік з оновленням Glamsterdam (EIP-7928).

Нове обмеження для більшої стабільності

Оновлення Fusaka вводить новий важливий елемент: встановлення ліміту газу на кожну транзакцію, що дорівнює 16,78 мільйона одиниць, відповідно до пропозиції EIP-7825.

До тепер, одна транзакція могла споживати весь газ, доступний у блоці, приблизно 45 мільйонів одиниць, що піддавало мережу ризикам заторів або атак відмови в обслуговуванні (DoS). Ліміт газу на транзакцію має на меті покращити ефективність блоку, зменшити ризики DoS та закласти основу для паралельного виконання.

Цей ліміт вже активний на тестових мережах Holesky та Sepolia, як частина підготовчих етапів для розгортання в основній мережі.

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

Зокрема, ця еволюція дозволяє:

• Запобігання монополізації ресурсів цілого блоку однією транзакцією ;
• Сприяння одночасному включенню кількох транзакцій з нижчою інтенсивністю ;
• Зменшення ризиків насичення або цілеспрямованих атак на споживання газу ;
• Оптимізація передбачуваності будівництва блоків для валідаторів та розробників.

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

Від тестових мереж до основної мережі, до масштабного паралельного виконання

Окрім цієї нової архітектури блоків, Fusaka представляє центральну інновацію під назвою PeerDAS, що означає “Вибірка доступності даних учасників”. Ця система дозволяє вузлам Ethereum зберігати лише випадкову частину “блоб” даних з другого шару, а не весь набір даних.

Мета полягає в зменшенні апаратних вимог при збереженні безпеки мережі. Це досягнення має на меті зміцнити впровадження рішень типу rollup, які залежить саме від цієї доступності даних. Дійсно, ця інновація PeerDAS “дозволяє зменшити потреби в апаратному забезпеченні при збереженні безпеки та сприяє більш економічному, високопродуктивному масштабуванню для мереж другого рівня”.

Впровадження PeerDAS відкриває шлях до наступного етапу у дорожній карті Ethereum: оновлення “Glamsterdam”, заплановане на 2026 рік, яке введе EIP-7928, першу конкретну ітерацію паралельного виконання транзакцій. Ця еволюція дозволить обробляти кілька операцій одночасно, замість виконання їх послідовно, як це ще відбувається сьогодні.

У цьому контексті Фусака виконує важливу роль: без обмежень газу на транзакцію та оптимізованої інфраструктури даних паралельне виконання не може бути безпечно реалізоване. Для Габріеля Трінтіналії, інженера в Consensys, “ці оновлення тестнету є необхідними для зміцнення довіри перед форком основної мережі”.

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