智能合約可升級性

什麼是智能合約可升級性？

智能合約可升級性是指已部署的智能合約系統在首次部署後，變更、替換、擴充或重新導向其邏輯的能力。

在加密貨幣領域，可升級性之所以被使用，是因為許多智能合約管理真實資產，團隊可能需要在上線後修正漏洞、改善功能、更新整合或因應安全問題。

官方 Ethereum 智能合約升級文件說明，智能合約通常被視為不可變更，但開發者可在需要未來變更時使用升級模式。

基本的已部署智能合約通常會永久保留相同程式碼，除非它在設計時已納入升級機制。

可升級智能合約系統會分離使用者面向地址、儲存狀態及業務邏輯，使新邏輯得以導入，而不必要求使用者手動遷移。

最常見的可升級性模型使用使用者互動的代理合約，以及包含目前邏輯的實作合約。

實作合約變更時，代理地址可維持不變，但其背後的程式碼會改變。

這對使用者很有用，因為餘額、權限及整合可能持續指向同一地址。

這也有風險，因為擁有升級權限的人員或治理系統，可能在使用者存入資金後變更合約行為。

簡單來說，智能合約可升級性是指將鏈上軟體設計為可在之後更新邏輯，同時保留重要狀態、地址連續性及使用者存取權。

為什麼智能合約可升級性很重要

智能合約可升級性很重要，因為已部署的區塊鏈程式碼可控制代幣、金庫、借貸市場、質押系統、跨鏈橋、NFT 或治理權利。

不可變更程式碼中的漏洞可能鎖定資產、破壞使用者功能或使資金暴露於攻擊者。

可升級性讓開發者能在部署後修補關鍵問題及改善協議。

OpenZeppelin 智能合約升級指南說明，可升級部署可在保留地址、狀態及餘額的同時修改合約程式碼。

這種保留很重要，因為使用者、錢包、分析工具及其他協議可能已依賴原始合約地址。

若沒有可升級性，團隊可能需要部署新合約，並要求使用者手動遷移資金或授權。

遷移可能緩慢、有風險、成本高且令人困惑。

不過，可升級性也改變了智能合約的信任模型。

可升級的合約，與沒有升級機制的合約相比，並非以同樣方式完全不可變更。

使用者應始終詢問誰可升級合約、如何核准升級、升級可多快發生，以及重大變更生效前使用者是否可退出。

智能合約可升級性如何運作

智能合約可升級性通常透過將儲存空間與邏輯分離來實現。

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

實作合約包含定義各項功能行為的邏輯。

使用者呼叫代理時，代理會將呼叫轉送至目前的實作合約。

在 Ethereum 類型系統中，這種轉送通常使用 delegatecall，它會在代理的儲存空間情境中執行實作邏輯。

這表示實作程式碼可讀寫代理儲存空間，如同該儲存空間屬於實作合約。

協議升級時，授權帳戶或治理流程會變更代理儲存的實作地址。

變更後，未來呼叫將導向新的實作邏輯。

舊儲存狀態可維持不變，因此只要儲存空間配置相容，使用者餘額及協議狀態即可延續。

此設計功能強大，但需要對儲存空間配置、初始化、授權、審計及升級治理訂定嚴格規則。

代理合約

代理合約是在許多可升級系統中，供使用者及其他合約互動的穩定合約地址。

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

OpenZeppelin 代理升級模式文件將非結構化儲存空間代理模式描述為可升級合約的基本建構模組。

代理很有用，因為使用者不必在每次邏輯升級時變更合約地址。

應用程式、錢包、儀表板及 DeFi 整合可繼續使用同一代理地址。

代理模式也帶來複雜性，因為使用者可能看到一個合約地址，但實際邏輯位於另一個地址。

區塊鏈瀏覽器在可偵測該模式時，通常會顯示代理資訊及實作地址。

檢閱可升級合約時，使用者應同時檢查代理及實作合約。

代理不會自動安全，因為安全性取決於升級控制、儲存空間相容性及實作程式碼品質。

代理是入口，而實作合約是入口背後的邏輯。

實作合約

實作合約是包含代理所使用業務邏輯的合約。

它可能定義轉帳、存入資產、提領、借貸、投票、鑄造、銷毀、暫停、強制平倉或其他協議操作的功能。

在基於代理的系統中，使用者通常不會直接與實作地址互動。

