以太坊下一次大升級 Glamsterdam 的 Gas 重定價，會讓一批寫死在舊價格假設裡的合約直接失效，而這些合約多數上線後就改不了。兩名開發者週日各自遞出互相競爭的修補草案：一派讓舊合約續用舊費率、只有新合約走新制；另一派照收新價，但用兩套計價帳本讓舊合約感覺不到變化。兩案都還是草案，也沒有時間表。
（前情提要：Glamsterdam 升級在即！以太坊基金會警告：部分錢包與工具恐因 Gas 新制失效）
（背景補充：Vitalik宣布以太坊擴充套件藍圖：Glamsterdam改變Gas機制，ZK-EVM 讓節點無需重執行驗證）
以太坊下一次大升級 Glamsterdam，可能會弄壞一批已經替使用者管錢的應用。兩名開發者週日（11 月 8 日）各自遞出互相競爭的修補草案，想在 Gas 重定價正式上線前，把這批「不能改的合約」救下來。
問題的源頭是 Glamsterdam 裡兩個調整價格的提案。EIP-8037 把建立合約的基礎費用從 32,000 gas 拉高到 183,600 gas，這還不含程式碼存放與後續執行的成本；EIP-8038 則調漲讀寫鏈上儲存資料的價碼。Gas 是以太坊替每一步運算計價的單位，價格一動，所有依賴它的應用就跟著動。
多數 DeFi 應用當初都是在「這些成本永遠不會變」的假設下寫出來的。有些應用每次呼叫另一個合約，就固定給一筆 gas 上限，一旦對方收費變貴，這筆呼叫直接失敗；更麻煩的是，合約部署之後就無法修改，這不是漏洞而是設計，開發者能做的只有重新部署一份新的，但舊合約裡鎖著的使用者資金不會自己搬家。
Leo Glisic 的解法是把指令集切成兩套。他的 EIP-8488 草案主張既有合約保留舊的費率表，新部署的合約則必須改用 V2 opcode，直接套用 EIP-8037 與 EIP-8038 的新價格。好處是舊合約的行為完全不變，代價是以太坊的指令集從此分岔成兩個版本，節點必須長期維護兩套規則。
Giulio Rebuffo 走另一條路：不切指令集，改切帳本。他的雙計價草案讓每筆交易同時跑兩套計價，一套用舊規則計算執行過程，另一套用新規則算出實際收取的費用，舊合約執行起來「感覺不到」價格變了，使用者帳單照新制走。草案自己也承認，這套設計還沒有任何執行客戶端實作，也沒有跑過共識測試。
時間壓力是真的。Glamsterdam 原本要在 10 月 26 日跑第二次排練，因為安全研究者示警而延後。安全研究者 pcaversaccio 在 X 上直接開砲，說他兩週前就把 Gas 漲價的問題反映給核心開發者，結論是 Glamsterdam 不該以現在的樣子出貨。另一位化名開發者 banteg 補刀，指出受影響合約的清單已經列到 20 萬份，而清單本身的方法學還有問題，實際被波及的協議恐怕更多。開發者在 10 月 29 日估出的下一場閉門測試時間是 11 月 16 日至 20 日，而這個時間點早在兩份草案出現之前就排好了。
兩案差在哪：一個切指令集，一個切帳本
對節點來說，Glisic 案相對單純，舊合約完全不動，等於用「版本」把歷史包袱圈起來；但代價是 EVM 從此背著兩套指令集，新舊合約互相呼叫時的邊界情況必須另外定義，否則同一段程式碼在不同版本下會算出不同結果。相較之下，Rebuffo 案對應用開發者最無痛，使用者看到的帳單一律走新價，舊合約則在另一本帳上照舊執行；問題在於每筆交易要算兩次，而且草案自己承認沒有共識測試，最壞的情況是不同客戶端在邊界條件下算出不同費用，把共識風險引進原本只是定價問題的爭議裡。
這次撞上的是「合約不能改」這條底線
過去十年的以太坊升級，多半刻意避開改動既有合約的 Gas 價格，因為那已經是整個生態的隱性契約。Glamsterdam 是第一次正面撞上它，而且不是意外：以太坊基金會先前就警告過，部分錢包與工具會因為 Gas 新制而失效，代表這是可預期的技術債。現在的問題不是要不要付，而是用哪一種方式付。
如果不修，風險也不只是「幾筆交易失敗」。清算邏輯、預言機餵價、跨協議的呼叫鏈條只要有一環因為固定 gas 上限而中斷，出錯的會是同一個時間點上的一整批部位，這在借貸協議裡意味著有人該被清算卻清算不了，或被錯誤清算。
後續觀察
第一個觀察點是 11 月 16 日至 20 日的閉門測試能不能如期開跑。Glamsterdam 已經延後過一次，若再延，年底上線的時程就守不住。第二個觀察點是兩份草案的去向：若被納入 Glamsterdam，等於以太坊在 Gas 重定價之外，額外背上一個相容性層；若被推到下一個升級，Gas 重定價與 ePBS 這類共識層改動就可能脫鉤，屆時開發者得在「先上共識改動、價格問題延後」之間重新排隊。
📍相關報導📍
以太坊 Glamsterdam 升級無限延期！ChainSecurity 揪出 13 個受影響合約
