一項於 10 月 26 日合併的規範變更，修補了以太坊存款處理流程中的一個漏洞。該漏洞原本可在網路的 Glamsterdam 升級啟動後，讓節點營運商將質押者仍在佇列中的存款，重新導向至自己控制的餘額。此修復落地於 consensus-specs 儲存庫——即以太坊各客戶端團隊所實作的參考規則——距離該漏洞在 GitHub 上被回報已過了兩週。只有分叉啟動時仍在佇列中等待的存款才可能被錯誤導向，而由於 Glamsterdam 尚未抵達主網，並沒有資金損失。

節點營運商原本如何可能奪走質押者的存款

集合質押協議通常會分擔運行驗證者的工作：協議提供 ETH，而外部的節點營運商持有驗證者的簽名金鑰。以太坊將簽名與提領功能分離，因此營運商可以運行驗證者，卻無法提領協議的質押資金。

Glamsterdam 將執行層變更與名為 Gloas 的共識層升級配對，並在內建的提議者-建構者分離機制下，新增 builder 作為一種新的參與者。builder 負責組裝區中承載交易的部分，並持有自己的餘額。在分叉時，以太坊會將仍在佇列中等待的合格存款轉換為 builder 帳戶。

這項轉換正是漏洞所在。根據舊規則，一旦待處理的存款為某把金鑰註冊了 builder，之後針對該金鑰的每一筆存款都會補充至該 builder,不論其提領憑證指向何處。營運商可以用自己控制的地址，為一把全新的金鑰排入一筆 builder 存款。如果質押協議隨後為同一把金鑰存入一筆驗證者存款,且兩者在分叉時都仍在佇列中，協議的 ETH 就會被記入營運商的 builder 餘額,營運商隨後便可將其提領。同時也不會建立任何驗證者。有些協議只有在證明新驗證者帶有其提領憑證後，才會釋出其餘質押資金，而這份證明將永遠不會出現。

在後續留言中，該議題的作者列出了可能被此漏洞破壞的設計：Lido 的預存款保證、Origin 的 OETH 以及 Rocket Pool 的 Saturn，同時標註這份清單是快速、由 AI 輔助的研究，可能包含錯誤。在每個案例中，風險敞口都是第一筆存款——在 Lido 與 Rocket Pool 的例子中為 1 ETH——其餘質押資金則在完成恢復步驟前保持鎖定。作者將這些描述為條件式的程式碼發現，而非實際存在的攻擊。

10 月 19 日遭關閉，一週後合併

該修復於 10 月 12 日提出。在兩次核心開發者會議上討論後，因缺乏客戶端支援而於 10 月 19 日被關閉，測試會議則提出在 Hoodi 測試網升級後再進行原型開發，以免打亂原定時程。

三天後，以太坊基金會延後 Glamsterdam 在 Hoodi 上的啟動，以調查 EIP-8037 與現有智能合約的互動問題，該問題與存款無關。多出來的時間重新開啟了辯論。10 月 23 日在下一次測試會議議程上的一則留言將這項存款變更與修訂後的時程連結起來，作者當天也加入了存款排序測試，該變更最終於 10 月 26 日合併。

新規則的作用

分叉之後，在 EIP-8282 之下，builder 與驗證者存款本就已分走不同的路徑。此修復將相同的邏輯套用至分叉時的佇列：由提領憑證、而非公鑰，決定每筆待處理存款的去向。

同一把金鑰仍可同時用於驗證者與 builder；每筆存款中聲明的用途，現在決定了它所資助的帳戶。

分叉之前還需要完成什麼

規範的合併只是第一步；各客戶端團隊現在必須實作相同的規則。Teku 於 10 月 27 日開啟的一項變更仍在審查中，Lodestar 的對應變更也仍處於開啟狀態。

這項後期變更還必須在每個客戶端中完全一致地落地。較舊的參考測試編碼的是先前的路由規則，因此遵循新規則的客戶端將無法通過這些測試。Teku 的作者回報已通過由更新後規範所產生的測試，但該規範尚未打包進正式的規範發布版本。如果各客戶端在抵達分叉時對同一佇列套用不同規則，它們將計算出不同的餘額，並對鏈的狀態產生分歧。

基金會尚未設定新的 Hoodi 日期或 Glamsterdam 主網日期。依賴存款證明的質押協議也有自己的防線：根據該議題作者的說法，在預存款檢查中拒絕已帶有 builder 存款的金鑰，即可防止此情境。後續值得關注的指標，是兩個仍開啟的客戶端 pull request、打包更新測試的規範發布版本，以及 Hoodi 與主網的新日期。