代理合約

什麼是代理合約？

代理合約是一種智能合約，會接收使用者呼叫，再將呼叫轉送至另一個包含實際業務邏輯的合約。

在加密貨幣領域，代理合約主要用於讓智能合約系統可以升級，同時維持相同的公開合約地址與儲存狀態。

使用者實際互動的合約通常稱為代理合約。

包含目前邏輯的合約通常稱為實作合約、邏輯合約或主副本。

OpenZeppelin 代理升級模式說明，代理式可升級設計會將合約儲存空間與合約邏輯分開。

這種區分很重要，因為智能合約部署後通常很難或無法變更。

若專案部署一般合約後才發現錯誤，團隊可能必須在新地址部署另一個合約。

代理合約透過維持相同的代理地址，並在升級獲准時改為指向新的實作合約，解決這個問題。

使用者、錢包及應用程式會繼續與代理地址互動，而該地址背後的邏輯則可以改變。

最簡單的理解方式是：代理合約是固定的正門，實作合約則是門後可替換的引擎。

代理合約的用途

代理合約的出現，是因為區塊鏈的不可篡改性同時帶來安全保障與操作上的限制。

不可篡改性很有用，因為使用者可以相信已部署的程式碼不會像一般網頁軟體一樣遭到暗中修改。

但當開發者需要修正錯誤、加入功能、因應安全問題、改善效能或支援新標準時，不可篡改性就會成為限制。

沒有代理合約時，升級智能合約通常代表必須部署新合約，並要求使用者遷移資產或權限。

這類遷移可能成本高、令人困惑、帶有風險，並造成干擾。

代理合約可讓使用者看到的地址維持不變。

這對 DeFi 協議、NFT 系列、DAO、代幣合約、跨鏈橋、質押系統、遊戲資產及帳戶抽象錢包都很重要。

由於整合方不必在每次邏輯變更時更新合約地址，因此代理合約可減少使用者操作上的阻礙。

代理合約也能讓緊急修正更容易部署，進而改善安全性。

然而，可升級性會引入信任假設，因為必須由某個人或治理流程取得權限，才能變更實作合約。

代理合約如何運作

代理合約會儲存狀態，並將函式呼叫轉送至實作合約。

使用者呼叫代理合約時，代理合約通常不會自行執行主要應用程式邏輯。

代理合約會透過

等低階 EVM 機制，將呼叫轉送至實作合約。

執行的是實作合約的程式碼，但被修改的儲存空間屬於代理合約。

這是代理式可升級系統得以運作的關鍵。

代理合約會保留餘額、設定、所有權變數、代幣供應量、使用者倉位及其他狀態。

實作合約則提供讀取及更新這些狀態所需的程式碼。

系統升級時，會部署一個採用新邏輯的實作合約。

接著，代理合約會將實作合約指標更新為新合約。

使用者看到的地址與已儲存資料仍留在代理合約中，未來的呼叫則會使用新邏輯。

代理合約與 Delegatecall

是許多代理合約運作時採用的低階機制。

一般外部呼叫會讓一個合約呼叫另一個合約，而被呼叫的合約會使用自己的儲存空間。

使用

時，被呼叫合約的程式碼會在呼叫合約的儲存空間環境中執行。

對代理合約而言，這表示實作合約的程式碼可以修改代理合約的儲存空間。

這項機制相當強大，因為代理合約可以保留狀態，同時更換所使用的實作程式碼。

這也帶有風險，因為撰寫實作程式碼時，必須考量代理合約的儲存布局。

若實作合約將資料寫入錯誤的儲存槽位，可能會破壞重要資料。

若代理合約委派給惡意實作合約，惡意邏輯就可能抽走資產或變更權限。

SWC-112 Delegatecall 警告建議開發者謹慎使用

，並避免呼叫不受信任的合約。

在代理系統中，

不只是技術細節，而是安全模型的核心。

代理合約與實作合約的差異

代理合約與實作合約肩負不同責任。

代理合約保留使用者呼叫的地址，通常也會儲存系統狀態。

實作合約則包含決定狀態如何變更的函式及規則。

例如，代幣代理合約可以在代理儲存空間中保存餘額，而實作合約則定義轉帳、核准、鑄造、銷毀或存取控制邏輯。

需要新功能時，開發者會部署新的實作合約。

接著，代理合約會升級並指向新的實作合約。

