Glamsterdam 升級延後，以太坊重新檢視合約風險

10月26日的Hoodi測試已被取消，包括其原定的2億gas上限。開發者正在審查一項針對主網上現有合約的重新定價提案。

以太坊已取消原定於下週一進行的測試。以太坊基金會10月22日的通知表示，Glamsterdam將不會於10月26日UTC 17:42:48在Hoodi上啟動，且未設定新的epoch。隨附的gas上限提升至2億的計劃也已從測試網日程中移除。這是對未來配置的推遲，而非對Hoodi已記錄區塊的逆轉。

開發者決定調查EIP-8037——一項改變創建新以太坊狀態價格的變更——如何與主網上的合約交互。基金會並未表示該升級已破壞主網。它也尚未為生產分叉設定日期。當前的營運風險在於Hoodi：仍帶有舊啟動時間的客戶端或自訂配置可能與修訂後的日程不一致。更深層的問題是，如何在不擾亂那些將舊數值嵌入代碼的應用的情況下，改變交易內部工作的成本。

Hoodi的10月26日分叉已從日程中移除

10月16日的Hoodi公告指定了epoch 132,352和slot 4,235,264。它將執行層的Amsterdam變更與共識層的Gloas變更以及2億gas上限配對。新通知完全取代了那些指示。營運者應閱讀兩類客戶端的最新發布說明；一個被描述為Glamsterdam相容的早期版本可能仍包含現已取消的Hoodi啟動。

這不僅僅是日程上的註腳。驗證者需要遵循與其對等節點相同的網路規則。如果其部分軟體在舊epoch時預期新的執行規則或共識職責，而網路並不如此，它可能失去跟隨規範鏈的能力。區塊構建者和驗證者基礎設施可能有自己的配置。因此，基金會告訴營運者在10月26日之前驗證修訂後的客戶端版本並移除過時的自訂設定，而不是因為分叉被推遲就假設什麼都不做是安全的。

Sepolia已於10月6日啟動Glamsterdam並測試了2億gas上限，正如對該次啟動的報導所記錄的那樣。一個測試網的成功啟動有用，但對另一個測試網並不具有決定性。Hoodi剩餘的演練被推遲，正是因為合約調查需要時間。沒有已公布的替代時間戳可供推斷為主網日期。

Glamsterdam於10月6日在Sepolia上啟動，開發者在那裡測試了2億gas上限。成功的測試並未解決EIP-8037將如何影響已在主網上運行的合約。Hoodi的演練被推遲，同時開發者調查這些交互，且未宣布替代日期。

今年該時程已不只一次變動。九月關於 Sepolia 計畫的報導描述了在公開測試進行前的 devnet 問題與 EIP-8037 實作問題。這些較早的問題並非證明與 10 月 22 日合約查詢具有相同成因。它們說明了為何隨著客戶端團隊從私下試驗轉向公開網路，這些日期一直是有條件的。關於測試網上 builder 行為的另一些疑慮涉及 Glamsterdam 的另一部分，不應與重新定價混為一談。最新通知為 Hoodi 暫停給出了一個具體原因：進一步調查 EIP-8037 與主網合約的互動。

為何在該提案中建立狀態的成本更高

一筆交易可以執行計算，也可以留下網路日後必須保留並存取的資料。建立新帳戶、開啟新的儲存槽或部署合約位元組碼，都會增加該持久狀態。EIP-8037 提議對這些操作收取更高費用，並將狀態建立部分單獨計量。其目標是讓價格更接近節點所承擔的較長期負擔，尤其是在允許區塊承載更多工作量的情況下。

該提案的示意表將新帳戶的狀態建立部分列為 183,600 gas，相較於目前的 25,000；新儲存槽為 97,920，相較於 20,000；24 KB 的部署為 37,784,880，相較於 4,947,200。該表並非對使用者將支付之 ETH 費用的普遍預測。它在某個擬議常數下單獨列出一個組成部分，其上還疊加其他執行費用，而最終的貨幣成本取決於當時的 gas 價格。此變動的幅度說明了為何具有嚴格限制的合約值得更仔細檢視。

