# [EIP8135] Blob容量をさらに拡張するBPO2アップグレードの仕組みを理解しよう！

> EIP8135は、Ethereumネットワークで2回目に実施されるBlob Parameter Only（BPO）アップグレードであるBPO2の公式記録です。

- URL: https://cardene.dev/articles/38906dd2d2ace9135be6
- 公開日: 2026-04-02
- 更新日: 2026-04-02
- トピック: 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

今回は、BPO1に続く2回目のBlob容量拡張であるBPO2の公式記録を提供する「**EIP8135**」についてまとめていきます。

:::message
以下にまとめられているものを解説しながらまとめていきます。
:::

https://eips.ethereum.org/EIPS/eip-8135

BPO1でBlob Target 10、Blob Max 15に拡張された後、さらなるスケーリングの余地を探るために実施される2回目のBPOアップグレードです。
**EIP8135**はそのBPO2の活性化情報とパラメータ値を公式に記録するMeta EIPです。

## 概要

**EIP8135**は、Ethereumネットワークで2回目に実施されるBlob Parameter Only（BPO）アップグレードである**BPO2**の公式記録です。

BPO1（**EIP8134**）が最初のBlob容量拡張を記録したのに対し、**EIP8135**はその次の段階であるBPO2を記録します。
BPO2では、BPO1で設定されたBlob Target 10、Blob Max 15をさらに引き上げ、Blob Target 14、Blob Max 21へと拡張しています。
これにより、L2がEthereumに投稿できるデータ量がさらに増加し、データアベイラビリティのスケーリングが進みます。

:::message
**EIP8134**（BPO1）については以下の記事を参考にしてください。
:::

[\[EIP8134\] Blobパラメータだけを変える軽量アップグレードBPO1の仕組みを理解しよう！](/articles/e234a68c68fee22c1e52)

## 動機

BPO1の実施後、ネットワークはより高いBlob容量にも耐えられることが観測されました。
しかし、より広い動作範囲で十分なデータを収集するには至っていませんでした。

BPO2はこの観測結果を踏まえて、同じ段階的スケーリング方針のもとBlobパラメータをさらに拡張します。
重要なのは、BPO2はL2からのデータ需要の増加に応えるために実施されるのではなく、制御された環境でシステムの限界を評価するために実施されるという点です。

:::message
BPO2の目的は「需要があるから拡張する」ではなく「どこまで安全に拡張できるかを確認する」ことです。
BPO1で得られたデータをもとに、Blob処理のパフォーマンス、スロットの信頼性、ネットワーク全体の安定性についてさらなる実証データを収集します。
観測結果に基づいてパラメータの一時停止や調整が可能な状態を維持しながら、段階的にスケーリングを進めています。
:::

## 仕様

#### BPO2パラメータ

BPO2で適用されるパラメータは以下の通りです。

| フィールド | 値 |
|-----------|-----|
| BPO識別子 | BPO2 |
| 活性化タイムスタンプ（UTC） | 1767747671 |
| Blob Target | 14 |
| Blob Max | 21 |
| Base Fee Update Fraction | 11,684,671 |

BPO2はBPO1のパラメータをベースラインとして構築されており、Blob容量の段階的な拡張を継続しています。

:::message
BPO1からの変化を以下にまとめます。

**Blob Target** はBPO1の10からBPO2では14に引き上げられました。
1ブロックあたりに期待されるBlob数が40%増加しています。

**Blob Max** はBPO1の15からBPO2では21に引き上げられました。
1ブロックに含められるBlobの上限が40%増加しています。

**Base Fee Update Fraction** はBPO1の8,346,193からBPO2では11,684,671に引き上げられました。
Blob数の増加に合わせて手数料の変動をより緩やかにすることで、急激な手数料の高騰を防いでいます。
:::

#### 過去のアップグレードとの比較

BPO2は、Cancunから始まったBlob容量の段階的拡張の4段階目にあたります。

| アップグレード | 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 |
| **BPO2** | 14 | 21 | 11,684,671 |

Cancunで最初にBlobが導入された時はMax 6でしたが、BPO2ではMax 21と3.5倍に拡張されています。
Blob Targetも3から14へと約4.7倍になっており、L2がEthereumに投稿できるデータ量は大幅に増加しています。

<!-- 画像: blob-capacity-transition-bpo2.png -->

#### データソース

BPO2のパラメータ値と活性化タイムスタンプは、クライアントのgenesis設定から取得されています。

```json
"bpo2Time": 1767747671,
"blobSchedule": {
  "bpo2": {
    "target": 14,
    "max": 21,
    "baseFeeUpdateFraction": 11684671
  }
}
```

このJSONは`blobSchedule`オブジェクトのBPO2エントリです。
クライアント実装によってフォーマットは異なる場合がありますが、この提案ではメインネットの正規設定値を反映しています。

## 補足

#### BPO1からBPO2への段階的拡張

BPO1とBPO2は、**EIP7892**が定めるBPOアップグレードの仕組みに基づいて実施される段階的なスケーリングです。

BPO1の実施後、ネットワークがより高いBlob容量に耐えられることが確認されましたが、より広い動作範囲での十分なデータは得られていませんでした。
BPO2はこの空白を埋めるために実施されます。

通常のプロトコル変更とは異なり、BPO2はL2からのデータ需要増加に応えることが主目的ではありません。
制御された方法でシステムの限界を評価し、Blob処理、スロットの信頼性、ネットワーク全体の安定性について追加の実証データを収集することが目的です。
観測結果に基づいてパラメータの一時停止や調整が可能な状態を維持しながらスケーリングを進める、エビデンスベースのアプローチが取られています。

<!-- 画像: bpo-schedule-overview.png -->

## セキュリティ

BPOアップグレードはBlobのスループットパラメータを調整するため、ネットワークの負荷特性に影響を与える可能性があります。
BPO2ではBlob Maxが21に引き上げられるため、バリデータやプロポーザーの処理負荷がBPO1と比べてさらに増加します。
安定性確保のために、慎重なモニタリング、段階的なロールアウト、エコシステム全体の調整が求められています。

## 引用

https://eips.ethereum.org/EIPS/eip-8135

https://eips.ethereum.org/EIPS/eip-8134

https://eips.ethereum.org/EIPS/eip-7892

## 最後に

今回は「**BPO2（Blob Parameter Onlyアップグレード 第2弾）**」についてまとめてきました。

BPO1に続く2回目のBlobパラメータ拡張として、Blob Target 14、Blob Max 21へとさらなる容量拡張が行われます。
需要駆動ではなくシステム限界の評価を目的としている点が特徴的で、Ethereumのデータアベイラビリティスケーリングが慎重かつ段階的に進められていることがわかります。

他でも色々記事を書いているのでぜひよろしければ読んでいってください！

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/