﻿---
title: "如何監控代理合約升級"
description: "監控可升級代理的實作、信標與控制權變更，並在執行後核驗程式碼、儲存相容性、初始化、權限和關鍵行為。"
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 如何監控代理合約升級

> 僅供教育參考，不構成投資建議；投資可能產生損失。

<a id="answer"></a>

## 直接答案

監控可升級系統時，既要看代理地址，也要看它的控制路徑。警示應指出誰能授權和執行升級、是否有強制延遲、舊實作與新實作為何，以及初始化呼叫資料。執行後還要獨立讀取鏈上設定並測試關鍵行為。

代理地址及其餘額可以保持不變，而委派執行的程式碼卻能改變權限、費用、記帳、暫停機制或提款邏輯。過去的稽核不會自動涵蓋新實作及其初始化過程。

<a id="mechanism"></a>

## 運作原理

首先識別代理模式。ERC-1967 為 `eip1967.proxy.implementation`、`eip1967.proxy.beacon` 和可選的 `eip1967.proxy.admin` 分別定義了儲存槽。直接更換實作時應發出 `Upgraded`，更換信標地址時應發出 `BeaconUpgraded`，管理員槽變更時應發出 `AdminChanged`。對於信標代理，還要呼叫信標的 `implementation()`，因為信標可在代理的信標槽不變時更換實作。

不要根據管理員槽推斷完整的權限模型。Transparent 代理可能透過 `ProxyAdmin` 控制，而 UUPS 的升級授權由目前邏輯合約中的 `_authorizeUpgrade` 實作。需要追蹤所有者、角色、多簽門檻、時間鎖、治理合約、緊急路徑，以及修改這些控制措施的能力。

同時使用事件訂閱和定期狀態讀取。ERC-1967 建議發出相應事件，但不強制每個實作都發出。透過獨立 RPC 節點記錄鏈、區塊、交易、代理、實作或信標、執行期程式碼雜湊、執行者及相關控制狀態。對已排程、已取消和已執行的操作分別警示，並按該鏈選定的確認或最終性策略等待後，再將狀態視為穩定。

<a id="example"></a>

## 範例

某借貸代理由 3-of-5 多簽透過 24-hour 時間鎖控制。升級排程後，監控器記錄提案識別碼、目標、呼叫資料、最早執行時間、目前實作、擬議實作及原始碼驗證狀態。審查者比較程式碼和儲存配置，檢查初始化呼叫，並核對角色、外部呼叫、費用、暫停規則和提款路徑的變化。

執行後，監控器再次讀取相關 ERC-1967 槽，核驗部署的執行期程式碼，並檢查實作版本、管理員或角色持有人、暫停狀態、資產記帳和唯讀提款預覽等預期後置條件。如果觀察到的地址或程式碼雜湊與已審提案不符，或定期輪詢發現事件未報告的變更，則觸發第二次警示。

<a id="risks"></a>

## 風險

- **控制權風險：** 名義上的多簽可能被其他所有者、角色、模組、治理合約、緊急金鑰或可變時間鎖繞過。應沿每條路徑追蹤到最終簽署者和延遲。
- **程式碼與儲存風險：** 未驗證程式碼、不相容的儲存配置、不安全的初始化或相依項目變化，可能破壞狀態或授予非預期權限。應驗證實際部署的成品，而不是只看儲存庫分支或稽核名稱。
- **監控風險：** 單一 RPC、只看事件的索引器、前端或區塊瀏覽器都可能延遲或出錯。應跨獨立資料來源核對事件、儲存、位元組碼、交易收據和協定狀態。
- **回應風險：** 沒有負責人和已演練流程的警示可能來得太遲。應明確延遲期內由誰審查、暫停整合、溝通或退出，同時認識到倉促批准和非官方恢復連結會帶來額外風險。

最低執行手冊：

1. 盤點每條鏈上的所有代理、信標、實作、管理員、角色和升級入口。
2. 儲存儲存槽、程式碼雜湊、控制狀態及關鍵唯讀結果的已知良好基準。
3. 在治理或時間鎖允許時於執行前警示，並在執行或取消時再次警示。
4. 將實際執行的目標、呼叫資料、實作、位元組碼、儲存配置和升級後狀態與已審提案比較。
5. 對意外變更、後置條件失敗、原始碼未驗證或延遲被縮短或繞過進行升級處置；不要把代理地址不變當作安全證明。

<a id="misconceptions"></a>

## 常見誤解

- **誤解 1：「只監控 `Upgraded` 就夠了。」** 信標實作變更和非標準代理可能需要監控另一個合約或輪詢狀態；事件必須與直接讀取結果核對。
- **誤解 2：「管理員槽能顯示每次升級由誰控制。」** 該槽是可選的，Transparent、UUPS、信標、治理和自訂設計把權限放在不同合約與函式中。
- **誤解 3：「原始碼已驗證或過去有稽核就證明升級安全。」** 應針對準確版本驗證已部署位元組碼、編譯器與建構假設、儲存相容性、初始化、設定和行為。

<a id="related"></a>

## 相關主題

- [多簽模組風險](/zh-tw/crypto/multisig-module-risk/)
- [代理合約](/zh-tw/crypto/proxy-contract/)
- [代理儲存衝突](/zh-tw/crypto/proxy-storage-collision/)
- [協定緊急暫停](/zh-tw/crypto/protocol-emergency-pause/)
- [可升級合約](/zh-tw/crypto/upgradeable-contract/)

<a id="sources"></a>

## 來源

- [ERC-1967：代理儲存槽](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals（查閱日期：2026-08-21）
- [代理](https://docs.openzeppelin.com/contracts/5.x/api/proxy) - OpenZeppelin（查閱日期：2026-08-21）
- [撰寫可升級合約](https://docs.openzeppelin.com/upgrades-plugins/writing-upgradeable) - OpenZeppelin（查閱日期：2026-08-21）
- [存取控制](https://docs.openzeppelin.com/contracts/5.x/access-control) - OpenZeppelin（查閱日期：2026-08-21）

Source: https://wiki.fcontext.com/zh-tw/crypto/proxy-upgrade-monitoring/index.mdx