相反地，使用者會與代理互動，由代理將執行委派給實作合約。

升級通常是指變更代理，使其指向新的實作合約。

新實作合約應與舊儲存空間配置及使用者預期相容。

危險的實作升級可能加入惡意邏輯、破壞帳務處理、變更權限或阻止提領。

因此，實作程式碼應在執行升級前完成驗證、審計、測試及檢閱。

使用者不應只因代理地址未變，就假設協議會永遠維持相同。

在可升級系統中，實作地址是安全性的重要部分。

Delegatecall

Delegatecall 是低階 EVM 機制，可讓一個合約執行另一個合約的程式碼，同時使用呼叫者的儲存空間情境。

在代理可升級性中，delegatecall 讓代理使用實作邏輯，同時將狀態保留在代理地址。

因此，新實作合約可改變行為，而不必從代理移動使用者餘額。

Delegatecall 很強大，因為它將程式碼與狀態分離。

它也有風險，因為實作合約必須假設自己正在寫入代理儲存空間，而非其自身儲存空間。

若實作合約使用與預期不同的儲存空間配置，變數可能衝突或破壞狀態。

錯誤的 delegatecall 設計可能覆寫所有權變數、餘額、映射或設定值。

除非完全了解儲存空間及 EVM 執行方式，否則開發者應避免自行撰寫自訂代理 delegatecall 邏輯。

使用者不必了解每個 opcode，但應知道可升級代理依賴技術性的間接轉送。

Delegatecall 是可升級合約需要專門審計的原因之一。

儲存空間配置

儲存空間配置是智能合約儲存空間中變數的順序及位置。

官方 Solidity 儲存空間配置文件說明狀態變數如何在儲存空間中配置，以及配置規則對合約及函式庫為何重要。

儲存空間配置是最重要的可升級性風險之一。

若新實作合約錯誤變更既有變數的順序、類型或結構，代理可能以新的錯誤方式解讀舊儲存資料。

例如，餘額映射可能被位移、擁有者地址可能遭覆寫，或設定變數可能被讀取為不同類型。

這稱為儲存衝突或儲存損壞風險。

開發者通常會在既有變數之後新增變數，而非插入中間。

他們也會避免在未仔細規劃遷移的情況下，變更變數類型或繼承順序。

現代升級工具可在允許升級前比較儲存空間配置。

使用者應將儲存空間配置安全視為可升級合約安全性的核心部分。

ERC-1967 代理儲存槽

ERC-1967 是定義實作地址、管理員地址及 beacon 地址等代理資訊特定儲存槽的標準。

官方 ERC-1967 標準定義標準代理儲存槽，讓工具及瀏覽器更可靠地識別代理設定。

這些標準化儲存槽可降低代理管理變數與應用程式儲存變數衝突的機率。

ERC-1967 也有助於區塊鏈瀏覽器向使用者顯示代理目前使用哪個實作合約。

許多現代代理系統依賴與 ERC-1967 相容的儲存槽。

此標準本身不會使升級安全。

它主要提供可預期的位置來儲存代理中繼資料。

開發者仍需要正確授權、儲存空間配置驗證、實作檢閱及安全的升級執行。

檢閱可升級合約的使用者，應確認代理是否遵循已知標準，而不是未知的自訂模式。

標準化代理儲存空間可改善透明度，但只是智能合約可升級性安全的一部分。

透明代理模式

透明代理模式會區分管理員呼叫與使用者呼叫，以降低代理函式與實作函式之間的函式選擇器混淆。

OpenZeppelin 代理文件說明，TransparentUpgradeableProxy 具有內建的管理員及升級介面。

在此模式中，一般使用者會透過代理與實作函式互動。

代理管理員負責執行升級操作，不應以使用者相同的方式，意外透過代理呼叫實作函式。

此設計有助於避免代理函式及實作函式共享相同選擇器時產生衝突。

透明代理廣泛使用，因為它提供清楚的管理員模型。

不過，它仍需要安全管理管理員金鑰。

若代理管理員由一把暴露的金鑰控制，整個協議可能面臨風險。

透明代理在搭配多重簽章控制、時間鎖、審計及清楚治理時可更安全。

此模式降低一項技術風險，但不會消除治理風險。

UUPS 代理模式

UUPS 是 Universal Upgradeable Proxy Standard 的縮寫。

