在以太坊中，Gas是一種用於定價交易或區塊處理計算量的資源單位。 Gas包含原始計算、讀寫儲存、資料頻寬等多種運算量，用戶需依照消耗的Gas支付交易費用。每個區塊最多包含3000萬Gas，價格透過EIP-1559調整。為了降低Rollup交易成本，提高無狀態客戶端儲存證明效率，引入了多維Gas概念。多維Gas可以分別針對不同資源設定價格和限制，提高網路吞吐量和安全性。儘管存在一些缺點，多維Gas仍然被認為是值得嘗試的改進方法。
作者：維塔利克‧布特林
編按：Karen，前瞻新聞
在以太坊中，資源直到最近還是有限的，並透過一種稱為“Gas”的單一資源來定價。 Gas 是快速處理特定交易或區塊所需「計算量」（計算量）的迫切單位。 Gas將多種類型的「計算量」融合在一起，其中最重要的包括：
1、原始計算（原始計算，如ADD、MULTIPLY）；
2、讀寫機和以太坊儲存（如SSTORE、SLOAD、ETH轉帳）；
3、數據頻寬；
4、產生區塊的ZK-SNARK證明的成本。
例如，我發送的短暫交易總共消耗了47,085 Gas。其中包括：（i）基本成本為21000 Gas，（ii）作為交易部分包含的calldata 位元組消耗了1556 Gas，（iii）讀寫儲存消耗了16500 Gas，（iv）產生日誌（log）消耗了2149 Gas，其餘用於EVM 執行。用戶必須支付的交易費用與交易消耗的Gas 成正比。一個區塊最多可以包含3000 萬Gas，而Gas 價格透過EIP-1559瞄準機制不斷調整，確保每個區塊平均包含1500萬Gas。
這種方法有一個優點：所有內容都合併為一個虛擬資源，所以市場設計非常簡單。優化交易以最小化成本很容易，優化區塊費用以主要費用高的費用相對容易（因為不包括MEV） ），並且沒有奇怪的激勵機制將一些交易與其他交易捆綁在一起以節省費用。
然而，這種方法也存在低效性：將不同的資源視為可以相互轉換，而實際的底層限制並不一樣。要理解這個問題，你可以先看下面這張K線走勢圖：
燃氣限制強加了一個約束條件：
實際的安全約束通常更接近：
錯誤導致氣體限製或無端地排除了實際安全的區塊，或接受了實際不安全的區塊，或兩者兼而有之。
如果有n種資源不同的安全限制，那麼一維Gas可能會使吞吐量最多降低n倍。因此，長期以來，人們一直對多維Gas的概念感興趣，而透過EIP-4844，我們現在實際上已經在以太坊上實現了多維氣體。本文探討了這種方法的優點，以及進一步增強的前景。
Blob：Dencun中的多維燃氣
今年年初，平均區塊大小為150 kB。其中很大一部分是Rollup 資料：Layer2 協定在鏈上資料儲存。這些數據非常昂貴：儘管Rollup 上的交易成本以太坊L1 上相應交易的5-10倍，但即使這樣的成本對於許多例子來說也太高了。
那為什麼不降低calldata 的Gas 成本（目前非零位元組為16 Gas，零位元組為4 Gas），因此Rollup 比較便宜呢？我們之前這樣做過，現在也可以再做一次。這裡但的答案是：區塊的最大大小是30,000,000/16=1,875,000 非零字節，而網路勉強能力或幾乎無法處理這樣大小的區塊了。再將成本降低4 倍從而瞬間提高到7.5 MB，這將對安全性帶來巨大的風險。
這個問題最終透過在每個區塊中引入一個獨立的、針對Rollup 介面的資料空間（稱為blob）來解決。
這兩種資源有不同的價格和限制：在Decun硬分叉之後，一個以太坊區塊最多可以包含（i）3000萬Gas和（ii）6個blob，每個blob可以包含約125 kB的calldata這兩種資源都有單獨的價格，並透過單獨的EIP-1559 的定價機制進行調整，目標是每個區塊平均使用1500 萬Gas 和3 個blob。
結果是，Rollup 的成本降低了100 倍，Rollup 上的交易量增加了3 倍以上，而理論上的最大區塊大小僅預期增加：從約1.9 MB 增加到約2.6 MB。
註：Rollup 交易費用，由Growthepie.xyz 提供。 Dencun 分叉發生於2024 年3 月13 日，引入了多維定價blob。
多維Gas 和無狀態客戶端
在不久的將來，無狀態客戶端（無狀態客戶端）的儲存證明也會出現類似的問題。無狀態客戶端是一種新型客戶端，將能夠驗證鏈，從而消耗在本地儲存大量或任何資料。客戶端透過接受該區塊中交易需要存取的以太坊狀態的特定部分的證明來實現這一點。
上圖展示了一個無狀態客戶端接收一個區塊，以及證明該區塊執行所達到的狀態特定部分（例如，帳戶餘額、程式碼、儲存）當前值的證明，這使得節點能夠在沒有任何儲存的情況下驗證一個區塊。
一次儲存讀取需要花費2100-2600 Gas，根據特定讀取類型，而儲存寫入成本更高。平均而言，一個區塊會執行大約1000 次儲存讀寫操作（包括ETH 餘額檢查、 SSTORE 和然而，理論上的峰值是30,000,000/2,100=14,285 次讀取。無狀態客戶端的頻寬負載與該數字成正比。
目前的計劃是透過將以太坊的狀態樹設計從Merkle Patricia trees 轉變為Verkle trees 來支援無狀態客戶端。然而，Verkle trees 不具備抗量子性，而對於較新的STARK 證明系統來說並不是最好的因此，許多人有興趣通過二進制Merkle 樹和STARK 來支持無狀態客戶端，或者完全跳過Verkle，或者在Verkle 過渡幾年後，一旦STARK 變得更加成熟，就進行升級。
基於二進制雜湊樹分支的STARK 論證具有許多優點，但其關鍵缺陷在於生成論證的時間很長：Verkle 樹可以每秒論證十萬個以上的值，基於哈希的STARK 通常只能每秒幾論證千個哈希，而證明每個值都需要包含多個哈希的「分支」（branch）。
考慮到今天從Binius 和Plonky3 等超優化證明系統以及Vision-Mark-32 等專用哈希中預測的數字，我們似乎將在一個實用範圍內的間歇期，即每秒證明1000 個值是可行的，但證明14,285 個數值則無法安裝。平均區塊不會出現問題，但潛在最壞情況下的區塊（由攻擊者發布）會破壞網路。
我們處理此類情況的預設方法是重新定價：提高儲存讀取的成本，以減少區塊的每次高峰到更安全的水平很多。但是，我們已經這樣做過幾次了，如果再次這樣做，會讓過多的應用變得太昂貴。一個更好的方法是多維Gas：分別對儲存存取進行限制和收費，將平均使用量保持在每個區塊1,000次儲存訪問，但設定每個區塊的上限進行設置，例如2000次。
多維氣體的普遍性
另一個值得考慮的資源是狀態大小的成長：也就是增加以太狀態大小的操作，這些操作之後需要全節點來保存。狀態大小成長的獨特坊所在，它的理由完全來自於長期持續的使用，而不是高峰。
因此，為了增加狀態大小的操作（例如，零到非零的SSTORE、合約創建），添加單獨的Gas 維度可能是有價值的，但目標不同：我們可以針對特定的平均使用設定一個浮動價格量，但完全不設定每個區塊的限制。
這顯示了多維天然氣的一個強大屬性：它讓我們能夠分別針對每個資源，詢問（i）理想平均使用量是多少？ （ii）每個區塊的安全最大使用量是多少？並基於每個資源區塊的頂峰來設定Gas價格，並讓平均使用量跟隨其後不同，我們有2n個自由度來設定2n個參數，根據對網路安全的考慮來調整每一個參數。
更複雜的情況，例如當兩種資源的安全性考慮部分相加時，可以透過使用一個操作碼或資源消耗多種類型的Gas 的某種數量來處理（例如，一個零到非零的SSTORE 可能）消耗5000個無狀態客戶端證明Gas和20000個儲存擴充Gas）。
每筆交易Max（大量數據或計算消耗較大的那種）
令𝑥1 為資料的Gas 成本，𝑥2 為計算Gas 成本，因此在維Gas 系統中我們可以寫出記帳交易的Gas 成本：
在本方案中，我們將交易的Gas 成本定義為：
也就是說，交易不是根據資料加計算來收費，而是根據其消耗的單一資源中的哪一種資源更多來收費。這可以輕鬆擴展以覆蓋更多維度（例如𝑚𝑎𝑥(…,𝑥3 ∗𝑠𝑡𝑜𝑟𝑎𝑔𝑒_𝑎𝑐𝑐𝑒𝑠) ）。
應該很容易看出這如何在保證安全性的同時提高吞吐量。理論上一個區塊中的最大資料量仍然是GasLIMIT/𝑥1，與一維Gas方案中相同。類似地，理論上的最大計算量量為GasLIMIT/𝑥2 ，同樣與一維Gas 方案中很少。然而，任何消耗數據和計算的交易的Gas 成本都會降低。
這大概是提議的EIP-7623中採用的方案，以減少最大區塊大小，同時進一步增加blob機制統計。 EIP-7623中精確的結構複雜一些：它保持當前的calldata價格為每位元組16 Gas，但增加了每位元組48 Gas 的底價；交易支付( 16 * bytes +execution_Gas ) 和( 48 * bytes ) 中的同類者。因此，EIP-7623 將區塊中理論最大交易調用資料從約1.9 MB減少到約0.6 MB，同時保持大多數應用程式的成本不變。這種方法的好處是它與目前的一維Gas方案相比變化非常小，因此非常容易實現。
這種方法有兩個缺點：
1、即使區塊中的所有其他交易只使用很少的該資源，但大量佔用某種資源的交易仍然不會消耗大量費用；
2、它鼓勵資料密集型和計算密集型交易合併到一大包中以節省成本。
我認為，EIP-7623這樣的規則，無論是用於交易通話資料還是其他資源，都可以帶來足夠大的好處，即使存在這些缺點，也是值得的。
然而，如果我們致力於（顯著更高的）開發努力，就會出現一種更理想的方法。
多維EIP-1559：更困難但更理想的策略
讓我們先回顧一下常規EIP-1559 的工作原理。我們將重點放在EIP-4844 中針對blob 引入的版本，因為它在數學上更加優雅。
我們追蹤一個參數extra_blobs 。在每個區塊期間，我們設定：
extra_blobs
其中TARGET = 3。相反，如果某個區塊的blob數量多於目標，則excess_blobs會增加，如果某個區塊的blob數量少於目標，則excess_blobs會減少。然後我們設定blob_basefee = exp( extra_blobs / 25.47) ，其中exp 是指數函數𝑒𝑥𝑝(𝑥)=2.71828^𝑥 的近似值。
也就是說，每當excess_blobs增加約25倍時，blob基本費用就會增加約2.7倍。如果blob變得太貴，平均使用量就會下跌，而excess_blobs開始減少，從而自動再次降低價格。 Blob的價格不斷調整，以確保平均而言，區塊是半滿的，究竟，每個區塊平均包含3個Blob。
如果使用量出現短期高峰，則初始出現限制：每個區塊最多只能包含6 個Blob，在這種情況下，交易可以透過提高優先費來相互補充。但是，在正常情況下，每個Blob須支付blob_basefee 加上少量的額外優先費用作為被納入的激勵。
這種Gas定價在以太坊中已經存在多年：早在2020年，EIP-1559就引進了非常相似的機制。透過EIP-4844，我們為Gas和Blob設定了兩個獨立的浮動價格。
註：2024年5月8日一小時內的Gas基本費用，單位為gwei。來源：ultrasound.money
原則上，我們可以為儲存讀取和其他類型的操作添加更多獨立浮動的費用，不過我在下一節中將詳細闡述一個需要注意的問題。
對於用戶來說，這種體驗與今天非常相似：你不再支付基本費用（basefee），而是支付兩項基本費用，但你的錢包可以將其從你的手中抽像出來，只給你顯示可以支付的預期費用和最高費用。
對於區塊鏈建構者來說，大多數時候最佳策略與今天相同：包括任何有效的內容。大多數區塊都未滿——無論是Gas還是Blob。一個遇到困難的情況是，當有足夠的時候的Gas 或足夠的Blob 超過區塊限制時，建構者需要潛在地解決多維背包問題以最大化其利潤。然而，即使存在相當好的近似演算法，在這種情況下，透過制定通用演算法來優化利潤所獲得的收益也比使用MEV進行相同操作所獲得的收益要小得多。
對於開發人員來說，主要的挑戰是需要重新設計EVM 及其相關基礎設施的功能，這些功能目前是基於單一價格和單一限制設計的，而現在需要將其改造成能夠適應多種價格和多種限制的設計。
應用程式開發人員面臨的一個問題是優化變得非常困難：在某些情況下，您不能再有效率地表示A 比B 更有效率，因為如果A 使用更多的呼叫數據，而B 使用更多的執行，那麼當calldata便宜時，當calldata昂貴時則更昂貴。
應用程式開發者面臨的一個問題是優化會變得有些困難：在某些情況下，你無法明確地說A 比B 效率更高，因為如果A 使用了更多的呼叫數據，而B 使用了更多的執行，那麼當calldata便宜時A可能更便宜，而當calldata昂貴時A可能更貴。
然而，開發者仍然可以透過基於長期歷史平均價格進行最佳化，來獲得相當不錯的結果。
多維定價、EVM 和子調用
在blob 中沒有出現問題，在EIP-7623 或甚至是針對calldata 的完整定價實作中也不會出現，但如果我們嘗試對狀態存取或其他任何資源進行單獨定價，那麼這個問題就會出現：即子呼叫（sub-calls）中的Gas限制。
EVM 中的Gas 限制位於兩個地方。首先，每筆交易都會設定一個Gas 限制（Gas Limit），限制了該交易中可以使用的Gas 目標。其次，當一個標誌存在另一個標誌時，該呼叫可以設定自己的Gas 限制。這允許約定調用他們不信任的其他約定，並且仍然保證他們在呼叫後剩餘的Gas 來執行其他計算。
註：帳戶抽象交易的追蹤軌跡，其中一個帳戶呼叫另一個帳戶，且僅向被呼叫者提供有限數量的Gas，以確保即使被呼叫者消耗了分配給其的全部Gas，外部呼叫也可以繼續運行。
挑戰在於：讓不同類型的執行之間實現多維Gas 似乎需要子呼叫為適配器類型的Gas 提供多種限制，這將需要對EVM 進行非常深入的更改，並且與現有應用程式不相容。
這就是為什麼多維Gas 提議通常停留在兩個維度的原因：資料和執行。資料（無論是交易calldata 還是blob）僅在EVM 外部分配，因此EVM 內部更換任何內容都可以使calldata 或blob 單獨定價。
我們可以想出一個「EIP-7623 式的解」來解決這個問題。這是一種簡單的實作：在執行期間，對儲存作業收取4 倍的費用；為了簡化分析，假設每個儲存作業都有10000 氣體。交易結束時，退款min(7500 * storage_operations,execution_Gas) 。結果是，在居民退款後，用戶需要支付以下費用：
執行氣體+ 10000 * 儲存操作– 分鐘(7500 * 儲存操作, 執行氣體)
這就是：
最大值（執行氣體+ 2500 * 儲存操作，10000 * 儲存操作）
這反映了EIP-7623 的結構。另一種方法是即時追蹤storage_operations 和execution_Gas ，並根據當時max(execution_Gas + 2500 * storage_operations, 10000 * storage_operations) 上漲多少費用2500 或10000。操作被呼叫。這避免了交易需要過度分配Gas，而這些Gas主要透過退款來收回。
我們沒有獲得子呼叫的細粒度許可：子呼叫可能會消耗交易的所有津貼以進行廉價的儲存操作。
但我們確實得到了一些足夠好的東西，即進行呼叫子的合約可以設定一個限制，並確保一旦子呼叫執行完成，主呼叫足夠的Gas進行所需的後處理（post-processing）。
我能想到的最簡單的「完整的多維定價解決方案」是：我們視為將子燃氣限製成比例的呼叫。相反，假設有𝑘種不同的執行類型，並且每筆交易都設定了多維限制𝐿1…𝐿𝑘 。假設在目前執行點，剩餘Gas 為𝑔1…𝑔𝑘 。假設呼叫CALL 操作碼，並使用子呼叫Gas 限制𝑆 。令𝑠1=𝑆 ，然後𝑠2=𝑠1/𝑔1*𝑔2 ， 𝑠3 =𝑠1/𝑔1∗𝑔3 ，以此類推。
也就是說，我們將第一種類型的Gas（實際上是VM執行）視為一種特殊的「帳戶單位」，然後分配其他類型的Gas，以便子呼叫在端點類型的Gas中都獲得相同的百分之一的可用Gas。這種方法有點難看（醜陋），最大限度地保證了一致性。
如果我們想在不犧牲剛性相容性的情況下，使該方案在不同類型的Gas 之間更加“中立”，我們可以簡單地調用子調用的Gas 限制參數表示為當前上下文中剩餘Gas 的一部分（例如，[1…63]/64）。
然而，無論在哪種情況下，都值得強調的是，一旦開始引入多維執行氣體，固有的複雜性（醜陋）就會增加，這似乎很難避免。
因此，我們的任務是做一個複雜的權衡：我們是否接受在EVM層面上某種程度的複雜性（醜陋）增加，以安全地釋放顯著的L1可擴展性增益，如果是的話，哪種很可能，我上面提到的兩個方案都不是最好的，但新生兒空間提出了更優雅、更好的方案。
特別感謝Ansgar Dietrichs、Barnabe Monnot 和Davide Crapis 的回饋和審查。
資訊來源：0x資訊編譯自網際網路。版權歸作者Vitalik Buterin所有，未經許可，不得轉載