僅供教育參考，不構成投資建議；投資可能產生損失。
直接答案
監控可升級系統時，既要看代理地址，也要看它的控制路徑。警示應指出誰能授權和執行升級、是否有強制延遲、舊實作與新實作為何，以及初始化呼叫資料。執行後還要獨立讀取鏈上設定並測試關鍵行為。
代理地址及其餘額可以保持不變，而委派執行的程式碼卻能改變權限、費用、記帳、暫停機制或提款邏輯。過去的稽核不會自動涵蓋新實作及其初始化過程。
運作原理
首先識別代理模式。ERC-1967 為 eip1967.proxy.implementation、eip1967.proxy.beacon 和可選的 eip1967.proxy.admin 分別定義了儲存槽。直接更換實作時應發出 Upgraded，更換信標地址時應發出 BeaconUpgraded，管理員槽變更時應發出 AdminChanged。對於信標代理，還要呼叫信標的 implementation()，因為信標可在代理的信標槽不變時更換實作。
不要根據管理員槽推斷完整的權限模型。Transparent 代理可能透過 ProxyAdmin 控制，而 UUPS 的升級授權由目前邏輯合約中的 _authorizeUpgrade 實作。需要追蹤所有者、角色、多簽門檻、時間鎖、治理合約、緊急路徑，以及修改這些控制措施的能力。
同時使用事件訂閱和定期狀態讀取。ERC-1967 建議發出相應事件，但不強制每個實作都發出。透過獨立 RPC 節點記錄鏈、區塊、交易、代理、實作或信標、執行期程式碼雜湊、執行者及相關控制狀態。對已排程、已取消和已執行的操作分別警示，並按該鏈選定的確認或最終性策略等待後，再將狀態視為穩定。
範例
某借貸代理由 3-of-5 多簽透過 24-hour 時間鎖控制。升級排程後，監控器記錄提案識別碼、目標、呼叫資料、最早執行時間、目前實作、擬議實作及原始碼驗證狀態。審查者比較程式碼和儲存配置，檢查初始化呼叫，並核對角色、外部呼叫、費用、暫停規則和提款路徑的變化。
執行後，監控器再次讀取相關 ERC-1967 槽，核驗部署的執行期程式碼，並檢查實作版本、管理員或角色持有人、暫停狀態、資產記帳和唯讀提款預覽等預期後置條件。如果觀察到的地址或程式碼雜湊與已審提案不符，或定期輪詢發現事件未報告的變更，則觸發第二次警示。
風險
- 控制權風險： 名義上的多簽可能被其他所有者、角色、模組、治理合約、緊急金鑰或可變時間鎖繞過。應沿每條路徑追蹤到最終簽署者和延遲。
- 程式碼與儲存風險： 未驗證程式碼、不相容的儲存配置、不安全的初始化或相依項目變化，可能破壞狀態或授予非預期權限。應驗證實際部署的成品，而不是只看儲存庫分支或稽核名稱。
- 監控風險： 單一 RPC、只看事件的索引器、前端或區塊瀏覽器都可能延遲或出錯。應跨獨立資料來源核對事件、儲存、位元組碼、交易收據和協定狀態。
- 回應風險： 沒有負責人和已演練流程的警示可能來得太遲。應明確延遲期內由誰審查、暫停整合、溝通或退出，同時認識到倉促批准和非官方恢復連結會帶來額外風險。
最低執行手冊：
- 盤點每條鏈上的所有代理、信標、實作、管理員、角色和升級入口。
- 儲存儲存槽、程式碼雜湊、控制狀態及關鍵唯讀結果的已知良好基準。
- 在治理或時間鎖允許時於執行前警示，並在執行或取消時再次警示。
- 將實際執行的目標、呼叫資料、實作、位元組碼、儲存配置和升級後狀態與已審提案比較。
- 對意外變更、後置條件失敗、原始碼未驗證或延遲被縮短或繞過進行升級處置；不要把代理地址不變當作安全證明。
常見誤解
- 誤解 1：「只監控
Upgraded就夠了。」 信標實作變更和非標準代理可能需要監控另一個合約或輪詢狀態；事件必須與直接讀取結果核對。 - 誤解 2：「管理員槽能顯示每次升級由誰控制。」 該槽是可選的，Transparent、UUPS、信標、治理和自訂設計把權限放在不同合約與函式中。
- 誤解 3：「原始碼已驗證或過去有稽核就證明升級安全。」 應針對準確版本驗證已部署位元組碼、編譯器與建構假設、儲存相容性、初始化、設定和行為。
相關主題
來源
- ERC-1967：代理儲存槽 - Ethereum Improvement Proposals（查閱日期：2026-08-21）
- 代理 - OpenZeppelin（查閱日期：2026-08-21）
- 撰寫可升級合約 - OpenZeppelin（查閱日期：2026-08-21）
- 存取控制 - OpenZeppelin（查閱日期：2026-08-21）