官方 EIP-1822 標準說明一種通用可升級代理模式，其升級邏輯與實作設計連結。

OpenZeppelin 文件說明，UUPSUpgradeable 將升級機制置於實作合約中，而不是採用透明代理相同的內建代理管理員結構。

UUPS 代理可比透明代理更精簡，因為代理本身可以更簡單。

但實作合約必須正確納入並保護升級函式。

不良的 UUPS 實作可能意外移除升級能力、暴露升級權限或允許未經授權的升級。

開發者也必須防止升級至會破壞升級路徑的實作合約。

若搭配成熟函式庫及驗證工具，UUPS 可兼具效率及彈性。

在不了解授權及升級安全檢查的情況下，不應盲目複製使用。

使用者應檢查誰控制 UUPS 升級，以及過去升級是否透明且經過審計。

Beacon 代理模式

Beacon 代理模式使用儲存多個代理實作地址的 beacon 合約。

每個代理不會各自儲存實作地址，而是從 beacon 讀取實作地址。

這使許多代理實例可藉由更新一個 beacon 同時升級。

Beacon 代理適用於部署許多類似合約的系統，例如金庫、流動性池、帳戶或使用者特定合約實例。

當許多實例需要相同升級時，它可降低營運複雜性。

它也可能增加影響範圍，因為不良的 beacon 升級可同時影響許多代理。

OpenZeppelin 代理文件將 BeaconProxy 與 UpgradeableBeacon 列為代理相關元件。

Beacon 權限必須受到仔細保護，因為它可能控制許多合約的邏輯。

使用者應檢查其使用的合約是否依賴 beacon，以及誰可更新該 beacon。

Beacon 對開發者很方便，但會將升級權力集中於共享控制點。

Diamond 代理模式

Diamond 代理模式讓一個類似代理的合約將函式呼叫路由至多個稱為 facets 的實作合約。

官方 EIP-2535 Diamond Standard定義模組化智能合約系統，函式可透過 facets 新增、替換或移除。

Diamond 適合可能超出合約大小限制，或需要模組化升級的大型系統。

Diamond 可將複雜邏輯整理至許多獨立 facets，同時維持一個主要地址。

此彈性可用於大型 DeFi 系統、遊戲、帳戶系統或協議框架。

它也增加複雜性，因為使用者及審計人員必須了解 facet 路由、選擇器表、儲存模式及升級權限。

Diamond 升級可只替換系統的一部分，因此追蹤變更很重要。

儲存設計尤其重要，因為多個 facet 可能共用同一儲存空間。

在適當時，開發者應使用清楚的 diamond storage 或命名空間儲存模式。

使用者應將 Diamond 合約視為需要仔細檢閱的進階可升級系統。

命名空間儲存

命名空間儲存是一種整理合約儲存空間的方法，讓不同模組使用定義好的儲存位置，以降低衝突風險。

官方 ERC-7201 Namespaced Storage Layout 標準定義一項慣例，用於在 Solidity 原始碼中記錄命名空間儲存的儲存位置。

命名空間儲存適用於可升級及模組化合約，因為它減少對長繼承鏈中單一簡單變數順序的依賴。

當合約由多個模組建立時，它可使升級更安全。

在編譯器及框架支援可用時，它也可協助工具更清楚驗證儲存變更。

OpenZeppelin 撰寫可升級合約指南指出，其升級外掛程式需要 Solidity 0.8.20 或更高版本，才能使用所需的編譯器資訊驗證命名空間儲存配置。

命名空間儲存不會消除審計的必要性。

它可協助架構化狀態，使未來變更更容易管理。

若開發者選擇此架構，應一致地使用命名空間儲存。

使用者可間接受益，因為更安全的儲存設計可降低升級相關狀態損壞的機率。

初始化函式

初始化函式是可升級合約用來取代建構函式的特殊設定函式。

在一般合約中，建構函式會在合約部署時執行。

在代理系統中，使用者與代理互動，而實作合約的建構函式無法以一般方式初始化代理儲存空間。

因此，可升級實作通常使用初始化函式設定擁有者、代幣名稱、權限、設定值及其他初始狀態。

除非使用為後續升級仔細設計的重新初始化函式，否則初始化函式只能執行一次。

若初始化函式未受保護，攻擊者可能初始化合約並取得重要角色控制權。

