Данктшардинг (Danksharding) — путь к массовому масштабированию Ethereum (после EIP-4844)

Данктшардинг (Danksharding) — направление масштабирования Ethereum, в котором сеть получает дешёвое и массовое хранилище данных для L2-роллапов за счёт «блобов» данных, отдельного рынка комиссий и выборочного доказуемого тестирования доступности данных (Data Availability Sampling, DAS). В отличие от классического «шардинга состояний», данктшардинг не делит состояние сети на части: он масштабирует пропускную способность публикации данных (data availability), что напрямую снижает издержки L2 и открывает путь к росту пропускной способности всей экосистемы.

Идея названа в честь исследователя Ethereum Dankrad Feist. Переход к полной модели идёт поэтапно: от прото-данктшардинга (EIP-4844, блобы + отдельный ценовой контур) к полноценному данктшардингу с DAS на уровне сети и дальнейшим наращиванием «блоб-пространства».

Коротко (зачем это нужно)

  • Больше данных → дешевле L2. Роллапы публикуют доказательства/трейсы в отдельные блоб-секции блока L1, не засоряя постоянное состояние. Это ончейн-гарантия доступности данных, необходимая для безопасности роллапов (и optimistic, и zk).
  • Отдельный рынок комиссий. Для «блобов» действует свой базовый тариф и своя «EIP-1559-подобная» динамика, поэтому цена за байт данных отвязана от обычного газа исполнения.
  • Лёгкие клиенты и децентрализация. В полной модели включается DAS: участники не скачивают все блобы, а выборочно проверяют доступность закодированных фрагментов. Это удерживает требования к узлам в разумных пределах и сохраняет децентрализацию.

Чем данктшардинг отличается от «классического» шардинга

  • Традиционный шардинг предполагал распил состояния и tx-потоков по многим шардам и их координацию. Данктшардинг идёт другим путём: состояние остаётся «единым», а масштабируется лента публикации данных. Это проще по реализации и совместимо с текущей архитектурой Ethereum (PoS + блокчейн исполнения), где масштабирование нагрузки исполнения уже вынесено на L2-уровень.
  • Ключевая разница — объект масштабирования. Данктшардинг увеличивает доступность данных (чтобы L2 могли дешево и безопасно «выкладывать» свои пакеты), а не количество независимых «мини-Ethereum» с отдельным состоянием.

Архитектура: из чего состоит данктшардинг

1) Блоб-данные (blobs). «Блоб» — это крупный блок двоичных данных (порядка ~128 KiB), который прикрепляется к транзакции особого типа и попадает в «боковой» сегмент блока L1. Блобы не хранятся навечно в полном узле: они обязаны сохраняться ограниченное время (около двух недель по эпохам), достаточное для того, чтобы все участники L2 гарантированно их скачали. При этом в основной цепи остаются коммитменты к этим данным (см. ниже), позволяющие проверять целостность и включение.

2) KZG-коммитменты и доказательства. Каждый блоб сопровождается полиномиальными KZG-коммитментами и компактными доказательствами корректности. Это позволяет проверять, что блоб действительно соответствует зафиксированному коммитменту, а также совместимо с будущим DAS: коммитменты и структура блоба заранее «подготовлены» для выборочного тестирования доступности.

3) Отдельный рынок «блоб-газа». Для блобов действует собственный базовый уровень комиссии и механика «excess blob gas» (аналог EIP-1559). В сети установлены цели по количеству блобов на блок и максимумы; если спрос выше цели, базовая цена блоб-пространства растёт, при падении спроса — снижается. Это убирает конкуренцию «данные vs исполнение» и сглаживает пики.

4) DAS (Data Availability Sampling). Полному данктшардингу необходим протокол выборочного тестирования доступности: узлы выбирают случайные доли закодированных блоб-данных и проверяют их доступность. Благодаря стирающей кодировке (erasure coding) достаточно доли фрагментов, чтобы с высокой вероятностью восстановить исходные данные, а значит — уверенно заявлять об их «публичной доступности».

5) Производство блоков и PBS. Данктшардинг укладывается в курс на разделение ролей «пропозер/билдер» (PBS): один пропозер выбирает готовый «пакет» (с транзакциями и блобами), который собирают специализированные билдеры, соревнующиеся ставками. В перспективе — вшитый в протокол PBS (ePBS), что ещё лучше синхронизирует рынок блок-построения с «блоб-пространством» и снижает риски централизации релеев/посредников.