代理地址維持不變，因此使用者與整合方不必改用新地址。

這種模式雖然實用，但使用者應確認由誰控制升級。

若單一私鑰控制代理管理者，該私鑰可能擁有合約的重大控制權。

若升級由治理機制透過時間鎖與投票流程控制，使用者可能有更多時間在升級生效前審查變更。

代理合約與一般智能合約的差異

一般智能合約通常會將儲存空間與邏輯放在同一個合約中。

部署後，一般合約的程式碼通常固定不變。

代理式系統會將儲存空間與邏輯分開，至少放在兩個合約中。

代理合約負責儲存狀態並轉送呼叫。

實作合約包含邏輯；若升級機制允許，就可以替換實作合約。

這讓代理系統比一般合約更有彈性。

但系統也更難稽核，因為安全性取決於代理合約、實作合約、管理者控制權、初始化流程、儲存布局及升級歷史。

對使用者而言，一般合約可能較容易理解，因為地址上的程式碼就是實際執行的程式碼。

使用者若遇到代理合約，就必須進一步檢查實作合約，才能確認目前執行的程式碼。

因此，區塊鏈瀏覽器通常會標示已驗證的代理合約，並在可辨識時顯示目前的實作地址。

代理合約與可升級性

可升級性是使用代理合約最常見的原因。

可升級合約讓開發者在部署後變更邏輯，同時維持代理地址不變。

這對修正錯誤、加入功能、改善 Gas 效率、支援新整合、調整治理或升級協議都很有用。

然而，可升級性會改變信任模型。

可升級合約不像不可升級合約那樣完全不可變。

使用者必須信任升級權限持有者不會引入惡意或草率的變更。

升級權限可能屬於單一擁有者、多重簽章錢包、DAO、時間鎖控制器或其他治理合約。

較安全的設計通常會讓升級權限透明，並提高濫用權限的難度。

例如，時間鎖可以讓使用者在重大升級生效前有時間退出。

若缺乏完善的管控，代理合約可能成為暗中控制使用者資金的後門。

ERC-1967 代理標準

ERC-1967 是廣泛使用的代理儲存槽位標準。

ERC-1967 標準定義了特定儲存槽位，用於保存實作地址、管理者地址及信標地址等代理資訊。

此標準的目的是避免代理合約與實作合約之間發生儲存衝突。

儲存衝突是指兩個變數意外使用相同的儲存槽位。

在代理系統中，這類問題尤其危險，因為代理儲存空間與實作邏輯會透過

互動。

ERC-1967 也有助於區塊鏈瀏覽器與開發者工具辨識代理合約背後目前使用的實作合約。

這讓代理系統更容易檢查與稽核。

許多常見的可升級代理模式都採用 ERC-1967 槽位。

採用知名標準不代表代理合約就一定安全。

但採用標準能減少可避免的混淆，也能協助工具辨識重要代理資料的儲存位置。

透明代理

透明代理是一種將管理者呼叫與使用者呼叫分開處理的代理模式。

在此模式中，一般使用者會呼叫代理合約，再由代理合約將呼叫轉送至實作合約。

管理者可以執行與升級相關的操作，但通常會受到限制，無法透過代理合約意外呼叫實作合約的函式。

此設計有助於避免代理管理者函式與實作合約函式發生函式選擇器衝突。

OpenZeppelin 的代理合約說明文件將

列為內建管理者及升級介面的代理合約。

透明代理相當常見，因為升級邏輯明確位於系統的代理端。

不過，與更精簡的代理模式相比，透明代理可能會有稍高的額外負擔。

透明代理也需要妥善管理代理管理者。

若代理管理者遭到入侵，攻擊者可能將合約升級至惡意邏輯。

透明代理的安全性仍取決於實作程式碼與管理者安全性。

UUPS 代理

UUPS 是 Universal Upgradeable Proxy Standard（通用可升級代理標準）的縮寫。

ERC-1822 UUPS 標準介紹一種透過實作邏輯管理升級相容性的代理設計。

在 UUPS 設計中，升級函式位於實作合約，而非複雜的代理管理者介面，因此代理合約可以更精簡。

這有助於降低部署成本及代理合約的複雜度。

不過，開發者必須在實作合約中正確保護升級函式。

若存取控制有誤，攻擊者可能就能升級系統。

若新的實作合約移除或破壞升級函式，代理合約之後可能難以甚至無法再次升級。

