可升級合約

什麼是可升級合約？

可升級合約是一種智能合約設計，允許區塊鏈應用程式在部署後變更或擴充其邏輯，同時保留面向使用者的相同地址、儲存狀態及餘額。

在加密貨幣領域，可升級合約最常用於 DeFi 協議、代幣系統、質押合約、跨鏈橋、借貸市場、智能帳戶、治理系統，以及其他可能隨時間需要修正或新增功能的鏈上應用程式。

傳統智能合約通常被視為不可變更，因為其已部署的程式碼一旦上鏈，便無法直接編輯。

可升級合約藉由將合約地址和儲存資料，與執行使用者操作的業務邏輯分離，來解決這項限制。

建立可升級合約最常見的方式是代理模式（proxy pattern），使用者與代理合約互動，而代理合約會將呼叫轉送至獨立的實作合約。

代理合約維持相同的公開地址，而在授權升級發生時，實作合約可替換為較新版本。

這代表協議每次修正錯誤、新增功能或改善內部邏輯時，使用者不需要遷移至新的合約地址。

對加密貨幣使用者而言，主要好處是延續性，因為代幣餘額、質押紀錄、投票權和協議倉位可保留在相同合約儲存空間中。

對開發者而言，主要好處是彈性，因為他們可改善協議，而無須強制完整遷移使用者資金與資料。

對投資人和交易者而言，主要疑慮是治理風險，因為升級權限可在使用者已存入資產後改變協議行為。

可升級合約如何運作

可升級合約通常至少有兩個核心部分：代理合約和實作合約。

代理合約是使用者、錢包、區塊鏈瀏覽器及其他智能合約通常互動的地址。

實作合約包含實際邏輯，例如轉帳規則、質押計算、借款功能、獎勵分配或存取控制檢查。

當使用者向代理合約發送交易時，代理會使用稱為

的低階機制，執行實作合約的程式碼。

透過

，實作邏輯會如同代理的一部分般執行，但儲存空間、地址及餘額仍與代理合約綁定。

因此，代理可在升級時變更實作地址，同時保留使用者資料。

升級本身通常由獲授權的管理員、多重簽名錢包、治理合約或時間鎖，將代理的實作指標變更為新的實作合約來完成。

新的實作合約必須經過審慎設計，以配合代理現有的儲存佈局。

若儲存佈局遭破壞，升級後的合約可能錯誤讀取餘額、所有權紀錄、權限或其他重要資料。

這是可升級合約需要比簡單的不可升級合約進行更嚴格工程設計、測試和稽核的主要原因之一。

為何可升級合約對加密貨幣重要

可升級合約很重要，因為加密貨幣應用程式通常保管真實資產，且無法依賴傳統軟體更新方式。

在一般網路應用程式中，開發者可修補後端程式碼、重新部署服務或變更資料庫，而無須要求使用者遷移資產。

在公有區塊鏈上，已部署的合約程式碼通常是永久的，因此若合約不可升級，嚴重錯誤可能需要艱難的遷移流程。

可升級設計可透過允許受控更新協議邏輯來減少此問題。

當專案需要修正漏洞、支援新的代幣標準、新增風險控制、提升 Gas 效率，或因應區塊鏈生態系統變化時，此設計相當實用。

然而，可升級性也會改變加密貨幣應用程式的信任模型。

若單一地址可立即升級合約，使用者必須信任該地址不會安裝惡意或疏忽的邏輯。

若升級由去中心化治理控制，使用者必須信任治理流程、投票規則、時間鎖和投票者參與情況。

設計良好的可升級合約，應在彈性與嚴格限制之間取得平衡，包括誰可升級、何時可升級，以及使用者如何監控變更。

代理模式

代理模式是可升級合約最廣泛使用的架構。

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

實作合約包含業務邏輯，但一般使用者不應直接使用它。

當協議升級時，會部署新的實作合約，並更新代理，使其指向該新實作合約。

面向使用者的地址維持不變，因此錢包、整合服務及其他合約可繼續呼叫代理地址。

Ethereum 的智能合約升級文件詳細說明了此設計。

代理模式功能強大，因為它避免手動遷移狀態；這類遷移可能成本高、風險高且令使用者困惑。

但若開發者不了解代理儲存空間、函式選擇器、初始化函式和管理員權限的運作方式，它也可能很危險。

代理合約不會僅因可升級就自動安全。

設計的安全性取決於實作品質、升級權限、測試、治理和監控。

實作合約

實作合約有時稱為邏輯合約，因為它包含定義應用程式如何運作的程式碼。

例如，在代幣合約中，實作合約可定義轉帳規則、授權、鑄幣限制、銷毀邏輯及基於角色的權限。

在質押合約中，實作合約可定義存入規則、提領規則、獎勵公式、懲罰邏輯及緊急控制機制。