Прото-данктшардинг (EIP-4844): что уже включено в сеть

Прото-данктшардинг — промежуточный этап, который уже активирован в сети вместе с апгрейдом Dencun. Он добавляет:

  • Новый тип транзакций с «блоб-данными».
  • KZG-коммитменты в заголовок/структуру блока и верификацию доказательств.
  • Отдельный рынок «блоб-газа» с целевым количеством блобов на блок (порог/максимум) и алгоритмом корректировки базовой цены.
  • Временное хранение блобов (порядок двух недель по эпохам), после чего остаются только коммитменты.

Этого достаточно, чтобы роллапы массово снизили издержки публикации данных и отвязались от дорогого calldata (которое хранится навечно и конкурирует с обычным газом исполнения). Уже на этом этапе многие L2 получают кратное снижение себестоимости батчей, а значит — и комиссии для пользователей.

Переходный штрих: часть L2 по инерции продолжала использовать calldata (привычный туллинг, лимиты блобов и т. д.), поэтому в дорожной карте исполнения предусмотрено дальнейшее «разведение» стимулов (например, повышение стоимости calldata и расширение блоб-пространства), чтобы экосистема окончательно перешла на «правильные рельсы» публикации данных.

Полный данктшардинг: что добавится поверх EIP-4844

Чтобы перейти от «прото» к полной модели, сети нужен следующий набор нововведений:

  • DAS в p2p-уровне — протокол «peer-to-peer data availability sampling», который позволит узлам не качать все блобы, а выборочно проверять доступность кусочков. Это даёт возможность безопасно поднимать лимиты на блобы и одновременно удерживать требования к железу.
  • Наращивание «блоб-пространства». По мере внедрения DAS сеть сможет увеличивать цель и максимум блобов на блок (по сравнению с прото-уровнем).
  • Совместная эволюция PBS/ePBS. Вшитый PBS (и «инклюжн-листы») повышают устойчивость к цензуре и упрощают координацию билдеров вокруг новых объёмов данных.
  • Инструменты для клиентов и лёгких узлов. Оптимизация синхронизации, хранение доказательств и кэширование, улучшение UX для операторов нод/валидаторов.

Итогом станет порядковый рост доступности данных при контролируемых требованиях к узлам, что даст L2 устойчиво низкую себестоимость публикации и высвободит потенциал для масштабирования TPS без ущерба децентрализации.

Как это снижает стоимость L2 на практике

У роллапов основная статья издержек — публикация данных L2 → L1 (для последующей проверки/восстановления состояния). До блобов это делалось через calldata в «исполнительной» части блока и конкурировало с обычными транзакциями. Теперь данные выносятся в блоб-сайдкар с другой ценовой динамикой и временным хранением, поэтому цена за байт заметно ниже и лучше предсказуема.

Дополнительно помогает сам дизайн блоба: крупная «плитка» фиксированного размера с отдельной тарифной моделью упрощает расчёт, а временное хранение снимает долгосрочную нагрузку на полные узлы. L2 получают:

  • Стабильный ончейн-уровень безопасности (данные доступны всем валидаторам/поверяющим).
  • Низкую и эластичную стоимость публикации даже в периоды горячего рынка.
  • Меньше накладных расходов на бриджи/доказательства за счёт стандартизации формата публикации.

Роль KZG-коммитментов и почему они «вперёд-совместимы» с DAS

KZG-коммитменты — это полиномиальные коммитменты к блобам. Их свойства:

  • Компактность: проверочные доказательства невелики и подходят для верификации на уровне блок-заголовка.
  • Однозначность: один коммитмент — конкретному полиному/набору данных.
  • Совместимость с DAS: удобно проверять малые выборки кусочков, не вытягивая весь блоб; структура блоба и коммитментов заранее «подготовлена» к выборочному тестированию.

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

PBS, MEV и билдеры: как рынок блоков меняется с данктшардингом

