«Безступінчаста трансмісія» в оновленні Ethereum Fusaka: створення механізму швидкого реагування для масштабування L2

Майбутній Ethereum буде схожий на автомобіль із «безступінчастою коробкою передач»: у майбутньому розширення Blob більше не потрібно буде жорстко прив’язувати до великих оновлень.

Автор: Zhixiong Pan

Передумови: оновлення Gas Limit без хардфорку

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

До цього єдиним винятком у протоколі Ethereum був Block Gas Limit (обмеження Gas для блоку). Gas Limit не визначається хардфорком, а дозволяє валідаторам під час пакування блоку робити невеликі коригування за допомогою алгоритму (наприклад, цього року з 30M до 60M). Такий механізм надає мережі певну гнучкість.

Поява EIP-7892, BPO (Blob Parameter Only), саме й покликана розширити цю гнучкість на сферу даних. Ключові параметри Blob стали керованими через конфігурацію, і завдяки BPO — «оновленню лише параметрів без зміни коду» — це впроваджується як легкий хардфорк. З точки зору розробки клієнта це майже як гаряче оновлення параметрів.

Це дозволяє Ethereum у питанні масштабування позбутися необхідності «кожного разу чекати великого хардфорку для зміни кількості Blob», а натомість частіше коригувати параметри через невеликі BPO-форки.

Чому кількість Blob така важлива? 

Основний об’єкт цього оновлення — Blob. Після оновлення Cancun (Dencun) більшість Rollup більше не записують основну частину даних транзакцій у дорогий calldata, а перемістили їх у спеціальну «тимчасову зону зберігання даних» — Blob.

Економічна логіка Blob дуже проста: Blob — це обмежений ресурс, кількість Blob, які можна підключити до кожного блоку, обмежена. Його ціна визначається співвідношенням попиту і пропозиції: коли попит з боку Layer 2 перевищує пропозицію, одинична ціна Blob зростає, що призводить до підвищення комісій L2.

Тому, за умови збереження безпеки, максимальне підвищення ліміту Blob — це найпряміший спосіб знизити витрати користувачів L2.

Ключові параметри: механізм Target і Max

У плані коригування BPO можна побачити дві пари чисел (наприклад, 10/15). Це два ключові пороги, встановлені на основі механізму EIP-4844:

Target (цільове значення): «регулятор» комісій 

Це ідеальне навантаження, встановлене для Ethereum. Система динамічно коригує базову комісію Blob (Base Fee) відповідно до цього значення. Якщо фактичне використання > Target, комісія зростає для стримування попиту; якщо фактичне використання < Target, комісія знижується.

Воно визначає пропускну здатність мережі у нормальному стані та базову ставку комісій.

Max (максимальне значення): «запобіжник» безпеки 

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

Це максимальна межа пропускної здатності мережі.

Крім того, починаючи з Pectra, параметри blob у основній мережі дотримуються співвідношення «Max = 1.5 × Target»: 6/9, 10/15, 14/21 — це саме такий розподіл.

Дорожня карта оновлення: чому Fusaka обрала «поступовий підхід»? 

Це масштабування не відбудеться одразу 3 грудня (UTC+8), а реалізується у три етапи за суворою стратегією: «спочатку впровадження технології, потім збільшення ємності».

Перший етап: впровадження Fusaka (3 грудня (UTC+8))

Параметри: Target: 6 / Max: 9 (залишаються незмінними порівняно з попередньою версією Pectra).

Оновлення Fusaka активувало ключову технологію PeerDAS (sampling доступності даних). Хоча технічно вже є можливість обробляти більше даних, з міркувань безпеки розробники вирішили не збільшувати навантаження мережі у перший день оновлення. Це «період безпечного спостереження» для перевірки стабільності PeerDAS при поточному трафіку.

Другий етап: BPO 1 (очікується 9 грудня (UTC+8))

Коригування параметрів: Target: 10 / Max: 15

Після приблизно тижня стабільної роботи PeerDAS вперше буде проведено гаряче оновлення через BPO. Цільове значення підвищиться з 6 до 10. Це перше суттєве масштабування у циклі Fusaka.

Третій етап: BPO 2 (очікується 7 січня 2026 року (UTC+8))

Коригування параметрів: Target: 14 / Max: 21

Після місяця повного стрес-тестування буде проведено друге гаряче оновлення. У порівнянні з запуском Fusaka, ємність зросте у 2,3 рази (6 → 14). Це означає повну реалізацію цього плану масштабування.

Висновок

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

Це означає, що майбутній Ethereum буде схожий на автомобіль із «безступінчастою коробкою передач»: розширення Blob більше не потрібно буде жорстко прив’язувати до великих оновлень, а можна буде планувати BPO3, BPO4 тощо з певною періодичністю, орієнтуючись на потреби L2 та продуктивність клієнтів, і оптимізувати пропускну здатність частими невеликими хардфорками, а не раз на кілька років.