一項相關的狀態存取提案，EIP-8038，對部分讀取與寫入重新定價。基金會的開發者影響指南指出，這些 gas 成本上次大幅調整是在 2021 年的 Berlin 分叉，而狀態已有所增長。計畫中的重新定價是與提升吞吐量的工作一同設計的；在未考量昂貴狀態操作的情況下擴大區塊，可能使節點營運者的驗證更為困難。因此，此次暫停同時涉及應用程式相容性與擴容計畫，儘管其宣布的觸發因素是 EIP-8037 的互動。

一個外部呼叫說明了為何這可能難以事先察覺。呼叫方可能刻意只傳遞足夠的 gas，讓接收方執行有限的操作，並假設任何進一步的工作都會安全失敗。若某個被重新定價的帳戶或儲存存取現在消耗了該額度，接收方可能在例行付款期間失敗，即使使用者為外層交易提供了充足的 gas。更改錢包的估算並不會改寫內部的額度。開發者需要檢查程式碼路徑及其周圍的失敗處理，因為有些應用程式會將失敗的外部呼叫視為回滾的理由，而其他應用程式則會繼續執行並記錄不同的結果。

Solidity 的 transfer 與 send 模式歷來會轉發 2,300 gas 的津貼。許多團隊已不再依賴該津貼，但已部署的合約可能仍會使用多年。基金會將固定津貼列為一類風險；它並未表示每個使用它們的呼叫都會失敗。執行少量工作的接收方可能仍在此額度之內，而觸及新近重新定價狀態的合約則可能超出。測試實際的交易對手，比僅憑函式名稱的存在就當作故障的證明更為重要。

第二類問題在於自動化。錢包、中繼者與託管方可能為例行任務儲存預設的 gas 上限。一項多年來成功運行的操作，即使應用程式合約本身健全，也可能開始出現 gas 不足。在前端提高估算值可以修復該路徑，但排程代理或使用較舊錢包的客戶可能繼續提交先前的上限。因此，開發者不僅必須找出受影響的程式碼，還必須找出為其建構交易的服務。

哪些合約可能遇到問題？

基金會在擬議的時程下重放了歷史主網交易。大多數沒有出現有意義的問題。在被標記的案例中，許多在提高其 gas 上限後完成了；較小的一組即使提供大幅更多的 gas 仍可能失敗。固定的津貼、發送到另一個合約的硬編碼 gas 數量，或基於 gasleft() 結果的分支，都可能改變交易走的路徑。先前的合約警告在 Hoodi 獲得其十月日期之前描述了這些類別。目前的延後使未解答的案例變得緊迫，但這並不表明所有以太坊合約都脆弱。

設想一個應用程式向另一個合約發送資金，同時提供固定的 gas 額度。在新時程下，接收合約可能需要更多 gas 來存取儲存。如果呼叫方的額度已嵌入已部署的程式碼中，僅提高頂層交易上限可能不會給接收呼叫更多空間。那麼失敗可能需要合約層級的修復或為使用者提供不同的路徑。相比之下，如果唯一的問題是錢包使用舊價格估算交易，更新估算並提供更高的上限可能就足夠了。這兩種情況在操作上是不同的。

一個特別不尋常的 EIP-8037 問題涉及透過減去兩次剩餘 gas 讀數來衡量工作量的程式碼。該提案解釋說，狀態 gas 儲備可能在某些情況下使 gasleft() 上升。預期非負減少的計算可能表現不同，而不可變的已部署合約無法就地修補。確切的影響取決於程式碼和交易路徑，這就是為什麼重放實際歷史交易比關於更高費用的通用警告更重要。

基金會的搜尋工具讓建構者檢查受影響的合約地址以及被標記分歧的原因。它建議在 devnet 上使用新時程進行測試，並檢查假設固定上限的程式碼，即使合約未出現在清單中。歷史重放是一種篩選，而非未來行為的完整清單：在樣本期間沒有使用者呼叫的路徑仍可能包含脆弱的假設。團隊需要針對他們營運的分支進行自己的測試。

