Hegota 中的擴展：利用ETH轉賬來錨定執行和帶寬

Ethereum Research

本文為機器翻譯

展示原文

我要感謝 Toni Wahrstaetter、Marius Vanderwijden 和 Parithosh Jayanthi，感謝他們參與討論並最終促成了這份報告的撰寫。

本文探討了Hegota在Glamsterdam事件後需要做出哪些改變才能繼續擴展gas上限。出發點是一個簡單的觀察：21,000 gas的ETH轉賬限制了槽位容量的兩個維度。

在執行方面，Glamsterdam 的重新定價將成本推高到轉讓上限允許的程度，將最壞情況下的執行成本固定在 100 Mgas/s。
在帶寬方面，一個包含大量傳輸的數據塊本身就是一個數據有效載荷（信封、簽名和 BAL 條目），任何定價工具都無法觸及，否則收費將超過 21k。

因此，我們使用傳輸完整塊作為錨塊。我們推導其帶寬性能，找到最大化 gas 限制的 PTC 截止時間，將其與對抗性 calldata + SLOAD塊進行比較，然後探討這對狀態增長、歷史記錄和內存意味著什麼。

主要發現

這筆 21k ETH 的轉賬錨定了槽位的兩端。它將最壞情況下的執行速度凍結在 100 Mgas/s ，並設定了約 0.0105 B/gas（每次轉賬最壞情況下為 221 B）的不可降低的字節密度，任何定價工具都無法低於此密度。錨定區塊的傳播速度約為 214 Mgas/s，因此其執行速度受限。在對稱的 25% 緩衝區下解決兩個上限問題，在 PTC 截止時間約為 6.4 秒時，可得到約 4.22 億個區塊。我們將 25% 的緩衝區視為指導原則，而非硬性下限，並略微放寬以取整數：我們建議在 $D = 6$s 時使用 4.5 億個區塊，這樣錨定區塊的執行緩衝區約為 25%，傳播緩衝區約為 11%。
Hegota 的重新定價任務是將所有定價組合的容量都降至轉賬線。由於我們無法在不觸及 21k 上限的情況下重新定價轉賬，因此目標是通過構建機制使其達到最壞情況。Glamsterdam 定價未能實現這一點：混合調用數據 + SLOAD塊的容量約為轉賬線的 2.2 倍，並將系統容量限制在約 302M，比錨定最優值低約 120M。解決方案是再次提高調用數據的最低容量（64 → 96），並增加 BAL 字節的覆蓋範圍，或者引入單一的統一調用數據速率（約 94）——在機制複雜性和事件廣度之間進行權衡。
在傳輸線以下，只有進一步的優化才能移動最優解。定價可以平衡傳輸線上的各種組合，但無法突破傳輸線。每 KB 的傳播時間每提高 10%，gas 上限大約增加 1400 萬至 1800 萬，最高可達 6.18 億。同時，ETH 轉賬執行時間的改進將允許更高的執行錨點，從而在不改變 PTC 截止時間的情況下提高 gas 上限。

背景

Glamsterdam 發佈了 ePBS（ EIP-7732 ）、BAL（ EIP-7928 ）以及重新定價包，其中包括數據定價 EIP 7976 （調用數據最低 64/64，標準 4/16）和7981 （訪問列表字節按最低費率計費）。重新定價的目標是實現最壞情況下 100 Mgas/s 的執行性能。該目標無法進一步提高：否則需要將 ETH 轉賬的 gas 成本重新定價到超過 21,000，這將導致某些硬件錢包的功能失效。因此，對於 Hegota 而言，100 Mgas/s 的執行性能基準被凍結，額外的擴展必須通過優化（包括執行和傳播方面的優化）、調整 PTC 截止時間以及（單獨地）降低過高的計算操作成本來實現。最後一個選項將並行分析，並且僅通過稍後提到的一個交互項納入本報告。

本文所依據的假設：