OpenZeppelin 的 UUPS 工具包含一些防護措施，以降低意外失去升級能力的風險，但開發者仍須仔細審查。

UUPS 代理相當靈活且有效率，因此功能強大。

若團隊不完全了解升級權限所在位置，UUPS 代理就會帶來風險。

信標代理

信標代理會從獨立的信標合約取得實作地址。

多個代理合約可以指向同一個信標，而不必各自儲存實作地址。

信標升級後，所有使用該信標的代理合約都能開始使用新的實作合約。

若專案需要部署許多應一併升級的相似合約，這種設計就很有用。

例如，工廠合約可以建立許多使用相同邏輯的使用者金庫、資金池、帳戶或 NFT 相關合約。

信標代理可以簡化大規模升級。

但風險也可能增加，因為一次信標升級就可能影響多個代理實例。

信標管理者必須受到妥善保護。

使用者應了解自己的合約是否依賴信標，因為信標變更可能改變許多合約的行為。

信標代理適合大量合約，但升級權力也因此集中在信標上。

最小代理與 ERC-1167

最小代理是一種非常精簡的代理合約，旨在以較低部署成本複製另一個實作合約的行為。

ERC-1167 最小代理標準定義了一種精簡的位元組碼模式，讓低成本合約複本能將呼叫委派至固定的實作合約。

最小代理通常稱為複本（clone）。

若專案需要部署許多相同邏輯的複本，例如錢包、金庫、資金池、帳戶或交易市場實例，最小代理就很實用。

每個複本都有自己的地址與狀態，但會重複使用實作邏輯。

由於不必一再部署完整的實作程式碼，因此可以節省 Gas。

並非每個最小代理都能升級。

許多 ERC-1167 複本會指向固定的實作合約，除非在其他位置加入額外的升級邏輯，否則無法更改目標。

這項差異很重要，因為最小代理著重於低成本複製，可升級代理則著重於替換邏輯。

有些系統會結合兩種概念，但兩者不應混為一談。

代理合約中的儲存布局

儲存布局是代理合約設計中最重要的議題之一。

由於代理合約負責儲存狀態，而實作合約提供邏輯，因此實作合約必須依照正確順序讀取及寫入儲存資料。

若新實作合約錯誤地變更變數順序，可能會將舊儲存資料解讀成錯誤的資料類型。

例如，餘額映射可能會被誤解為擁有者變數，或設定值可能遭新增變數覆寫。

這可能使合約無法正常運作，或產生安全漏洞。

可升級合約框架通常要求開發者將新變數附加在後方，而非重新排序或刪除舊變數。

有時會使用儲存空隙，為未來變數預留空間。

儲存布局檢查可以在部署前發現許多升級錯誤。

開發者應將儲存布局視為合約公開安全模型的一部分。

若可升級專案沒有說明如何在升級時檢查儲存布局，使用者就應保持謹慎。

代理合約的初始化

可升級代理合約通常使用初始化函式，而非建構子。

建構子只會在實作合約部署時執行。

但在代理系統中，使用者實際互動的是代理合約，因此代理合約的儲存空間需要初始化。

因此，設定邏輯通常會透過代理合約呼叫初始化函式來執行。

初始化時可能會設定擁有者、代幣名稱、金庫地址、管理角色、供應量、費用設定或治理參數。

若忘記初始化，代理合約可能無人保護。

若攻擊者搶先呼叫初始化函式，就可能成為擁有者或管理者。

若初始化函式可以多次呼叫，重要設定就可能遭到覆寫。

因此，可升級合約需要使用初始化防護，避免重複初始化。

初始化錯誤是可升級合約最常見且最危險的錯誤之一。

代理管理者與升級權限

代理管理者是能夠升級代理實作合約的帳戶或合約。

此角色可能由單一錢包、多重簽章錢包、DAO 投票、時間鎖或治理合約控制。

管理者角色極為重要，因為它能變更控制使用者資產的程式碼。

即使先前的實作合約安全無虞，若管理者升級至惡意邏輯，使用者仍可能損失資金。

若管理者金鑰遭竊，攻擊者可能就能替換實作合約。

若管理者反應過慢或治理流程過度分散，緊急修正可能難以進行。

良好的代理治理應在安全性、應變速度、透明度及使用者退出權之間取得平衡。

