天天看點

詳述 EIP-7706 并梳理最新的 Ethereum 的 Gas 機制

作者:MarsBit

原文作者: @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的情況下。在當時核心開發者看來這個機制面臨着以下四個方面的問題:

l 交易費用水準的波動性與交易的共識成本之間的不比對:對于處在活躍狀态的區塊鍊中,交易的打包需求充足,這意味着區塊可以被輕易填滿,但這往往也意味着整體費用的波動性極大。例如當平均Gas Price為10 Gwei時,網絡因在一個區塊中再接受一筆交易而産生的邊際成本是平均Gas Price為1 Gwei時的10 倍,這是不可接受的。

l 對使用者來說不必要的延遲:由于每個區塊有gaslimit的硬性限制,加上曆史交易量的自然波動,交易通常會等待幾個區塊才能被打包,但這對整體網絡來說是低效的;即不存在允許一個區塊更大而下一個區塊更小的“松弛”機制來滿足逐個區塊的需求差異。

l 定價效率低下:由于采用簡單的拍賣機制導緻了公允價格發現的效率較低,這意味着對于使用者來說,給出一個合理的定價将是困難的,這也就意味着有非常多情況下,使用者付高了手續費。

l 無區塊獎勵的區塊鍊将不穩定:當取消挖礦帶來的區塊獎勵并采取單純的手續費模型時,可能會導緻很多不穩定,例如激勵挖掘竊取交易費用的“姐妹塊”,開啟更強大的自私挖掘攻擊向量等。

直到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的計算是直接由系統決定的而非使用者自由指定。具體的代碼如下:

詳述 EIP-7706 并梳理最新的 Ethereum 的 Gas 機制

其中可知當parent_gas_used 大于parent_gas_target時,那麼目前區塊的base fee将相比于上一個區塊的base fee加上一個偏移值,至于偏移值則是取parent_base_fee乘以上一個區塊gas總用度相對gas target的偏移量并對gas target與一個常量取餘與1的最大值。反之邏輯類似。

另外Base fee将不再作為獎勵配置設定給礦工,而是直接銷毀,進而時ETH的經濟模型處于通縮的狀态,有利于價值的穩定。而另一方面Priority fee則相當于使用者給礦工的打賞,可以自由定價,這一定程度上可以讓礦工的排序算法得到一定程度的複用。

詳述 EIP-7706 并梳理最新的 Ethereum 的 Gas 機制

随着時間推進到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 對網絡造成的壓力,并且随着網絡在較大區塊下展現出可靠性,預計會在未來的更新中增加。

詳述 EIP-7706 并梳理最新的 Ethereum 的 Gas 機制

對于執行環境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的縮放比例。

詳述 EIP-7706 并梳理最新的 Ethereum 的 Gas 機制

值得注意的是一個新的參數設計,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,使得排序器成本進一步降低。