EIP-4844 (Proto-danksharding): блобы и дешёвые L2-транзакции

Задачи EIP-4844 и место в дорожной карте Ethereum

До EIP-4844 L2-rollup’ы публиковали данные о транзакциях на L1 в виде:

• calldata — байты, навсегда остающиеся в истории Ethereum.

Это:

• гарантировало надёжную доступность данных;
• но делало публикацию очень дорогой и ограниченной по объёму.

EIP-4844 решает две задачи:

• даёт rollup’ам отдельное, дешевлеe пространство для данных — блобы;
• готовит протокол к будущему danksharding: архитектура и криптопримитивы совместимы с выборочной проверкой доступности данных (DAS).

Связанные элементы дорожной карты описаны на страницах Данктшардинг (Danksharding) — путь к массовому масштабированию Ethereum и PeerDAS и EIP-7251 в Ethereum — масштабирование данных и валидаторов.

Что такое блобы и blob-транзакции

EIP-4844 добавляет новый тип транзакций (часто называют «тип-3»), который:

• несёт один или несколько blob’ов — крупных кусков бинарных данных фиксированного размера;
• публикует коммитменты этих блобов в блоке L1;
• оплачивает отдельный компонент комиссии — blob gas.

Ключевые свойства блоба:

• размер порядка 128 КиБ (4096 полей по 32 байта);
• блоб хранится в консенсус-слое (Beacon Chain), а не в исполнении (EVM);
• через ~4096 эпох (~18 дней) блоб-данные могут быть удалены, но коммитменты остаются;
• смарт-контракты не имеют доступа к содержимому блоба — только к хэшу/коммитменту (например, через BLOBHASH).

С точки зрения узлов:

• им приходится хранить блоб-данные только ограниченное время;
• этого достаточно, чтобы все участники L2 скачали и реплицировали их в свою DA-инфраструктуру (индексаторы, архивация, отдельные DA-слои).

KZG-коммитменты и проверка целостности

Чтобы узлы могли быть уверены, что:

• данные блоба не подменялись;
• коммитмент действительно соответствует содержимому,

EIP-4844 использует KZG-коммитменты:

• блоб интерпретируется как набор значений некоторого полинома;
• на этот полином строится KZG-коммитмент;
• вместе с блобом могут публиковаться KZG-доказательства отдельных точек.

Свойства:

• компактные доказательства и коммитменты;
• проверка быстрая и дешёвая;
• корректность полагается на корректный trusted setup (KZG-церемония с множеством участников).

Подробнее о примитиве см. KZG-коммитменты — полиномиальные коммитменты для Ethereum (EIP-4844 и Verkle).

Отдельный рынок комиссий: blob gas

Для блобов создаётся собственный рынок комиссий, похожий на EIP-1559:

• есть таргет по количеству блобов в блоке и верхний лимит;
• если спрос выше таргета — blob base fee растёт;
• если ниже — blob base fee снижается.

Это отделяет:

• «обычный» gas (исполнение EVM, calldata);
• и «blob gas» (DA-место для rollup’ов).

Итого:

• дешёвое пространство под блобы почти не конкурирует с обычными L1-транзакциями;
• нагрузка rollup’ов переносится в отдельный контур ценообразования.

Ключевые параметры EIP-4844

Как rollup использует блобы: схема по шагам

Типичный workflow для L2-rollup’а:

• 1. Агрегация транзакций.

Оператор rollup’а собирает десятки/сотни L2-транзакций в пакет, исполняет их off-chain и рассчитывает новое состояние.

• 2. Публикация данных в блобе.

Пакет данных записывается в один или несколько blob’ов. На L1 отправляется blob-транзакция с коммитментами блобов.

• 3. Проверка и хранение.

Узлы консенсус-слоя проверяют KZG-коммитменты. Блоб-данные доступны всем узлам и индексаторам в течение срока хранения.

• 4. Использование proof’ов.

В зависимости от типа rollup’а:

• optimistic-роллап опирается на fraud proofs (см. Fraud proof (доказательство мошенничества) в optimistic-rollup’ах);
• ZK-роллап публикует validity proof к состоянию.

В обоих случаях доказуемость корректности опирается на доступность блоб-данных.

• 5. Репликация и удаление.

