引言：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常量之間的差值來決定，當總的blob gas消耗超過目標值，即差值爲正時，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計算邏輯，每個非零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，使得排序器成本進一步降低。

聲明：

1. 本文轉載自[深潮 TechFlow]，著作權歸屬原作者[Web3Mario]，如對轉載有異議，請聯系Gate Learn團隊，團隊會根據相關流程盡速處理。
2. 免責聲明：本文所表達的觀點和意見僅代表作者個人觀點，不構成任何投資建議。
3. 文章其他語言版本由Gate Learn團隊翻譯， 在未提及Gate.io)的情況下不得復制、傳播或抄襲經翻譯文章。