若新實作合約需要新的狀態變數，可能需要重新初始化函式以安全設定它們。

開發者必須保護初始化函式，並在適當時停用獨立實作合約的初始化功能。

當可升級合約的初始化歷程不明確時，使用者應保持警覺。

初始化錯誤是可升級合約漏洞的主要來源。

升級權限

升級權限是可核准升級的帳戶、合約、多重簽章錢包、時間鎖、DAO 或治理系統。

升級權限是可升級合約最重要的信任假設之一。

若一把私鑰控制升級，該金鑰可能可以替換協議邏輯。

若多重簽章錢包控制升級，使用者必須信任簽署者群組及其營運安全性。

若 DAO 控制升級，使用者必須了解投票權、法定人數、提案延遲、執行延遲及治理攻擊風險。

若時間鎖控制升級，使用者可能有時間在變更生效前檢閱及退出。

安全的升級流程通常結合多重簽章執行、時間鎖延遲、公開提案揭露、審計檢閱及監控。

升級權限應可見且有文件記錄。

若小型群組可立即變更可升級合約，使用者不應將其視為無需信任。

在可升級系統中，治理設計就是安全設計。

時間鎖

時間鎖會在升級提案或核准後延遲執行。

此延遲讓使用者、審計人員、研究人員及監控系統有時間檢閱即將進行的變更。

時間鎖可降低突發升級立即改變合約行為的風險。

若使用者不同意升級，它也可讓使用者有時間提領資金。

不過，時間鎖並不完美，因為在活躍攻擊期間，緊急修復可能需要速度。

部分系統使用較短的緊急路徑及較長的一般治理路徑。

緊急路徑可保護使用者免受攻擊利用，但也可能產生中心化風險。

好的協議會清楚說明其時間鎖規則。

使用者應檢查升級是延遲、立即，還是由緊急權力控制。

時間鎖的價值在於將升級權限從即時權力轉化為可見的延遲權力。

治理控制的升級

治理控制的升級使用代幣投票、委託投票、委員會核准、DAO 提案或類似系統來核准實作變更。

這可能比單一管理員金鑰更去中心化。

它也可能使升級較慢且更複雜。

治理安全取決於投票者分布、法定人數規則、提案門檻、投票延遲、執行延遲、委託，以及抵抗買票或閃電貸治理攻擊的能力。

治理投票不會自動代表變更在技術上安全。

投票者可能核准自己未完全理解的程式碼。

惡意提案可能在大型升級套件中隱藏危險邏輯。

協議應在投票前發布清楚的升級差異、審計、模擬結果及淺白說明。

使用者在將資產存入協議前，應檢閱治理升級流程。

治理可分散權力，但不會消除技術安全檢閱的必要性。

不可變更合約與可升級合約

不可變更智能合約在部署後無法變更，除非其設計中包含外部控制或遷移路徑。

可升級智能合約可透過定義的升級機制變更其邏輯。

不可變更合約通常較容易理解，因為已部署程式碼保持固定。

但若發現嚴重漏洞且沒有安全修復方式，它們也可能有風險。

可升級合約可以修正漏洞並新增功能。

它也可能引入信任風險，因為未來邏輯可能與使用者最初檢閱的程式碼不同。

沒有哪種模型一定更好。

若規則永遠不應變更，簡單代幣合約可能偏好不可變更性。

複雜的 DeFi 協議可能需要可升級性，以進行安全修補及因應變動市場條件。

適合的設計取決於風險、複雜性、治理成熟度及使用者預期。

遷移與可升級性的差異

遷移是部署新合約，並將使用者、資產或整合從舊合約移至新合約。

可升級性是指在保留狀態或使用者面向連續性的同時，變更既有地址或系統背後的邏輯。

遷移可能較容易理解，因為舊合約保持不變，而新合約獨立存在。

遷移也可能造成困擾，因為使用者可能需核准轉帳、移動倉位、領取新代幣或更新整合。

可升級性可帶來更流暢的使用者體驗，因為同一地址保持有效。

可升級性也可能將重大變更隱藏在同一地址後方。

部分協議會依變更嚴重程度同時使用兩種方式。

小型漏洞修復可能使用升級，重大重新設計則可能使用遷移。

使用者應了解協議是否能原地變更，或是否需要手動遷移。

遷移風險與升級風險不同，但兩者都需要仔細溝通。

