Vitalik 在 2024 年 5 月 13 日發布了 EIP-7706 提案，提出了對現有 Gas 模型的補充方案，將 calldata 的 gas 計算單獨剝離出來，並定制了類似 Blob gas 的 base fee 定價機制，進一步降低 L2 的運行成本。
作者：馬裡奧看 Web3
引言：Vitalik 在 2024 年 5 月 13 日發布了 EIP-7706 提案，提出了對現有 Gas 模型的補充方案，將 calldata 的 gas 計算單獨剝離出來，並定制了類似 Blob gas 的 base fee 定價機制，進一步降低 L2 的運作成本。與之相關的提案還需要追溯到 2022 年 2 月提出的 EIP-4844，相隔時間甚久，因此查閱相關資料，希望對最新的 Ethereum Gas 機製做一個綜述，方便大家快速了解。
目前已支援的 Ethereum Gas 模型—EIP-1559 和 EIP-4844
在最初的設計中，Ethereum 採用了一個簡單的拍賣機制對交易費用進行定價，這需要用戶主動為自己的交易出價，也就是設定 gas price，通常情況下，由於用戶付出的交易費將歸屬於礦工，所以礦工將根據經濟最優的原則，按照出價高低來決定交易打包順序，注意這是在忽略 MEV 的情況下。在當時核心開發者看來這個機制面臨以下四個面向的問題：
- 交易費用水準的波動性與交易的共識成本之間的不匹配：對於處在活躍狀態的區塊鏈中，交易的打包需求充足，這意味著區塊可以被輕易填滿，但這往往也意味著整體費用的波動性極大。例如當平均 Gas Price 為 10 Gwei 時，網路因在一個區塊中再接受一筆交易而產生的邊際成本是平均 Gas Price 為 1 Gwei 時的 10 倍，這是不可接受的。
- 對用戶來說不必要的延遲：由於每個區塊有 gaslimit 的硬性限制，加上歷史交易量的自然波動，交易通常會等待幾個區塊才能被打包，但這對整體網路來說是低效的；即不存在允許一個區塊更大而下一個區塊更小的「鬆弛」機制來滿足逐個區塊的需求差異。
- 定價效率低：由於採用簡單的拍賣機制導致了公允價格發現的效率較低，這意味著對於用戶來說，給出一個合理的定價將是困難的，這也意味著有非常多情況下，用戶付高了手續費。
- 無區塊獎勵的區塊鏈將不穩定：當取消挖礦帶來的區塊獎勵並採取單純的手續費模型時，可能會導致很多不穩定，例如激勵挖掘竊取交易費用的 “姐妹區塊”，開啟更強大的自私挖礦攻擊向量等。
直到 EIP-1559 的提出與執行，Gas 模型有個第一次迭代，EIP-1559 時 Vitalik 等核心開發者在 2019 年 4 月 13 日提出的，並在 2021 年 8 月 5 日的 London 升級中被採用，該機制摒棄了拍賣機制，轉而採用了一種 Base fee 和 Priority fee 的雙重定價模型，其中 Base fee 將根據父區塊中已產生的 gas 消耗情況與一個浮動且遞歸的 gas target 之間的關係透過一個既定的數學模型定量計算，直觀的效果為若上一個區塊中 gas 使用情況超過了預定的 gas target 時，則上調 base fee，若不及 gas target，則下調 base fee，這樣做既可以比較好的反應供需關係，又可以使得對於合理 gas 的預測變得更加精準，不至於出現由於誤操作導致的天價 Gas Price，因為 base fee 的計算是直接由系統決定的而非用戶自由指定。具體的程式碼如下：
其中可知當 parent_gas_used 大於 parent_gas_target 時，那麼當前區塊的 base fee 將比起上一個區塊的 base fee 加上一個偏移值，至於偏移值則是取 parent_base_fee 乘以上一個區塊 gas 總體用度相對 gas target 的偏移量並對 gas target 與一個常數取餘與 1 的最大值。反之邏輯類似。
另外 Base fee 將不再作為獎勵分配給礦工，而是直接銷毀，從而時 ETH 的經濟模型處於通貨緊縮的狀態，有利於價值的穩定。而另一方面 Priority fee 則相當於用戶給礦工的打賞，可以自由定價，這一定程度上可以讓礦工的排序演算法得到一定程度的複用。
隨著時間推進到 2021 年，那時 Rollup 的發展逐漸進入佳境，我們知道無論 OP Rollup 還是 ZK Rollup 都意味著需要將 L2 的數據做壓縮處理後的某些證明數據通過 calldata 上傳至鏈上實現數據可用性（Data Available）或直接交由鏈上做驗證。這就讓這些 Rollup 解決方案在維護 L2 的最終性時面臨著很大的 Gas 成本，而這些成本最終都將轉嫁到用戶的身上，因此那時大部分的 L2 協議使用成本並沒有想像那麼低。
同時 Ethereum 也面臨著區塊空間競爭的窘境，我們知道每個區塊存在一個 Gas Limit，這意味著當前區塊中的所有交易的 Gas 消耗加總不可以超過該值，按當前的 Gas Limit 為 30000000 來計算，理論上有 30,000,000 / 16 = 1,875,000 位元組的限制，其中 16 指的是 EVM 處理每個 calldata 位元組需要消耗 16 單位的 Gas，也意味著單一區塊最多可以承載的資料規模約 1.79 MB。而 L2 排序器所產生的 Rollup 相關資料通常資料規模較大，這就使其與其他主鏈使用者的交易確認產生競爭，導致單一區塊可以打包的交易量變小，進而影響主鏈的 TPS。
為了解決這個窘境，核心開發者們於 2022 年 2 月 5 日提出了 EIP-4844 提案，並在 2024 年二季度初的 Dencun 升級後得到了實施。該提案提出了一種新的交易類型，名為 Blob Transaction，相較於傳統類型的 Transaction，Blob Transaction 的核心思想是補充了一個新的資料類型，即 Blob data。區別於 calldata 類型，blob data 不可以被 EVM 直接，而只能存取其 hash，也稱為 VersionedHash。另外還有兩個相伴而來的設計，其一相較於普通交易，blob transaction 的 GC 週期更短，從而保證區塊數據不至於過於臃腫，其二 blob data 的具有原生的 Gas 機制，總體上所呈現的效果於 EIP-1559 類似，但在數學模型上選擇自然指數函數，使其在應對交易規模波動時穩定性上表現較好，因為自然指數函數的斜率亦為自然指數函數，這意味著無論此時網路交易規模處在什麼狀態，當交易規模快速飆升時，blob gas 的 base fee 反應的更充分，從而有效遏制交易活躍度，同時該函數還有一個重要的特性，當橫坐標為 0 使，函數值為 1。
base_fee_per_blob_gas = MIN_BASE_FEE_PER_BLOB_GAS * e**(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION)
其中 MIN_BASE_FEE_PER_BLOB_GAS 和 BLOB_BASE_FEE_UPDATE_FRACTION 為兩個常數，而 excess_blob_gas 則由父區塊中總的 blob gas 消耗於一個 TARGET_BLOB_GAS_PER_BLOCK 正量之間的差值來決定，當 TARGET_BLOB_GAS_PER_BLOCK 量值之間的差值來常數，e**(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION) 大於 1，則 base_fee_per_blob_gas 變大，反之則變小。
這樣對於一些只希望利用 Ethereum 的共識能力為某些規模較大的資料做存證以保證可用性的場景就可低成本的執行，同時不會擠佔區塊的交易打包能力。以 Rollup 排序器為例，可以透過 blob transaction 將 L2 的關鍵資訊封裝到 blob data 中，並在 EVM 中透過精巧的設計，利用 versionedHash 實作鏈上驗證的邏輯。
需要補充的是當前 TARGET_BLOB_GAS_PER_BLOCK 和 MAX_BLOB_GAS_PER_BLOCK 的設定為主網帶來了一個限制，即每個區塊的平均處理 3 個 blob (0.375 MB) 的目標和最多 6 個 blob (0.75 MB) 的限制。這些初始限制旨在最大限度地減少該 EIP 對網路造成的壓力，並且隨著網路在較大區塊下展現可靠性，預計將在未來的升級中增加。
對於執行環境 Gas 消耗模型的再細化－EIP-7706
在明確了目前 Ethereum 的 Gas 模型後，我們來看下 EIP-7706 提案的目標與實施細節。該提案由 Vitalik 在 2024 年 5 月 13 日提出。與 Blob data 類似，該提案對另一個具有特殊性的資料欄位對應的 Gas 模型進行了剝離，這個資料欄位即為 calldata。並且優化了對應的程式碼實作邏輯。
從原理上 calldata 的 base fee 計算邏輯與 EIP-4844 中 base fee for blob data 相同，均採用了指數函數並根據父區塊中的實際 gas 消耗值與目標值的偏差值來計算對當前 base fee 的縮放比例。
值得注意的是一個新的參數設計，LIMIT_TARGET_RATIOS=[2,2,4]，其中 LIMIT_TARGET_RATIOS[0] 表示了執行操作類 Gas 的目標比率，LIMIT_TARGET_RATIOS[1] 表示 Blob data 類 Gas 的目標比率，LIMIT_RGET_ 2] 表示 calldata 類別 Gas 的目標比率，這個向量用來計算父區塊中三類 gas 對應的的 gas target 值，計算邏輯如下，即分別使用 LIMIT_TARGET_RATIOS 對 gas limit 做整除操作：
其中 gas_limits 的設定邏輯如下：
gas_limits[0] 必須遵循現有的調整公式
gas_limits[1] 必須等於 MAX_BLOB_GAS_PER_BLOCK
gas_limits[2] 必須等於 gas_limits[0] // CALLDATA_GAS_LIMIT_RATIO
我們知道目前 gas_limits[0] 為 30000000，CALLDATA_GAS_LIMIT_RATIO 被預設為 4，這表示目前 calldata gas target 約為 30000000 // 4 // 4 = 1875000，又因為依照目前的 calldata gas 計算零 Bytes 消耗 16 Gas，零 Bytes 消耗 4 Gas，假設某段 calldata 中非零與零 Bytes 的分佈各佔 50%，則平均處理 1 Bytes 的 calldata 需要消耗 10 Gas。因此目前的 calldata gas target 應對應 187500 bytes 的 calldata 數據，約為目前平均用量的 2 倍。
這樣做的好處在於大幅減少了 calldata 達到 gas limit 的情況發生的機率，透過經濟模型使 calldata 的用量保持在一個較為始終的狀態，同時也杜絕了對 calldata 的濫用。之所以做這樣的設計還是為 L2 的發展掃平障礙，搭配 blob data，使得排序器成本進一步降低。
免責聲明：作為區塊鏈資訊平台，本站所發布文章僅代表作者及來賓個人觀點，與 Web3Caff 立場無關。文章內的資訊僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