範圍	價值	筆記
執行錨點R R	100兆氣體/秒	受21k轉會上限的限制
槽端T_3 T 3	12秒
信標塊認證截止日期T_1 T 1	3秒	ePBS下最早的有效載荷傳播開始時間；2秒與3秒的比較仍待定。
安全緩衝區	執行窗口和傳播窗口均為 25%。	指導原則，並非硬性規定；建議的 450M/6s 點運行率約為 25% / 傳播率約為 11%。
傳播模型	t = 569 + 0.443 \cdot \text{KB} t = 569 + 0.443 ⋅ KB ms (p90, MEV-boost)	根據 Toni 的最壞情況塊大小分析；snappy 壓縮後的大小，在發佈後測量（ p_{90} - \min p 90 − min ）。傳輸塊被視為不可壓縮（snappy 壓縮後 ≈ 原始大小）。
冷`SLOAD`	3,000	EIP-8038初步編號；Hegota 中未更改
冷賬戶訪問（ `BALANCE` ）	3,000	EIP-8038初步編號；Hegota 中未更改
冷藏`SSTORE`	13,000	EIP-8038初步編號；Hegota 中未更改
Calldata 定價	64/64 地板，4/16 標準	EIP-7976/7981
國家創建	`CPSB = 1530` ，固定	最新EIP-8037規範（150M 參考，120 GiB/年）

資源分佈圖

按資源所受約束的類型對資源進行分類很有幫助，因為這決定了每種資源如何應對更高的氣體限制：

資源	約束類型	更高的限額會發生什麼（Glamsterdam定價）	赫戈塔行動
執行	每個槽位，在D D之後	最壞情況下的執行時間隨G G 的增加而增加；與通過D D進行的傳播進行權衡	（假設）不會上調價格
帶寬	每個槽位，在D D之前	最壞情況下的有效載荷隨G G增長；BAL 字節未定價。	分叉變更（本報告的核心）
州增長	累計（磁盤）	增長率隨G增長，因為`CPSB`是固定的。	重新導出`CPSB` （分支項）
歷史	累計（磁盤+服務）	隨著G G 的生長	到期前提條件； `LOGDATA`審核
記憶	按事務處理（RAM）	不隨G G增長（受EIP-7825限制，每次交易）	沒有任何

接下來的章節將介紹每個槽位的權衡（這決定了 gas 限制），最後我們將回到累積資源。

傳遞塊作為錨塊

一次傳輸攜帶多少字節？

傳輸不會寫入存儲，也不會運行任何操作碼，但它仍然會發送字節：它的信封和簽名，以及 EIP-7928 在 BAL 中為其保留的記錄。

實際情況下，類型 2 轉賬的信封大小約為 110 字節：簽名（ r和s各 32 字節，加上y_parity ）約為 65 字節，20 字節的收款人地址在 RLP 幀化後約為 21 字節，剩餘約 25 字節用於 nonce、兩個費用字段、gas 限制、金額、鏈 ID 和空的訪問列表。表中我們向上取整到 130 字節，作為當前所有交易類型的最壞情況信封大小。

對於 BAL 而言，一次轉賬涉及兩個賬戶（發送方：餘額 + nonce；接收方：餘額）。由於 RLP 將餘額編碼為最小長度（≤ 11 B，受 ETH 總供應量限制，而非 32 B），並將 nonce 編碼為 1–2 B，因此最壞情況下的邊際貢獻約為 91 B。

設想	建造	每筆轉賬	\beta_t β t (字節/gas)
最壞情況會計	130個信封 + 91 BAL	221	0.01052

傳播模型基於經過 snappy 壓縮後的字節進行校準，因此我們將這 221 字節的原始數據映射到網絡傳輸中，並將傳輸塊視為不可壓縮數據（經過 snappy 壓縮後的數據 ≈ 原始數據）。這在最壞情況下是安全的——簽名是 snappy 無法觸及的隨機字節——並且是該報告中最重要的假設：任何實際的壓縮都只會放寬限制並提高可達的 gas 上限。測量實際編碼塊的壓縮邊緣字節斜率是該報告中指出的最重要的數據任務。

PTC截止日期應該放在哪裡？

截止時間D將時隙分為傳播窗口（從 $T_1 = 3$ 秒到D ）和執行窗口（從D秒到 12 秒）。在兩個窗口都保持 25% 的緩衝準則的情況下，當錨區塊能夠及時傳播和執行時，gas 限制L是可行的：

L \le 0.75 \cdot R \cdot (12 - D) \qquad \text{(執行)}

L ≤ 0.75 ⋅ R ⋅ ( 12 − D ) （執行）

0.443 \cdot \beta_t \cdot \frac{L}{1000} + 569 \;\le\; 0.75 \cdot (D - T_1) \cdot 1000 \qquad \text{(傳播)}

