---
title: "ブロブスペース"
description: "イーサリアムのブロブスペース、符号化済み・利用可能容量、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.

# ブロブスペース

> 教育目的の情報であり、財務・セキュリティ上の助言ではありません。ブロブ・スケジュール、PeerDAS の前提、クライアントの挙動、ロールアップの導出、アーカイブへのアクセスは変更または破綻する可能性があります。

<a id="answer"></a>

## 直接の答え

ブロブスペースは、ブロックとともにコミットされるブロブに対してイーサリアムが提供する、上限付きで一時的なデータ可用性容量です。EVM 実行用ブロックスペース、コントラクトストレージ、永久ファイルシステム、トークンではありません。タイプ 3 取引はバージョン付きハッシュを含み、認証済みブロブデータはコンセンサス層のサイドカーまたは PeerDAS のデータ列を通じて伝送されます。EVM はバージョン付きハッシュを参照して開示点を検証できますが、ブロブのペイロードを直接読めません。

PeerDAS はブロブを消失訂正符号で拡張し、拡張行列を `128 columns` に分割します。全ノードに全ブロブのダウンロードを求めず、各ノードが一部をカストディしてサンプリングします。これは確率的なローカル可用性判断を支えますが、ロールアップ実行の有効性、イーサリアムのファイナリティ、ブリッジの安全性、永久的な取得可能性を証明しません。容量はフォークで変わります。`2026-08-13` 時点で Fusaka BPO2 後のメインネットは 1 ブロック当たり `14 blobs per block` を目標とし、最大 `21` を許可します。1 ブロブ取引の上限は `6 blobs` です。

<a id="mechanism"></a>

## 仕組み

1. ネットワーク、ブロックまたはスロット、有効なフォークと BPO スケジュール、ロールアップと導出版を確定します。過去の `3/6`、Pectra の `6/9`、現在の `14/21`、テストネット、将来の値は相互に流用できません。
2. 投稿対象を特定します。タイプ 3 取引、バージョン付きハッシュ、KZG コミットメントと証明、ブロブのインデックス、L1 起点を記録し、ロールアップが calldata や代替 DA ではなくイーサリアムのブロブを実際に使ったか確認します。コミットメントはデータを拘束しますが、バイト列が利用可能だったことを単独では証明しません。
3. 単位を分けます。1 ブロブは `4,096 field elements * 32 bytes = 131,072 encoded bytes` です。制約のないペイロードには通常、フィールド要素当たり `31 bytes`、合計 `126,976 usable bytes` を使います。圧縮、フレーミング、パディング、ブロブガス、消失訂正符号で拡張されたセル、アプリケーションのバイト数は別の量です。
4. スケジュール上限を確認します。目標値は価格フィードバックを導くもので、予約容量ではありません。ブロック最大値はコンセンサス上の上限で、期待スループットではありません。PeerDAS の `6 blobs per transaction` と現在のブロック上限 `21 blobs per block` は別です。
5. 可用性経路を検証します。PeerDAS は一次元の消失訂正符号拡張、認証済みセルと列、gossip、ピア要求を使います。現在の値ではノードは少なくとも `8 columns` をサンプリングし、カストディ義務も負います。`64 of 128 columns` 以上を取得すると拡張行列を再構築できます。
6. コミットメント収録済み、データ列取得・検証済み、ローカル DA 検査合格、L1 ブロックが安全またはファイナライズ済み、ロールアップ・バッチの復号・導出済み、最低提供期間内、独立アーカイブ検査済みという各状態を分けて追跡します。可用性だけで後続状態が成立するわけではありません。
7. 列欠落、エクリプス攻撃・ネットワーク分断、伝播遅延、L1 再編、スケジュール・クライアント不一致、ロールアップ形式更新、アーカイブ喪失を演習します。プロトコル期間終了前に必要なデータを取得・再構築・保存し、バッチャーと利用者の費用会計には別のブロブ手数料トピックを使います。

<a id="example"></a>

## 計算例

- **1 ブロブのバイト単位。** 符号化容量は `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` です。いずれも圧縮・フレーミング前の、日付とメインネットに固有のブロック当たり上限です。
- **取引上限とブロック上限。** `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` です。スロット欠落と実際の収録数で実現値は変わり、提供期間は永久アーカイブの保証ではありません。

<a id="risks"></a>

## リスク

- 古いフォークまたは BPO スケジュールを適用する。
- メインネット、テストネット、別ネットワークの上限を混同する。
- 目標値を保証・予約容量とみなす。
- 最大値を通常の期待スループットとみなす。
- 取引当たり 6 ブロブとブロック上限を混同する。
- 符号化、利用可能、圧縮、フレーミング、ブロブガスの単位を混同する。
- パディングやロールアップ形式のオーバーヘッドを落とす。
- calldata や代替 DA をイーサリアムのブロブスペースと表示する。
- ブロブのコミットメントと一致しないバージョン付きハッシュを受け入れる。
- 有効な KZG 開示証明を、バイト列が利用可能だった証明とみなす。
- サンプリングを全ブロブの完全なローカルダウンロードとみなす。
- データ可用性と状態遷移の有効性を混同する。
- ローカル DA 検査と L1 またはロールアップのファイナリティを混同する。
- 遅延、エクリプス攻撃、分断、相関したピアで列を失う。
- 名目容量があっても再構築またはピア要求に失敗する。
- L1 再編でコミットメントを失う、または順序が変わる。
- 導出や異議申立て前に最低提供期間が終わる。
- 利用不能、破損、不完全なアーカイブまたはインデクサーに依存する。
- 圧縮・プロトコル更新後にロールアップの導出が失敗する。
- ブロブが利用可能というだけでブリッジや退出を安全とみなす。

<a id="misconceptions"></a>

## よくある誤解

- ブロブスペースはコントラクトが calldata のように読める永久ストレージである。
- `128 KiB` ブロブの全バイトを制約なくアプリケーションに使える。
- PeerDAS 下でも全イーサリアムノードが全ブロブを完全にダウンロードして永久保存する。
- KZG コミットメント、サンプリング成功、ファイナライズ済み収録が、ロールアップ状態の正しさと利用者の退出可能性を証明する。
- メインネット容量は `3/6`、`6/9` または現在の `14/21` に永久固定される。

<a id="related"></a>

## 関連トピック

- [ブロブ手数料とロールアップのコスト](/ja/crypto/blob-fee-rollup-cost/)
- [データ可用性サンプリング](/ja/crypto/data-availability-sampling/)
- [ロールアップ](/ja/crypto/rollup/)

<a id="sources"></a>

## 出典

- [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/ja/crypto/blobspace/index.mdx