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

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

• Больше доступного места под данные → дешевле L2.

Роллапы публикуют доказательства и трассы исполнения в отдельные блоб-секции блока L1, не засоряя постоянное состояние. Это ончейн-гарантия доступности данных, необходимая для безопасности и optimistic-, и zk-роллапов.

• Отдельный рынок комиссий для данных.

Для «блобов» действует свой базовый тариф и своя динамика по принципу EIP-1559, поэтому цена за байт данных отвязана от обычного газа исполнения.

• Лёгкие клиенты и децентрализация.

В полной модели включается DAS: узлы не скачивают все блобы, а выборочно проверяют доступность закодированных фрагментов. Это удерживает требования к узлам в разумных пределах и сохраняет децентрализацию L1.

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

Традиционный шардинг в ранних планах Ethereum предполагал:

• распил состояния и потока транзакций по множеству шардов;
• сложную координацию между ними и кросс-шардные операции.

Данктшардинг идёт другим путём:

• состояние Ethereum остаётся единым;
• масштабируется именно лента публикации данных для L2;
• безопасность и финальность остаются на уровне Layer-1, а масштабирование вычислений выносится на L2.

Иными словами, объект масштабирования — данные, а не «несколько мини-Ethereum с отдельными состояниями». Это проще для реализации и хорошо согласуется с rollup-centric roadmap.

Proto-danksharding (EIP-4844): что уже работает

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

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

Этого достаточно, чтобы:

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

Часть L2 по инерции всё ещё использует calldata (исторические тулчейны, ограничения по блобам и т.п.), поэтому в roadmap Ethereum предусмотрены дальнейшие стимулы к миграции: повышение относительной стоимости calldata и постепенное расширение блоб-пространства.

Отдельный обзор: Proto-danksharding (EIP-4844).

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

Чтобы перейти от «proto» к полной модели, Ethereum нужно:

• внедрить DAS на уровне p2p-сети (PeerDAS и аналоги), чтобы узлы могли безопасно работать с выборочным скачиванием фрагментов;
• увеличить цель и максимум блобов на блок, опираясь на DAS;
• эволюционировать PBS → ePBS, чтобы:
  • снизить зависимость от внешних релеев;
  • лучше учитывать блоб-пространство в аукционах блоков;
• улучшить инструменты для клиентов и лёгких узлов:
  • оптимизированная синхронизация;
  • хранение коммитментов и кэшей;
  • удобные режимы работы для валидаторов.

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

Как данктшардинг снижает стоимость L2 на практике

У большинства L2-роллапов основная статья расходов — публикация данных L2 → L1, чтобы при необходимости можно было восстановить состояние или оспорить его. До EIP-4844 это делалось через calldata:

• данные конкурировали с обычными транзакциями за место в блоке;
• хранение было «вечным» — каждый байт навсегда оставался в истории.

С появлением блобов:

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

Для L2 это означает:

• меньше расходов на батчинг и более агрессивную упаковку транзакций;
• более низкие комиссии для пользователей;
• меньше стимулов искать компромиссные (и менее безопасные) модели DA.

Роль KZG-коммитментов и совместимость с DAS

KZG-коммитменты — полиномиальные коммитменты к данным блоба. Их свойства важны для данктшардинга:

• компактные доказательства, подходящие для проверки в контексте блока;
• однозначная привязка к исходным данным;
• удобство для DAS: можно проверять отдельные точки/фрагменты, не загружая весь блоб.

Благодаря этому:

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

Подробнее см. KZG-коммитменты и PeerDAS и Data Availability Sampling.

PBS, MEV и билдеры в эпоху данктшардинга

С ростом объёма данных для L2 меняется и рынок блоков:

• появляются билдеры, специализирующиеся на сборке блоков с учётом блоб-пространства и прибыли от MEV;
• отдельный рынок «блоб-газа» встраивается в аукционы PBS;
• в будущем ePBS и механизмы «списков включения» (inclusion lists) должны:
  • повысить устойчивость к цензуре;
  • упростить прогнозируемость включения критичных блобов.

Для операторов узлов это означает:

• более сложный, но более прозрачный рынок блок-производства;
• рост числа роллапов и специализированных билдеров, работающих с блобами.

Подробнее про разделение ролей см. PBS (Proposer-Builder Separation).

Риски и «подводные камни» данктшардинга

• Краткосрочное хранение блобов.

Хорошо для дисков узлов, но требует надёжной инфраструктуры ретривала у L2 (архивы, репликаторы). После истечения срока в L1 остаются только коммитменты.

• Консервативные лимиты на этапе proto-danksharding.

Пока DAS не внедрён, цель и максимум по блобам ограничены. В пиковые моменты часть L2 может продолжать использовать calldata или ограничивать размер батчей.

• Рынок билдеров и централизация.

До ePBS сеть зависит от внешних релеев и небольшого числа крупных билдеров; это создаёт операционные и цензурные риски, которые нужно снижать архитектурой и конкуренцией.

• Сложность реализации.

KZG, новые типы транзакций, p2p-протоколы DAS и PBS требуют аккуратных имплементаций и аудитов. Ошибки на этом уровне затрагивают всю сеть и L2-экосистему.

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

• Переходите на блобы.

Если ваш роллап всё ещё публикует данные через calldata, планируйте миграцию на блоб-транзакции — это снизит издержки и отвяжет вас от цен обычного газа.

• Стройте надёжный контур ретривала.

Нужны репликаторы/архивы и индексы, которые быстро отдают блобы пользователям, провайдерам доказательств и аналитическим сервисам.

• Следите за рынком блоб-газа.

Мониторьте цель/максимум блобов на блок, базовую цену и загрузку. Это критично для планирования частоты и размера батчей.

• Готовьтесь к DAS.

Закладывайте в дизайн клиента поддержку выборочного скачивания и проверки фрагментов данных; учитывайте будущие требования PeerDAS к сети.

• Проектируйте «мягкую деградацию».

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

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

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

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

• DAS (Data Availability Sampling) — выборочное доказуемое тестирование доступности данных; ключ к масштабированию DA без роста требований к узлам.

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

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

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

См. также

• Ethereum (ETH)
• Дорожная карта обновлений Ethereum
• Layer-1 (L1)
• Layer-2 (L2) на Ethereum
• Layer-2 и роллапы на Ethereum — технический хаб
• Data Availability (доступность данных)
• Роллап (rollup) как L2 над Ethereum
• Блокчейн-тримлемма
• Proto-danksharding (EIP-4844)
• KZG-коммитменты
• Апгрейд Ethereum Fusaka — PeerDAS, масштабирование L2 и новые подписи
• PBS (Proposer-Builder Separation)