重放的結果也取決於交易樣本。一個合約可能在其很少被呼叫的函數中包含固定的 gas 額度；如果該路徑不在重放的歷史中，該工具無法證明其失敗。基金會建議維護者檢查程式碼，即使其地址未出現在受影響的清單中。一個大型應用程式可能有多個合約、可升級的前端和自動化代理，每個提供不同的 gas 上限。團隊需要按照使用者實際呼叫的方式測試操作，包括可能將舊估算保存在快取中的錢包或機器人。

對於行為發生變化的合約，修復提交交易的介面並不總是足夠。如果內部呼叫的 gas 額度已編譯到不可變的程式碼中，其所有者可能需要遷移到新合約。此類遷移可能涉及轉移餘額、授權或使用者權限，並傳達新地址。難度取決於產品的設計；沒有證據表明每個被標記的合約都需要這項工作。這正是為什麼可透過上限修復的失敗與可能損壞的合約之間的區別對團隊及其客戶都很重要。

測試指南對使用帳戶抽象或多次合約呼叫來完成單一使用者操作的應用程式尤其相關。一個結帳流程可能在一序列中授權資產、路由交換並結算商家。如果內部步驟使用硬編碼的額度，客戶可能會看到付款失敗，卻不知道哪個合約觸及了上限。在擬議規則下重放整個序列比孤立地檢查每個合約的公開方法更有資訊量。維護者應記錄第一個失敗的步驟，以及更大的外部 gas 上限是否真的改變了結果。

合約在呼叫失敗後也可能有不同的行為，而非只是單純停止。一個記錄事件、記入內部餘額或嘗試第二條路徑的備援機制，可能在其原始作者從未預期的條件下繼續運作。這種分歧正是僅以「交易成功」描述的測試結果可能不足的原因。輸出狀態和事件需要與舊的執行結果進行比較。基金會的「成功執行但發生變更」類別捕捉了這種可能性，而不會自動宣告其有害。

錢包、RPC 和工廠面臨不同的工作

錢包和遠端程序呼叫供應商會在用戶簽署之前估算交易所需的 gas。EIP-8037 表示 eth_estimateGas 和節點軟體必須同時考量執行 gas 和新的狀態 gas 維度。一個舊的快取常數可能會低估一筆狀態密集的交易。用戶隨後可能會看到失敗的交易，即使合約在正確估算的限制下可以運作。因此，基礎設施更新是相容性的一部分，而不僅僅是疊加在協定之上的便利措施。

確定性部署工廠呈現了另一個狹窄的情況。EIP-8037 討論了最初使用預先簽署交易和硬編碼 gas 限制放置在標準地址的工廠。在一個在工廠存在之前就採用新排程的全新網路上，舊的預先簽署部署可能會耗盡 gas。該提案明確表示，現有主網和 layer 2 網路上已部署的實例不受該特定創世情境的影響。報告這個注意事項很重要：暗示以太坊上已經使用的每個工廠即將消失會造成誤導。

建構者還需要區分未變更的合約和未變更的成本。一筆交易可能成功，但消耗不同數量的 gas。一個批次部署或建立許多儲存槽的業務，即使沒有任何函式失敗，也可能面臨實質上不同的成本結構。其產品可能需要不同的費用報價、修訂的補貼政策或改變其儲存資訊的方式。基金會的重播類別正是為此將完全相同的執行、變更但成功的執行、可透過限制修復的失敗以及可能損壞的合約區分開來。

EIP-8037 中的數字值得另一項限定說明。其範例使用假設的 0.08 gwei 基礎費用將擬議的 gas 轉換為 ETH。如果基礎費用改變，為相同 gas 支付的 ETH 也會改變。開發者在將表格與現有帳單進行比較時，必須加上執行費用和實際交易條件，而不是將七倍的狀態成本變化呈現為用戶完整付款的七倍增加。該提案的目的是將成本分配給資源；一個人的最終費用取決於交易中這些資源的組合。

