Ethereumの利用が突然減少、Fusakaが問題解決に役立つ可能性を示唆

Ethereumは2025年12月3日にFusakaアップグレードを有効化し、Blob Parameter Overridesメカニズムを通じてネットワークのdata availability容量を大幅に拡張しました。この仕組みは、blob（圧縮された取引データパッケージ）が徐々に調整可能な目標値と最大値を持つように設定できるものであり、レイヤー2のロールアップがEthereumにアップロードする安全性と完結性を確保した圧縮データのことです。

次の2回の調整により、1ブロックあたりのblob目標は6から10、次に14へと引き上げられ、最大値は21に設定されました。Fusakaの核心的な目的は、blobデータのスループットを増やすことでロールアップのコストを削減することにあります。

しかし、3か月のデータ収集の結果、技術的容量と実際の使用レベルの間に明確なギャップが存在することが判明しました。MigaLabsによる750,000以上のスロットの分析では、Fusaka有効化以降もネットワークは14 blob/ブロックの目標に達していないことが示されています。

特に注目すべきは、最初のパラメータ調整後でも中央値のblob使用率が減少している点です。16 blob以上を含むブロックは、ミス率が著しく高くなっており、ネットワークの信頼性が新しい容量制限に近づくにつれて低下していることを示しています。

レポートの結論は非常に率直です：実際に必要性が生じてblobのパラメータを増やすまでは、ミス率が正常に戻るまで調整を続けるべきではありません。

Fusakaは何を変更し、いつ行われたか

Fusaka以前は、EIP-7691に基づき、Ethereumは1ブロックあたり6 blob、最大値は9を目標としていました。Fusakaアップグレードは、2回のBlob Parameter Override調整を導入しました。

最初の調整は2025年12月9日に行われ、目標を10、最大値を15に引き上げました。2回目は2026年1月7日に実施され、目標を14、最大値を21にさらに引き上げました。

*EthereumのFusakaアップグレードのロードマップは、blobのパラメータが2025年12月から2026年1月までの間に6/9から12/15、そして14/21へと段階的に増加したことを示しています。*これらの変更はハードフォークを必要とせず、Ethereumはクライアント間の協調によって容量を調整できる仕組みになっています。

MigaLabsの分析では、ソースコードと再現可能な方法を用いて、変換期間中のblob使用率とネットワーク性能を追跡しています。結果として、最初のoverride後に中央値のblob数は6から4に減少しましたが、全体の容量は拡大しています。16 blob以上のブロックは非常に稀であり、観測期間全体で165〜259回しか出現しません。

つまり、ネットワークには余裕があるものの、未だ十分に活用されていない状態です。

また、レポートは一つの不整合も指摘しています。タイムラインの記述によると、最初のoverrideは6から12に引き上げたとありますが、Ethereum Foundationのメインネット通知やドキュメントでは、実際には6から10への増加と確認されています。この分析では、Ethereum Foundationの公式パラメータを用い、MigaLabsの実測データとミス率も分析の基盤としています。

blobのミス率が多いblob数のブロックで急増

ネットワークの信頼性は、「missed slot」（伝播や検証が正しく行われなかったブロック）を通じて測定され、明確な傾向を示しています。

blob数が少ない場合、基本的なミス率は約0.5％です。16 blob以上のブロックでは、この値は0.77％から1.79％に上昇します。2回目のoverride後の最大値21 blobでは、ミス率は1.79％に達し、基準値の約3倍となっています。

blob数10〜21の各レベルを分析すると、信頼性の低下を示す曲線が徐々に増加し、14 blobの目標を超えると顕著になります。

これは特に重要であり、Ethereumの現行インフラ—バリデータのハードウェア、ネットワーク帯域、アテステーションの時間—が高容量のブロック処理に困難を抱えていることを示しています。

