以太坊暫緩 Hoodi 測試網分叉：稽核發現 Gas 計費改動可能改變合約行為

為何突然踩煞車？

Glamsterdam 升級透過多項提案調整以太坊對「狀態」操作的計費方式。其中 EIP-8037 改變協議如何核算「建立狀態」（例如合約儲存槽位等會跨交易持續存在的資料）的成本；EIP-8038 則重新定價「讀取／存取現有狀態」的相關操作。兩者作用在交易執行路徑的不同環節——合約可能先讀值、再對外呼叫、最後寫入結果——若只檢視最後一步的 Gas，容易忽略前段讀取與呼叫如何壓縮後續可用的執行預算。

ChainSecurity、Dedaub 與基金會內部審查方共同參與檢視。稽核指出：即便升級前就已部署、程式碼一字未改的合約，在新規則下仍可能在相同使用者輸入下產生不同結果。這也是 Hoodi 分叉無法按原時程推進的核心原因。

失敗呼叫為何成為焦點？

多數使用者只在交易失敗時才會深究 Gas，但對 DApp 而言，「子合約回傳失敗後要怎麼做」正是業務邏輯所在。一個合約呼叫另一個合約執行流程中的某一步；若被呼叫方失敗，呼叫方可以選擇整筆回滾，也可以在失敗處理程式中記錄結果並繼續——例如批次處理器可能標記某一筆失敗並處理下一筆。

ChainSecurity 的分析說明：在新 Gas 核算下，同一條失敗路徑可能與舊規則不同——在舊規則下可能導致外層交易回滾的情況，新規則下呼叫失敗後，若仍有足夠 Gas 完成失敗處理器，外層交易反而可能繼續並留下不同鏈上紀錄。兩種情境內層呼叫都失敗，但最終狀態卻可能不一致。

此外，以太坊在 EIP-150 下本就限制呼叫時可轉發的 Gas 比例（相關情境下約六十四分之一可留在呼叫者端）。問題在於執行返回後，呼叫者實際剩餘 Gas 與完成後續指令所需成本在新定價下如何重新計算。

gasleft() 與八項待驗證假設

部分合約使用 `gasleft()` 與硬編碼門檻比較，判斷是否還能安全繼續。在舊 Gas 表下校準的數字，遇到狀態讀寫或轉發 Gas 時，升級後可能不再可靠——而部署後的合約無法自動更新當初寫死的常數。

基金會 11 月更新描述，目前有 八項假設 仍在審查，測試至少涵蓋兩大問題：其一，實作新規則的各客戶端對同一筆交易是否得出一致狀態與 Gas 結果；其二，該一致結果是否與既有合約預期相符。後者必須沿應用邏輯追蹤——例如失敗回呼是否被視為可繼續的業務結果、呼叫前是否已寫入狀態、以及如何區分「業務拒絕」與「Gas 不足導致呼叫未真正執行」。這些路徑在一般部署測試中容易遺漏，因為典型交易預算往往足以同時涵蓋呼叫與失敗處理。

與主網時程的關係

Hegota 等相關工作據報仍在並行推進。社群若要觀察 Glamsterdam 何時再往前邁進，可留意 修訂後的測試網排程 以及後續測試所產生的客戶端一致性與應用層回歸結果。對開發者而言，現在是重新檢視合約中對失敗路徑、狀態寫入順序與 Gas 門檻假設的時機；對投資人與使用者而言，則代表主網升級節奏可能因安全審查而調整，但目的在於避免「同碼不同果」的隱性風險進入正式環境。

結論

以太坊將 Hoodi 分叉暫緩，並非升級喊停，而是對 EIP-8037／EIP-8038 所帶來的狀態 Gas 重定價進行更嚴謹的交叉驗證。稽核所揭示的合約行為差異，提醒整個生態系：協議升級的影響會穿透到應用層。在修訂時程與測試結果公布前，開發團隊與審計方仍需共同釐清，哪些舊假設可以保留、哪些必須改寫。

原文連結：https://crypto.news/ethereum-put-glamsterdams-hoodi-fork-on-hold-what-did-auditors-find/