在借貸合約中，實作合約可定義抵押品規則、利息計算、強制平倉邏輯及風險參數。

當代理將呼叫委派給實作合約時，實作合約程式碼會使用代理的儲存空間。

這代表實作合約應撰寫成其變數將儲存在代理合約內的形式。

開發者通常應防止使用者直接初始化或不當使用實作合約。

他們也應確保任何新實作合約與舊版的儲存佈局相容。

若新的實作合約錯誤變更儲存空間，可能對鏈上資料造成永久損害。

儲存佈局

儲存佈局是可升級合約安全性中最重要的概念之一。

在 Solidity 中，狀態變數會依特定規則放入儲存槽位，包括變數順序和繼承順序。

合約升級時，新實作合約必須以與舊實作合約相同的方式解讀代理既有儲存資料。

開發者通常只會在既有變數後新增變數，而不會刪除變數、重新排序變數或變更變數類型。

若合約原本將使用者餘額存放在某個槽位，新版本不得意外將同一槽位視為管理員地址或獎勵變數。

儲存衝突可能導致餘額錯誤、權限遺失、帳務不正確或可被利用的合約行為。

Solidity 儲存佈局文件說明 Solidity 如何在持久性儲存空間中組織狀態變數。

現代可升級合約函式庫也包含工具和檢查機制，可在部署前協助開發者偵測不安全的儲存變更。

即使使用工具，每次升級時仍應仔細審查儲存佈局。

ERC-1967 代理儲存槽位

ERC-1967 是常見的 Ethereum 標準，為實作地址、管理員地址和 Beacon 地址等代理資訊定義特定儲存槽位。

ERC-1967 的目的在於降低代理和實作合約之間的儲存衝突。

它也協助區塊鏈瀏覽器和開發工具識別代理背後的實作合約。

若沒有標準儲存槽位，錢包、瀏覽器、稽核人員和監控工具會更難了解代理正在使用哪一個邏輯合約。

ERC-1967 特別重要，因為代理本身需要儲存升級相關資料，而實作合約也預期使用代理的儲存空間。

官方ERC-1967 規格定義了這些代理儲存槽位慣例。

對加密貨幣使用者而言，ERC-1967 可讓可升級合約更容易檢查，因為許多工具可顯示目前實作地址。

對開發者而言，ERC-1967 提供更安全且標準化的代理中繼資料儲存方式。

ERC-7201 命名空間儲存

ERC-7201 是一個較新的智能合約命名空間儲存佈局標準。

命名空間儲存會將相關狀態變數歸入特定命名空間，以減少儲存佈局衝突，特別適用於複雜的可升級系統。

當合約使用繼承、模組、外掛程式或多個可升級元件時，這很有幫助。

OpenZeppelin Contracts 5.x 在其可升級版本中，使用包含 ERC-7201 風格儲存命名空間的可升級合約模式。

官方ERC-7201 規格說明一種在 Solidity 原始碼中記錄命名空間儲存位置的慣例。

對開發者而言，命名空間儲存可讓升級更容易推理，因為每個合約元件可保有自己的儲存區域。

對使用者而言，命名空間儲存大多不可見，但若正確實作，可提升安全性。

它無法取代稽核、測試和審慎的升級審查。

以初始化函式取代建構子

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

一般建構子只會在合約部署時執行一次，但在代理設計中，代理使用實作合約的程式碼時，不會為代理狀態執行實作合約的建構子。

因此，可升級合約通常將設定邏輯移至如

的函式中。

初始化函式會設定代幣名稱、代幣代號、所有者地址、管理員角色、費用參數或初始設定等值。

初始化函式必須受到保護，使其對每個代理只能執行一次。

若初始化函式可被呼叫超過一次，攻擊者可能重設所有權、變更權限或取得合約控制權。

OpenZeppelin 的撰寫可升級合約指南說明為何基於代理的可升級合約以初始化函式取代建構子。

當新版新增設定需求時，良好的可升級合約也會謹慎使用重新初始化函式。

每個初始化函式和重新初始化函式都應作為升級流程的一部分接受審查。

透明代理

透明代理是一種將管理員呼叫與使用者呼叫分開的代理設計。

在此模型中，管理員可執行升級相關操作，而一般使用者會被轉送至實作合約。

透明代理模式有助於避免管理員意外透過代理觸發實作函式的問題。

它也可降低代理管理員函式和實作函式之間發生函式選擇器衝突的風險。

此模式常見於正式生產系統，因為它為升級提供明確的管理員結構。

其代價是可能涉及額外的部署和管理元件，例如代理管理員合約。

對使用者而言，重點在於識別誰控制代理管理員，以及升級是否有延遲、受治理或受外部監控。

UUPS 代理

UUPS 是 Universal Upgradeable Proxy Standard 的縮寫。

在 UUPS 設計中，升級邏輯通常置於實作合約，而非完全由代理本身管理。

