作者：John Otander，以太坊核心開發(fā)人員；翻譯：xiaozou

這篇文章的靈感來自于以太坊常使人Vitalik在最近的Reddit AMA 中的回答。

Vitalik指出，適度提高GasLimit是合理的，Gas Limit已經(jīng)近三年沒有增加，這是該協(xié)議歷史上最長的時(shí)間，。Vitalik還做了一些簡單的計(jì)算表示將以太坊GasLimit提高到4000萬。

本文講述了為何說提高以太坊Gas Limit比較困難？提高以太坊Gas Limit帶來的風(fēng)險(xiǎn)，以及相關(guān)解決方案。

1、Gas Limit（Gas限制）

Gas limit決定了一個(gè)區(qū)塊內(nèi)的工作完成量，因此決定了每個(gè)區(qū)塊可以執(zhí)行多少交易。提高gas limit將使以太坊能夠處理更高的交易吞吐量或更復(fù)雜的交易。一直以來，具體的gas limit設(shè)置受礦工/質(zhì)押者影響，并且多年來限額一直在增加。下圖來自etherscan.io，顯示了gas歷史用量（非常接近gas limit，所有限額增加都被市場消化掉了）。

2、風(fēng)險(xiǎn)

現(xiàn)在提高gas limit涉及到幾個(gè)風(fēng)險(xiǎn)。

（1）漏塊率

我在之前的文章中提到，叔塊率（uncle rate）是評估gas limit增加時(shí)討論最多的一個(gè)指標(biāo)?，F(xiàn)在，在以太坊合并之后，再也沒有叔塊了。我們要想知道節(jié)點(diǎn)是否能很好地處理了當(dāng)前的gas limit，唯一的方法就是看漏塊率。但這個(gè)指標(biāo)是有瑕疵的，因?yàn)樗伙@示當(dāng)前供應(yīng)不足的節(jié)點(diǎn)。它并沒有提供給我們一個(gè)很好的指標(biāo)來顯示gas limit的增加，而且它只顯示了平均情況，而不是在攻擊中可能發(fā)生的最壞情況。

（2）狀態(tài)大小

區(qū)塊18418786（2023年10月24日）的賬戶快照為10.33GB，存儲(chǔ)快照為76.59GB，因此整體狀態(tài)大致為87GB。區(qū)塊17419840（2023年6月6日）的狀態(tài)略小于80GB。這意味著狀態(tài)在4個(gè)月內(nèi)大約增長了7GB，也就是說每月增長約2GB。

如果我們使用87+(2*12*#年)來推斷，一年后的狀態(tài)將是111GB，五年后將是207 GB。這里的問題不在于大小。每個(gè)人都可以存儲(chǔ)這么多的數(shù)據(jù)，但是訪問和修改這些數(shù)據(jù)卻會(huì)變得越來越慢。

這還只是快照，是一般狀態(tài)。Geth還需要以不同的形式存儲(chǔ)此狀態(tài)，以便驗(yàn)證狀態(tài)根。區(qū)塊18418786的另一種狀態(tài)存儲(chǔ)形式（trie節(jié)點(diǎn)）大約需要180GB。

因此，目前僅用于狀態(tài)存儲(chǔ)的總空間大小約為267GB。如果我們提高gas limit，狀態(tài)大小會(huì)增長得更快。

狀態(tài)增長的問題在于，與過去不同，我們沒有明確的途徑來移除狀態(tài)。沒有我們可以迅速實(shí)施的具體的狀態(tài)期限建議來讓我們擺脫不斷增長的狀態(tài)。

（3）歷史規(guī)模

在我2021年的一篇文章中曾提到，一個(gè)完整的geth節(jié)點(diǎn)大約為350GB（新修剪的）。大約三年過后，一個(gè)完整的geth節(jié)點(diǎn)（在pbss上）超過900GB。下圖顯示了交易的總累積量。從中很容易看出，交易量在三年內(nèi)增加了一倍多，從大約9.8億筆增加到超22億筆。

隨著L2的崛起，歷史規(guī)模已經(jīng)成為一個(gè)更大的問題，因?yàn)樗鼈儸F(xiàn)在（在4844上線之前）存儲(chǔ)數(shù)據(jù)的方式是calldata。區(qū)塊18418786的塊體超過427GB，區(qū)塊17419840（同樣是4個(gè)月前）的塊體為339GB，這意味著4個(gè)月內(nèi)增長28GB，也就是說大約每月增長9GB。我們可以用427+(9*12*#年)來推斷這種增長，即一年后為535GB，五年后為967GB（再次假設(shè)為線性增長）。

希望在EIP-4844上線后，這種增長會(huì)放緩，屆時(shí)L2將停止使用CALLDATA來獲取數(shù)據(jù)可用性，并轉(zhuǎn)為使用幾周后到期的blob。

EIP-4444將解決歷史增長問題，因?yàn)槿?jié)點(diǎn)不再需要存儲(chǔ)所有歷史。實(shí)現(xiàn)EIP-4444需要一個(gè)可靠的網(wǎng)絡(luò)來檢索歷史，然后我們才能使全節(jié)點(diǎn)停止歷史數(shù)據(jù)服務(wù)。