升級公告發布後設定時間鎖，可延後升級執行並提升信任。

多重簽章要求多位簽署者共同核准，可降低單一金鑰風險。

公開升級提案與稽核資料有助於使用者了解變更內容。

代理合約與區塊鏈瀏覽器

區塊鏈瀏覽器通常可協助使用者檢查代理合約。

優質的瀏覽器可能會標示某個地址是代理合約，並指出目前的實作地址。

若代理合約遵循 ERC-1967 等已知標準，瀏覽器也可能顯示代理管理者資訊。

這有助於使用者與稽核人員檢查實際執行的程式碼。

若瀏覽器無法辨識代理合約，使用者可能只檢查到代理位元組碼，而漏看實作邏輯。

這可能造成錯誤的安全感，因為代理合約中實際可見的應用程式程式碼可能很少。

使用者應確認實作合約是否已驗證。

使用者也應確認實作合約是否曾隨時間變更。

若代理合約已升級至新邏輯，舊稽核可能不再適用。

若要進行高價值操作，檢查代理合約、實作合約、管理者及升級歷史，遠比只檢查畫面上顯示的地址安全。

代理合約與代幣合約

許多代幣合約會使用代理合約，以支援未來升級。

可升級代幣可以維持相同代幣地址，同時變更轉帳規則、費用規則、鑄造邏輯、銷毀邏輯、跨鏈橋邏輯、合規規則或治理功能。

若代幣需要隨時間調整，這種設計就很有用。

但這也可能帶來風險，因為使用者購買或接收代幣後，所依賴的規則仍可能改變。

例如，升級可能新增轉帳限制、變更費用機制、加入暫停權限或修改存取控制。

使用者不應假設代幣規則永久固定，應先確認代幣合約是否可升級。

使用者也應確認由誰控制升級，以及治理程序是否會延遲變更生效。

代幣使用代理合約不代表它一定不安全。

這只代表它的信任模型與完全不可變的代幣合約不同。

關鍵在於升級權限是否透明且受到妥善保護。

代理合約與 DeFi 協議

DeFi 協議常使用代理合約，因為金融應用程式需要維護。

借貸協議、自動化做市商、衍生品系統、質押金庫或收益策略，可能在稽核後、市場變化後、預言機改善後或發現錯誤後需要升級。

代理合約讓這些系統能持續改進，而不必要求每位使用者遷移倉位。

這種方式相當方便，因為 DeFi 倉位可能很複雜，且與許多協議相互連結。

然而，可升級性也會帶來系統性風險。

廣泛使用的 DeFi 合約若發生不良升級，可能同時影響許多使用者與整合服務。

可升級的 DeFi 協議應具備嚴謹測試、稽核、監控、治理管控及緊急應變程序。

使用者不應只確認協議是否通過稽核。

使用者還應確認目前的實作合約是否經過稽核，以及未來升級是否需要公開審查。

在 DeFi 中，代理合約雖能提升可維護性，卻也更加凸顯治理的重要性。

代理合約與 NFT

NFT 專案可能使用代理合約來升級中繼資料邏輯、鑄造邏輯、市場整合、版稅邏輯、質押系統或遊戲機制。

NFT 代理合約可以讓專案在推出後新增功能。

若實作合約控制代幣 URI 邏輯，也可能讓中繼資料內容發生變化。

當專案從單純的收藏品發展為遊戲、會員資格或數位身分系統時，這種設計可能很有幫助。

若收藏者預期規則固定或中繼資料永久不變，這種設計也可能引發爭議。

NFT 買家應確認 NFT 合約是否可升級，以及中繼資料能否變更。

買家也應確認誰控制升級管理者。

完全不可變的 NFT 與可升級 NFT 都可能是合理設計，但兩者提供的保障不同。

收藏者應了解自己買的是規則固定的鏈上資產，還是參與一個可能持續演變的專案。

代理合約讓 NFT 開發更有彈性，但也需要信任專案的升級流程。

代理合約與 DAO

DAO 可能使用代理合約升級治理模組、金庫工具、投票系統、質押合約或協議參數。

與單一管理者控制的代理合約相比，由 DAO 控制的代理合約可能更透明，因為升級可能需要提案與投票。

然而，DAO 治理不會自動讓升級變得安全。

投票參與率低、買票、治理攻擊、倉促提出提案或程式碼變更不明，都可能造成風險。

