# [EIP8134] Blobパラメータだけを変える軽量アップグレードBPO1の仕組みを理解しよう！ > EIP-8134は、Ethereumネットワークで初めて実施されたBlob Parameter Only（BPO）アップグレードであるBPO1の公式記録です。 - URL: https://cardene.dev/articles/e234a68c68fee22c1e52 - 公開日: 2026-03-30 - 更新日: 2026-03-30 - トピック: Blockchain - タグ: ethereum, eip, l2, ブロックチェーン ## はじめに 初めまして。 『DApps開発入門』という本や色々記事を書いているかるでねです。 https://amzn.asia/d/gxvJ0Pw 以下でも情報発信しているので、興味ある記事があればぜひ読んでみてください！ https://cardene.notion.site/EIP-2a03fa3ea33d43baa9ed82288f98d4a9 https://twitter.com/cardene777 https://zenn.dev/heku https://cardene.substack.com/ https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58 今回は、Blobパラメータだけを変更する軽量なアップグレード方式の最初の適用例を記録した「**EIP-8134**」についてまとめていきます。 :::message 以下にまとめられているものを解説しながらまとめていきます。 ::: https://eips.ethereum.org/EIPS/eip-8134 Ethereumのデータ容量を段階的に拡張するために、Blobパラメータだけを変更する軽量なアップグレード方式が導入されました。 EIP-8134はその最初の適用例であるBPO1の活性化情報とパラメータ値を公式に記録するMeta EIPです。 ## 概要 EIP-8134は、Ethereumネットワークで初めて実施されたBlob Parameter Only（BPO）アップグレードである**BPO1**の公式記録です。 従来のハードフォーク（大規模なプロトコル変更を伴うアップグレード）と異なり、BPOアップグレードはBlobに関するパラメータだけを変更する軽量なネットワークアップグレードです。 EIP-8134では、BPO1の活性化タイムスタンプ・Blob Target・Blob Max・Base Fee Update Fractionという4つの値を正式に記録することで、エコシステムの参加者がBPO1の内容を一箇所で確認できるようにしています。 :::message **Blobとは** Blob（Binary Large Object）は、EIP-4844で導入されたEthereumの新しいデータ領域です。 L2（Layer 2）がトランザクションデータをEthereumに投稿する時に使うデータ形式で、通常のトランザクションデータよりもはるかに安いコストでデータを保存できます。 Blobは約18日間（4096エポック）ネットワークに保持された後、自動的に削除されます。 ::: ## 動機 Ethereumのスケーリング戦略は、トランザクションの実行をL2に任せ、Ethereum自体はデータアベイラビリティ（DA）レイヤーとして機能するという方針です。 L2からのDA需要は急速に増加していますが、Blobパラメータの変更を大規模なハードフォークの一部としてしか行えないのでは、L2の成長スピードに追いつけません。 #### 従来のハードフォークの課題 従来のハードフォーク（CancunやPrague等）はプロトコル全体に大きな変更を加えるため、以下の課題がありました。 | 課題 | 詳細 | |------|------| | 準備期間が長い | クライアント実装、テスト、コミュニティ調整に数ヶ月かかる | | 変更が大きすぎる | Blobパラメータ以外にも多数の変更が含まれ、リスクが高い | | 頻度が低い | 年に1〜2回程度しか実施できず、需要の変化に即応できない | #### BPOアップグレードの利点 BPO（Blob Parameter Only）アップグレードは、Blobに関するパラメータだけを変更する仕組みです。 EIP-7892が定めるBPOの仕組みでは、クライアント側の設定変更のみでパラメータを適用できるため、テストや準備の負担が大幅に軽減されます。 これにより、Blobの容量を安全かつ迅速に拡張できるようになります。 #### なぜMeta EIPが必要か EIP-7892がBPOアップグレードの仕組みとルールを定義していますが、個々のBPOアップグレードで実際にどの値が適用されたのかは追跡していません。 実際のところ、BPO1の活性化タイミングやパラメータ値はクライアントのリポジトリや運用メモに散在していて、エコシステムの参加者が一貫した情報を得ることが難しい状態でした。 EIP-8134はこのギャップを埋めるために、BPO1の正式な記録を1つのドキュメントにまとめています。 ## 仕様 #### BPO1パラメータ BPO1で適用されるパラメータは以下の通りです。 | フィールド | 値 | |-----------|-----| | BPO識別子 | BPO1 | | 活性化タイムスタンプ（UTC） | 1765290071 | | Blob Target | 10 | | Blob Max | 15 | | Base Fee Update Fraction | 8,346,193 | BPO1はFusakaアップグレード後に実施される最初のBlobパラメータ変更であり、Blob容量の段階的な拡張の第一歩です。 :::message **各パラメータの意味** **Blob Target** 1ブロックあたりに含まれることが期待されるBlobの数です。 ネットワークはこの値を「ちょうどいい量」として扱い、実際のBlob数がTargetより多ければ手数料を上げ、少なければ手数料を下げて需要を調整します。 BPO1ではこれが10に設定されています。 **Blob Max** 1ブロックに含めることができるBlobの上限数です。 Targetを超えてBlobを含めること自体は可能ですが、Maxを超えることはできません。 BPO1ではこれが15に設定されています。 **Base Fee Update Fraction** Blob手数料がどれくらいの速さで変動するかを決める係数です。 値が大きいほど手数料の変動が緩やかになります。 BPO1では8,346,193に設定されており、Blob数が増えてもいきなり手数料が跳ね上がらないよう調整されています。 ::: #### 過去のアップグレードとの比較 BPO1は、CancunとPragueで段階的に拡張されてきたBlob容量をさらに引き上げるものです。 | アップグレード | Blob Target | Blob Max | Base Fee Update Fraction | |--------------|-------------|----------|--------------------------| | **Cancun** | 3 | 6 | 3,338,477 | | **Prague** | 6 | 9 | 5,007,716 | | **BPO1** | 10 | 15 | 8,346,193 | Cancunで初めてBlobが導入された時はTarget 3、Max 6でした。 PragueでTarget 6、Max 9に拡張され、BPO1ではTarget 10、Max 15へとさらに引き上げられています。 1ブロックあたりに含められるBlobの最大数が2.5倍（Cancun比）になったことで、L2がEthereumに投稿できるデータ量も大幅に増加しています。 ![blob-capacity-transition.png](/images/qiita-a66b1758-296b-4240-bb42-1afe812dd1c8.webp) #### データソース BPO1のパラメータ値と活性化タイムスタンプは、クライアントのgenesis設定から取得されています。 ```json "bpo1Time": 1765290071, "blobSchedule": { "cancun": { "target": 3, "max": 6, "baseFeeUpdateFraction": 3338477 }, "prague": { "target": 6, "max": 9, "baseFeeUpdateFraction": 5007716 }, "bpo1": { "target": 10, "max": 15, "baseFeeUpdateFraction": 8346193 } } ``` このJSONは、各アップグレードでのBlobパラメータをまとめて管理する`blobSchedule`オブジェクトの一部です。 クライアント実装によってフォーマットは異なる場合がありますが、この提案ではメインネットの正規設定値を反映しています。 ## 補足 #### EIP-7892との関係 EIP-8134を理解するには、BPOアップグレードの仕組みを定義したEIP-7892との関係を知っておくことが重要です。 EIP-7892は「**BPOアップグレードとは何か**」を定義する仕様です。 具体的には以下の内容を規定しています。 - BPOアップグレードで変更できるパラメータ（target, max, baseFeeUpdateFraction） - クライアント設定ファイルでの記述方法（`blobSchedule`オブジェクト） - 実行レイヤーとコンセンサスレイヤーの整合性要件 - P2Pネットワーキングへの影響 一方、EIP-8134は「**BPO1で実際に何が変わったのか**」を記録するMeta EIPです。 EIP-7892が「ルールブック」だとすれば、EIP-8134は「試合記録」のような位置づけです。 :::message **EIP-7892とEIP-8134の役割分担** EIP-7892はBPOアップグレードの仕組み全体を定めています。 変更できるパラメータの種類、クライアント設定の書き方、活性化の方法といったフレームワークを提供します。 EIP-8134はそのフレームワークに基づいて実施された最初のBPOアップグレード（BPO1）の具体的な値と日時を記録します。 今後BPO2、BPO3と実施されるたびに、同様のMeta EIPが作成される想定です。 ```mermaid graph TD A[EIP-7892
BPOの仕組みを定義] --> B[BPO1
EIP-8134] A --> C[BPO2
将来のMeta EIP] A --> D[BPO3
将来のMeta EIP] ``` ::: ![eip7892-8134-relationship.png](/images/qiita-9c9e319d-f1a0-4874-a6e4-7a7d28f2e82c.webp) #### BPO1を独立した文書として記録する意義 BPO1はFusakaアップグレード直後にBlobパラメータを制御的に拡張することで、メインネット環境での実証評価を可能にしています。 この変更により、クライアント・バリデータ・プロポーザーにわたる実際のパフォーマンスデータを収集し、スロット安定性やシステム全体の振る舞いをエビデンスベースで評価できるようになります。 次のスケーリング判断はこのデータに基づいて行われるため、BPO1を独立したパラメータ更新として文書化することは、透明性とプロセスの明確性を確立する上で重要です。 ## セキュリティ BPOアップグレードはBlobの容量を増やすため、ネットワークの負荷特性に影響を与える可能性があります。 Blob数の増加はバリデータやプロポーザーの処理負荷を高め、スロットの安定性に影響する可能性があります。 そのため、慎重なモニタリング、段階的なロールアウト、エコシステム全体の調整が安定性確保のために求められています。 BPO1がFusaka直後ではなく段階的に実施されるのも、まさにこのリスクを管理するためです。 メインネットでの実際のパフォーマンスデータを収集した上で、次のスケーリング判断を行うエビデンスベースのアプローチが取られています。 ## 引用 https://eips.ethereum.org/EIPS/eip-8134 https://eips.ethereum.org/EIPS/eip-7892 https://eips.ethereum.org/EIPS/eip-4844 https://eips.ethereum.org/EIPS/eip-7840 ## 最後に 今回は「**BPO1（Blob Parameter Onlyアップグレード）**」についてまとめてきました。 Ethereumがデータアベイラビリティレイヤーとしてスケールしていくために、大規模なハードフォークを待たずにBlobの容量を段階的に拡張できるBPOアップグレードは重要な仕組みです。 EIP-8134はその最初の適用例であるBPO1の正式な記録であり、Cancun→Prague→BPO1と着実にBlob容量が拡大してきた流れを確認できます。 他でも色々記事を書いているのでぜひよろしければ読んでいってください！ https://amzn.asia/d/gxvJ0Pw https://cardene.notion.site/EIP-2a03fa3ea33d43baa9ed82288f98d4a9 https://zenn.dev/heku https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58 https://twitter.com/cardene777 https://cardene.substack.com/