WEEX 唯客博客， 作者：Vitalik Buterin 編譯：Karen，Foreisght News 在以太坊中，資源直到最近還是有限的，並通過一種稱為「 Gas 」的單一資源來定價。 Gas 是衡量處理特定交易或區塊所需「計算量」（ computational effort ）的度量單位。 Gas 將多種類型的「計算量」融合在一起，其中最重要的包括： 1、原始計算（ Raw computation ，例如 ADD 、 MULTIPLY ）； 2、讀寫和寫入以太坊存儲（例如 SSTORE 、 SLOAD 、 ETH 轉賬）； 3、數據帶寬； 4、生成區塊的 ZK – SNARK 證明的成本。 例如，我發送的這筆交易總共消耗了 47,085 Gas 。其中包括：（ i ）基本成本為 21000 Gas ，（ i i ）作為交易一部分包含的 calldata 位元組消耗了 1556 Gas ，（ i i i ）讀寫存儲消耗了 16500 Gas ，（ i v）生成日誌（ log ）消耗了 2149 Gas ，其餘用於 EVM 執行。用戶必須支付的交易費用與交易消耗的 Gas 成正比。一個區塊最多可以包含 3000 萬 Gas ，並且 Gas 價格通過 EIP -1559 target i ng 機制不斷調整，確保每個區塊平均包含 1500 萬 Gas 。 這種方法有一個主要的優勢：因為所有內容都合併為一個虛擬資源，所以市場設計非常簡單。優化交易以最小化成本很容易，優化區塊以收取儘可能高的費用相對容易（不包括 MEV ），並且沒有奇怪的激勵機制鼓勵一些交易與其他交易捆綁以節省費用。 然而，這種方法也存在低效性：它將不同的資源視為可以相互轉換，而實際的底層限制並不一樣。要理解這個問題，你可以先看下面這張圖表： Gas 限制強加了一個約束條件： 實際的底層安全約束通常更接近： 這種差異導致 Gas 限制要麼無端地排除了實際安全的區塊，要麼接受了實際上不安全的區塊，或者兩者兼而有之。 如果有 n 種資源具有不同的安全限制，那麼一維 Gas 可能會使吞吐量最多降低 n 倍。因此，長期以來，人們一直對多維 Gas 的概念感興趣，而通過 EIP -4844，我們現在實際上已經在以太坊上實現了多維 Gas 。本文探討了這種方法的優點，以及進一步進行增強的前景。 Blob ： Dencun 中的多維 Gas 今年年初，平均區塊大小為 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 ）來解決。 這兩種資源有不同的價格和限制：在 Dencun 硬分叉之後，一個以太坊區塊最多可以包含（ i ）3000 萬 Gas 和（ i i ）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 和無狀態客戶端 在不久的將來，無狀態客戶端（ stateless clients ）的存儲證明也會出現類似的問題。無狀態客戶端是一種新型客戶端，將能夠驗證鏈而無需在本地存儲大量或任何數據。無狀態客戶端通過接受該區塊中交易需要訪問的以太坊狀態的特定部分的證明來實現這一點。 上圖展示了一個無狀態客戶端接收一個區塊，以及證明該區塊執行所觸及的狀態特定部分（例如，賬戶餘額、代碼、存儲）當前值的證明，這使得節點能夠在沒有任何存儲的情況下驗證一個區塊。 一次存儲讀取需要花費 2100-2600 Gas ，具體取決於讀取類型，而存儲寫入成本更高。平均而言，一個區塊會執行大約 1000 次存儲讀寫操作（包括 ETH 餘額檢查、 SSTORE 和 SLOAD 調用、合約代碼讀取和其他操作）。然而，理論上的最大值是 30,000,000/2,100=14,285 次讀取。無狀態客戶端的帶寬負載與該數字成正比。 目前的計劃是通過將以太坊的 State tree 設計從 Merkle Patricia tree s 轉變為 Verkle tree s 來支持無狀態客戶端。然而， Verkle tree s 不具備抗量子性，並且對於較新的 STARK 證明系統來說並不是最優選擇。因此，許多人有興趣通過二進位 Merkle tree s 和 STARK s 來支持無狀態客戶端，要麼完全跳過 Verkle ，要麼在 Verkle 過渡幾年後，一旦 STARK 變得更加成熟，就進行升級。 基於二進位哈希樹分支的 STARK 證明具有許多優點，但其關鍵弱點在於生成證明的時間很長： Verkle 樹可以每秒證明十萬個以上的值，基於哈希的 STARK s 通常只能每秒證明幾千個哈希，而證明每個值都需要包含許多哈希的「分支」（ branch ）。 考慮到今天從 Binius 和 Plonky3 等超優化證明系統以及 Vision – Mark -32 等專用哈希中預測的數字，我們似乎將在一段時間內處於一個實用範圍內，即每秒證明 1000 個值是可行的，但證明 14,285 個值則不可行。平均區塊會沒問題，但潛在最壞情況下的區塊（由攻擊者發布）會破壞網路。 我們處理此類情況的 default 方法是重新定價：提高存儲讀取的成本，以減少每個區塊的最大值到更安全的水平。但是，我們已經這樣做了很多次，如果再次這樣做，會使太多應用變得太昂貴。一個更好的方法是多維 Gas ：分別對存儲訪問進行限制和收費，將平均使用量保持在每個區塊 1,000 次存儲訪問，但設置每個區塊的上限進行設置，例如 2000 次。 多維 Gas 的普遍性 另一個值得考慮的資源是狀態大小的增長：即增加以太坊狀態大小的操作，這些操作之後需要全節點來保存。狀態大小增長的獨特之處在於，限制它的理由完全來自於長期持續的使用，而不是峰值。 因此，為增加狀態大小的操作（例如， zero – to -non zero SSTORE 、合約創建）添加一個單獨的 Gas 維度可能是有價值的，但目標不同：我們可以設定一個浮動價格來針對特定的平均使用量，但完全不設置每個區塊的限制。 這展示了多維 Gas 的一個強大屬性：它讓我們能夠分別針對每個資源，詢問（ i ）理想平均使用量是多少？（ i i ）每個區塊的安全最大使用量是多少？與基於每個區塊的最大值來設定 Gas 價格，並讓平均使用量跟隨其後不同，我們有 2n 自由度來設定 2n 參數，根據對網路安全的考慮來調整每一個參數。 更複雜的情況，例如當兩種資源的安全性考慮部分相加時，可以通過使一個操作碼或資源消耗多種類型的 Gas 的某種數量來處理（例如，一個 zero – to -non zero SSTORE 可能消耗 5000 個無狀態客戶端證明 Gas 和 20000 個存儲擴展 Gas ）。 每筆交易 Max （選取數據或計算消耗更大的那種） 令 𝑥1 為數據的 Gas 成本， 𝑥2 為計算 Gas 成本，因此在一維 Gas 系統中我們可以寫出一筆交易的 Gas 成本： 在這個方案中，我們將交易的 Gas 成本定義為： 也就是說，交易不是根據數據加計算來收費，而是根據它消耗的兩種資源中哪一種資源更多來收費。這可以輕鬆擴展以覆蓋更多維度（例如 𝑚𝑎𝑥(…,𝑥3∗𝑠𝑡𝑜𝑟𝑎𝑔𝑒_𝑎𝑐𝑐𝑒𝑠𝑠) ）。 應該很容易看出這如何在保證安全性的同時提高吞吐量。理論上一個區塊中的最大數據量仍然是 Gas LIMIT /𝑥1，與一維 Gas 方案中完全相同。類似地，理論上的最大計算量是 Gas LIMIT /𝑥2 ，同樣與一維 Gas 方案中完全相同。然而，任何消耗數據和計算的交易的 Gas 成本都會降低。 這大概是提議的 EIP -7623 中採用的方案，以減少最大區塊大小，同時進一步增加 blob 計數。 EIP -7623 中的精確機制稍微複雜一些：它保持當前的 calldata 價格為每位元組 16 Gas ，但增加了每位元組 48 Gas 的 floor price ；交易支付 ( 16 * bytes + execution _ Gas ) 和 ( 48 * bytes ) 中的較高者。因此， EIP -7623 將區塊中理論最大交易調用數據從約 1.9 MB 減少到約 0.6 MB ，同時保持大多數應用程序的成本不變。這種方法的好處是它與當前的一維 Gas 方案相比變化非常小，因此非常容易實現。 不過這種方法有兩個缺點： 1、即使區塊中的所有其他交易只使用很少的該資源，但大量佔用一種資源的交易仍然會不必要地收取大量費用； 2、它激勵數據密集型和計算密集型交易合併到一個捆綁包中以節省成本。 我認為， EIP -7623 這樣的規則，無論是對於交易 calldata 還是其他資源，都可以帶來足夠大的好處，即使存在這些缺點，也是值得的。 然而，如果我們願意投入（顯著更高的）開發努力，就會出現一種更理想的方法。 多維 EIP-1559：更困難但理想的策略 讓我們首先回顧一下常規 EIP -1559 的工作原理。我們將重點關注 EIP -4844 中針對 blob 引入的版本，因為它在數學上更加優雅。 我們跟蹤一個參數 excess _ blobs 。在每個區塊期間，我們設置： excess _ blobs