0.443 ⋅ β t ⋅ L 1000 +569 ≤ 0.75 ⋅ ( D − T 1 ) ⋅ 1000 （傳播）

第一個上限隨著DD的移動而下降；第二個上限上升。最優解是交叉點：

設想	D^* D ∗ (s)	L^* L ∗	L^* L ∗處的有效載荷
最壞情況會計處理（221 B）	6.38	422M	4.44 MB

在兩個窗口都保持 25% 指導原則的情況下，以轉移為錨定的最優值約為 422M，時間約為 6.4 秒。25% 的緩衝只是一個指導原則，而非硬性規定，因此我們略微放寬它，建議採用整數操作值——450M，時間約為 6 秒，並將截止時間略微提前，以犧牲傳播空間為代價來換取更高的限制。執行緩衝保持在約 25%；傳播緩衝吸收了這一變化，從 25% 降至約 11%——此時錨定塊使用傳播窗口的約 89%，而不是 75%。

工作點	執行緩衝區	傳播緩衝區
422M @ 6.38秒（對稱最優）	25%	25%
450米@6秒（推薦）	約25%	約11%

剩餘的不確定性在於傳播擬合（p90 百分位數和 Toni 強調尾部權重與保守的\sqrt{n\cdot\text{size}} √ n ⋅ size 權重之比）以及後 snappy 壓縮假設。傳播改進（如下）將恢復 450M 處的對稱 25% 緩衝，或將該限制提高。

對抗塊

傳輸阻塞並非最糟糕的情況。

轉移區塊錨定了槽位，但它並非我們能夠構建的最密集區塊——其密度 \beta_t \approx 0.0105 β t ≈ 0.0105 B/gas 是一個下限，而非上限。由於我們無法在不觸及 21k 上限的情況下對轉移區塊進行定價，因此我們的目標是通過構建使其達到最壞情況：協議定價的每個組合都應最多攜帶\beta_t β t字節/gas 。任何定價高於\beta_t β t的區塊都會在轉移區塊之前鎖定槽位，並將L^* L ∗拉低至 422M 以下，因此我們需要檢查每個區塊。

單資源塊的字節密度是指其每次操作的字節佔用量與其 gas 成本之比， \beta = b/c β = b / c :

1/F 1 / F用於樓層呼叫數據
32/c 32 / c用於冷啟動SLOAD （32 字節 BAL 密鑰）
20/c 20 / c用於訪問冷賬戶，例如BALANCE （20 字節地址）
64/c 64 / c用於冷SSTORE （BAL 中的 32 字節鍵 + 32 字節值）

混合區塊會添加儘可能密集的廉價調用數據——16 gas/字節的標準費率，直到達到仍低於 7976 的份額——其餘部分則填充冷SLOAD調用：

β(F, c) = \frac{1 - 512/c}{F} + \frac{32}{c}

β ( F , c ) = 1 − 512 / cF +32攝氏度

根據假設的 Glamsterdam 價格（冷SLOAD 3,000，冷賬戶訪問 3,000，冷SSTORE 13,000，呼叫數據下限F = 64 F = 64 ）評估菜單，我們得到：

堵塞	建造	β β (B/氣體)	× 傳輸線
ETH 轉賬（錨定）	221 B / 21,000 氣體	0.01052	1.00倍
冷藏`SSTORE`	640億/13000	0.00492	0.47×
冷`BALANCE`	20 B 地址 / 3,000	0.00667	0.63倍
冷`SLOAD`	32 B 鍵 / 3,000	0.01067	1.01×
樓層呼叫數據	1/F 1 / F ， F = 64 F = 64	0.01563	1.49倍
混合 25% calldata@16 + 75% `SLOAD`	β(64, 3000) β ( 64 , 3000 )	0.02363	2.25倍

主要觀察結果：