這可使代理更小且部署成本更低，但也代表實作合約必須正確包含並保護升級函式。

若升級授權邏輯有誤，合約可能容易遭受未授權升級。

若未來實作版本移除或破壞升級函式，代理可能變得難以或無法再次升級。

UUPS 代理很受歡迎，但需要審慎的存取控制和測試。

使用者應確認 UUPS 合約是否有明確的升級權限、時間鎖及公開的升級紀錄。

Beacon 代理

Beacon 代理是一種讓多個代理合約從共用 Beacon 合約讀取實作地址的設計。

透過變更儲存在 Beacon 中的實作地址，可同時升級多個代理實例。

當協議部署許多相似合約，例如金庫、資金池、帳戶或代幣化倉位時，Beacon 代理可能很實用。

主要優勢是營運效率，因為一次 Beacon 升級可更新許多代理。

主要風險是集中性，因為錯誤的 Beacon 升級可同時影響許多合約。

Beacon 所有權和升級權限應受到強健治理和監控保護。

Diamond 模式

Diamond 模式是一種升級架構，其中一個代理可將不同函式呼叫路由至不同實作合約，這些合約通常稱為 facets。

這可讓大型智能合約系統拆分為較小模組。

Diamond 設計可升級系統的一部分，而不必一次替換所有函式。

這對需要在單一地址下提供眾多功能的複雜加密貨幣協議很有用。

其代價是複雜性，因為開發者必須非常謹慎地管理函式選擇器、facet 儲存空間、存取控制和升級規則。

Diamond 類系統功能強大，但一般使用者可能比檢查較簡單的代理架構更難檢查它們。

可升級合約的優點

可升級合約的第一項優點是修正錯誤。

若發現嚴重問題，開發者可能可修補邏輯，而無須要求使用者手動遷移資金。

第二項優點是擴充功能。

協議可在保留相同合約地址的同時新增抵押品類型、獎勵規則、模組或安全控制機制。

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

升級後，錢包、分析平台、聚合器和其他智能合約可繼續指向相同代理地址。

第四項優點是使用者體驗。

使用者可能無須在每次協議更新時重新授權、提領、再次存入或手動移動倉位。

第五項優點是緊急應變。

治理良好的升級流程可協助協議比完整遷移流程更快因應即時風險。

可升級合約的風險

可升級合約最大的風險是管理員濫權。

若升級權限由脆弱私鑰、疏忽團隊或遭入侵的治理流程控制，合約可能被有害地變更。

惡意升級可能抽走資金、阻止提領、變更費用、修改餘額或移除使用者保護機制。

另一項主要風險是儲存空間損毀。

設計不佳的實作升級，可能破壞舊資料和新邏輯之間的關係。

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

使用者可能認為自己正在與單一合約互動，但實際行為取決於目前實作地址和升級權限。

第四項風險是監控不足。

若使用者和整合服務未追蹤升級，可能錯過協議行為的重要變更。

第五項風險是治理遭掌控。

若投票權集中，小型群體可能批准有利自身、卻損害其他使用者的升級。

使用者如何評估可升級合約

使用者應先確認合約是否為代理，以及目前使用哪一個實作合約。

當合約遵循 ERC-1967 等常見代理標準時，許多區塊鏈瀏覽器會顯示代理資訊。

使用者也應檢查誰有權限升級合約。

由單一外部擁有帳戶控制的升級，通常比由多重簽名、時間鎖或透明治理流程控制的升級風險更高。

使用者應檢視專案是否在升級前公告。

他們也應確認合約是否經稽核、稽核報告是否涵蓋升級邏輯，以及先前升級是否安全執行。

若存入大額資產，使用者應注意時間鎖期限、緊急暫停權限、管理員角色變更及升級事件歷史。

即使合約技術上撰寫良好，若升級權限過度集中或監控不足，仍可能具有風險。

開發者最佳實務

除非具備深厚安全經驗，否則開發者應使用經充分審查的升級框架，而非從頭撰寫代理邏輯。

他們應透過多重簽名所有權、基於角色的權限、時間鎖或鏈上治理等強健存取控制來保護升級函式。

他們應為初始部署和每條升級路徑撰寫自動化測試。

他們應在升級前後比較儲存佈局，以偵測不安全的變更。

他們應使用初始化保護，並避免未受保護的設定函式。

除非必要且經完整審查，否則應避免危險的低階模式。

他們應發布實作原始碼，並使代理關係易於檢查。

升級發生時，應發出明確事件，讓監控系統可偵測變更。

他們應記錄變更內容、變更原因及所考量的風險。

他們應規劃緊急應變，同時不賦予單一參與者無限制權力。

可升級合約與不可變更合約的比較

不可變更合約在部署後無法變更已部署程式碼。

