Автор: Є Хуейвень
Джерело: Wallstreetcn
Сьогодні Ethereum впроваджує ключове оновлення мережі під назвою «Fusaka», що є ще однією важливою віхою у його безперервній стратегії масштабування. Це оновлення спрямоване на значне збільшення обсягу даних і оптимізацію ефективності протоколу, що ще більше знизить вартість транзакцій у Layer-2 мережах і зміцнить позиції Ethereum як глобального ефективного розрахункового шару.
Згідно з планом, оновлення Fusaka буде активовано 3 грудня 2025 року на висоті блоку 13,164,544. Це новий крок на шляху масштабування Ethereum після оновлень Dencun і Pectra. Керівник криптовалютного підрозділу Goldman Sachs Kenny Lee зазначає, що Fusaka представляє наступний етап у дорожній карті масштабованості Ethereum, мета якого — перетворити мережу на розрахунковий шар із глобальним впливом і вигідною вартістю.
Найважливішою зміною цього оновлення є впровадження технології «PeerDAS» (Peer Data Availability Sampling — вибіркове забезпечення доступності даних між вузлами). Ця функція має на меті теоретично збільшити обсяг даних Layer-2 у 8 разів, що дозволить досягти більшої пропускної здатності транзакцій і суттєво знизити комісії для користувачів Layer-2.
Крім того, оновлення Fusaka включає впровадження механізму форку «Blob-Only Parameter» (BPO), що робить майбутнє збільшення мережевої ємності більш гнучким; а також оптимізує продуктивність Layer-1 основної мережі за допомогою функцій зберігання з терміном дії та контролю блоків, і покращує функціональність гаманців і користувацький досвід. Сукупність цих змін є структурним стрибком Ethereum у напрямку масштабованості, стійкості та операційної ефективності.
Від Dencun до Fusaka: фокус на масштабуванні та оптимізації інфраструктури
Оновлення Fusaka фактично є синхронною активацією оновлення консенсусного шару «Fulu» та виконуючого шару «Osaka». Згідно з остаточним рішенням Ethereum Foundation, оновлення включає пропозиції щодо поліпшення Ethereum (EIPs), що зосереджені на трьох основних напрямках:
-
Підвищення ефективності Layer-1: включає зберігання з терміном дії (EIP-7642) та ліміт газу для транзакцій (EIP-7825) тощо, з метою підтримки ефективної роботи вузлів у міру зростання навантаження на мережу.
-
Розширення обсягу даних Layer-2: основа — PeerDAS (EIP-7594), а також оновлення параметрів Blob (EIP-7892) і оптимізація комісій за Blob (EIP-7918).
-
Покращення користувацького досвіду та інструментів для розробників: охоплює детермінований попередній вибір пропонентів (EIP-7917) і попередньо скомпільовану підтримку кривої secp256r1 (EIP-7951) для розширення функціоналу гаманців і розробки додатків.
Ці три напрямки повністю відповідають стратегічним пріоритетам, визначеним Ethereum Foundation у квітні 2025 року (масштабування основної мережі Ethereum, масштабування Blobs, покращення користувацького досвіду). У цій статті основна увага приділяється збільшенню обсягу даних Layer-2 і оптимізації механізму комісій.
Ключова місія: шлях масштабування з фокусом на L2
Щоб зрозуміти, чому Ethereum зосереджується на масштабуванні через Layer-2, слід звернутися до його філософії дизайну.
У «трикутнику блокчейну» (де децентралізація, безпека та масштабованість не можуть бути досягнуті одночасно), Ethereum на ранніх етапах віддав перевагу децентралізації та безпеці базового шару (Layer-1). Це призвело до того, що зі зростанням попиту на децентралізовані додатки Layer-1 зіткнувся з високими комісіями та повільним підтвердженням транзакцій.
Щоб вирішити цю проблему, Ethereum прийняв дорожню карту «Rollup-centric». Ця стратегія передбачає перенесення більшості обробки транзакцій на Layer-2 мережі, які виконують транзакції поза основним ланцюгом, а потім публікують стислі дані назад у Layer-1 для остаточного розрахунку та забезпечення безпеки.
Такий модульний підхід дозволяє Ethereum досягати масштабованості без шкоди для принципів децентралізації. Однак це породжує нову проблему — «доступність даних»: як довести всій мережі, що опубліковані стислі дані є дійсними, не змушуючи кожен вузол завантажувати всі дані повністю.
PeerDAS: ключ до 8-кратного збільшення обсягу даних
Найвпливовіша функція оновлення Fusaka — PeerDAS — створена саме для вирішення проблеми доступності даних.
До Fusaka, хоча оновлення Dencun і впровадило «Blobs» як економічний спосіб зберігання даних для Layer-2, кожен повний вузол Ethereum все одно мав завантажувати повний обсяг Blob-даних, що обмежувало пропускну здатність і максимальну продуктивність мережі.
PeerDAS радикально змінює цю модель. Після оновлення мережа розбиває Blob-дані на дрібні частини та розподіляє їх між різними вузлами. Кожен вузол повинен завантажити й перевірити лише невелику частину загальних даних (близько 1/8), і за допомогою криптографічних методів забезпечується цілісність і доступність всього набору даних. Це значно знижує вимоги до ресурсів окремого вузла, що теоретично забезпечує близько 8-кратного зростання обсягу даних у мережі. PeerDAS закладає основу для подальшого масштабування Blobs і є ключовим драйвером зниження вартості транзакцій у Layer-2.
BPO-форк: гнучкіше збільшення ліміту Blob
Зі зростанням активності транзакцій у Layer-2 (див. малюнок 2) попит на простір для Blob також постійно зростає.
Згідно з даними Coinmetrics, кількість Blob на добу має тенденцію до зростання. Однак у межах поточного механізму збільшення кількості Blob у кожному блоці вимагає складного «хардфорку», координація якого є складною і відбувається рідко.
Щоб усунути це вузьке місце, Fusaka впроваджує механізм «Blob-Only Parameter (BPO) fork». Це спеціалізований легкий форк, який використовується лише для оновлення параметрів, пов’язаних із Blob (наприклад, максимальна кількість Blob на блок). Завдяки вузькому фокусу та контрольованому впливу команди розробників можуть частіше й безпечніше впроваджувати такі оновлення, поступово збільшуючи обсяг даних у мережі без необхідності чекати на масштабні оновлення з іншими функціями. За даними Ethereum Foundation, BPO-форки будуть запрограмовані заздалегідь, щоб протягом кількох тижнів поетапно подвоювати кількість Blob до досягнення максимуму.
Стабільний ринок комісій: впровадження механізму мінімальної ціни для Blob
Після оновлення Dencun Layer-2 при публікації даних в Ethereum стикаються з двома незалежними комісіями: виконання Gas і Blob Gas. Коли попит на Blob низький, їхня комісія може впасти майже до нуля, але Layer-2 все одно змушені платити значну комісію за виконання Gas. Такий «збій цінового сигналу» призводить до неефективного ціноутворення та нестабільності ринку.
Щоб вирішити цю проблему, Fusaka через EIP-7918 впроваджує механізм «мінімальної ціни» для Blob. Ця мінімальна ціна не є фіксованою, а динамічно прив’язується до комісії за виконання Gas.
Коли ринкова комісія за Blob опускається нижче цієї мінімальної ціни, алгоритм коригування комісій не дозволяє їй знижуватися далі. Це має забезпечити, щоб комісія за Blob завжди відображала її економічну цінність, ринок комісій залишався чутливим до навантаження мережі, а Layer-2 отримували стабільніше й передбачуване цінове середовище.
Вплив на ринок і потенційні ризики
Очікується, що оновлення Fusaka матиме глибокий вплив на ринок. Збільшення обсягу даних завдяки PeerDAS і BPO-форку може ще більше знизити операційні витрати Layer-2. Водночас механізм мінімальної ціни EIP-7918 гарантує, що простір Blob не буде використовуватися надто дешево, зберігаючи економічну стійкість мережі. Це може посилити конкуренцію між Layer-2 мережами, зміщуючи акцент із вартості транзакцій на користувацький досвід, екосистемну співпрацю та глибину ліквідності.
Однак це оновлення також супроводжується певними ризиками та міркуваннями:
-
Ризик виконання: будь-який великий хардфорк несе ризик невдачі координації клієнтів або появи вразливостей, що може тимчасово дестабілізувати мережу.
-
Обмежений вплив на комісії основної мережі: безпосередні переваги оновлення стосуються переважно Layer-2, і комісії Gas у основній мережі Ethereum у короткостроковій перспективі можуть не знизитися.
-
Вимоги до обладнання: хоча PeerDAS підвищує ефективність, вищі цілі для Blob із часом можуть збільшити потребу у пропускній здатності для валідаторів.
-
Затримка адаптації екосистеми: Layer-2 і розробникам dApp потрібен час, щоб повністю скористатися перевагами нової архітектури.
