Часть III · Глава 34 из 43 · Cancun · Deneb

EIP-4844: блобы — дешёвые данные для роллапов

Роллапы обязаны публиковать свои данные на L1, чтобы кто угодно мог их проверить, — но как постоянная calldata это было разорительно дорого. Выведем блобы шаг за шагом: отдельная полоса для данных, коммитмент, чтобы её связать, отсечение через ~18 дней и собственный рынок комиссий.

Обновлено 13 сент. 2026 г. · 14 мин
Предполагается
  • роллапы
  • газ и EIP-1559

Ethereum масштабируется, выталкивая исполнение на роллапы (L2): они прогоняют тысячи транзакций офчейн и публикуют на L1 только результаты. Но роллап обязан опубликовать данные этих транзакций где-то публично, иначе никто не смог бы проверить его работу. Годами он публиковал эти данные как обычную calldata — и это единственное решение делало комиссии L2 болезненными и ограничивало, насколько дёшево вообще мог стать Ethereum. EIP-4844 («proto-danksharding») исправил это странно выглядящим новым объектом под названием блоб. Странным — пока вы его не построите: начните с проблемы calldata и исправляйте ровно то, что не так, шаг за шагом.

1 шаг Проблема данных

Почему роллапы обязаны публиковать данные — и почему calldata вредила

Роллап сжимает батч транзакций L2 и публикует его на L1. Он обязан опубликовать лежащие в основе данные, чтобы кто угодно — пользователь, оспаривающий, конкурирующий узел — мог восстановить состояние L2 и проверить (или опровергнуть) заявленный роллапом результат. Это доступность данных (data availability) Гарантия того, что данные за блоком или батчем действительно опубликованы, так что кто угодно может их скачать и независимо проверить или оспорить состояние. Отличается от хранения их вечно. : не «хранить их вечно», а «убедиться, что каждый может их получить». Очевидным местом для этого была calldata транзакции.

батч роллапа~128 KB txcalldata каждый узел, навсегда node 1node 2node 3node 4 16 газа/байт · хранится всеми узлами вечно · конкурирует с газом
Данные роллапа как calldata: 16 газа/байт, хранятся каждым узлом вечно и оцениваются на том же самом рынке газа, что и ваши свопы, — так что перегрузка L1 и данные роллапа борются за один и тот же блок.

Три вещи вредят одновременно. Calldata стоит 16 газа за байт — дорого. Она хранится каждым полным узлом вечно — вы платите за постоянное хранение. И она делит тот же рынок газа, что и исполнение, так что загруженный L1 напрямую подскакивает стоимость роллапа, а данные роллапа конкурируют за то же место, что и транзакции всех остальных. Комиссии роллапов доминировала эта единственная строка расходов.

→ Шаг 2: дать данным собственную полосу.

2 шаг Отдельная полоса

Отдельная, невидимая для EVM полоса — связанная коммитментом

Добавляем новое место для данных, рядом с calldata, а не внутри неё: блоб — большой (~128 КБ) кусок, прикреплённый к новому типу транзакции (0x03) в «сайдкаре». Ключевое свойство: EVM не может прочитать содержимое блоба. Это не состояние, с которым оперируют контракты, — это просто данные, о публикации которых сеть договорилась. Так что блобы несут данные роллапа, не раздувая состояние, к которому обязан прикасаться EVM.

Но если EVM не может прочитать блоб, а (следующий шаг) узлы собираются его удалить, как кто-то потом докажет, что блок действительно включал правильные данные, а не мусор? Свяжите каждый блоб с помощью KZG commitment 48-байтовый криптографический коммитмент к блобу (рассматриваемому как полином). Он однозначно фиксирует содержимое блоба и позволяет кому угодно проверить конкретный кусок против него крошечным доказательством — без хранения всего блоба. : 48-байтового значения, помещённого в блок. EVM получает опкод BLOBHASH (версионированный хеш этого коммитмента) и прекомпайл поточечной проверки (point-evaluation), так что контракт роллапа может сверить конкретный кусок блоба с его коммитментом — вообще не храня блоб целиком.

