--- id: 11 title: 為什麼單執行緒 EVM 會卡住 TPS：從歷史壅塞到執行模型 slug: evm-single-thread-bottleneck date: 2026/08/22 summary: 以太坊歷次壅塞背後，是 EVM 必須逐筆串列執行的設計選擇。本文說明 Gas 上限與 EIP-1559 為何無法改寫執行模型，以及確認延遲如何放大單執行緒天花板。 keywords: 單執行緒EVM,TPS上限,Gas壅塞,EIP-1559,確認延遲 heroImage: /images/community-bg.png --- 公鏈效能的討論裡，TPS 常被當成唯一標尺。但若追問「為什麼以太坊主網長期只能維持十幾筆每秒量級的吞吐量」，答案很少是「硬體不夠」，而是執行模型本身：以太坊虛擬機按照設計，一次只跑完一筆交易，再進入下一筆。這個約束保證了全網確定性重放，也把吞吐量釘在單執行緒的物理邊界上。 理解這條邊界，比記住某個瞬時 TPS 數字更重要。後面幾篇會分別談擴容地圖、平行路線與樂觀並行控制；本稿先把問題釘死——單執行緒 EVM 為什麼會卡住 TPS，歷史上的壅塞如何反覆證實這一點，以及為什麼提高 Gas 上限或引入 EIP-1559 都治不了執行模型本身。 ## 串列執行不是疏漏，是確定性的代價 EVM 的執行語意要求：同一區塊內的交易按規範順序依次執行。一筆交易的完整狀態寫回完成後，下一筆才能開始讀取狀態。這樣設計的直接好處是：任意誠實節點重放同一交易序列，都會得到同一狀態根。共識層只需就「交易順序與區塊內容」達成一致，不必再爭論「平行交錯後誰先寫誰」。 代價同樣直接。現代伺服器有幾十個邏輯核心，但經典 EVM 節點在執行的熱路徑上仍近似「一核幹活、其餘核心旁觀」。兩筆互不相關的轉帳——例如 A 付給 B、C 付給 D——在串列模型裡也不能同時推進，因為排程器預設假定任意交易都可能觸碰全域狀態樹的任意角落。Merkle Patricia Trie 把帳戶與儲存槽掛在同一棵巨大結構上，進一步強化了「沒有先驗的依賴資訊就不敢平行」的工程習慣。 於是出現一種結構性落差：網路頻寬與磁碟 I/O 可以縱向擴充，執行吞吐量卻被「一次一筆」卡住。當需求低於這個硬上限時，使用者感覺不到；一旦需求越過上限，多餘的交易只能進記憶池排隊，價格機制開始起作用——這就是壅塞的技術定義。 ## 歷史壅塞：同一病因的不同症狀 2017 年的 CryptoKitties 是第一次被廣泛記錄的大規模壅塞。這款養貓遊戲在高峰期佔據了可觀比例的鏈上交易，待處理佇列膨脹，普通轉帳的確認從秒級拉到小時級，Gas 價格被推到數百 gwei。事後檢討時，社群往往把責任歸到「遊戲太紅」，但更準確的說法是：熱門應用只是把本已存在的容量天花板暴露出來。 此後劇本反覆重演。2020–2021 年 DeFi 組合呼叫密集時，Gas 長期處於高位；2022 年 Otherside 等虛擬土地類 NFT 鑄造中，短時競價把費用推到極端水準，甚至出現小額轉帳被報出天文數字手續費的案例。觸發原因不同——遊戲、流動性挖礦、NFT 搶購——但排隊邏輯相同：執行引擎每秒能消化的「有效運算」有上限，超額需求只能用更高的出價擠掉低價交易。 這些事件還暴露了優先費 Gas 拍賣的放大效應。在早期的一價拍賣模型下，稀缺機會（鑄造名額、套利窗口）會誘發連環加價，費用水位被整網抬高，普通使用者被迫為別人的熱點買單。壅塞不僅是「慢」，也是「貴」，而「貴」往往比「慢」更早把邊緣使用者擠出鏈上活動。 ## Gas 上限：在同一條車道上加寬，而不是改車道數 以太坊社群持續透過提高區塊 Gas 上限來擠出更多容量。更大的 Gas 上限意味著每個區塊可以容納更多運算，短期看 TPS 會隨之上移。但這仍然發生在串列執行的框架之內：你是在加寬單一車道，而不是把公路改成多車道平行通行。 這條路徑有明確的邊際遞減與外部成本。Gas 上限越高，全節點在單位時間內需要執行、校驗與儲存的狀態變更越多，同步與硬體門檻也隨之上升。若把「擴容」等同於「無限抬高 Gas 上限」，最終會把去中心化驗證能力擠出普通人可及的範圍。因此，Gas 上限調整是有用的營運旋鈕，卻不是執行模型的替代品。它回答的是「在單執行緒約束下多塞一點工作」，而不是「如何讓多筆無衝突交易同時推進」。 公開監測網站上常見的以太坊主網 TPS 數字——日常十幾筆、短時峰值更高、理論峰值再高一些——也應放在同一語境理解。這些數字會隨時間與測量窗口變化，關鍵不在精確小數，而在數量級：單執行緒模型把上限釘在一個對「全球結算層」敘事偏緊的區間，而日常運行往往比理論峰值低數倍。 ## EIP-1559：改的是費用形成，不是執行寬度 2021 年上線的 EIP-1559 重構了費用市場。基礎費用隨區塊利用率動態調整並被銷毀，使用者另付優先費爭取更快被打包。研究動機包括：減少一價拍賣下的系統性超額支付、降低同一區塊內報價的劇烈抖動、削弱礦工/驗證者從基礎費用本身抽取價值的能力。 實務上，EIP-1559 確實改善了費用的可預測性，也讓「平時也按壅塞價出價」的現象有所緩解。但它從不承諾提高串列執行的物理吞吐量。當區塊持續被打滿，基礎費用會上調，把超額需求擠出市場——這是價格發現，不是產能擴張。把 EIP-1559 理解成「擴容方案」是常見的誤讀；更準確的定位是「在固定執行產能下更乾淨的排隊與計價規則」。 同理，優先費與後來的 MEV 相關機制，討論的是交易如何排序、以及如何捕獲排序價值，仍然預設執行階段按序串列完成。排序層再精巧，只要執行層一次只能消化一筆，容量硬頂就還在。 ## 確認延遲：另一條被 TPS 掩蓋的軸線 TPS 描述的是單位時間內完成多少筆；確認延遲描述的是使用者從廣播到「足夠可信地認為不可逆」要等多久。兩者相關但不等價。即使平均 TPS 看起來還可以，若記憶池堆積，單筆交易的等待時間仍可能拉長到使用者無法接受。 以太坊還疊加了共識確認語意：出塊間隔、最終性 gadget、重組風險等，都會納入「使用者體驗上的確認」。執行層壅塞時，交易可能長時間停留在 pending，應用層逾時、橋接窗口與做市商庫存風險一併放大。對支付與高頻互動而言，延遲尖峰往往比平均 TPS 更傷產品。 因此，單執行緒瓶頸的完整圖景是：吞吐量上限決定「系統能吃多少」；排隊與費用決定「誰吃得上」；確認延遲決定「吃上之後要等多久」。三者同源——執行寬度不夠——表現卻不同，評估任何「擴容」敘事時都應分開來看。 ## 結論：要動的是執行模型 把歷史壅塞、Gas 上限與 EIP-1559 放在一起，結論會變得非常清楚：費用市場與區塊參數可以管理稀缺，但不能消滅稀缺的根源。只要 EVM 保持「全域狀態 + 逐筆串列」的經典形態，TPS 就會有硬天花板，熱門應用會週期性地把整網拖進高費用、高延遲的狀態。 要突破這條天花板，產業轉向了另一類問題：如何在保留可驗證確定性的前提下，讓無衝突交易平行執行？答案並不唯一——確定性預先宣告、樂觀並行控制、物件模型等路線各有假設。對仍想相容以太坊位元組碼與工具鏈的專案而言，可選空間會被進一步收窄。這些問題屬於擴容地圖與平行路線的討論範圍；本稿只需確立前提：治本的對象是執行模型，而不是再轉一圈 Gas 旋鈕。 ## 延伸閱讀 - 下一篇：[《區塊鏈擴容地圖：L1 平行、L2、分片與 DA 各自解決什麼》](/zh-Hant/blog/blockchain-scaling-map) - 相關閱讀：[《平行執行的三條路線：確定性排程、樂觀 OCC 與物件模型》](/zh-Hant/blog/parallel-execution-approaches)、[《效能指標詞典：TPS、BPS、確認延遲、最終性、衝突率》](/zh-Hant/blog/performance-metrics-glossary)