只有冷SLOAD能與傳輸線相媲美。冷BALANCE操作僅需消耗 3,000 gas（0.63 倍）即可將其 20 字節的地址寫入 BAL 庫，而冷SSTORE操作則需消耗 13,000 gas（0.47 倍）即可寫入一個 64 字節的鍵值對——兩者都遠低於傳輸線。冷SLOAD操作消耗的 3,000 gas 所支持的 32 字節存儲鍵是狀態訪問操作每消耗一個 gas 所能增加的最大字節密度數據，這也是為什麼攻擊塊都是用冷SLOAD構建的原因。
Cold SLOAD基本上位於這條線上。在 3,000 gas 時，其 32 字節密鑰提供 0.01067 B/gas，比\beta_t β t高 1%；這條線恰好在c = 3{,}041 c = 3,041處達到。
有兩個定價區塊超過了閾值：純看漲期權數據區塊（1.49倍）和混合區塊（2.25倍）。兩者的超限原因相同——看漲期權數據的定價低於轉移閾值——但正如我們接下來將要展示的，它們需要不同的解決方案。

最小的槓桿：重新提高呼叫數據底線

純調用數據塊超出限制的原因很簡單：EIP-7976 規定的 64 gas/byte 的下限意味著1/64 = 0.0156 1 / 64 = 0.0156 B/gas，比\beta_t β t高出 49%。解決方法很簡單——將下限提高到

F^* = \left\lceil 1 / \beta_t \right\rceil = \lceil 1 / 0.01052 \rceil = \lceil 95.06 \rceil = 96 \text{ gas/byte}

F ∗ = ⌈ 1 / β t ⌉ = ⌈ 1 / 0.01052 ⌉ = ⌈ 95.06 ⌉ = 96氣體/字節

這是 Hegota 最簡單的數據定價調整。然而，這仍然無法解決混合區塊的問題。提高F值會縮小廉價調用數據的份額（從16/64 = 25%降至16/96 = 16.7 % ），但冷SLOAD剩餘部分會持續向 BAL 中添加字節，導致整體字節密度為β(96, 3000) = 0.0193 B / gas 。這仍然比基準線高出1.84倍。

事實上，當F → ∞時，字節密度趨近於32/ c ，這正是SLOAD塊本身的密度。這意味著，即使設置有限的調用數據下限，也無法將混合塊的密度降低到足夠低的程度。

馴服混合塊的三種方法

剩餘的瓶頸是混合塊，其價格是線路價格的 1.84 倍。我們有三種選擇。前兩種選擇對看漲期權數據層看不到的 BAL 字節進行定價，併疊加在剛剛推導出的 64 到 96 的平臺價格上漲之上；第三種選擇不對 BAL 進行定價，而是移除混合塊所利用的雙速率看漲期權數據結構。

方案一：將 BAL 字節納入最低收費。顯而易見的解決方案是將 BAL 字節納入最低收費計算。Toni的這項提議將 7623 式的最低收費標準擴展到每個有效載荷字節，包括 BAL 字節。這樣，每個收費字節最多產生1/96字節的gas ，且完全不需要更改SLOAD 。其代價是引入一種新的 gas 計費機制，該機制會維護一個運行時最低收費累加器，並跟蹤每個冷訪問路徑。此機制僅作用於最低收費端，因此不會影響普通用戶和 21k 流量傳輸。

方案二：內置數據附加費。或者，我們可以為每個佔用 BAL 的操作（冷訪問、冷存儲等）添加顯式數據組件。這僅涉及常量，是目前最簡單的機制。但這種 BAL 字節定價方式實際上相當於對狀態訪問進行重新定價。將混合塊納入定價機制需要大幅提高冷狀態訪問成本，這與凍結錨點的理念相悖，即使它在執行上是安全的。此外，這還會進一步導致純操作碼塊定價錯誤，而這些塊本身就已經被納入定價機制。

方案 3：統一的 calldata 價格，不採用 BAL 定價。混合區塊之所以有效，是因為 calldata 有兩種價格——低廉的 16 gas/byte 標準價格（最高可達最低份額）和高於該價格的最低價格。如果我們給 calldata 單一的價格p ，那麼這個瓶頸就消失了。每個 calldata 字節的成本為p ，因此 calldata 區塊的上限為1/p ，將其混合到狀態區塊中只會降低密度。最壞的情況會退化到密度最高的未定價狀態操作，即成本為32/ c的冷SLOAD 。因此p只需要阻止純 calldata 的價格超過SLOAD即可。

\frac{1}{p} \le \frac{32}{c} \;\Rightarrow\; p \ge \frac{c}{32} \approx 94 \text{ gas/byte} \quad (c = 3{,}000)

1便士≤ 32攝氏度⇒ p ≥ c 32 ≈ 94 gas/字節（ c = 3,000 ）

