Перейти к содержанию
Financial Context Wiki

Пространство блобов

Практическое руководство по проверке пространства блобов Ethereum: кодированной и полезной емкости, выборки и хранения PeerDAS, временного сохранения, вывода состояния роллапа и действующих ограничений конкретного форка.

Обновлено

Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.

Краткий ответ

Пространство блобов — ограниченная временная емкость Ethereum для доступности данных блобов, обязательства которых включены вместе с блоками. Это не пространство исполнения EVM, не хранилище контрактов, не постоянная файловая система и не токен. Транзакция типа 3 содержит версионированные хеши, а аутентифицированные данные блобов передаются в дополнительных объектах уровня консенсуса или столбцах PeerDAS. EVM может прочитать версионированный хеш и проверить раскрытие в точке, но не саму полезную нагрузку блоба.

PeerDAS расширяет блобы кодом стирания, делит расширенную матрицу на 128 columns и позволяет узлам хранить и проверять подмножества вместо загрузки каждым узлом каждого полного блоба. Это дает вероятностное локальное суждение о доступности, но не доказывает корректность исполнения роллапа, финальность Ethereum, безопасность моста или постоянную возможность извлечения. Емкость меняется между форками. На 2026-08-13 mainnet Ethereum после Fusaka BPO2 ориентируется на 14 blobs per block и допускает максимум 21, а одна транзакция ограничена 6 blobs.

Как это работает

  1. Зафиксируйте сеть, блок или слот, активный форк и расписание Blob-Parameter-Only, а также роллап и версию вывода состояния. Исторические 3/6, Pectra 6/9, текущие 14/21, тестовые сети и будущие параметры не взаимозаменяемы.
  2. Определите объект публикации: транзакцию типа 3, версионированные хеши, обязательства и доказательства KZG, индексы блобов, источник L1 и факт применения блобов Ethereum, а не calldata или альтернативной DA. Обязательство связывает данные, но само по себе не доказывает доступность байтов.
  3. Разделяйте единицы. Один блоб содержит 4,096 field elements * 32 bytes = 131,072 encoded bytes; произвольная полезная нагрузка обычно использует 31 bytes на элемент поля, то есть 126,976 usable bytes. Сжатие, форматирование, дополнение, blob gas, расширенные кодом стирания ячейки и байты приложения — разные величины.
  4. Проверьте ограничения расписания. Цель управляет ценовой обратной связью и не является зарезервированной емкостью. Максимум блока — предел консенсуса, а не ожидаемая пропускная способность. Ограничение PeerDAS 6 blobs per transaction отличается от текущего максимума 21 blobs per block.
  5. Проверьте путь доступности. PeerDAS использует одномерное расширение кодом стирания, аутентифицированные ячейки и столбцы, рассылку и запросы к пирам. При текущих параметрах узел проверяет минимум 8 columns и выполняет обязанности хранения; получение минимум 64 of 128 columns позволяет восстановить расширенную матрицу.
  6. Разделяйте состояния жизненного цикла: обязательство включено, столбцы данных получены и проверены, локальная проверка DA пройдена, блок L1 безопасен или финализирован, пакет роллапа декодирован и выведен, минимальное окно обслуживания действует, независимый архив испытан. Доступность не делает истинными все последующие состояния.
  7. Отработайте отсутствие столбцов, eclipse-атаку или разделение сети, задержку распространения, реорганизацию L1, несовпадение расписания или клиента, обновление формата роллапа и потерю архива. Получите, восстановите и сохраните нужные данные до окончания протокольного окна, а затраты пакетировщика и пользователя учитывайте по отдельной статье о комиссиях за блобы.

Разобранные примеры

  • Байтовые единицы одного блоба. Кодированная емкость равна 4,096 * 32 = 131,072 bytes = 128 KiB. Общая произвольная нагрузка равна 4,096 * 31 = 126,976 bytes = 124 KiB. Разница — 4,096 bytes, или 3.125% кодированной емкости; сжатие и форматирование роллапа дополнительно уменьшают нагрузку приложения.
  • Текущая емкость блока. При цели получаем 14 * 131,072 = 1,835,008 encoded bytes = 1.75 MiB и 14 * 126,976 = 1,777,664 usable bytes = 1.6953125 MiB. При максимуме — 21 * 131,072 = 2,752,512 encoded bytes = 2.625 MiB и 21 * 126,976 = 2,666,496 usable bytes = 2.54296875 MiB. Это зависящие от даты ограничения mainnet на блок до сжатия и форматирования.
  • Ограничения транзакции и блока. Транзакция с 6 blobs несет 786,432 encoded bytes = 0.75 MiB и 761,856 usable bytes = 0.7265625 MiB. Для максимального блока 21-blob нужны минимум 4 transactions, например 6 + 6 + 6 + 3; целевой блок 14-blob может состоять из 6 + 6 + 2. Ни одно распределение не является квотой роллапа.
  • Окно обслуживания и номинальный объем. 4,096 epochs * 32 slots * 12 seconds = 1,572,864 seconds = 18.2044444444 days. При номинальных 7,200 slots per day и цели 14-blob кодированный объем составляет 100,800 blobs per day = 12.3046875 GiB per day, а обычный полезный объем — 11.920166015625 GiB per day. Пропущенные слоты и фактическое включение меняют результат, а окно обслуживания не обещает постоянного архива.

Риски

  • Применение устаревшего форка или расписания Blob-Parameter-Only.
  • Смешение ограничений mainnet, тестовой или другой сети.
  • Принятие цели за гарантированную или зарезервированную емкость.
  • Принятие максимума за обычную ожидаемую пропускную способность.
  • Смешение лимита шести блобов на транзакцию с лимитом блока.
  • Смешение кодированных, полезных, сжатых, форматированных единиц и blob gas.
  • Пропуск дополнения или накладных расходов формата роллапа.
  • Обозначение calldata или альтернативной DA пространством блобов Ethereum.
  • Принятие версионированного хеша, не совпадающего с обязательством блоба.
  • Принятие корректного раскрытия KZG за доказательство доступности байтов.
  • Принятие выборки за полную локальную загрузку каждого блоба.
  • Смешение доступности данных с корректностью перехода состояния.
  • Смешение локальной проверки DA с финальностью L1 или роллапа.
  • Потеря столбцов из-за задержки, eclipse-атаки, разделения или коррелированных пиров.
  • Отказ восстановления или запроса к пирам при номинальной емкости.
  • Потеря или перестановка обязательства при реорганизации L1.
  • Истечение минимального окна обслуживания до вывода или оспаривания.
  • Зависимость от недоступного, поврежденного или неполного архива или индексатора.
  • Отказ вывода состояния роллапа после обновления сжатия или протокола.
  • Предположение о безопасности моста или выхода только из-за доступности блобов.

Распространенные заблуждения

  • Пространство блобов — постоянное хранилище, которое контракты читают как calldata.
  • Каждый байт блоба размером 128 KiB доступен для произвольной нагрузки приложения.
  • В PeerDAS каждый узел Ethereum загружает и постоянно хранит каждый полный блоб.
  • Обязательство KZG, успешная выборка или финализированное включение доказывают правильность состояния роллапа и возможность выхода.
  • Емкость mainnet навсегда закреплена на 3/6, 6/9 или текущем расписании 14/21.

Связанные темы

Источники

Навигация

Поиск по вики...