イーサリアム Fusaka アップグレードの「無段変速」：L2スケーリングの迅速な対応メカニズムの構築

将来のEthereumは「無段変速機」を搭載したかのようになり、今後はBlobの拡張が大型バージョンアップと強く結びつく必要がなくなります。

執筆：Zhixiong Pan

背景：Gas Limitのアップグレードはハードフォーク不要

Fusakaアップグレード以前、Ethereumプロトコル層のほとんどのコアパラメータ（ブロック報酬、難易度調整アルゴリズムなど）はクライアントソフトウェアに「ハードコーディング」されていました。つまり、たとえ数値を1つ変更したいだけでも、長いEIP提案、テストネットでの検証、そして全ノードの大規模なハードフォーク（Hard Fork）を調整する必要があり、通常半年以上かかることもありました。

それ以前、Ethereumプロトコルで唯一の例外はBlock Gas Limit（ブロックGas上限）でした。Gas Limitはハードフォークで決まるのではなく、バリデーター（Validators）がブロックをパッケージングする際にアルゴリズムで微調整できる仕組みです（例えば今年は30Mから60Mに引き上げ）。この仕組みにより、ネットワークに一定の柔軟性が与えられています。

EIP-7892、BPO（Blob Parameter Only）の登場は、この柔軟性をデータ領域にも拡張するためのものです。Blobの主要パラメータを設定駆動型にし、BPOという「パラメータだけを変更し、コードは変更しない」軽量なハードフォークで有効化します。クライアント開発の観点からは、ほぼパラメータのホットアップデートのようなものです。

これによりEthereumはスケーリング問題において、「Blob数を調整するたびに次の大型ハードフォークを待つ」必要がなくなり、小規模なBPOフォークでより頻繁にパラメータ調整が可能となります。

なぜBlobの数が重要なのか？ 

今回調整の中心となるのはBlobです。Cancunアップグレード（Dencun）以降、ほとんどのRollupは大部分のトランザクションデータを高価なcalldataに書き込むのではなく、Blobという専用の「一時的なデータマウント領域」に移行しました。

Blobの経済学的ロジックは非常にシンプルです：Blobは希少なリソースであり、各ブロックにマウントできるBlobの数は限られています。その価格は需給関係によって決まり、Layer 2の需要が供給を上回ると、Blobの単価が上昇し、L2の手数料が高くなります。

したがって、安全性を確保した上で、できるだけBlobの上限数を引き上げることが、L2ユーザーのコストを下げる最も直接的な手段です。

コアパラメータ：TargetとMaxの仕組み

BPOの調整計画では、2つのペアになった数字（例：10/15）が見られます。これはEIP-4844の仕組みに基づく2つの重要な閾値です：

Target（目標値）：手数料の「調整器」 

これはEthereumが設定した理想的な負荷量です。システムはこの値に基づき、Blobの基本手数料（Base Fee）を動的に調整します。実際の使用量がTargetを超えると手数料が上昇し需要を抑制し、使用量がTarget未満の場合は手数料が下がります。

これがネットワークの通常状態でのスループット能力と手数料基準を決定します。

Max（最大値）：安全の「ブレーカー」 

これはネットワークのダウンを防ぐために設定された物理的なハード上限です。需要がどれだけ高くても、プロトコルは1ブロックに含めることができるBlobの数をこの値以下に強制します。これによりノードが過大なデータ処理でダウンしたり、オフラインになるのを防ぎます。

これがネットワークの処理能力の上限となります。

また、Pectra以降、メインネットのblobパラメータは基本的に「Max = 1.5 × Target」のパターンに従っています：6/9、10/15、14/21はいずれもこの比率です。

アップグレードロードマップ：Fusakaはなぜ「段階的アプローチ」を選んだのか？ 

今回のスケーリングは12月3日（UTC+8）に一気に実施されるのではなく、厳格な「まず技術を導入し、その後容量を解放する」という3段階戦略を採用しています：

第1段階：Fusakaアップグレード実施（12月3日（UTC+8））

パラメータ状態：Target: 6 / Max: 9（以前のPectraバージョンと同じで変更なし）。

FusakaアップグレードでPeerDAS（データ可用性サンプリング）というコア技術が有効化されました。技術的にはより多くのデータを処理できる能力を備えていますが、安全のため、開発者はアップグレード初日にネットワーク負荷を増やさないことを選択しました。これは「安全観察期間」であり、PeerDASメカニズムが現状のトラフィック下で安定しているかを検証するためのものです。

第2段階：BPO 1（12月9日（UTC+8）予定）

パラメータ調整：Target: 10 / Max: 15

PeerDASが約1週間安定稼働した後、BPOメカニズムで初のホットアップデートを実施します。目標値は6から10に引き上げられます。これはFusaka期間中の最初の実質的なスケーリングです。

第3段階：BPO 2（2026年1月7日（UTC+8）予定）

パラメータ調整：Target: 14 / Max: 21

1ヶ月間の十分なストレステストを経て、2回目のホットアップデートを実施します。Fusaka導入時と比べて容量は2.3倍（6 → 14）になります。これにより今回のスケーリング計画が完全に実現されます。

まとめ

BPOの導入は画期的です。「Blobを拡張するたびに大型機能ハードフォークを待つ」という従来のパラダイムを打破し、スケーリングを一連のパラメータだけを変更するミニハードフォークに分割しました。

これは、将来のEthereumが「無段変速機」を搭載したかのようになり、今後はBlobの拡張が大型バージョンアップと強く結びつく必要がなくなり、L2の需要やクライアント性能に応じて、定期的にBPO3、BPO4を計画し、より密な小規模ハードフォークでスループットを最適化できることを意味します。数年に一度しか変更できない時代は終わるのです。