擬議重新定價的規模應與容量目標一併解讀。區塊中更多的交易空間可能使網路驗證成本高昂，如果這些交易不成比例地建立持久狀態。EIP-8037 為該增長分配了一個獨立的計量器，使成本不會消失在更大的標題 gas 限制中。EIP-8038 處理對現有狀態的存取。它們解決資源問題的不同部分，而僅有可運作的區塊建構器無法確立應用程式正確處理重新定價。

以太坊的區塊存取清單有另一項任務。它們告訴客戶端一個區塊觸及哪些帳戶和儲存位置，幫助將一些驗證工作平行組織。這可能在有利條件下允許更大的吞吐量，但它不會消除新帳戶和儲存槽所新增的持久儲存。測試網需要在真實活動下運行組合升級，因為一個維度的改善可能暴露另一個維度的限制。此次延期使得該組合 Hoodi 演練目前尚未完成。

許多用戶將間接地透過其錢包報價的 gas 限制或應用程式的費用估算首次遇到這些變化。一筆不建立新狀態的交易可能與一筆部署大型合約的交易產生不同的效果。一個承諾固定交易成本的交易介面需要檢查其承諾是否仍涵蓋其執行的操作。在沒有最終主網排程、觀察到的需求和最終參數的情況下，關於所有以太坊費用朝一個方向變動的概括結論將為時過早。

2 億這個數字是測試網設定

Glamsterdam 結合的不只是重新定價。內建的提議者-建構者分離改變了區塊載荷的交接，而區塊層級存取清單幫助客戶端識別一個區塊將觸及的帳戶和儲存。開發者計劃以 2 億的 Hoodi gas 限制測試這些變更，與 Sepolia 一致。該數字是一個測試網參數。它從未承諾以太坊主網會立即採用相同的限制，或用戶費用會下降某個百分比。

移除 Hoodi 的 gas 上限時間表，可讓被推遲的分叉各組成部分保持一致。營運商下週一將不會在該網路上測試 Glamsterdam 下預期更高的容量。開發者仍可使用 Sepolia 和專門構建的開發網來研究重新定價的影響。Hoodi 排練的缺失會影響客戶端團隊在選擇主網時間之前建立信心的順序，但基金會尚未公布修訂後的生產時間表。

其經濟邏輯並不像「更便宜的 gas」這句口號那麼簡單直接。對創建持久狀態收取更高費用，可能使某筆特定交易在相同 gas 價格下變得更貴。更大的安全容量，若日後被採用並使用，在其他情況下可能緩解擁堵。需求決定用戶為區塊空間出價多少，而最終的協議設定決定哪些操作變得更貴或更便宜。無論是暫停還是成功的測試，本身都無法解決這些市場變數。

公開協調是有成本的，但帶著已知的不確定性繼續推進，成本可能更大。營運商已為舊 epoch 準備好軟體，現在必須移除該時間表；應用程式開發者則必須繼續針對一個最終形態可能改變的提案進行測試。這次重置的成本是可見的。一條導致廣泛使用的合約失敗的主網規則將更難逆轉，其後果可能涉及資金或依賴的應用程式。10 月 22 日的通知並未量化此類風險，但明確表示開發者認為這種交互作用足夠重要，因而叫停了 Hoodi 排練。

修訂後的提案可以保留對狀態收費的目標，同時改變 gas 儲備的運作方式或現有合約的過渡規則。它也可以保留規範，並要求有針對性的應用程式修復。推遲通知中並未出現對這兩條路線的公開決定。讀者應避免將一項調查視為最終的設計選擇。確切的修正（如果有的話）將比 Hoodi 等待多少天更為重要。

開發者為何選擇等待