良好的 DAO 升級流程應包含易讀的摘要、技術差異說明、稽核連結、風險分析、投票時程及時間鎖延遲。

DAO 成員應清楚了解哪些合約可升級，以及治理擁有哪些權限。

若治理可以升級金庫合約、代幣合約或核心協議邏輯，投票者就必須為重大安全決策負責。

代理合約可以協助 DAO 隨時間調整。

但代理合約也可能讓治理機制變更使用者原以為穩定的規則。

DAO 的可升級性應清楚揭露、完整記錄並受到審慎管控。

代理合約的優點

代理合約的第一項優點是可升級性。

專案可以修正錯誤、新增功能及改善邏輯，而無須更改主要合約地址。

第二項優點是狀態延續性。

實作邏輯變更時，使用者餘額、倉位、權限及設定仍可保留在代理合約中。

第三項優點是整合穩定性。

錢包、dApp、索引器及其他合約可以繼續使用相同地址。

第四項優點是降低遷移阻礙。

每次升級後，使用者可能不必手動將資產移至新合約。

第五項優點是複本模式能提高 Gas 效率。

最小代理可以比每次部署完整程式碼更低成本地部署許多相似合約。

第六項優點是模組化架構。

團隊可以更明確地分離儲存空間、邏輯、升級控制及部署模式。

只有在代理合約經過妥善設計、稽核、治理及監控時，這些優點才有價值。

代理合約的風險

第一項風險是惡意升級。

若升級權限遭到入侵或由不誠實者掌控，對方可能以惡意邏輯取代安全的程式碼。

第二項風險是儲存衝突。

若儲存布局錯誤，升級可能破壞重要合約狀態。

第三項風險是初始化失敗。

未初始化的代理合約或實作合約可能讓攻擊者取得控制權。

第四項風險是函式選擇器衝突。

若代理模式設計不佳，代理管理者函式與實作合約函式可能互相衝突。

第五項風險是稽核內容不符。

合約或許曾經通過稽核，但目前的實作合約可能已經不同。

第六項風險是隱藏的複雜性。

使用者可能沒發現自己互動的是代理合約，而非簡單且不可變的合約。

第七項風險是治理權遭把持。

攻擊者可能透過投票權、管理者權限或社交工程影響升級流程。

第八項風險是工具辨識錯誤。

若代理合約採用自訂或非標準設計，區塊鏈瀏覽器、錢包及索引器可能無法正確顯示代理資訊。

互動前如何檢查代理合約

使用者應先確認區塊鏈瀏覽器是否將該合約地址標示為代理合約。

使用者應查找目前的實作地址。

使用者應確認實作合約原始碼是否已公開並通過驗證。

使用者應確認實作合約最近是否曾變更。

使用者應查明由誰控制代理管理者或升級權限。

使用者應確認升級是透過多重簽章、DAO、時間鎖，還是單一私鑰進行。

使用者應比較稽核日期與實作合約部署日期。

使用者應閱讀官方說明文件，了解合約是否有意設計為可升級。

使用者不應因代理地址未變，就假設合約不可變。

存入大量資金前，使用者應將代理合約檢查納入一般的審慎評估流程。

開發者的最佳做法

開發者應使用經充分審查的代理框架；若未經專家審查，不應自行撰寫自訂代理邏輯。

適當情況下，開發者應遵循 ERC-1967 等標準，讓工具能檢查代理狀態。

開發者應透過嚴謹的存取控制保護升級函式。

對重要的升級權限，開發者應使用多重簽章錢包、時間鎖或治理合約。

開發者應謹慎撰寫初始化函式，並防止重複初始化。

每次升級前，開發者都應測試儲存布局。

若不了解後果，開發者絕不可重新排序、刪除或更改既有儲存變數。

開發者應在區塊鏈瀏覽器上驗證實作合約。

進行重大變更前，開發者應發布升級公告、稽核資料及技術說明。

開發者應監控升級事件，並準備好在升級失敗時迅速應對。

使用者的最佳做法

使用者應了解，可升級代理合約並不等同於完全不可變的智能合約。

存入大量資金前，使用者應確認誰可以升級代理合約。

使用者應確認升級是否受時間鎖延遲。

使用者應檢查最新的實作合約是否已驗證並經過稽核。

若代理管理者由單一且身分不明的錢包控制，使用者應特別謹慎。