Proposer-Builder Separation (PBS) разделяет роли: валидатор-пропозер выбирает лучший блок (по биду), а билдеры соревнуются в сборке полезной нагрузки — транзакций и блобов. Плюсы связки с данктшардингом:

  • Больше специализации: появляются билдеры, оптимизирующие «блоб-пакеты» для роллапов и/или сетевого DAS.
  • Лучшее ценообразование: отдельный рынок «блоб-газа» + аукцион билдера → более прозрачная стоимость публикации данных.
  • Устойчивость к цензуре (с развитием ePBS/«инклюжн-листов»): пропозеру проще гарантировать включение «обязательных» элементов (в т.ч. критичных блобов).
  • Для операторов нод это означает: правила игры становятся яснее, а для L2 — встраиваемая предсказуемость времени публикации и цены.

Риски и «подводные камни»

  • Кратковременное хранение блобов. Оно экономит диски узлов, но заставляет операторов L2/архивы держать надёжные ретриверы: через ~две недели в L1 остаются только коммитменты.
  • Ограничения пропускной в «прото»-этапе. До включения DAS цель/максимум блобов консервативны; иногда L2 продолжают публиковать часть данных как calldata — по инерции инструментов или при пиковом спросе на блоб-пространство.
  • Рынок билдеров и централизация. Пока ePBS не «вшит», зависимость от внешних релеев и немногих билдеров может вызывать операционные/цензурные риски (их постепенно снимают архитектурой ePBS и инклюжн-листами).
  • Сложность клиентских реализаций. KZG, доказательства, новые типы транзакций, сетевые протоколы DAS — всё это требует строгих имплементаций и аудитов.

Практические рекомендации разработчикам

  • Переходите на блобы. Если ваш L2 всё ещё публикует данные через calldata — планируйте переход на блоб-публикацию. Это снизит издержки, упростит расчёты и уберёт зависимость от цен за газ исполнения.
  • Сервис ретривала. Постройте надёжный retrieval-контур: репликаторы/архивы + индексы для быстрой отдачи блобов пользователям и провайдерам доказательств.
  • Мониторинг «блоб-рынка». Отслеживайте цель/максимум блобов на блок, текущую базовую цену и динамику спроса — это влияет на стоимость батчинга.
  • Готовьтесь к DAS. Заранее заложите поддержку выборочного скачивания и проверки; держите в уме сетевую модель PeerDAS и требования к пирами.
  • Разделяйте риски. В интеграциях с биржами/кастоди проектируйте «мягкие деградации»: если блоб-рынок перегрет, временно снижайте размер батчей, используйте приоритеты и квоты.

Терминология (для закрепления)

Blob (блоб) — «плитка» данных, прикрепляемая к транзакции особого типа; хранится временно, а в блоке остаются коммитменты и доказательства.

KZG-коммитмент — компактное криптографическое «обязательство» к данным блоба; позволяет проверять корректность без скачивания всего. См. KZG-коммитменты (перспективная страница).

DAS — выборочное доказуемое тестирование доступности данных; ключ к масштабированию без роста требований к узлам. См. PeerDAS/DAS (перспективная страница).

PBS/ePBS — разделение ролей пропозера/билдера и его «вшитая» версия; повышает устойчивость и прозрачность рынка блоков. См. PBS (перспективная страница).

Calldata — постоянные данные в «исполнительной» части блока; дороже и конкурентнее, чем блобы.

Хронология и дорожная карта

Дата/этап Что произошло Значение для масштабирования
Dencun (2024) Активация EIP-4844: блобы, отдельный рынок комиссий, коммитменты KZG, временное хранение «Первый этаж» данктшардинга — L2 получают дешёвую публикацию данных
2024–2025 Экосистема адаптируется: миграция L2 на блобы, улучшение инструментов, «подталкивание» от calldata к блобам Снижение себестоимости батчей, рост загрузки блоб-пространства
Дальше Включение DAS на p2p-уровне (PeerDAS), постепенное увеличение целевых/макс. блобов, развитие ePBS Порядковый рост пропускной способности публикации данных без ущерба децентрализации

См. также в 24k Wiki

Блокчейн и Ethereum: Блокчейн — как устроен распределённый реестр, Ethereum

L2 и приложения: dApp и L2, DeFi

Криптография и доказательства: Zero-knowledge, zk-SNARKs

Инфраструктура и рынки: Биржи и он/офф-рамп

Прото-данктшардинг (EIP-4844), KZG-коммитменты, PeerDAS/DAS, Proposer-Builder Separation

Task Runner