本文へ移動
Financial Context Wiki

ブロブスペース

イーサリアムのブロブスペース、符号化済み・利用可能容量、PeerDAS のサンプリングとカストディ、一時的保持、ロールアップの導出、フォーク依存の現行上限を検証重視で解説します。

更新日

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

直接の答え

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

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

仕組み

  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 再編、スケジュール・クライアント不一致、ロールアップ形式更新、アーカイブ喪失を演習します。プロトコル期間終了前に必要なデータを取得・再構築・保存し、バッチャーと利用者の費用会計には別のブロブ手数料トピックを使います。

計算例

  • 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 です。スロット欠落と実際の収録数で実現値は変わり、提供期間は永久アーカイブの保証ではありません。

リスク

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

よくある誤解

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

関連トピック

出典

ナビゲーション

Wiki を検索...