（4）同步時(shí)間

Gas limit在很多方面都可以影響同步時(shí)間：

·完全同步變得很慢，一個(gè)geth節(jié)點(diǎn)需要一周多的時(shí)間才能完全同步鏈，其他客戶端已經(jīng)優(yōu)化了更好的完全同步模式。

·同步歷史數(shù)據(jù)比較慢。因?yàn)槲覀冃枰螺d更多的數(shù)據(jù)，所以同步歷史數(shù)據(jù)部分就會(huì)比較慢。

·快照同步狀態(tài)比較慢，因?yàn)槲覀冃枰螺d的狀態(tài)更多了。

·快照恢復(fù)較慢。由于pivot point（樞軸點(diǎn)）在快照同步期間移動(dòng)，因此我們在磁盤上有許多需要修復(fù)的不完整狀態(tài)。如果pivot移動(dòng)更頻繁，并且每個(gè)塊有更多的更改，那么該修復(fù)階段就會(huì)變慢。

·由于節(jié)點(diǎn)需要通過更多的更改才能形成區(qū)塊頭，因此與鏈同步的速度會(huì)更慢。

（5）客戶端多樣性

構(gòu)建一個(gè)新的EL客戶端本身就是一項(xiàng)艱巨的任務(wù)。增加gas limit還有一個(gè)額外的缺點(diǎn)，那就是會(huì)使構(gòu)建客戶端并優(yōu)化以供主網(wǎng)使用變得更加困難。Geth已經(jīng)開發(fā)了10多年，進(jìn)行了大量優(yōu)化。可能存在相反的觀點(diǎn)，認(rèn)為新客戶端可以借鑒現(xiàn)有客戶端，不再犯同樣的錯(cuò)誤。

然而，我們已經(jīng)看到了兩個(gè)客戶端（用python編寫的Execution Specs和使用javascript編寫的EthereumJ）的主網(wǎng)困境。這也意味著現(xiàn)在使用某些語言編寫的客戶端行不通了。受限于語言開銷和代碼庫的成熟度，增加gas limit將讓一些客戶端掉隊(duì)。

我們在KZG中也看到了這一點(diǎn)，為了獲得所需的性能，大多數(shù)客戶端依賴于調(diào)用C-KZG（一個(gè)用C語言編寫的代碼庫），而不是使用用他們所選的語言編寫的庫。

（6）最差情況

在考慮gas limit時(shí)，我們不能只看一般情況。我們總是要考慮最差的情況。當(dāng)然，當(dāng)鏈處于平均負(fù)載情況下，節(jié)點(diǎn)可能會(huì)運(yùn)行得很好，但是如果突然連續(xù)5個(gè)塊的磁盤I/O增加一倍會(huì)發(fā)生什么？