Пока блобы живут на L1, участники успевают скачать их и сохранить в собственных DA-системах (архивы, внешние DA-слои). После этого блобы могут быть удалены из консенсус-слоя.

Эффект EIP-4844 для L2: комиссии и масштабирование

EIP-4844 заметно изменил экономику L2:

• Снижение стоимости публикации данных.

Переход с calldata на блобы:

• резко уменьшает цену за килобайт данных;
• позволяет rollup’ам сильно сократить комиссии для пользователей, особенно при высокой активности.

• Рост доступного DA-пространства.

Таргет по блобам на блок даёт отдельный канал пропускной способности, не конкурирующий напрямую с обычными L1-транзакциями.

• Подготовка к danksharding.

Архитектура с блобами и KZG-коммитментами — фундамент для будущего:

• data availability sampling;
• увеличения числа и объёма блобов;
• полноценного danksharding, когда L2 смогут расти ещё на порядки.

Эффект EIP-4844 стоит рассматривать вместе с общим развитием L2-экосистемы (см. L2-экосистема Ethereum: optimistic и ZK-rollups, L3 и shared-sequencers и Сравнение комиссий L1 и L2: сколько стоит транзакция в Ethereum и популярных L2).

Ограничения и риски EIP-4844

Несмотря на плюсы, у подхода есть ограничения:

• Ограниченный срок хранения данных.

Блобы не сохраняются навсегда:

• инфраструктура rollup’а должна успеть выгрузить и реплицировать данные;
• для долгосрочного хранения нужны архивы и внешние DA-решения;
• при ошибках в операционке возможны проблемы с восстановлением истории.

• Зависимость от параметров blob-рынка.

При всплесках спроса:

• blob base fee может существенно вырасти;
• комиссии L2 временно «откусят» часть выгоды от EIP-4844.

• Trusted setup для KZG.

Безопасность KZG-коммитментов опирается на честность хотя бы одного участника KZG-церемонии. Это не практический блокер, но важное теоретическое допущение.

• Это ещё не полный danksharding.

Proto-danksharding:

• не реализует DAS для всех узлов Ethereum;
• аккуратно ограничен по количеству/размеру блобов;
• всё ещё промежуточный этап по сравнению с целевым дизайном danksharding.

FAQ по EIP-4844

Чем блобы отличаются от calldata? Calldata навсегда остаётся в истории Ethereum, доступна EVM и оплачивается обычным gas. Блоб-данные:

• живут только в консенсус-слое и ограниченное время;
• не читаются из смарт-контрактов;
• оплачиваются по отдельному рынку blob gas и дешевле для больших объёмов.

Можно ли прочитать содержимое блоба из смарт-контракта? Нет. Контракт оперирует лишь хешами/коммитментами. Сами блобы доступны только на уровне узлов. Если приложению нужны данные on-chain, их по-прежнему нужно хранить в calldata или состоянии.

Сколько блобов может быть в блоке? На запуске:

• протокол нацеливается на несколько блобов на блок (таргет);
• есть верхний жёсткий лимит.

Точное значение параметров может эволюционировать в будущих апгрейдах.

Снижает ли EIP-4844 комиссии на L1? Прямо — нет. Обычные L1-транзакции продолжают конкурировать за обычный gas. EIP-4844 снижает стоимость DA для L2, что отражается на комиссиях в rollup’ах.

Это «готовый danksharding»? Нет, это proto-этап. Чтобы реализовать полный danksharding, Ethereum ещё предстоит:

• внедрить DAS и расширить пропускную способность DA;
• оптимизировать хранение/проверку данных;
• развивать stateless-клиентов и Verkle-деревья (см. Векторные коммитменты (vector commitments) — основа Verkle-деревьев и KZG в Ethereum и Verkle tree — компактные доказательства состояния для Ethereum).

См. также

• Ethereum (ETH)
• Архитектура Ethereum (EL/CL)
• Дорожная карта апгрейдов Ethereum
• Danksharding и масштабирование DA
• PeerDAS и выборочная проверка DA
• Data availability
• DA-решения для rollup’ов
• Layer 2 над Ethereum
• Обзор экосистемы L2
• Сравнение комиссий L1 и популярных L2
• Validity proof
• Fraud proof