原始碼驗證

原始碼驗證有助於使用者將發布的原始碼與已部署位元組碼比對。

官方 Ethereum 智能合約驗證文件說明，驗證會比較智能合約原始碼與編譯後位元組碼。

對可升級合約，使用者應在可行時同時驗證代理及目前實作合約。

僅驗證代理未必能顯示完整業務邏輯。

已驗證的實作合約可協助使用者閱讀目前邏輯，但仍應檢查升級權限。

協議升級時，新實作合約也應完成驗證。

使用者不應因先前實作合約曾接受審計，就假設合約仍然安全。

升級可新增函式、變更權限、修改帳務處理或引入新漏洞。

驗證是透明度措施，而非完整安全保證。

可升級系統需要在每次升級後持續驗證。

儲存空間預留槽

儲存空間預留槽是在可升級合約中保留的未使用儲存槽，使未來版本可新增變數，而不會意外位移子合約儲存空間。

此模式常見於大量使用繼承的可升級合約。

儲存空間預留槽可能以保留給未來變數的固定大小未使用陣列呈現。

未來升級新增狀態變數時，開發者可相應縮小預留槽大小。

儲存空間預留槽很有用，但需要自律。

錯誤使用預留槽仍可能造成儲存空間配置問題。

命名空間儲存是一種較新的方法，可在某些架構中降低對大型儲存空間預留槽的依賴。

開發者應遵循升級框架及編譯器工具的指南。

審計人員應在每次升級時檢閱儲存空間預留槽及配置變更。

使用者不需要管理儲存空間預留槽，但在開發者正確使用時可從中受益。

升級測試

升級測試會檢查新實作合約是否可與既有代理狀態正確運作。

一般單元測試不足夠，因為它們可能部署具有乾淨儲存空間的全新合約。

升級測試應模擬舊版本、填入真實狀態、執行升級，接著針對既有狀態測試新版本。

測試應檢查餘額、權限、帳務處理、代幣授權、角色指派、預言機設定、暫停邏輯及使用者倉位。

測試也應確認未經授權的使用者無法升級合約。

在適當時，分叉測試可協助模擬針對真實鏈上狀態的升級。

儲存空間配置驗證工具可在部署前偵測許多不安全變更。

測試覆蓋範圍應包括成功路徑及失敗路徑。

每次升級都應視為帶有額外遷移風險的新部署。

未經嚴謹測試便升級的協議，會使使用者暴露於可避免的危險。

升級審計

升級審計會檢閱新實作合約、儲存變更、初始化或重新初始化邏輯、存取控制及治理執行路徑。

升級審計應比較舊版本與新版本。

目標不僅是檢查新程式碼，也要了解新程式碼如何影響既有狀態及使用者。

審計人員應檢閱儲存空間配置、外部呼叫、權限、升級授權、緊急控制、事件及與整合的相容性。

他們也應檢閱升級是否會對呼叫合約的應用程式造成 ABI 破壞性變更。

審計不保證安全，但可降低風險。

大型協議在升級影響使用者資金時，應發布審計報告或摘要。

小型升級若涉及帳務處理、權限、提領或預言機邏輯，仍可能危險。

使用者在信任重大實作升級前，應檢查其是否已完成審計。

升級審計是防範隱藏回歸問題的核心防線。

ABI 相容性

ABI 相容性是指外部應用程式在升級後，仍可如預期呼叫合約。

ABI 定義錢包及應用程式使用的函式名稱、輸入、輸出、事件及錯誤。

若升級移除函式、變更回傳類型、改變事件行為，或變更整合方所依賴的假設，可能破壞相容性。

破壞 ABI 的變更可能導致前端 App、機器人、會計系統或 DeFi 整合失效。

即使儲存空間安全，若介面未經協調即變更，使用者體驗仍可能中斷。

開發者應在升級前清楚記錄 ABI 變更。

整合方應監控其依賴協議的實作升級。

若應用程式未針對新實作合約更新，使用者可能看到失敗交易。

ABI 相容性是升級安全的一部分，因為智能合約存在於更廣泛的生態系統中。

技術上有效的升級若不慎變更介面，仍可能破壞真實使用者的使用情境。

管理員金鑰風險

管理員金鑰風險是控制升級的金鑰或帳戶遭竊、濫用、遺失，或由不可信方控制的風險。