若使用者在協議中持有大量倉位，應監控升級事件。

若使用者不了解風險，就應避免向可升級合約核准無上限的代幣額度。

使用者應在使用協議後撤銷不必要的核准。

使用者應記得，即使過去的行為看似安全，升級仍可能改變未來的運作方式。

使用者應將代理合約視為需要持續評估信任程度的彈性系統。

對代理合約的常見誤解

一種誤解是代理合約一定不安全。

若代理合約採用經驗證的模式、完善的存取控制、穩健的治理、稽核及透明升級機制，就可能是安全的。

另一種誤解是代理合約只要使用熱門框架就一定安全。

即使是標準代理合約，若實作合約帶有惡意程式碼或管理者遭到入侵，仍可能很危險。

另一種誤解是代理地址已包含使用者需要審查的所有邏輯。

實際上，重要的應用程式邏輯通常位於實作合約中。

另一種誤解是稽核一定涵蓋目前的程式碼。

若代理合約已升級，舊稽核可能不涵蓋新的實作合約。

另一種誤解是最小代理一定可升級。

許多最小代理只是指向固定邏輯的低成本複本。

常見問題

代理合約是什麼意思？

代理合約是一種將呼叫轉送至另一個合約的智能合約，通常可讓系統在更換實作邏輯時，維持相同地址與儲存狀態。

加密貨幣專案為什麼使用代理合約？

專案使用代理合約來支援升級、修正錯誤、加入功能、降低遷移阻礙、維持地址穩定，並有效率地部署許多相似合約。

代理合約可以升級嗎？

許多代理合約可以升級，但並非所有代理合約都能升級，因為有些最小代理會指向固定邏輯。

什麼是實作合約？

實作合約是包含代理透過轉送或

執行之邏輯的合約。

代理合約中的 delegatecall 是什麼？

是一種 EVM 運算，讓代理合約能在使用自身儲存空間環境的情況下執行實作合約程式碼。

什麼是 ERC-1967？

ERC-1967 是一項標準，定義代理資料專用的儲存槽位，例如實作合約、管理者及信標地址。

什麼是透明代理？

透明代理是一種可升級代理模式，會將管理者的升級呼叫與一般使用者呼叫分開，以降低函式衝突風險。

什麼是 UUPS 代理？

UUPS 代理是一種可升級代理模式，升級邏輯由實作合約處理，而非主要放在代理合約中。

什麼是信標代理？

信標代理會從信標合約取得實作地址，因此變更信標就能一併升級多個代理合約。

什麼是最小代理？

最小代理是一種精簡的合約複本，通常以 ERC-1167 為基礎，會將呼叫轉送至共用實作邏輯，以降低部署成本。

代理合約有風險嗎？

有。若升級權限薄弱、儲存布局錯誤、初始化不安全，或使用者不了解邏輯可能變更，代理合約就可能帶有風險。

如何確認某個合約是否為代理合約？

可以查看區塊鏈瀏覽器上的代理標籤、實作地址、ERC-1967 儲存槽位、已驗證的原始碼及升級事件。

結論

代理合約是一種智能合約設計模式，會將使用者看到的地址與已儲存狀態，和實際執行合約行為的邏輯分開。

此模式在加密貨幣領域廣泛使用，因為它讓智能合約可以升級，而不必要求使用者與整合方改用新地址。

代理合約會接收呼叫、保存儲存狀態，並通常透過

將執行工作轉送至實作合約。

ERC-1967、ERC-1822 及 ERC-1167 等標準，有助於建立透明代理、UUPS 代理、信標代理及最小代理等常見設計。

代理合約帶來可升級性、狀態延續性、整合穩定性及更低成本部署合約複本等重要優點。

代理合約也帶來重大風險，包括惡意升級、儲存衝突、合約未初始化、管理者金鑰遭入侵、治理不明及稽核內容過時。

對開發者而言，代理合約應被視為高風險的架構元件，必須經過審慎設計、測試、權限控管及公開說明。

對使用者而言，代理合約的檢查方式應與一般不可變合約不同，因為代理背後的邏輯可能隨時間改變。

最簡單的理解方式是：代理合約在受控條件下維持相同的鏈上地址，同時允許替換該地址背後的程式碼。

這種彈性能讓加密貨幣系統更安全且更容易維護，但前提是升級權力透明、受到限制並經過妥善治理。