以太坊的流程允許客戶端團隊在公開測試網啟用之前調整計畫。10 月 22 日在 All Core Devs Execution call 248 上做出的決定，是在先前的警告以及對受影響構建者的外聯之後作出的。公開通知指出了正在調查的領域，但並未公布面臨風險的合約最終數量、EIP-8037 的新版本，或調查結束的日期。將此次延遲稱為所有已部署合約中已確認的缺陷，會超出該發布的內容；將其稱為例行的日程調整，則會忽略其所述原因。

舊配置必須在兩層上都被撤回。執行客戶端處理交易和狀態，而共識客戶端協調驗證者和分叉時間表。只有當這些客戶端在規則和時間上達成一致，網路才能測試升級。為 10 月 26 日專門安裝版本的 Hoodi 營運商必須查找修訂後的發布說明。基金會表示，將在確認新客戶端版本後添加連結，而不是將其最初的相容性表格視為最新。

證據的順序也提供了教訓。重放歷史揭示了受影響的小群體；公開測試網在真實環境中揭示客戶端和應用程式的行為；主網則將最終規則暴露於大規模的經濟使用中。每個階段都回答了前一階段無法回答的問題。Hoodi 的短暫延遲可能為合約工作爭取時間，但它本身並不能證明最終規則安全。繼續推進的決定應遵循測試結果和明確的營運商指示。

營運商通知的範圍值得詳細說明。普通的主網持有者無需因為 Hoodi 的時間表被撤回而更改錢包。為分叉做準備的 Hoodi 節點營運商則需要重新查看發布說明。調查該 EIP 的協議工程師需要確定在重放中發現的合約行為是可接受的、可透過工具修復的，還是修改提案的理由。應用程式團隊需要測試其自身的執行路徑。這些是不同的受眾，有不同的截止日期，而單一的「升級延遲」警報並不能為他們每個人提供正確的指示。

基金會的下一篇貼文也可以解決開發者將如何與受影響團隊溝通的問題。其 8 月的指南稱已開始直接外聯，但僅憑外聯數量並不能確定合約已被修復。可測試的證據是針對特定產品更新後的合約、修訂後的 gas 配置或記錄在案的備用方案。一些不可變的合約可能需要用戶遷移，這引發了單獨的溝通和安全問題：客戶必須知道合法的替代品位於何處，並避免欺詐性地址。尚未宣布任何大規模遷移，因此對於無法就地更改程式碼的團隊來說，這仍是一個應急方案。

在另一個日期之前會發生什麼

修訂後的時程應說明將測試哪些 EIP-8037 規則、若提案被修訂則有哪些變更，以及哪些客戶端版本對新的 Hoodi 紀元達成一致。應用程式維護者需要時間執行受影響合約的搜尋、更新估算器、在足夠的情況下提高上限，並在不足的情況下檢查硬編碼的內部呼叫額度。如果一個可能已損壞的已部署合約沒有直接升級路徑，其團隊可能需要在任何主網分叉之前說明使用者將如何取得替代方案。

公開證據將包括重播方法論與更新的受影響合約調查結果、使用最終 gas 排程的開發網結果、由多樣化客戶端達成一致的 Hoodi 啟用，以及一份獨立的主網公告。即使是一次順利的 Hoodi 啟用，也只是一次演練，而非對特定 ETH 價格或最終交易手續費的保證。對使用者而言，實際的情況是尚未宣布任何 10 月 26 日的主網行動。當前的行動屬於 Hoodi 營運者，以及那些其應用程式對 gas 做出假設的團隊。

值得關注的重點

• 客戶端發布：明確移除舊有 10 月 26 日 Hoodi 啟用計畫的執行層與共識層更新。
• EIP-8037 調查結果：新的重播結果、擬議 gas 規則的變更，以及對帶有硬編碼上限或 gasleft() 邏輯的合約之處理方式。
• 替代時段：在調查結束後，恢復可測試配置的附日期 Hoodi 計畫。
• 應用程式修正：受影響建置者的報告，說明較高的上限是否足夠，或已部署的程式碼是否需要另一條路徑。
• 主網通知：在測試網序列與客戶端協調之後，由基金會發布的獨立生產排程。

常見問題