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

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

Автор: Zhixiong Pan

Фон: обновление Gas Limit без необходимости хардфорка

До обновления Fusaka большинство основных параметров протокольного уровня Ethereum (таких как вознаграждение за блок, алгоритм корректировки сложности и др.) были «жёстко закодированы» в клиентском ПО. Это означало, что даже для изменения одного значения требовалось пройти долгий процесс предложения EIP, тестирования в тестовой сети и координации всех узлов для проведения масштабного хардфорка, что обычно занимало полгода или даже больше.

До этого единственным исключением в протоколе Ethereum был Block Gas Limit (лимит газа блока). 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 (выборочное подтверждение доступности данных) — ключевую технологию. Хотя технически сеть уже способна обрабатывать больше данных, разработчики решили не увеличивать нагрузку в первый день обновления ради безопасности. Это «период наблюдения за безопасностью» для проверки стабильности 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 и производительности клиентов, а не раз в несколько лет.