EIP-4844（Proto-Danksharding）の導入によって、イーサリアムには「ブロブトランザクション」という全く新しい種類のトランザクションが追加されました。通常のイーサリアムトランザクションとは異なる構造を持つこのトランザクションが、どのように機能するのかを理解することは、ブロックチェーン技術の深い理解につながります。
本記事では、ブロブトランザクションの内部構造から、ネットワーク上でのデータ伝播、バリデーターノードの処理フロー、そしてL2ロールアップがどのようにブロブを活用しているかまでを詳細に解説します。
技術的な詳細を理解することで、なぜEIP-4844がここまで革命的なコスト削減を実現できたのか、そして将来的な完全Dankshardingへの道筋が見えてくるはずです。
ブロブトランザクションの基本構造
通常トランザクションとの違い
イーサリアムの通常のトランザクション（タイプ0、タイプ1、EIP-1559のタイプ2）と比較して、EIP-4844で導入されたブロブトランザクション（タイプ3）には大きな構造的違いがあります。
通常のトランザクションには送信者アドレス、受信者アドレス、送金額、ガス代、nonce、データ（calldata）、署名などが含まれています。ブロブトランザクションにはこれらに加えて、ブロブデータ本体、KZGコミットメント、KZGプルーフという3つの追加フィールドが含まれています。
ただし重要な点として、ブロブデータ本体はトランザクションの「サイドカー（sidecar）」として扱われます。ブロックチェーンに永続的に記録されるのはコミットメント値のみであり、ブロブデータ本体は約18日後に削除されます。この設計がストレージ効率を保ちながらデータを提供できる仕組みの核心です。
ブロブの内部フォーマット
1つのブロブは4096個のフィールド要素（field elements）で構成されます。各フィールド要素は32バイトの整数値であり、BLS12-381楕円曲線の位数未満の値です。つまり1つのブロブの容量は4096 × 32 = 131,072バイト（約128KB）となります。
ブロブデータはBLS多項式として解釈されます。4096個の評価点でサンプリングされた多項式という概念で表現することで、KZGコミットメントの計算が可能になります。このような多項式表現はなじみのない概念かもしれませんが、要は128KBのデータを数学的に扱いやすい形式に変換したものと理解できます。
L2ロールアップがブロブにデータを詰め込む際は、独自のエンコード方式でロールアップのトランザクションデータを圧縮・変換して格納します。受信側（L2のフルノード）はこのエンコード方式を理解してブロブからデータを復元します。
KZGコミットメントとプルーフの仕組み
コミットメント計算のプロセス
ブロブトランザクションをネットワークに送信する前に、送信者（通常はL2のシーケンサー）はブロブデータからKZGコミットメントを計算する必要があります。
KZGコミットメントの計算には、信頼されたセットアップ（Trusted Setup）で生成された「構造化参照文字列（SRS: Structured Reference String）」が使用されます。SRSはブロックチェーンノードがあらかじめ保持している公開パラメータです。ブロブの多項式表現とSRSを組み合わせることで、48バイトという非常にコンパクトなコミットメント値が計算できます。
重要なのは、異なるブロブデータからは必ず異なるコミットメント値が生成される（衝突困難性）という暗号的性質です。したがって、コミットメント値が一致すれば、そのブロブデータが正確に存在することが保証されます。
プルーフによる検証の効率化
KZGプルーフは、ブロブ多項式の特定の点における評価値が正しいことを証明するためのデータです。プルーフのサイズもわずか48バイトと非常にコンパクトです。
検証者（バリデーターノード）はコミットメント値とプルーフを使って、ブロブデータの任意の点での値を効率的に検証できます。この検証操作はKZGコミットメントのペアリング検証として実装されており、ブロブ全体をダウンロードしなくても正確性を確認できます。
この特性が将来のDankshardingで重要になります。完全なDankshardingでは各バリデーターがブロブ全体をダウンロードせず、ランダムサンプリングとプルーフによってデータ可用性を確認するDAS（Data Availability Sampling）が実装される予定です。
ブロブのネットワーク伝播とゴシッププロトコル
サイドカーとしての伝播
EIP-4844では、ブロブデータはトランザクションデータとは別の伝播経路を持つように設計されています。ブロブデータとそのコミットメント・プルーフをまとめた「ブロブサイドカー（BlobSidecar）」は、イーサリアムのコンセンサス層のP2Pネットワークを通じて伝播します。
これはトランザクションが実行層のP2Pネットワークで伝播するのとは異なる経路です。イーサリアムのDencunアップグレード以降、コンセンサス層のノードがブロブサイドカーを受信・検証・保存する責任を持ちます。実行層のノードはブロブデータのコミットメント値のみを保持します。
この分離設計により、ブロブデータの流通がブロックの伝播を妨げることなく、独立して処理できます。高スループットと低レイテンシを両立させるための重要な設計判断です。
ブロブの保存期間と削除メカニズム
コンセンサス層のノードはブロブサイドカーを約18日間（正確には4096エポック × 32スロット = 131,072スロット ≈ 18.2日）保存します。この期間は、L2ロールアップが異議申し立て（チャレンジ）に必要なデータが確保できる期間として設計されています。
18日を超えたブロブデータは各ノードの実装に従って削除されます。Ethereumの仕様では削除は義務ではなく、ノードオペレーターは必要に応じてより長期間保持することも可能ですが、ネットワークの標準的な動作としては18日後に削除されます。
Ethereum Portalネットワークや独立したデータアーカイバーサービスがブロブデータの長期保存を提供することで、必要に応じて古いブロブデータにアクセスできる仕組みが整備されつつあります。
L2ロールアップがブロブを使用する仕組み
オプティミスティックロールアップの活用方法
OptimismやArbitrumといったオプティミスティックロールアップは、L1にデータを提出する方法としてブロブを活用しています。以前は通常のトランザクションのcalldataとしてロールアップのデータを提出していましたが、EIP-4844以降はブロブを使用します。
オプティミスティックロールアップのシーケンサーは、L2で処理したトランザクションデータをブロブにまとめて定期的にL1に提出します。不正証明（Fraud Proof）の期限である7日間、このブロブデータが利用可能であれば十分であり、18日間の保存期間は余裕を持って設計されています。
実際には、ブロブ1つあたりの容量128KBに、複数のトランザクションを圧縮して詰め込みます。Optimismの場合、ひとつのブロブに数百から数千件のL2トランザクションを格納できます。これにより、L1への提出コストをL2の多数のユーザーで分担する効率的な構造が実現します。
zkEVMとブロブの親和性
zkEVM系のロールアップ（zkSync Era、Polygon zkEVMなど）は、ゼロ知識証明と組み合わせてブロブを活用しています。zkEVMはL2のトランザクションの正確性を数学的に証明するゼロ知識証明を生成し、この証明とともにトランザクションデータをL1に提出します。
ゼロ知識証明自体はサイズが比較的大きいため、calldata経由でL1に提出するとガス代が高くなる問題がありました。EIP-4844では証明の補助データをブロブに格納することで、L1提出コストを大幅に削減できます。
zkEVMはオプティミスティックロールアップと比べてL1へのデータ提出頻度が高い傾向があるため、EIP-4844によるコスト削減効果が特に大きく表れる特性があります。
ブロブ手数料とガス代の計算方法
ブロブベースフィーの算出ロジック
EIP-4844は通常のガス市場とは独立したブロブ専用の手数料市場を導入しました。ブロブのベースフィー（base fee per blob gas）は、前のブロックのブロブ使用量に基づいて自動調整されます。
具体的には、前ブロックのブロブ数がターゲット（3ブロブ）を上回った場合、次のブロックのブロブベースフィーが増加します。下回った場合は減少します。この調整はEIP-1559の通常のガスベースフィーと同様のメカニズムで、約12.5%の増減幅で行われます。
ブロブの手数料はブロブガス単位（blob gas units）で表され、1ブロブは131,072のブロブガスに相当します。支払う手数料はブロブガス量 × ブロブベースフィーで計算されます。現状のブロブベースフィーは通常のガスに比べて非常に低コストであり、L2のデータ提出コストの大幅削減を可能にしています。
コールデータとブロブのコスト比較
EIP-4844以前、L2はL1のコールデータを使ってトランザクションデータを提出していました。コールデータのコストはゼロバイトが4ガス、非ゼロバイトが16ガスです。128KBのデータをすべて非ゼロバイトで提出した場合、16 × 131,072 = 2,097,152ガスとなります。
EIP-4844のブロブでは同じ128KBのデータを1ブロブ = 131,072ブロブガスで提出でき、ブロブベースフィーが非常に低い（通常のガス価格の1/1000以下の場合もある）ため、実質的なコストはコールデータ経由の100分の1以下になることがあります。
ただし、ブロブベースフィーはブロブ需要が増えると上昇します。L2の採用が増えてブロブの使用量がターゲット（3ブロブ/ブロック）を継続的に超えると、コスト削減効果が薄れる可能性があります。これが完全なDankshardingでブロブキャパシティを大幅に拡大する必要性の背景にあります。
バリデーターノードへの影響
ストレージとネットワーク帯域幅の増大
EIP-4844の実装によって、バリデーターノードは新たな負荷を担うことになりました。各ブロックで最大6ブロブ（約768KB）のデータを受信・検証・保存する必要があります。18日間の保存期間を考慮すると、ブロブデータだけで最大約100GBの追加ストレージが必要になる計算です。
ネットワーク帯域幅についても、ブロブサイドカーの伝播によって増大します。EIP-4844の仕様設計では、これらの追加負荷が一般的な家庭用インターネット接続でも対応可能な範囲に収まるよう慎重に調整されました。バリデーターの分散性（誰でもバリデーターになれる環境）を維持することがイーサリアムの分散化にとって重要だからです。
クライアント実装の対応状況
Dencunアップグレードに向けて、すべての主要なイーサリアムクライアント実装がEIP-4844に対応しました。実行層クライアントのGeth、Nethermind、Besu、Erigon、そしてコンセンサス層クライアントのPrysm、Lighthouse、Teku、Nimbus、Lodesstarなど、多様なクライアント実装が並行して動作することで、クライアントの多様性によるセキュリティが保たれています。
特にコンセンサス層クライアントはブロブサイドカーの処理に直接関わるため、実装の正確性が重要です。複数の独立したクライアントチームが異なるプログラミング言語で実装を行っており、特定のクライアントのバグがネットワーク全体に影響することを防いでいます。
まとめ
ブロブトランザクションは、通常のイーサリアムトランザクションとは異なる構造を持つ新しいデータ形式です。KZGコミットメントによるデータの暗号的保証、独立した手数料市場、約18日間の一時保存設計など、それぞれの技術的選択がL2コスト削減という目標に向けて緻密に設計されています。
技術的な詳細を理解することは、EIP-4844の限界や将来的な課題を把握するためにも重要です。ブロブキャパシティの制限、長期データ保存の課題、完全Danksharding実現までの道筋など、まだ解決すべき課題も存在します。イーサリアムの技術進化を追っていくうえで、これらの基礎知識は不可欠といえるでしょう。
よくある質問
Q. ブロブはEVMから直接読み取れますか？
ブロブデータ本体はEVM（スマートコントラクト）から直接読み取ることはできません。スマートコントラクトからアクセスできるのはブロブのコミットメント値とプルーフのみです。これはEVM外のコンセンサス層でブロブデータが管理されているためです。L2のコントラクトはコミットメント値を参照してデータの正確性を検証します。
Q. 1ブロックに含められるブロブの最大数はいくつですか？
Dencunアップグレード時点では、1ブロックあたり最大6ブロブが含められます。ターゲット（目標値）は3ブロブに設定されており、需要に応じてベースフィーが調整されます。将来的な完全Dankshardingでは、この上限が大幅に拡大される予定です。
Q. ブロブトランザクションを送信するにはどのようなツールが必要ですか？
開発者向けには、ethers.js（v6以降）やweb3.py、viem（JavaScript）などの主要なライブラリがEIP-4844のブロブトランザクションをサポートしています。L2のシーケンサーはこれらのライブラリを使用してブロブトランザクションをL1に提出しています。一般ユーザーはL2のdAppsを普通に使うだけでよく、ブロブを意識する必要はありません。
※本記事は情報提供を目的としており、投資を推奨するものではありません。暗号資産への投資は元本割れのリスクがあります。投資判断はご自身の責任で行ってください。
