作者：John Otander，以太坊核心開發人員；翻譯：喜來順財經xiaozou
這篇文章的靈感來自于以太坊常使人Vitalik在最近的?Reddit AMA 中的回答。
Vitalik指出，適度提高Gas?Limit是合理的，Gas Limit已經近三年沒有增加，這是該協議歷史上最長的時間，。Vitalik還做了一些簡單的計算表示將以太坊Gas?Limit提高到4000萬。
本文講述了為何說提高以太坊Gas Limit比較困難？提高以太坊Gas Limit帶來的風險，以及相關解決方案。
Gas limit決定了一個區塊內的工作完成量，因此決定了每個區塊可以執行多少交易。提高gas limit將使以太坊能夠處理更高的交易吞吐量或更復雜的交易。一直以來，具體的gas limit設置受礦工/質押者影響，并且多年來限額一直在增加。下圖來自etherscan.io，顯示了gas歷史用量（非常接近gas limit，所有限額增加都被市場消化掉了）。
現在提高gas limit涉及到幾個風險。
（1）漏塊率
我在之前的文章中提到，叔塊率（uncle rate）是評估gas limit增加時討論最多的一個指標。現在，在以太坊合并之后，再也沒有叔塊了。我們要想知道節點是否能很好地處理了當前的gas limit，唯一的方法就是看漏塊率。但這個指標是有瑕疵的，因為它只顯示當前供應不足的節點。它并沒有提供給我們一個很好的指標來顯示gas limit的增加，而且它只顯示了平均情況，而不是在攻擊中可能發生的最壞情況。
（2）狀態大小
區塊18418786（2023年10月24日）的賬戶快照為10.33GB，存儲快照為76.59GB，因此整體狀態大致為87GB。區塊17419840（2023年6月6日）的狀態略小于80GB。這意味著狀態在4個月內大約增長了7GB，也就是說每月增長約2GB。
如果我們使用87+(2*12*#年)來推斷，一年后的狀態將是111GB，五年后將是207 GB。這里的問題不在于大小。每個人都可以存儲這么多的數據，但是訪問和修改這些數據卻會變得越來越慢。
這還只是快照，是一般狀態。Geth還需要以不同的形式存儲此狀態，以便驗證狀態根。區塊18418786的另一種狀態存儲形式（trie節點）大約需要180GB。
因此，目前僅用于狀態存儲的總空間大小約為267GB。如果我們提高gas limit，狀態大小會增長得更快。
狀態增長的問題在于，與過去不同，我們沒有明確的途徑來移除狀態。沒有我們可以迅速實施的具體的狀態期限建議來讓我們擺脫不斷增長的狀態。
（3）歷史規模
在我2021年的一篇文章中曾提到，一個完整的geth節點大約為350GB（新修剪的）。大約三年過后，一個完整的geth節點（在pbss上）超過900GB。下圖顯示了交易的總累積量。從中很容易看出，交易量在三年內增加了一倍多，從大約9.8億筆增加到超22億筆。
隨著L2的崛起，歷史規模已經成為一個更大的問題，因為它們現在（在4844上線之前）存儲數據的方式是calldata。區塊18418786的塊體超過427GB，區塊17419840（同樣是4個月前）的塊體為339GB，這意味著4個月內增長28GB，也就是說大約每月增長9GB。我們可以用427+(9*12*#年)來推斷這種增長，即一年后為535GB，五年后為967GB（再次假設為線性增長）。
希望在EIP-4844上線后，這種增長會放緩，屆時L2將停止使用CALLDATA來獲取數據可用性，并轉為使用幾周后到期的blob。
EIP-4444將解決歷史增長問題，因為全節點不再需要存儲所有歷史。實現EIP-4444需要一個可靠的網絡來檢索歷史，然后我們才能使全節點停止歷史數據服務。
（4）同步時間
Gas limit在很多方面都可以影響同步時間：
·?完全同步變得很慢，一個geth節點需要一周多的時間才能完全同步鏈，其他客戶端已經優化了更好的完全同步模式。
·?同步歷史數據比較慢。因為我們需要下載更多的數據，所以同步歷史數據部分就會比較慢。
·?快照同步狀態比較慢，因為我們需要下載的狀態更多了。
·?快照恢復較慢。由于pivot point（樞軸點）在快照同步期間移動，因此我們在磁盤上有許多需要修復的不完整狀態。如果pivot移動更頻繁，并且每個塊有更多的更改，那么該修復階段就會變慢。
·?由于節點需要通過更多的更改才能形成區塊頭，因此與鏈同步的速度會更慢。
（5）客戶端多樣性
構建一個新的EL客戶端本身就是一項艱巨的任務。增加gas limit還有一個額外的缺點，那就是會使構建客戶端并優化以供主網使用變得更加困難。Geth已經開發了10多年，進行了大量優化。可能存在相反的觀點，認為新客戶端可以借鑒現有客戶端，不再犯同樣的錯誤。
然而，我們已經看到了兩個客戶端（用python編寫的Execution Specs和使用javascript編寫的EthereumJ）的主網困境。這也意味著現在使用某些語言編寫的客戶端行不通了。受限于語言開銷和代碼庫的成熟度，增加gas limit將讓一些客戶端掉隊。
我們在KZG中也看到了這一點，為了獲得所需的性能，大多數客戶端依賴于調用C-KZG（一個用C語言編寫的代碼庫），而不是使用用他們所選的語言編寫的庫。
（6）最差情況
在考慮gas limit時，我們不能只看一般情況。我們總是要考慮最差的情況。當然，當鏈處于平均負載情況下，節點可能會運行得很好，但是如果突然連續5個塊的磁盤I/O增加一倍會發生什么？
運行時間并不是我們需要考慮的唯一指標，如果攻擊者可以占用其他資源，如磁盤I/O、CPU時間或內存，他們可能會迫使較低配置的機器脫機。特別是在以太坊合并后，在同一臺機器上運行兩個客戶端，攻擊其中一個客戶端可能也會讓另一個客戶端狀態不穩定。在以太坊合并測試的早期，我們目睹過幾次這樣的情況：一個客戶端的內存泄漏會導致整個系統崩潰。
另一個需要考慮的最壞情況是證明大小（proof size）。隨著gas limit的增加，兩個區塊之間可能發生的潛在狀態變化也會增加。這對前面討論的快照同步是有影響的，但它也會影響執行層輕客戶端的證明大小。現在這還不是什么大事，merkle-patricia tree（默克爾-帕特里夏樹）的證明太大了，無法通過網絡發送。但是，如果我們想要實現在同一臺機器上運行多個輕客戶端的交叉驗證思想，那么證明大小就會非常重要。
我們就這么完了嗎？我們會一直保持30MGas的上限嗎？不是的！
在我2021年的一篇文章中，我為當時我們面臨的困境提出了解決方案。對于我們在2021年面臨的完全同步問題，geth實現了快照同步和快照。對于修剪和數據庫布局的問題，geth實現了PBSS。Txpool在處理高交易負載方面變得更加可靠，并且大部分MEV搶跑交易都轉移給了建設者。許多交易也轉移到了L2，這反過來又增加了主網交易的平均規模。
唯一沒有實現的解決方案是regenesis。多年來，人們的觀點發生了一些變化，大多數人似乎都傾向于將EIP-4444歷史期限作為歷史數據增長的短期解決方案。對于EIP-4444的發布，我們需要一個強大的歷史數據服務節點網絡，這樣歷史就不會丟失，即使它不再被所有全節點存儲（順便說一句，大多數比特幣節點根本不存儲歷史數據）。
我們至今仍然沒有找到一個體面的、現實的狀態期限方式。
正如你在上海升級之前看到的攻擊，有一些已知攻擊阻止了我們提高gaslimit。（據我所知）所有漏洞都已解決了。
在撰寫本文時，EIP-4844正在測試網上發布。該EIP將提高節點的存儲和I/O需求。在我看來，在嘗試任何類型的gas limit增加之前，等等看這一變化對主網的影響是最安全的做法。一旦L2轉向Blob交易，我們就應該增加calldata成本（因為在我看來，與數據需要存儲的其他東西相比，calldata的價格被低估了）。這也可以作為L2使用blobspace的一個強制函數。
總之，我想提醒大家在考慮提高gas limit時要小心行事，因為它會影響節點的很多方面，有些影響會相對明顯。在相關討論中，考慮gas limit變化的長期和短期影響是非常重要的。
喜來順財經
<strike id="ykeqq"></strike>
<fieldset id="ykeqq"></fieldset>