原文作者： @Web3 Mario
引言：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 倍，這是不可接受的。
對用戶來說不必要的延遲：由於每個區塊有gas limit 的硬性限制，加上歷史交易量的自然波動，交易通常會等待幾個區塊才能被打包，但這對整體網路來說是低效的；即不存在允許一個區塊更大而下一個區塊更小的「鬆弛」機制來滿足逐個區塊的需求差異。
定價效率低：由於採用簡單的拍賣機制導致了公允價格發現的效率較低，這意味著對於用戶來說，給出一個合理的定價將是困難的，這也意味著有非常多情況下，用戶付高了手續費。
無區塊獎勵的區塊鏈將不穩定：當取消挖礦帶來的區塊獎勵並採取單純的手續費模型時，可能會導致很多不穩定，例如激勵挖掘竊取交易費用的“姐妹區塊”，開啟更強大的自私挖礦攻擊向量等。
直到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 類別GYY 的目標比率，LILIM 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 ，又因為按當前的calldatadata 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，使得排序器成本進一步降低。