運(yùn)行時(shí)間并不是我們需要考慮的唯一指標(biāo)，如果攻擊者可以占用其他資源，如磁盤I/O、CPU時(shí)間或內(nèi)存，他們可能會(huì)迫使較低配置的機(jī)器脫機(jī)。特別是在以太坊合并后，在同一臺(tái)機(jī)器上運(yùn)行兩個(gè)客戶端，攻擊其中一個(gè)客戶端可能也會(huì)讓另一個(gè)客戶端狀態(tài)不穩(wěn)定。在以太坊合并測試的早期，我們目睹過幾次這樣的情況：一個(gè)客戶端的內(nèi)存泄漏會(huì)導(dǎo)致整個(gè)系統(tǒng)崩潰。

另一個(gè)需要考慮的最壞情況是證明大?。╬roof size）。隨著gas limit的增加，兩個(gè)區(qū)塊之間可能發(fā)生的潛在狀態(tài)變化也會(huì)增加。這對前面討論的快照同步是有影響的，但它也會(huì)影響執(zhí)行層輕客戶端的證明大小?，F(xiàn)在這還不是什么大事，merkle-patricia tree（默克爾-帕特里夏樹）的證明太大了，無法通過網(wǎng)絡(luò)發(fā)送。但是，如果我們想要實(shí)現(xiàn)在同一臺(tái)機(jī)器上運(yùn)行多個(gè)輕客戶端的交叉驗(yàn)證思想，那么證明大小就會(huì)非常重要。

3、解決方案

我們就這么完了嗎？我們會(huì)一直保持30MGas的上限嗎？不是的！

在我2021年的一篇文章中，我為當(dāng)時(shí)我們面臨的困境提出了解決方案。對于我們在2021年面臨的完全同步問題，geth實(shí)現(xiàn)了快照同步和快照。對于修剪和數(shù)據(jù)庫布局的問題，geth實(shí)現(xiàn)了PBSS。Txpool在處理高交易負(fù)載方面變得更加可靠，并且大部分MEV搶跑交易都轉(zhuǎn)移給了建設(shè)者。許多交易也轉(zhuǎn)移到了L2，這反過來又增加了主網(wǎng)交易的平均規(guī)模。

唯一沒有實(shí)現(xiàn)的解決方案是regenesis。多年來，人們的觀點(diǎn)發(fā)生了一些變化，大多數(shù)人似乎都傾向于將EIP-4444歷史期限作為歷史數(shù)據(jù)增長的短期解決方案。對于EIP-4444的發(fā)布，我們需要一個(gè)強(qiáng)大的歷史數(shù)據(jù)服務(wù)節(jié)點(diǎn)網(wǎng)絡(luò)，這樣歷史就不會(huì)丟失，即使它不再被所有全節(jié)點(diǎn)存儲(chǔ)（順便說一句，大多數(shù)比特幣節(jié)點(diǎn)根本不存儲(chǔ)歷史數(shù)據(jù)）。

我們至今仍然沒有找到一個(gè)體面的、現(xiàn)實(shí)的狀態(tài)期限方式。

正如你在上海升級之前看到的攻擊，有一些已知攻擊阻止了我們提高gaslimit。（據(jù)我所知）所有漏洞都已解決了。

在撰寫本文時(shí)，EIP-4844正在測試網(wǎng)上發(fā)布。該EIP將提高節(jié)點(diǎn)的存儲(chǔ)和I/O需求。在我看來，在嘗試任何類型的gas limit增加之前，等等看這一變化對主網(wǎng)的影響是最安全的做法。一旦L2轉(zhuǎn)向Blob交易，我們就應(yīng)該增加calldata成本（因?yàn)樵谖铱磥?，與數(shù)據(jù)需要存儲(chǔ)的其他東西相比，calldata的價(jià)格被低估了）。這也可以作為L2使用blobspace的一個(gè)強(qiáng)制函數(shù)。

總之，我想提醒大家在考慮提高gas limit時(shí)要小心行事，因?yàn)樗鼤?huì)影響節(jié)點(diǎn)的很多方面，有些影響會(huì)相對明顯。在相關(guān)討論中，考慮gas limit變化的長期和短期影響是非常重要的。