這比最低費率 96 略低：降低最低費率只會改變誰付費，而不會改變費率本身。96的最低費率只會對數據量大的交易收取費用，而統一的 94 則對每個調用數據字節都收取最低費率。這比 16 的標準費率高出約 6 倍。作為交換，它是最簡單的機制（單一費率，無需 BAL 計費，無需max() ）。

選擇在於機制複雜性和影響範圍。方案 1 對用戶的影響最小——它隻影響超過調用數據最低限額的區塊——但它引入了一種新的 gas 計費機制。方案 2 和方案 3 都只是對常量進行更改，但它們會影響所有執行影響 BAL 的操作的用戶（方案 2）或所有調用數據的用戶（方案 3）。方案 3 比方案 2 更簡潔、更合理，因為產生 BAL 字節的操作已經包含了執行成本和帶寬成本的正確價格。混合區塊僅利用了調用數據的雙速率結構，因此移除它可以直接解決問題，完全不需要修改 BAL 字節。

如果傳播速度加快呢？

定價機制可以平衡傳輸線上的成分，但不能低於傳輸線。超過這個點，只有傳播模型本身可以改進，例如基於內存池的有效載荷重構（大多數有效載荷字節已經存在於對等節點的內存池中）、Gossip 協議和拓撲結構的改進，或者糾刪碼分發。重新運行中心交叉算法，斜率提高x % ：

邊坡改善	D^* D ∗ (s)	L^* L ∗
— (0.443 毫秒/KB)	6.38	422M
-10%	6.19	436M
-20%	6.00	4.5億
-30%	5.79	4.66億
-40%	5.56	4.83億
-50%	5.32	5.01億
開銷減半（569 毫秒 → 285 毫秒）	6.12	4.41億

大致而言，斜率每提高 10%，gas 限制就會增加 14-18M ，同時截止時間會提前；-20% 的斜率在 $D = 6.0$s 時達到約 450M，從而恢復到推薦限制的 25% 對稱緩衝區；-50% 的斜率在 $D \approx 5.3$s 時達到約 501M。固定開銷減半（569 → 285 ms）本身就相當於斜率降低一個十分位（約 +19M）。需要注意的是，傳輸量大的有效載荷壓縮性最差（簽名是隨機字節），因此基於壓縮的改進對攻擊尾部的幫助大於對錨塊本身的幫助。

整個框架的硬性限制在於執行效率：當D接近T_1加上固定開銷時，執行窗口會在約 8.2 秒處飽和，即在 100 Mgas/s 的 75% 下達到618M 。要突破這個限制，就需要提高實際執行吞吐量，而這正是針對高價計算操作重新定價的並行分析所要解決的問題。這項工作與本報告在一點上存在關聯：更便宜的執行成本會將更多事務推到調用數據層，因此在F = 96時，調用數據層的發生率應該根據重新定價後的執行成本進行評估。

對其他資源的影響

州增長：重新推導`CPSB`

最新的 EIP-8037 規範修正了CPSB = 1530 ，該值是在 1.5 億的參考上限下，針對 120 GiB/年的目標值推導出來的，並明確將重新推導推遲到後續分支。如果 CPSB 仍為 1530，則在 4.5 億的上限下，目標增長率約為 360 GiB/年。使用該規範在新上限下的推導結果，我們得到：

工作點	`CPSB`	新插槽（64 B）	新賬戶（120 B）	24 KiB 部署
4.5億	約4600	294k	551k	113M 狀態氣體
501M（p2p拉伸）	約5110	327k	613k	126M 狀態氣體

無論如何，轉賬都不會受到影響，因為只有創建新賬戶才會支付狀態氣，這是在具有儲層模型的獨立維度中發生的。

此外，實際需求將如何響應更高的區塊限制和增加的CPSB也是一個問題。最終結果可能會因用戶對 Glamsterdam 分叉的適應情況而有所不同。

歷史：無需重新定價，但到期日變得更加重要