将来的に需要が急増し、頻繁に21 blobの上限に近づく場合、ミス率の高まりは最終性の遅延やリオーグのリスク増大につながる可能性があります。レポートはこれを一つの境界線とみなしており、ネットワークは技術的には多blobのブロックを処理できるものの、その安定性と信頼性を維持できるかは未確定です。

少ないブロック（16点以下）では誤り率は0.75％未満にとどまる一方、点数が多い場合は1％を超え、21点では1.79％に達しています。## blobの経済性とストックプライスの役割

Fusakaは容量拡張だけでなく、EIP-7918を通じてblobの価格設定メカニズムも変更しました。これにより、blobのストックプライスの最低価格が導入され、blobの入札価格が1 weiまで下落するのを防いでいます。

従来、blobの需要が低く、実行コストが優先される場合、base feeはゼロに近づき、価格シグナルの意味が失われていました。一方、レイヤー2のロールアップは、Ethereumに取引データをアップロードするためにblobの料金を支払い、その料金は計算コストやネットワーク負荷を反映すべきと期待されていました。

コストがほぼゼロになると、経済的フィードバックループが崩壊し、容量消費行動がコストに見合わなくなるため、需要の実態を観測できなくなります。

EIP-7918のストックプライスは、blobの料金を実行コストに連動させることで、需要が低くても価格が経済的シグナルとして機能し続けることを保証します。これにより、「フリーライダー」問題を回避し、将来の容量拡張の意思決定に役立つ明確なデータを提供します。

HildobbyのDuneダッシュボードの初期データによると、Fusaka後のblob料金は安定しており、過去の急激な低下傾向は見られません。平均blob数も、MigaLabsの結論と一致し、容量の未充填状態が続いていることを示しています。

「blob」の取引手数料は2024年初と末にピークを迎え、その後2025年を通じて徐々に低下し、2026年には低水準を維持しています。## Fusakaはどれほど効果的か？

技術的には、Fusakaは容量拡張に成功し、Blob Parameter Overrideの仕組みが議論を呼ぶハードフォークなしで機能できることを証明しました。ストックプライスも有効に働き、blob料金の経済的無意味化を防いでいます。

しかしながら、使用量は依然として容量を下回り、信頼性は新容量の上限付近で著しく低下しています。ミス率の曲線は、Fusaka前のレベルとoverride後の10/15パラメータも良好に処理できていることを示していますが、16 blobを超えると徐々に圧力がかかり始めています。

これにより、明確なリスクプロファイルが形成されます。レイヤー2の活動が突発的に増加し、頻繁に21 blobの上限に近づく場合、ネットワークは高ミス率に直面し、最終性やリオーグ耐性に影響を及ぼす可能性があります。

また、最初のoverride後に中央値のblob数が減少したことは、容量が増加しても、現状のロールアップはblob availabilityの制約にまだ達していないことを示唆しています。取引量が十分でないか、圧縮やバッチングの最適化により、現状の容量に適合させている可能性もあります。

Blobscanのデータも、個別のロールアップが比較的安定したblob数を維持し、余剰容量を迅速に利用していないことを示しています。

Ethereumの次の一歩

Ethereumのロードマップには、PeerDASの導入や、データアベイラビリティサンプリングの再設計による容量拡張と分散性・安全性の向上が含まれています。

しかし、Fusakaの結果は、現状の粗容量がボトルネックではないことを示しています。ネットワークは、14/21の範囲内で「大きくなる」余地があり、blobのミス率のデータはインフラのアップグレードも必要であることを示唆しています。

より安全なアプローチは、現状の目標に向かって徐々に使用量を増やし、クライアントやバリデータが高blob負荷に最適化されるにつれてミス率が改善するかを観察し、安定的に処理できることが証明された段階でのみパラメータを調整することです。

Fusakaは将来の成長の余地とblob経済の安定化をもたらしましたが、即時の使用爆発や最大容量の信頼性問題の根本解決には至っていません。容量が満たされるかどうかは未確定であり、現状のデータでは答えられません。