若攻擊者取得升級權限，他們可能部署惡意邏輯來掏空資金或變更餘額。

若管理員金鑰遺失，團隊可能無法修補未來漏洞。

若一人控制管理員金鑰，使用者必須信任此人不會惡意或疏忽行事。

多重簽章錢包可透過要求多項核准降低單一金鑰風險。

時間鎖可透過增加延遲，降低突發升級風險。

DAO 治理可分散升級權力，但也會引入治理攻擊風險。

協議應揭露誰控制升級，以及金鑰如何受到保護。

使用者應將隱藏或不清楚的管理員控制視為重要警訊。

在可升級合約中，管理員安全通常與程式碼安全同等重要。

緊急升級

緊急升級是用於修正關鍵漏洞或阻止活躍攻擊的快速升級。

當等待完整治理週期過於緩慢時，它可保護使用者資金。

緊急升級也可能產生中心化風險，因為它可能繞過一般檢閱、投票或時間鎖延遲。

協議應在緊急事件發生前定義緊急權力。

緊急控制應範圍有限、有文件記錄、可受監控，並由可信流程治理。

緊急升級後，團隊應發布關於變更內容及原因的清楚資訊。

使用者應了解協議是否具有緊急升級權利。

沒有緊急路徑的協議，對攻擊利用的反應可能較慢。

具備無限制緊急權力的協議可能需要使用者投入過多信任。

最佳設計會在快速保護與透明度、問責性之間取得平衡。

可升級代幣

可升級代幣是指部署後邏輯仍可變更的代幣合約。

這可支援漏洞修正、合規變更、新手續費模型、跨鏈變更或功能更新。

它也可能允許危險變更，例如新增鑄造權限、轉帳限制、黑名單或意外費用。

使用者不應在未檢查代幣合約是否可升級前，假設其規則固定。

即使名稱、代號及地址維持相同，具有升級權限的代幣仍可能變更行為。

代幣持有者應檢閱管理員角色、鑄造權限、暫停控制、黑名單函式及升級治理。

重大升級後應檢查已驗證原始碼。

流動性提供者應特別謹慎，因為代幣規則變更可能影響交易池。

可升級代幣可能合法，但其信任模型不同於不可變更代幣。

應向使用者清楚揭露代幣可升級性。

可升級 DeFi 協議

可升級 DeFi 協議可變更借貸、交換、質押、強制平倉、金庫策略、利率或抵押品規則的邏輯。

這種彈性可能有用，因為 DeFi 市場變化快速，且漏洞可能十分嚴重。

它也可能帶來風險，因為使用者存入資金後，協議規則可能改變。

升級可能改變提領邏輯、費用計算、風險參數、預言機來源或強制平倉行為。

使用者應檢查 DeFi 協議升級是由團隊、多重簽章錢包、時間鎖或治理流程控制。

他們也應檢查關鍵合約是不可變更還是可升級。

協議可能同時包含部分不可變更合約及部分可升級合約。

DeFi 升級風險尤其重要，因為合約通常持有集中流動性。

一次不良升級可能同時影響許多使用者。

可升級 DeFi 需要持續監控，而非一次性信任。

可升級性與預言機

預言機為智能合約提供資產價格等外部資料。

可升級協議可能可以變更預言機邏輯或預言機地址。

官方 Ethereum 預言機文件說明，預言機很有必要，因為智能合約無法自行直接存取鏈下資料。

當舊價格來源不再可靠或出現更佳來源時，預言機可升級性可能有用。

若管理員可切換至受操縱或惡意預言機，它也可能危險。

在借貸及衍生品系統中，不良預言機升級可能造成不公平的強制平倉或錯誤結算。

使用者應檢查誰可變更預言機來源，以及這些變更是否受時間鎖控制。

開發者應採用穩健的預言機治理及監控。

預言機變更應視為高風險升級。

即使資料來源位於主要合約程式碼之外，它們仍是智能合約邏輯的一部分。

可升級性與跨鏈橋

跨鏈橋通常使用可升級合約，因為跨鏈橋邏輯必須因應新鏈、訊息格式、驗證者集合、風險控制及安全修補。

跨鏈橋可升級性可改善適應能力。

它也可能產生重大信任風險，因為跨鏈橋可能控制大量鎖定或鑄造資產。

惡意跨鏈橋升級可能變更提領規則、不當鑄造包裝資產或重新導向資金。