在 2024 年 5 月至 2025 年 5 月期間，以 36M 的容量限制，測得的 geth 歷史記錄（包括頭部、主體和收據）每天增長約 525 MiB，每年約 180 GiB （更多信息請點擊此處）。如果按線性比例擴展到 450M，則增長速度約為每年 2.2 TiB 。這已經包含了存儲在收據中的日誌，但由於測量窗口早於 BAL（塊訪問日誌），因此該數據未包含日誌。BAL（EIP-7928）是另一個大小相當的歷史通道——約佔傳輸塊字節數的 41%，並且在狀態訪問密集型組合中佔據主導地位——但 EIP-7928 允許將存儲的 BAL 修剪到其哈希根，因此它們的持久貢獻取決於保留窗口。

在當前歷史增長率下，滾動歷史到期（EIP-4444系列）對驗證者而言變得更加重要。然而，這種增長率仍在可控範圍內，因此無需重新定價。

記憶：無事可做

最壞情況下的 EVM 內存佔用量是按事務計算的：相對於 EIP-7825 上限的二次方擴展成本，單個幀的內存佔用量約為 3-4 MB，並且內存會在順序執行的事務之間釋放。更高的塊限制會增加每個塊的事務數，而不是併發內存。只有當 7825 上限提高或線性內存定價（EIP-7923/7686）沒有相應的補償限制時，這種情況才會改變。

計算：向下重定價

凍結 100 Mgas/s 錨點的另一面是，大多數操作的 Gas 成本相對於該錨點而言過高：它們的最壞情況客戶端運行時間低於當前的 Gas 成本，因此它們消耗的 Gas 預算比實際運行時間更多。根據當前的客戶端性能測試結果，我們可以重新定價約 62 項 EVM 操作和預編譯操作，其中 36 項操作的 Gas 成本將低於錨點價格下的 1。這些操作包括低成本、高頻的算術運算、位運算、棧操作和內存操作。

這種過高的定價造成了吞吐量的浪費。在主網流量中，目前約有 12.4% 的區塊 gas 被浪費在了收費高於其合理運行成本的操作上。如果採用整數舍入法（ max(⌈exact⌉, 1) ）重新定價，可以將這一比例降低至約 2.6% 。

10% 的收益固然不錯，但很可能不足以彌補重新定價 62 項操作的成本。因此，建議 Hegota 中的計算成本保持不變。

Hegota 實際發貨的商品

#	物品	類型
1	Gas limit → ~450M, $D = 6$s	驗證器協調，門控於 2–5
2	Calldata 樓層 64 → 96	一個常數（7976/7981）
3	混合塊定價：BAL 最低對、內在附加費或統一看漲期權數據價格（~94）	單一開放機制決策
4	`CPSB`重新推導：1,530 → ~4,600（p2p 拉伸時約為 5,110）	根據 8037 規範流程，有一個恆定不變的因素。
5	p2p 坡度/架空線路改進	非岔路軌道：每增加 10% 的坡度，軌道高度增加 14–18 米，最高可達約 501 米。

侷限性

所有傳播數均繼承了 Toni 的p90 MEV 增強擬合（ 569 + 0.443 \cdot \text{KB} 569 + 0.443 ⋅ KB ms，快速壓縮後的大小，在發佈後測量為p_{90} - \min p 90 − min ）和 T_1 = 3$s 的假設；兩者都是選擇，而非既定條件。Toni 的保守加權\sqrt{n\cdot\text{size}} √ n ⋅ size會產生更陡峭的斜率（局部/高百分位擬合的斜率更陡峭），兩者都會拉低最優值；交叉點每秒移動約 51M，並且與斜率成正比。
每次傳輸的字節數是根據已確認的 RLP 最小長度編碼得出的，因此幀開銷已得到解決；但 Toni 的傳播模型是基於快照後的字節進行校準的，並且我們假設傳輸塊是不可壓縮的（快照後 ≈ 原始 221 B）。實際的網絡壓縮以及block_access_index寬度隨交易數量的增長仍然沒有建模，並且會影響每個主要數值——特別是壓縮只會放寬界限並提高L^* L ∗ 。
交叉模型將傳播和執行嚴格視為串行，並設置了 25% 的硬緩衝區；流水線化或重疊驗證會將最優解向外移動。
8037 個數字遵循實時規範（ CPSB = 1530 ）；本地 EIPs 存儲庫仍然保留著較舊的自動伸縮草案，其中的數字不適用。
歷史預測將今天測量的歷史增長（標題、主體、收據）與氣體限制線性縮放；觀察到的 30M→36M 縮放接近線性，但成分變化（blob 採用、實際 BAL 大小）將使其移動。