這為使用者提供強大的可預測性，因為除非合約本身已包含可設定參數，否則規則是固定的。

可升級合約可透過既定升級機制變更其邏輯。

這為開發者提供彈性，但要求使用者信任升級流程。

不可變更合約通常適合簡單資產、極簡協議，或固定規則比未來彈性更重要的系統。

可升級合約通常適合可能需要修補、風險控制、整合和長期維護的複雜協議。

沒有任何一種設計永遠更好。

正確選擇取決於受保護的價值、應用程式複雜性、預期升級需求及治理強度。

為何可升級性影響代幣與協議風險

可升級合約可能直接影響代幣持有者，因為合約邏輯可能定義鑄幣、銷毀、轉帳限制、費用或治理權利。

若升級改變代幣規則，可能影響市場信心和代幣效用。

可升級質押合約可能影響獎勵率、鎖定期、懲罰和提領行為。

可升級借貸合約可能影響抵押率、強制平倉門檻、利率及市場風險控制。

可升級跨鏈橋可能影響資產託管、訊息驗證及提領邏輯。

因此，交易者和長期投資人應將升級權限視為協議基本面分析的一部分。

代幣在市場層面可能看似去中心化，但仍可能依賴可由小型群體升級的合約。

理解可升級性有助於使用者判斷協議規則是否真正固定，或仍可能變更。

常見誤解

常見誤解之一是，可升級合約代表原始合約程式碼會在鏈上被編輯。

在大多數代理設計中，原始代理程式碼不會被編輯，而是讓代理指向另一個實作合約。

另一個誤解是可升級性始終不好。

當可升級性具透明度、受到限制、經過稽核且負責任地治理時，可能相當實用。

第三個誤解是稽核可消除升級風險。

稽核可審查目前程式碼和升級流程，但未來實作版本仍可能引入新風險。

第四個誤解是使用者只需檢查代幣合約地址。

對可升級系統而言，使用者也應檢查實作合約、管理員角色及升級事件。

第五個誤解是去中心化會自動防止不良升級。

若投票權集中、參與度低或提案難以審查，治理仍可能失敗。

FAQ

加密貨幣中的可升級合約是什麼？

可升級合約是一種智能合約設計，允許協議在部署後變更邏輯，同時保留相同地址和儲存資料。

加密貨幣專案為何使用可升級合約？

加密貨幣專案使用可升級合約來修正錯誤、新增功能、改善安全控制、降低遷移成本，並維持長期整合。

可升級合約安全嗎？

當可升級合約使用強健存取控制、審慎的儲存管理、稽核、監控及透明治理時，可能具備安全性。

可升級合約的主要風險是什麼？

主要風險是獲授權升級者可能安裝有害或有缺陷的邏輯，進而改變協議行為或使使用者資金面臨風險。

什麼是代理合約？

代理合約是面向使用者的合約，負責儲存資料，並將呼叫轉送至包含目前邏輯的實作合約。

什麼是實作合約？

實作合約是邏輯合約，定義代理將呼叫委派給它時，函式應如何運作。

為何可升級合約使用初始化函式？

可升級合約使用初始化函式，是因為建構子邏輯不會以一般合約部署相同的方式初始化代理的儲存空間。

什麼是儲存衝突？

儲存衝突發生於新合約邏輯以與舊佈局衝突的方式讀取或寫入儲存槽位時。

什麼是 ERC-1967？

ERC-1967 是一項標準，為實作地址、管理員地址和 Beacon 地址等代理資訊定義儲存槽位。

什麼是 ERC-7201？

ERC-7201 是命名空間儲存佈局標準，有助於組織狀態變數，並減少複雜可升級合約的儲存衝突。

可升級合約之後可以變成不可變更嗎？

可以，部分專案可放棄或停用升級權限，但使用者應在鏈上驗證，而非僅依賴公告。

使用者如何確認合約是否可升級？

使用者可在區塊鏈瀏覽器檢查合約、尋找代理資訊、檢視實作地址，並確認管理員或治理權限。

結論

可升級合約是一種強大的智能合約設計，讓加密貨幣協議能在保留地址、狀態和餘額的同時改善邏輯。

最常見的設計使用代理合約儲存資料，並將執行委派給可替換的實作合約。

此模型可讓錯誤修正、功能升級和長期協議維護更容易進行。

若升級權限集中、儲存佈局處理不當或治理薄弱，也可能帶來嚴重風險。

ERC-1967 代理儲存槽位、ERC-7201 命名空間儲存、初始化函式、稽核、時間鎖及透明管理員控制等重要標準與實務，可降低這些風險。

對加密貨幣使用者而言，可升級性應始終是風險分析的一部分，因為它決定協議規則是固定的，還是仍可能改變。

對開發者而言，可升級合約應被視為安全關鍵基礎設施，從首次部署起便需要審慎設計、測試、監控和治理。