以太坊Fusaka升級裡的「無段變速箱」：建立L2 擴容的快速反應機制

作者：Zhixiong Pan

在Fusaka 升級之前，以太坊協議層絕大多數核心參數（如區塊獎勵、難度調整演算法等）都被「硬編碼」在客戶端軟體中。這意味著，即使只是想修改一個數值，也必須經歷漫長的EIP 提案、測試網演練，並協調全網節點進行一次大規模的硬分叉（Hard Fork），這通常需要半年甚至更久的周期。

在此之前，以太坊協議中唯一的例外是Block Gas Limit（區塊Gas 上限）。 Gas Limit 並非由硬分叉決定，而是允許驗證者（Validators）在打包區塊時，透過演算法進行微小的調整（例如今年從30M 提升至60M）。這種機制賦予了網路一定的彈性。

EIP-7892，BPO（Blob Parameter Only）的出現，正是為了將此彈性擴展到資料領域。它把Blob 的關鍵參數做成了配置驅動，並透過BPO 這種「只改參數、不改程式碼」的輕量化硬分叉來生效。從客戶端開發的角度來看，幾乎就像是在做一次參數熱更新。

它讓以太坊在擴容問題上，擺脫了「每次想調Blob 數都得等下一次大型硬分叉」的節奏，可以透過小號BPO 分叉更頻繁地調參。

本次調整的核心對像是Blob。自從坎昆升級（Dencun）之後，大多數Rollup 不再把大部分交易資料寫進昂貴的calldata，而是遷移到了Blob 這個專門的「臨時資料掛載區」。

Blob 的經濟學邏輯非常簡單：Blob 是稀缺資源，每個區塊能掛載的Blob 數量是有限的。它的價格來自供需關係，當Layer 2 的需求超過供應時，Blob 的單位價格就會增加，導致L2 手續費變貴。

因此，在確保安全的前提下，盡可能提高Blob 的數量上限，是降低L2 使用者成本最直接的手段。

在BPO 的調整計畫中，可以看到有兩個成對出現的數字（例如10/15）。這是基於EIP-4844 機制設定的兩個關鍵閾值：

這是以太坊設定的理想負載量。系統會根據這個數值動態調整Blob 的基本費用（Base Fee）。如果實際使用量> Target，費用上漲以抑制需求；如果實際使用量< Target，費用下降。

它決定了網路在正常狀態下的吞吐能力和費率基準。

這是為了防止網路癱瘓而設定的物理硬上限。無論需求多高，協定強制規定單一區塊包含的Blob 數量不得超過此值，以防止節點因處理過大數據而宕機或斷線。

它是網路承載能力的極限天花板。

另外，從Pectra 之後，主網的blob 參數基本上遵守「Max = 1.5 × Target」的模式：6/9、10/15、14/21，都是這個比例。

本次擴容並非在12 月3 日一步到位，而是採用了一個嚴謹的「先部署技術，後釋放容量」的三階段策略：

參數狀態：Target: 6 / Max: 9（與先前的Pectra 版本保持一致，無變化）。

Fusaka 升級啟動了PeerDAS（資料可用性採樣）這項核心技術。雖然技術上具備了處理更多資料的能力，但為了安全起見，開發者選擇在升級首日不增加網路負載。這是一個「安全觀察期」，用於驗證PeerDAS 機制在現有流量下的穩定性。

參數調整：Target: 10 / Max: 15

在PeerDAS 穩定運作約一週後，透過BPO 機制進行首次熱更新。目標值從6 提升至10。這是Fusaka 週期內的第一次實質擴容。

參數調整：Target: 14 / Max: 21

在經過一個月的充分壓力測試後，進行第二次熱更新。相較於Fusaka 上線時，容量翻了2.3 倍（6 → 14）。這標誌著本次擴容計畫的完全落地。

BPO 的引進是里程碑式的。它打破了「每次擴Blob 都要等一場大型功能硬分叉」的舊範式，把擴容拆成了一系列只改參數的迷你硬分叉。

這意味著，未來的以太坊就像安裝了一個「無段變速箱」，以後擴Blob 不必和大版本強綁定，可以根據L2 需求和客戶端性能，每隔一段時間規劃BPO3、BPO4，用更密集的小步硬分叉來調優吞吐，而不是幾年才改一次。