tx · type 0x03 сайдкар блоба · ~128 КБEVM не может это прочитать EVM читает tx, но не блоб KZG-обязательство · 48 Б заголовок блока блоб едет рядом, но вне EVM; его связывает 48-байтный KZG-коммитмент
Транзакция типа 0x03 несёт блоб в сайдкаре, который EVM не может прочитать. 48-байтовый KZG-коммитмент попадает в заголовок и связывает блоб, так что любой кусок можно верифицировать без полных данных.
Формула
versioned_hash = 0x01 1 ++ sha256(commitment) 2 [1:] 3
  1. 1 байт версии — позволяет схеме коммитмента измениться позже
  2. 2 хеш KZG-коммитмента, связывающего блоб
  3. 3 отбросить его первый байт; байт версии занимает это место
EVM видит только этот 32-байтовый версионированный хеш — байты блоба никогда не попадают в слой исполнения.

→ Шаг 3: выбрасываем данные (намеренно).

3 шаг Выбрасываем потом

Доступность, а не хранение: отсечение через ~18 дней

Вот прыжок, который делает это дешёвым. Узлы хранят сырые байты блоба только в течение окна — около 18 дней (4096 эпох) — затем удаляют их. Этого окна достаточно с запасом: достаточно долго, чтобы любой роллап, оспаривающий или пользователь скачали данные, и чтобы любое доказательство мошенничества или валидности успело разрешиться. После того как оно проходит, данные выполнили свою единственную задачу. Цепочка хранит крошечный коммитмент в истории вечно, но не 128 КБ за ним.

данные блобаможно скачать обрезано ~18 days коммитмент остаётся хранится ~18 дней, затем чистится — остаётся только commitment
Данные блоба хранятся ~18 дней — достаточно долго, чтобы скачать и доказать, — затем отсекаются. В истории остаётся только 48-байтовый коммитмент. Доступность, а не постоянное хранение.

В этом весь концептуальный сдвиг: роллапам никогда не было нужно постоянное хранение, им была нужна временная доступность. Разделение этих двух вещей превращает «дорого навсегда» в «дёшево и одноразово».

→ Шаг 4: оцениваем их отдельно.

4 шаг Собственный рынок комиссий

Отдельный рынок комиссий: blob-газ

Оцениваем блобы в собственной единице — blob-газ — с собственной базовой комиссией в стиле EIP-1559, полностью отдельной от исполнения. На Cancun каждый блок целился в 3 блоба и допускал до 6 (EIP-7691 поднял это до 6/9 в Pectra, а PeerDAS в Fusaka продолжает поднимать через BPO-форки); базовая комиссия блобов двигается вверх или вниз за блок к этой цели и сжигается, точно как базовая комиссия исполнения. Поток данных роллапа теперь повышает blob-базовую комиссию, не трогая цену газа вашего свопа, — а загруженный слой исполнения не делает блобы дороже. Два независимых сигнала перегрузки, две независимые цены.

блобов на блок 123 456 цель 3 спрос скачет выше target базовая комиссия блоба следует спросу выше цели → комиссия растёт; к цели → падает
Блобы измеряются в собственной единице с собственной базовой комиссией — на старте Cancun цель 3, максимум 6 за блок (с тех пор поднято — 6/9 в Pectra, выше в Fusaka), сжигается, — так что спрос на блобы и спрос на исполнение никогда не давят на цену друг друга.
blob base fee = MIN · e^(excess / UPDATE_FRACTION) 0.00.61.21.82.4 at target (3 blobs): price holds over target → exponential excess blob gas (blocks above target) →
Базовая комиссия блобов в зависимости от накопленного избытка blob-газа. На уровне цели (3 блоба на старте Cancun, с тех пор поднято) или ниже избыток остаётся на месте, и цена держится около минимума; как только блоки превышают цель, избыток накапливается, и комиссия растёт экспоненциально (e^(избыток/UPDATE_FRACTION)) — по собственной кривой, никогда не касаясь цены execution-газа.
04 Глубже Куда двигаться дальше