核心開發者：調整區塊空間大小需要考量多面向因素，Gas Limit 絕不是能隨意調整的參數
以太坊核心開發者 Marius Van Der Wijden 針對 Vitalik 增加區塊容量的建議彙整更多面向的考量點，認為以太坊再提高區塊容量會帶來許多其他風險，需要謹慎思考，建議至少等待 EIP-4844 升級完畢。
Vitalik 提議提升區塊容量
以太坊創辦人 Vitalik Buterin 於以太坊基金會在 Reddit AMA 活動時，提出提高目前以太坊現有的 Gas Limit，從 300 萬 Gas Limit 調整至 400 萬，上升幅度約 33%，預計將可以有效提升以太坊的網路吞吐量。
Vitalik 同時表示以太坊已經三年沒有調整過此參數，適當的調整是合理的。
廣告 - 內文未完請往下捲動
(Reddit AMA｜Vitalik Buterin呼籲提高Gas上限以提高吞吐量)
背景知識
Gas Limit
燃料費限制 (Gas Limit) 決定了一個區塊可以完成多少交易，提高燃料費限制將使 Ethereum 能夠處理更高的交易吞吐量或更複雜的交易，也就是增加了區塊空間。
從歷史上看 Gas Limit 多年來一直在增加。藉由燃料費歷史使用量可以得知 Gas Limit 變化，實際結果兩者非常接近，因為幾乎每塊都被市場充分利用了。
節點儲存資料
運行區塊鏈的節點，需要保存區塊鏈上的資料大家都知道，但其實資料還可以分為兩類：
- 狀態數據 (state)：當下的數據，目前網路的帳戶、合約、代幣參數。例如目前 Alice 擁有多少代幣、以太坊目前擁有多少帳戶數。
- 歷史數據 (history)：過去的數據，狀態數據以外的完整資料，可以想像成過去狀態數據的總和 (但不是直接加總堆疊)。例如 Alice 於某個時刻曾轉帳給 Bob 的交易紀錄。
狀態數據確保網路共識相同，虛擬機運作時需要隨時讀取，決定網路運作效率；而歷史數據則是確保網路安全性的關鍵。
提高 Gas Limit 有許多風險
狀態數據大小膨脹
在區塊高度 18418786 (2023/10/24)，帳戶帳本快照的大小為 10.33GB，儲存快照為 76.59GB，因此整體狀態大小約為 87 GB。而在區塊高度 17419840 (2023/6/6)，以太坊狀態略小於 80 GB。
代表這四個月來狀態成長約 7 GB，每月幾乎有 2 GB。按照這個速度，一年內網路狀態大小將達到 111 GB，五年後達到 207 GB。
問題不在於網路狀態的大小本身，而是存取速度。
幾乎任何裝置都可以儲存 200 GB 的數據，但是每當虛擬機修改狀態時要重新掌握的資料量更多，存取和修改狀態的速度會變得越來越慢。
這還只是狀態快照版本 (plain state) 的大小，以太坊客戶端 Geth 還需要以不同的形式儲存狀態 (例如 trie 樹)，以便驗證狀態根 (state root)。這些數據在區塊高度 18418786 處大約需要 180 GB。
因此目前僅狀態所需的總空間大小約為 267 GB。如果增加 Gas Limit，這個大小會成長得更快，不利節點運作。
狀態膨脹的問題在於目前沒有可以減少的方式。不像是歷史紀錄，有機會以過期或是修剪 (pruned) 的方式降低所需空間大小，狀態大小沒有辦法輕易減少，就像是沒辦法隨意丟棄某個帳戶資料。
狀態爆炸 (State Explosion)：狀態資料大小不斷增加，將會影響區塊鏈的運作效能與可擴展性，且目前沒有好的解決方式。
歷史數據同樣增加
除了狀態數據，別忘了還有歷史數據。
2021 年 2 月儲存完整歷史數據的 Geth 節點，所需大小約為 350GB (經修剪)，大約三年後已超過 900GB。以太坊累積歷史交易數三年內增加一倍多，從約 9.8 億筆增加到 22 億筆交易。
且隨著 Layer2 的興起，歷史記錄大小成長速度已成為更大的問題，因為 Rollups 儲存資料的方式是 calldata。其在區塊高度 18418786 的大小超過 427 GB，同樣四個月前，區塊高度 17419840 的大小為 339 GB，成長了 28GB，每月平均成長 9GB。
不過歷史數據不同於狀態數據，現有已經有許多方法嘗試降低歷史數據成長的問題。
希望在 EIP-4844 中這種增長速度能確實放緩，因為 Layer2 將停止使用 calldata 來實現資料可用性，並轉移到資料幾週後就會過期的 Blob。
而針對其他歷史數據，EIP-4444 提出的資料過期設計將解決這些問題，全節點不再需要儲存所有歷史記錄。不過實作 EIP-4444 需要一個強大的網路來檢索歷史記錄，確保資料可用性足夠。
節點同步時間增加
Gas Limit 提升將會有多重因素影響節點同步所需時間：
- 完全同步變得更慢：目前 Geth 節點需要一周以上的時間才能完全同步區塊鏈，不過確實其他客戶端已經更好地優化了此問題。
- 同步歷史數據速度降低：節點初次同步歷史數據時，需要下載的資料量變多。
- 同步狀態數據速度降低：每次節點快照狀態時需要下載的資料量變多。
- 快照修復 (snap healing) 速度降低：由於狀態在快照時網路仍然在運作，因此同步狀態時會有些不完整的狀態需要修復，此修復過程會變更慢。
- 追趕速度降低：因為節點需要進行更多更改才能到達最新狀態。
客戶端多元化程度降低
建立新的執行層客戶端 (execution layer clients, EL clients) 本來就已經是一項艱鉅的任務，若增加 Gas Limit 會使得建立新客戶端或是更新變得更加困難。
不過也有反駁論點是新客戶端可以向現有客戶端學習，而把事情做得更好。
然而，已經看到兩個客戶端包含 Execution Specs (基於 python 建構) 與 EthereumJS (基於 javascript 建構) 遇到技術上的困難，若此時提高 Gas Limit 將使這些客戶端更難以跟上，最終消失，使生態無法再使用某些語言的客戶端，最終導致客戶端逐漸中心化。
近期在引入 KZG 的過程中也看到了這點問題，為了獲得所需的效能，大多數客戶端依賴於呼叫 C-KZG (一個用 C 編寫的函式庫)，而不是使用原本其選擇的語言編寫的函式庫。
其他需要思考的情況
在考慮改變 Gas Limit 時，不能僅考慮平時的情況，同樣需要思考最壞的可能。
當網路沒有過載，節點或許可以運作良好，但如果突然連續 5 個區塊交易量翻倍，會發生什麼情況？接下來 5 秒內網路表現會如何？
運行時間不是唯一需要考量的指標，如果攻擊者可以佔用其他資源，例如磁碟 I/O、CPU 或內存，可能都會迫使硬體配置較低的節點離線。特別是在合併後，兩個客戶端在同一台電腦上運行時，攻擊一個客戶端可能會導致另一個客戶端不穩定。
另一個需要考慮的情況是證明大小。隨著 Gas Limit 增加，兩個區塊之間狀態變化應該會差更多，除了如同前面所討論的這會對快照同步有影響，也會影響輕客戶端的驗證。現在這不是什麼大問題，因為 merkle-patricia 的證明已經太大，無法透過網路發送。然而如果想實現在同一台機器上運行多個輕客戶端的交叉驗證，證明大小就變得重要。
是否有解決方案？
期待技術更進一步發展
看完上述風險，難道只能始終保持當前 Gas Limit 嗎？其實也不盡然，隨著技術的進步或許可以解決上述問題。
過去在 2021 年，當時以太坊面臨許多問題，因為技術的開發而逐漸獲得解決。全同步速度的問題藉由 Geth 實作了快照同步，而針對修剪和資料庫佈局的問題，Geth 實作了 PBSS，Txpool 在處理高交易量方面變得更加強大， MEV 問題暫時藉由外部設計將交易轉移到 builder，而現在許多交易也轉移到了 L2，成功增加網路整體效能。
唯一尚未實施的解決方案是再生 (regenesis)。目前看起來大多數人都贊成 EIP-4444，將交易資訊加上保存期限的設定，作為歷史數據成長的短期解決方案。
不過目前開發團隊仍然沒有找到一種體面且務實的狀態數據修剪方式，鼓勵每個有興趣的人加入以太坊這方面相關研究的行列。
現階段不要提升 Gas Limit 較適當
目前 EIP-4844 正在測試網路啟動，將增加節點的儲存和輸入輸出設定，因此，等待主網上的這項變更完成之後，再來思考任何類型的 Gas Limit 增加是最安全的選項。
且一旦完成更新後，calldata 的價格被低估應該先增加其使用的成本，視情況而後動，同時也可以促使 Layer2 使用 blobspace。
Gas Limit 需要非常謹慎視之
總而言之，在考慮增加 Gas Limit 時要小心謹慎，因為它會影響節點的許多不同面向，其中一些面向很重要，也需要同時考量長短期的影響，Gas Limit 絕非可以隨意調整的參數。
