Ethereum Fusakaアップグレードにおける「連続可変ギアボックス」：L2スケーリングのための高速応答メカニズムの確立

著者: 潘志雄

背景: ガス制限のアップグレードにはハードフォークは必要ありません

Fusakaアップグレード以前は、イーサリアムプロトコルレイヤーのコアパラメータ（ブロック報酬や難易度調整アルゴリズムなど）のほとんどがクライアントソフトウェアに「ハードコード」されていました。つまり、単一の値を変更したい場合でも、長いEIP提案プロセス、テストネットのドリル、そしてネットワーク全体にわたる大規模なハードフォークの調整が必要であり、通常は6ヶ月、あるいはそれ以上の時間を要していました。

これまで、イーサリアムプロトコルにおける唯一の例外はブロックガスリミットでした。ガスリミットはハードフォークによって決定されるのではなく、バリデーターがブロックをパッケージングする際にアルゴリズムを用いて微調整を行うことができます（例えば、今年は3000万から6000万に増加）。このメカニズムにより、ネットワークにはある程度の柔軟性がもたらされます。

EIP-7892（Blob Parameter Only）は、この柔軟性をデータ領域に拡張するために開発されました。Blobの主要なパラメータを構成駆動型とし、Blobの軽量ハードフォークによってこれを実装することで、コードを変更することなくパラメータを変更できます。クライアント側の開発の観点からは、これはほぼホットパラメータアップデートを実行するようなものです。

これにより、スケーリングの問題に関して、「Blob 数を調整するたびに次のメジャーハードフォークを待たなければならない」というサイクルから Ethereum が解放され、より小さな BPO フォークを通じてより頻繁なパラメータ調整が可能になりました。

ブロブの数はなぜ重要ですか?

この調整の中心的なターゲットはBLOBです。Cancunアップグレード以降、ほとんどのRollupはトランザクションデータのほとんどを高価なcalldataに書き込むのではなく、専用の「一時データマウントポイント」であるBLOBに移行しています。

BLOBの経済ロジックは非常にシンプルです。BLOBは希少なリソースであり、各ブロックに関連付けることができるBLOBの数には限りがあります。その価格は需要と供給によって決まります。レイヤー2 BLOBの需要が供給を上回ると、BLOBの単価が上昇し、レイヤー2トランザクション手数料が上昇します。

したがって、セキュリティを確保するという前提で、ブロブ数の上限を可能な限り増やすことが、L2 ユーザーのコストを削減する最も直接的な方法です。

コアパラメータ：ターゲットとマックスのメカニズム

BPO調整計画には、2つの数値ペア（例：10/15）が見られます。これらは、EIP-4844メカニズムに基づいて設定された2つの主要なしきい値です。

ターゲット (またはターゲット値): コストの「調整器」。

これはEthereumが設定した理想的な負荷係数です。システムはこの値に基づいてBLOBの基本手数料を動的に調整します。実際の使用量が目標値を上回る場合、需要を抑制するために手数料が増加し、実際の使用量が目標値を下回る場合、手数料が減少します。

通常の条件下でのネットワークのスループットとレートのベンチマークを決定します。

Max (最大値): 安全な「ヒューズ」。

これは、ネットワークの麻痺を防ぐために設定された物理的なハードリミットです。需要がどれほど高くても、プロトコルは、1つのブロックに含まれるBLOBの数がこの値を超えないように規定しています。これにより、過剰なデータ処理によるノードのクラッシュやオフライン化を防止します。

これは、ネットワーク収容能力の究極の限界を表します。

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

アップグレードロードマップ: Fusaka が「ステップバイステップ」アプローチを選択した理由は何ですか?

この容量拡張は 12 月 3 日に一気に完了したわけではなく、「最初にテクノロジーを導入し、次に容量を解放する」という厳格な 3 段階戦略を採用しました。

フェーズ1：Fusakaアップグレード開始（12月3日）

パラメータステータス: ターゲット: 6 / 最大: 9 (以前の Pectra バージョンと一致しており、変更はありません)。

Fusakaのアップグレードでは、コア技術であるPeerDAS（データ可用性サンプリング）が有効化されました。技術的にはより多くのデータを処理できるものの、セキュリティ上の理由から、開発者はアップグレード初日にネットワーク負荷を増加させないことを選択しました。これは、既存のトラフィック状況下でPeerDASのメカニズムの安定性を検証するための「セキュリティ観測期間」でした。

フェーズ2: BPO 1 (12月9日予定)

パラメータ調整：目標：10 / 最大：15

PeerDASが約1週間安定稼働した後、BPOメカニズムを介して最初のホットアップデートが実行されました。目標値は6から10に増加しました。これはFusakaサイクルにおける最初の大幅な拡張でした。

フェーズ3：BPO 2（2026年1月7日予定）

パラメータ調整：目標：14 / 最大：21

1ヶ月にわたる徹底的なストレステストを経て、2回目のホットアップデートを実施しました。Fusakaの稼働開始時と比較して、キャパシティは2.3倍（6→14）に増加しました。これにより、拡張計画は完了です。

要約

BPOの導入は画期的な出来事でした。「Blobを拡張するたびに大規模なハードフォークが必要」という従来のパラダイムを打ち破り、拡張をパラメータのみを変更する一連のミニハードフォークに分割しました。

これは、将来のイーサリアムが無段変速機（CVT）のような存在になることを意味します。Blobの拡張は、もはやメジャーバージョンに強く縛られることはありません。代わりに、L2の需要とクライアントのパフォーマンスに基づいて、BPO3とBPO4を随時計画し、数年に一度の変更ではなく、より頻繁な小規模なハードフォークによってスループットを最適化できるようになります。