使用者應檢查跨鏈橋升級權限、驗證者治理、時間鎖、審計及緊急控制。

跨鏈橋本已很複雜，因為它依賴多個網路及驗證假設。

可升級性又增加了一層風險。

具備強大升級治理的跨鏈橋合約可能比由單一金鑰控制的合約更安全。

不過，沒有任何升級流程可消除所有跨鏈橋風險。

跨鏈橋使用者在轉移資產前，應了解技術及治理假設。

可升級性與使用者信任

可升級性帶來信任權衡。

使用者可受益於漏洞修正及功能改善。

使用者也承擔未來邏輯可能以自己不喜歡的方式改變的風險。

透明的升級流程可透過在變更前展示變更內容來提升信任。

隱藏或即時的升級流程可能降低信任，因為使用者無法及時評估變更。

協議應以淺白語言說明升級權利。

它們應發布實作地址、管理員地址、時間鎖詳細資訊、審計報告及治理提案。

使用者不應只詢問合約是否已審計。

他們應詢問已審計的程式碼明天是否可能被替換。

在可升級智能合約中，信任取決於目前程式碼及未來變更控制。

如何檢查合約是否可升級

先查看區塊鏈瀏覽器上的合約頁面，確認是否被標示為代理。

若瀏覽器顯示實作地址，接著檢查該地址。

檢閱代理是否採用 ERC-1967、Transparent Proxy、UUPS、Beacon Proxy 或 Diamond 等已知模式。

檢查實作原始碼是否已驗證。

透過管理員地址、擁有者角色、多重簽章錢包、時間鎖或治理合約，檢查誰控制升級。

檢閱最近是否有實作變更或升級交易事件。

閱讀協議文件以了解升級政策。

檢查審計報告，確認可升級性是否包含在審計範圍內。

若協議採用 DAO 控制的升級，請監控治理提案。

只看合約地址並不足夠，因為可升級系統需要一併檢閱代理、實作合約及權限結構。

智能合約可升級性的常見錯誤

常見錯誤之一，是在升級時變更儲存變數順序。

另一項錯誤是忘記保護初始化函式。

第三項錯誤是僅使用一把私鑰作為升級管理員。

第四項錯誤是未使用時間鎖或未發布公告便進行升級。

第五項錯誤是部署新實作合約但未驗證原始碼。

第六項錯誤是假設舊審計仍涵蓋新實作合約。

第七項錯誤是以破壞整合的方式變更 ABI。

第八項錯誤是未針對既有類生產狀態測試升級。

第九項錯誤是在未深入檢閱下使用自訂代理邏輯。

第十項錯誤是當小型管理員群組可立即替換邏輯時，卻告訴使用者系統已去中心化。

智能合約可升級性的優點

第一項優點是可在部署後修正漏洞。

第二項優點是可新增功能，而不必要求使用者手動遷移。

第三項優點是為使用者、錢包及整合保留地址連續性。

第四項優點是提升緊急情況下的應變能力。

第五項優點是提高複雜協議的長期可維護性。

第六項優點是在快速變動的加密貨幣市場中，更順暢地迭代產品。

第七項優點是可更新預言機整合、風險參數或外部相依項目。

第八項優點是在協議設計演進時減少遷移摩擦。

這些優點說明許多成熟的加密貨幣應用程式為何選擇可升級架構。

當升級權限透明、安全、有延遲、經過審計且受到負責任治理時，這些優點最為顯著。

智能合約可升級性的風險與限制

第一項風險是惡意或已遭入侵的升級權限。

第二項風險是在不安全的實作變更期間發生儲存損壞。

第三項風險是初始化或重新初始化函式遭濫用。

第四項風險是透過管理員金鑰形成隱藏的中心化。

第五項風險是 ABI 或行為變更導致整合失效。

第六項風險是使用者可能感到困惑，因為可見地址可能保持相同，但邏輯已改變。

第七項風險是緊急升級遭濫用。

第八項風險是僅涵蓋舊實作合約的審計帶來錯誤信心。

第九項風險是治理遭控制或倉促投票。

第十項風險是複雜性使系統更難讓使用者及審計人員理解。

開發者最佳實務

在可行時，使用成熟且經充分檢閱的升級函式庫，而非自訂代理程式碼。

