---
title: "Пространство блобов"
description: "Практическое руководство по проверке пространства блобов Ethereum: кодированной и полезной емкости, выборки и хранения PeerDAS, временного сохранения, вывода состояния роллапа и действующих ограничений конкретного форка."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Пространство блобов
> Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.
## Краткий ответ
Пространство блобов — ограниченная временная емкость 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`.
## Связанные темы
- [Комиссии за блобы и затраты роллапов](/ru/crypto/blob-fee-rollup-cost/)
- [Выборочная проверка доступности данных](/ru/crypto/data-availability-sampling/)
- [Роллап](/ru/crypto/rollup/)
## Источники
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (дата обращения: 2026-08-13)
- [EIP-7594: PeerDAS - Peer Data Availability Sampling](https://eips.ethereum.org/EIPS/eip-7594) - Ethereum Improvement Proposals (дата обращения: 2026-08-13)
- [EIP-7840: Add blob schedule to EL config files](https://eips.ethereum.org/EIPS/eip-7840) - Ethereum Improvement Proposals (дата обращения: 2026-08-13)
- [EIP-7892: Blob Parameter Only Hardforks](https://eips.ethereum.org/EIPS/eip-7892) - Ethereum Improvement Proposals (дата обращения: 2026-08-13)
- [Checkpoint #8: Jan 2026](https://blog.ethereum.org/2026/01/20/checkpoint-8) - Ethereum Foundation Blog (дата обращения: 2026-08-13)
- [Fulu -- Data Availability Sampling Core](https://github.com/ethereum/consensus-specs/blob/master/specs/fulu/das-core.md) - Ethereum Consensus Specifications (дата обращения: 2026-08-13)
- [Data availability](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org (дата обращения: 2026-08-13)
- [Blockchain Data Storage Strategies](https://ethereum.org/developers/docs/data-availability/blockchain-data-storage-strategies/) - Ethereum.org (дата обращения: 2026-08-13)
Source: https://wiki.fcontext.com/ru/crypto/blobspace/index.mdx