2024年3月のDencunアップグレードで実装されたEIP-4844は、イーサリアムのデータ保存モデルに大きな変革をもたらしました。従来のcalldataに加えて「ブロブ（blob）」という新しいデータ型が導入されたことで、レイヤー2ロールアップはL1へのデータ投稿コストを劇的に削減できるようになりました。
本記事では、ブロブトランザクションの技術的な仕組みを深掘りします。単なる「安くなった」という表面的な理解にとどまらず、なぜブロブが安いのか、どのような暗号学的保証が得られるのか、そして従来のデータ保存方法との本質的な違いは何かについて、体系的に解説していきます。
専門的な内容を含みますが、できる限りわかりやすい言葉で説明します。投資に関する判断はご自身でされるようお願いします。
従来のcalldataによるデータ保存の課題
calldataとは何か：EVM実行コンテキストでの役割
calldataは、イーサリアムのスマートコントラクト呼び出し時に引数として渡されるデータ領域です。EVM（Ethereum Virtual Machine）の実行中にアクセス可能であり、コントラクトは受け取ったcalldataを読み取って処理を行います。L2ロールアップはこのcalldataを使い、多数のトランザクションをまとめたバッチデータをL1スマートコントラクトに送信していました。
しかし、calldataには根本的なコスト上の問題があります。calldataに書き込まれたすべてのデータは、全てのフルノードが永遠に保持しなければなりません。ブロックチェーンの不変性という特性上、一度記録されたデータは削除できないため、イーサリアムノードのストレージ要件は年々増大し続けます。この永続的なストレージコストがcalldataを高価にしている主要な要因です。
L2ロールアップにとってのcalldataコスト問題
Optimismの2023年のデータによると、L2の運営コストのうち約70〜80%がL1へのデータ投稿（calldata）に費やされていたとされています。この高いデータ投稿コストは、L2ユーザーの手数料に直接反映されます。
具体的には、2023年のガス代高騰時にはOptimismでも1回のトランザクションで数十セントから1ドル以上の手数料がかかるケースがありました。これはL1（イーサリアムメインネット）に比べれば安いものの、理想的なスケーラビリティソリューションには程遠い状況でした。
ブロブの技術的構造：byte型からbytes48まで
ブロブの内部フォーマット：フィールド要素と多項式表現
EIP-4844のブロブは、単純なバイト配列ではなく、BLS12-381楕円曲線上の体（field）の要素として構造化されています。具体的には、1つのブロブは4096個のフィールド要素から構成され、各フィールド要素は32バイト（256ビット）です。したがって1ブロブの総容量は4096 × 32 = 131,072バイト（128KB）となります。
この構造をとる理由は、KZGコミットメントと多項式コミットメントスキームを適用するためです。ブロブデータを多項式の係数として解釈することで、暗号学的な証明の生成と検証を効率的に行うことができます。
ブロブの各フィールドとその意味
EIP-4844のトランザクション（タイプ3トランザクション）は、通常のトランザクションフィールドに加えて、ブロブ固有のフィールドを持ちます。
- blob_versioned_hashes：ブロブのバージョン付きハッシュのリスト（各32バイト）。EVMからアクセス可能な唯一のブロブ関連データ
- max_fee_per_blob_gas：ブロブガスに対して支払う最大価格（wei単位）
- blobs：実際のブロブデータ（ネットワーク上では伝播するが、実行ペイロードには含まれない）
- commitments：各ブロブに対応するKZGコミットメント（48バイト）
- proofs：KZGプルーフ（48バイト）
注目すべきは、blobsフィールドが実行ペイロード（execution payload）に含まれない点です。ブロブデータはビーコンブロック（コンセンサスレイヤー）を通じて伝播し、実行レイヤーとは分離された経路で処理されます。
KZGコミットメントの数学的基礎
多項式コミットメントスキームの仕組み
KZGコミットメントは、Kate、Zaverucha、Goldberg（2010年）によって提案された多項式コミットメントスキームです。このスキームの核心は、大きなデータ（多項式）を短い「コミットメント」（ダイジェスト）に変換し、そのデータの任意の点での値を短い「証明」（プルーフ）によって検証できるという特性にあります。
数学的には、次のように機能します。
- データをn次多項式f(x)として表現する
- 秘密のスカラー値τ（タウ）を使ってコミットメントC = f(τ)·Gを計算する（Gは楕円曲線の生成点）
- 任意の点zにおける値f(z)を証明するプルーフπを生成できる
- 検証者はCとπのみを使って、f(z)が正しいことを確認できる
イーサリアムではτを誰も知らないように「信頼できるセットアップ」（Trusted Setup Ceremony、KZG Ceremony）でパラメータを生成しました。2023年に実施されたこのセレモニーには14万人以上が参加し、セキュリティを担保しました。
BLOBHASH命令：EVMからのコミットメントアクセス
EIP-4844では、新しいEVM命令BLOBHASH（オペコード0x49）が導入されました。この命令を使うと、スマートコントラクトはトランザクションに付随するブロブのバージョン付きハッシュを参照できます。ただし、ブロブデータ本体にはEVMから直接アクセスできません。
バージョン付きハッシュは、KZGコミットメントのSHA256ハッシュの先頭を0x01（バージョン番号）で置き換えた32バイトの値です。将来的にKZGとは異なるコミットメント方式（たとえばSTARKベース）に移行する際も、バージョン番号を変えるだけで後方互換性を保てる設計になっています。
ブロブの生存期間：18日間の意味
なぜ18日間なのか：プルーニングの仕組み
ブロブデータの保持期間は4096エポック（1エポック = 約6.4分）で計算すると約18.2日となります。この数字は、Optimistic Rollupのチャレンジ期間（標準7日間）を大幅に上回るように設定されており、L2の不正証明システムが機能するのに十分な時間を確保しています。
保持期間が終了すると、ノードはブロブデータを削除できます（削除しなければならないわけではありませんが、デフォルトではプルーニングされます）。コミットメントとバージョン付きハッシュはブロックヘッダーとして永続的に保持されるため、過去のブロブの存在証明は残り続けます。
アーカイブサービスの必要性と現状
ブロブデータがプルーニングされるため、過去の特定のブロブ内容を参照したい場合には、アーカイブノードやサードパーティのアーカイブサービスが必要になります。現在は以下のようなサービスが存在します。
- Blobscan.com：ブロブデータの検索・閲覧が可能なオープンソースのブロックエクスプローラー
- Ethereum.org Blob Archive：イーサリアムファウンデーションが提供するアーカイブAPI
- EthStorage：ブロブデータを長期保存するための分散型ストレージプロトコル
L2プロジェクト自身もバッチデータのバックアップを保持していることが多く、実際の運用では大きな問題は生じていないと報告されています。
タイプ3トランザクションの処理フロー
メモリプール（mempool）でのブロブ処理
EIP-4844で導入されたタイプ3トランザクション（blob-carrying transaction）は、従来のタイプ0・1・2トランザクションとは異なる処理経路を持ちます。まず、タイプ3トランザクションはブロブデータとともにp2pネットワークに伝播されますが、サイズが大きいためmempoolでの扱いが従来とは異なります。
各ノードは、タイプ3トランザクションのブロブデータを一時的にキャッシュしますが、従来のトランザクションのような全ノードへの積極的な転送は行われません。代わりに、「ブロブサイドカー」と呼ばれる仕組みで、ブロブデータは実行ペイロードとは別経路で伝播されます。
ブロック提案からファイナリティまでの流れ
バリデーターがブロックを提案する際、タイプ3トランザクションの実行ペイロードにはブロブデータ本体は含まれず、代わりにblob_versioned_hashesのみが含まれます。ビーコンブロックにはブロブサイドカーが添付され、コンセンサスレイヤーを通じて伝播されます。
他のバリデーターは、KZGコミットメントとプルーフを検証することで、ブロブデータの整合性を確認します。ブロブ全体をダウンロードせずに検証できるため、バリデーターの負荷を抑えられます。将来的にDASが実装されると、さらに少ないデータダウンロードで検証が可能になります。
クライアント実装における対応状況
主要イーサリアムクライアントのブロブ実装
EIP-4844の実装にあたって、すべての主要なイーサリアムクライアントがアップデートを行いました。実行クライアント側では、Geth、Nethermind、Besu、Erigonが対応しています。コンセンサスクライアント側では、Prysm、Lighthouse、Teku、Nimbus、Lodestarが対応しています。
各クライアントのブロブ実装には若干の差異があり、特にブロブのキャッシュ管理やp2p伝播の実装方法に違いがあります。Dencunアップグレードの本番実装前のテストネット検証では、クライアント間の相互運用性問題も発見・修正されました。
L2プロジェクトのブロブ採用状況
Dencunアップグレード後、主要なL2プロジェクトは比較的迅速にブロブへの移行を完了しました。Optimism、Arbitrum、Base、Starknet、zkSync Eraなどの主要プロジェクトは、2024年3〜4月中にブロブを使ったバッチ投稿に切り替えました。
移行後の効果として、各L2で平均トランザクション手数料が大幅に低下しました。特にBaseでは手数料が0.01ドル以下になるケースも報告されており、マイクロペイメントの実用化が現実に近づいています。ただし手数料はブロブ需要によって変動するため、参考程度に捉えてください。
まとめ
ブロブトランザクションは、単なる「安いデータ保存手段」ではなく、暗号学的な保証を持ちながら一時的にのみデータを保持するという、まったく新しい設計思想に基づいています。KZGコミットメントによって整合性が保証されつつ、約18日後にデータが削除されることでノードのストレージ負荷が抑えられます。
この設計は、L2ロールアップが「L1の安全性を継承しながら低コストで運用する」という目標を達成するために最適化されており、将来のDanksharding実装への重要な足がかりとなっています。イーサリアムエコシステムの技術的発展を追う上で、ブロブトランザクションの仕組みを理解することは非常に有益です。
よくある質問
ブロブトランザクションはどのウォレットから送信できますか？
現時点では、エンドユーザーが直接ブロブトランザクションを送信するユースケースはほとんどありません。主にL2ロールアップのシーケンサーが、バッチデータの投稿に使用します。将来的にはより多くのアプリケーションがブロブを活用する可能性がありますが、現状では一般ユーザーが意識する機会は限られています。
KZGセレモニーの「信頼できるセットアップ」は安全ですか？
KZGセレモニー（Powers of Tau）では、参加者の全員がランダムな秘密値を生成し、そのうち一人でも秘密を守れば全体のセキュリティが保たれます。2023年のセレモニーには14万人以上が参加しており、現実的なリスクは非常に低いと評価されています。ただし、信頼できるセットアップが不要なSTARKベースの代替案も研究が続いています。
ブロブデータの最大スループットはどのくらいですか？
現在の設定（ターゲット3ブロブ/ブロック、ブロック時間12秒）では、ブロブによる理論的最大スループットは1秒あたり約32KB（3×128KB÷12秒）程度です。これはL2全体で共有されるリソースのため、L2が増えると競合が生じる可能性があります。完全なDanksharding実装後は64ブロブ/ブロックとなり、約10倍以上のスループットが期待されます。
※本記事は情報提供を目的としており、投資を推奨するものではありません。暗号資産への投資は元本割れのリスクがあります。投資判断はご自身の責任で行ってください。