僅在了解其權衡後，選擇 Transparent Proxy、UUPS、Beacon Proxy 或 Diamond 等明確升級模式。

每次升級前驗證儲存空間配置。

仔細保護初始化函式及重新初始化函式。

對重要升級權限使用多重簽章控制、時間鎖及治理流程。

發布實作地址、升級交易及淺白的升級說明。

驗證每個新實作合約的原始碼。

在適當時，針對類生產狀態及分叉環境執行升級測試。

執行前審計重大升級。

監控升級事件，並在架構允許時準備回復或事件應變計畫。

使用者最佳實務

存入資金前，檢查合約是否可升級。

檢閱誰控制升級權限。

優先選擇升級時採用時間鎖、多重簽章控制、審計及公開治理的協議。

檢查目前實作合約的原始碼是否已驗證。

不要假設舊審計涵蓋新實作合約。

若您大量使用協議，請監控重大協議升級公告。

了解緊急升級是否可繞過一般延遲。

檢閱管理員角色、暫停控制、預言機控制及代幣鑄造權限。

在可行時，考慮於具爭議或不清楚的升級前提領資金。

將可升級性視為信任假設，而非次要技術細節。

FAQ

Smart Contract Upgradeability 是什麼意思？

Smart Contract Upgradeability 是指已部署智能合約系統可透過預先設計的升級機制，在部署後變更其邏輯。

為什麼智能合約需要升級？

智能合約會為修正漏洞、新增功能、改善安全性、更新整合、調整風險控制或因應協議需求變化而升級。

可升級智能合約的安全性較低嗎？

可升級智能合約不會自動更不安全，但它增加了管理員控制、儲存空間配置、治理及未來實作變更相關風險。

什麼是代理合約？

代理合約是通常保留系統狀態的穩定地址，會將呼叫轉送至實作合約。

什麼是實作合約？

實作合約包含代理透過委派方式執行的邏輯。

智能合約升級最大的風險是什麼？

最大風險是獲授權或已遭入侵的升級權限，可能以錯誤或惡意邏輯取代安全邏輯。

什麼是儲存空間配置風險？

儲存空間配置風險是新實作合約錯誤讀取或寫入既有代理儲存空間，並破壞重要狀態的可能性。

可升級性中的時間鎖是什麼？

時間鎖會延遲升級執行，讓使用者及檢閱人員能在變更生效前檢查提議的變更。

已驗證原始碼代表可升級合約安全嗎？

不代表。已驗證原始碼可提升透明度，但使用者仍必須檢閱升級權限、審計、儲存安全、治理及未來變更風險。

如何判斷合約是否可升級？

您可以檢查區塊鏈瀏覽器的代理標籤、實作地址、ERC-1967 儲存槽、升級事件、管理員角色、治理文件及審計報告。

結論

智能合約可升級性是一種設計方法，使區塊鏈應用程式可在部署後變更合約邏輯，同時保留重要地址及狀態。

它被廣泛使用，因為加密貨幣應用程式上線後通常仍需要漏洞修正、功能改善、安全修補及整合更新。

最常見的可升級性設計使用代理、實作合約、delegatecall、標準化儲存槽及受控的升級權限。

可升級性可讓協議更容易維護且更具韌性，但也改變信任模型，因為未來程式碼可能與使用者最初檢閱的程式碼不同。

可升級系統的安全性取決於儲存空間配置紀律、初始化保護、原始碼驗證、測試、審計、管理員金鑰安全、時間鎖及透明治理。

除非升級權限已被移除，或設計上已無法執行升級，否則使用者絕不可將可升級合約視為完全不可變更。

開發者絕不可將可升級性視為簡單捷徑，因為此模式增加嚴重的工程及治理責任。

對新手而言，智能合約可升級性最好理解為一種在部署後更新區塊鏈軟體的方式。

對進階使用者而言，它是一個完整安全模型，涉及代理架構、儲存相容性、存取控制、治理執行、監控及使用者退出權利。

在加密貨幣詞彙表的脈絡中，Smart Contract Upgradeability 是指已部署智能合約系統可透過受控機制變更其邏輯，同時保留重要鏈上狀態及使用者面向地址的能力。

重點是，智能合約可升級性可保護使用者免受永久性漏洞影響並支持協議演進，但由於升級權力也可能成為重大風險來源，因此必須以透明度、強大控制、審慎測試及清楚揭露來處理。