作者：@Web3Mario
引言：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常數之間的差值來決定，當總的值差值時，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_TARGET_RATIOS[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計算邏輯，每個非零零Bytes16 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，使得排序器成本進一步降低。
