對任何智能合約（尤其是持有/管理大量通證的合約）來講，可升級性流程及其治理都是重要的一個方面。該流程定義了誰能夠以及如何通過上傳一套新版本的合約執行代碼來改變智能合約的行為，顯然，可升級性流程本身也是可以不斷加以調整和“升級”的，
本文旨在介紹智能合約可升級性模式，將其與彩虹橋架構進行匹配，并提出對這些升級進行治理等改進的階段性計劃。我們會在這里對提出的計劃進行討論，并根據社區和驗證節點的評論加以調整并確定最終方案。當前我們需要對主要方案達成一致，具體細節則可以以后慢慢調整。 我們會在2021年3月16日（星期二）結束討論，形成對可升級性計劃的最終決定。我們會根據用戶的反饋對介紹提議的原始文章不斷更新。
為什么這很重要
只要人們有辦法對合約代碼進行更改，那么即便是已經經過審計和廣泛測試的合約，仍然會由于版本的更新而出現嚴重漏洞，并最終給該合約持有的通證帶來損失。這對彩虹橋合約是至關重要的。彩虹橋合約需要跟鎖定通證打交道，對橋接的通證的鑄造和銷毀擁有全部控制權。這也是為什么所有的升級都應該接受全面測試和驗證，尤其是在項目晚期階段更應如此。 然而，安全方面有利有弊。在理想狀態下，合約代碼沒有缺陷，所以不需要快速的或隱性的升級以修補關鍵漏洞（有關此類升級的影響，可參見‘以太坊是一片黑森林’以及‘逃離黑森林’這兩篇文章）。在這種情況下，我們可以分階段升級并聯合多方代表就升級進行投票（時間周期往往很長），對此類方法的使用已有先例，比如比特幣協議升級就是采用的這類方法。不過遺憾的是，投票周期可能會持續數月之久，
文章一：https://twitter.com/ilblackdragon/status/1367408735837188096
文章二：https://samczsun.com/escaping-the-dark-forest/
現實中的合約是存在漏洞的，尤其是在早期階段，這種情況尤為明顯。因此當通證存在風險的時候，能夠快速升級以解決此類問題，將升級時間縮至最短就變得很有必要。這樣就把分階段升級和投票的方法排除在外，因為黑客將能夠分析升級代碼，找到真正的漏洞所在并加以利用。然而，如果開發者未對升級進行充分測試，或者故意實施某些惡意行為，被鎖定的通證仍然可能失竊， 不存在一體適用的解決方案：全部方案都有各種權衡，因為彩虹橋是NEAR生態中很重要的一部分，包括不打算使用彩虹橋的用戶在內的每個人都應該知道彩虹橋的治理方式和升級方式。
問題范圍
“彩虹橋架構第二版”增加了這一問題的復雜性，以下是關于彩虹橋架構的幾個不同方面：
1. NEAR區塊鏈
- 核心合約，比如EthClient,EventProver
- 核心連接器，比如FungibleTokenConnector
- 定制化連接器，由第三方開發
2. 以太坊區塊鏈
- 核心合約，如NearClient,NearProover, BorshDecoder, Ed25519
- 核心連接器，如Erc20Connector
- 定制化連接器，由第三方開發
3. 非區塊鏈服務
- 區塊中繼器，負責把區塊頭發給客戶端，保證彩虹橋運正常運轉
- 監管者-負責對提交給以太坊的NEAR區塊頭進行檢查，發生錯誤區塊被提交的情況時，給系統發送質疑。
- 交易中繼器（尚未開發）負責代表用戶發送最終交易，有效地將用戶與彩虹橋之間的互動變得原子化
非區塊鏈服務可能會由任何人運行，彩虹橋的設計方式決定了即使是這些服務的錯誤行為也不會將資金置于危險之中。只要有一對未被破壞的區塊中繼器和監管者便足以擁有一套健康的和最新的彩虹橋基礎設施，我們將能夠快速運轉起來，服務若發生任何問題，它們會修復漏洞并重啟。我們鼓勵社區或者通過托管副本提升冗余，或者開發監管者腳本，后者會在發現異常行為時拋出警告， 盡管定制化連接器對本次討論來說似乎不是很重要，但有兩點考慮需要我們注意：
- 如果我們能就連接器的可升級性提供一個建議方法（目的是避免核心彩虹橋升級出現的一些問題），這對開發者來講將會是很有幫助的，
- 定制化的連接器正使用核心合約，合約的接口（方法、參數）未來可能會根據升級發生改變，所以這些連接器應該采用一種通用的升級方案，
此外，需要我們記住的是存儲通證/數據的合約是連接器，而核心的彩虹橋合約的用途僅限于驗證。因此，我們需要在升級期間對連接器合約多加留意，核心的彩虹橋合約能夠被再次部署至新地址，并且不會對系統造成任何重大損害（轉賬會有些延遲，連接器需要更改核心彩虹橋的鏈接以及調用接口）。
現有方法
這篇來自 OpenZepplin的部落格是講述以太坊可升級性方法的最全面同時也是最新的一篇文章。若想了解更多資訊，也可查看Consensys部落格。
OpenZepplin:https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades/
Consensys:https://consensys.github.io/smart-contract-best-practices/software_engineering/
簡而言之，以下方法被廣泛使用：
1. 注冊表，一個特殊的“注冊表”合約，可對合約的各個版本進行追蹤。用戶/合約在與合約交互之前應該從注冊表中獲得最新版本的合約的地址，
- 優點：簡單，易于審計，能與多個版本協作
- 缺點：數據遷移不清晰，需要額外調用來查詢實際使用的合約
2. 參數/策略配置/特定功能。合約擁有更新參數或地址鏈接的方法，此類地址會執行該邏輯中的部分片段。
- 優點：可以進行微調，主合約代碼不可更改的特性為用戶帶來額外的安全性，
- 缺點：主合約中的漏洞無法被修復，高度依賴使用場景，沒有標準的經過測試的代碼
3. 代理。一個特殊的代理合約，只負責將代碼調用委托給執行合約，
- 優點：地址是靜態的，數據與執行是隔離的
- 缺點：設計復雜，可能會因為EVM的某些具體情況（函數篩選沖突，存儲沖突）導致很多問題發生
4. 可變合約（metamorphic contracts）。合約使用CREATE2操作碼部署，能夠在使用selfdestruct操作碼之后進行升級
- 優點：不需要代理（proxy）
- 缺點：合約狀態在升級過程中被刪除，不能在單個交易內發起升級，由此帶來合約會有停機時間
治理
除了可升級性，升級治理還有很多不同的方法：
1. 單一秘鑰/外部擁有賬戶。一把單一秘鑰能夠對合約進行升級
- 優點：速度快
- 缺點：中心化，存在單點故障
2. 多簽，M把秘鑰中要有N把對升級進行簽名
- 優點：參與方數量不是很大的情況下非常快速，不存在單點故障問題
- 缺點：仍然是PoA模型；需要為{Ethereumconsensus, NEAR consensus}集合引入額外的信任實體，
3. 時間鎖，合約的所有者（合約或單個秘鑰）能夠籌劃升級，從籌劃交易開始到完成，一般耗時1~7天
- 優點：用戶如果不同意升級，有足夠的時間中止服務
- 缺點：無法快速升級，在籌劃期黑客可以分析代碼并破解當前版本
4. 可暫停性（帶有逃生艙），合約可以執行一個暫停全部操作的方法，在暫停模式下，對合約進行的任何操作都是不被允許的，或者用戶也可以中止該項服務，
- 優點：有逃生艙，為時間鎖的安全升級問題提供了解決方案
- 缺點：暫停本質上是中心化的，因此應該在時間上有所限制
5. “提交-展示”升級。安全升級提議（以哈希形式）被提交給合約，代碼被展示給受信任的安全專家。審批通過之后，升級就會被展示并同時被應用。
- 優點：為時間鎖的安全升級問題提供了解決方案，減少了黑客對漏洞進行倒序開發的風險
- 缺點：與多簽治理幾乎沒什么區別
6. DAO/total voting。合約由利益相關者的投票治理。在NEAR的平臺中，我們指的是驗證節點投票。
- 優點：完全的去中心化，如果投票出了問題，這意味著NEAR協議層也會出現問題了，這時彩虹橋會是次要問題。
- 缺點：速度可能會慢一些，如何應用安全補丁尚不清楚，驗證節點的職責范圍會被擴大。投票決策也應該被發送至以太坊合約，如果彩虹橋停止運行，上述操作可能會發生問題。
當前事務狀態
注：關于NEAR區塊鏈智能合約的可升級性，目前還沒有完全確定的指導方案。最值得注意的是這份提議，來自以太坊的全部方法也都可采用。
提議：https://github.com/near/NEPs/pull/123 目前彩虹橋的可升級性按照以下方法實現：
1. 以太坊
- 核心合約目前是不可升級的，不過它們已通過了安全審計。核心彩虹橋升級通過發布新的彩虹橋實例來運行，使得連接器需要更改地址來進行交易完成性的驗證
- 同質化通證連接器擁有特殊功能，可允許轉移通證至新的部署環境
- 治理模型使用單個秘鑰
2. NEAR
- 核心合約通過了安全審計，不過擁有完整的訪問秘鑰，我們能夠在同樣的賬戶里部署新版本的合約，這樣連接器不用再更改證明地址了。
- 同質化通證連接器也擁有完整的訪問秘鑰，可以在地址不發生改變的情況下被更新。
可升級性方案設想
- 代碼中的漏洞數量在彩虹橋的運行初期達到峰值，之后會逐漸下降
- 彩虹橋測試范圍會逐漸擴大
- 升級的測試次數會越來越多，考量也會越來越重
- 產品的用戶基礎會逐漸增加
- 彩虹橋中的鎖定價值會逐漸增加（錯誤的成本也會增加）
一般考慮事項
將設想和通用實踐考慮在內，我們建議就彩虹橋合約的可升級性使用分階段的方法：早期階段將會有簡單的可升級性模型，治理模式將更為中心化，之后會發展為更為去中心化的方法，
階段1：中心化治理，沒有固定的接口
* 這樣做的目的是為避免遷移橋接/鎖定通證，同時讓用戶可以提取通證， 該方法十分簡單，允許快速迭代，可通過將通證存放在安全地方的方式對重大漏快速做出反應， 重要：未來和彩虹橋集成（無論是合約層面還是區塊鏈外部）的全部DApp都應該能夠更新集成代碼，包括合約地址和接口，
階段2：獨立的多簽治理，代理模式
由一小組經驗豐富的安全工程師和若干家企業組成了彩虹橋治理委員會。這些實體持有兩條鏈的多簽合約的秘鑰。核心彩虹橋合約和以太坊連接器實現代理模式，不過合約的實際接口未來可能會有所改變。 我們排除了單點故障的風險，但代價是系統對漏洞的反應速度會有所降低。總體來說，該方法讓彩虹橋擁有了更強的風險承受能力， 重要：未來和彩虹橋集成（無論是合約層面還是區塊鏈外部）的全部DApp都應該能夠更新集成代碼，盡管合約地址不會被更改。
階段3：獨立的多簽治理，擁有凍結期的代理模式、可暫停性、逃生艙和固定接口等功能/特點
該階段會改變治理模型，但不會改變可升級性模式。通過允許用戶在任何時候都可以中止該系統，我們正在增加彩虹橋的可預測性，使其對終端用戶更加友好。我們使用凍結期處理漏洞，多簽合約不能永久性地停止彩虹橋的執行，此外在這一階段，各個接口大致是固定的，這意味著不必同時升級彩虹橋的集成和彩虹橋本身， 重要：使用彩虹橋的用戶在該階段需要關注彩虹橋的更新。發生資金風險以及開發團隊無法及時對問題進行修復的情況時，我們會要求用戶使用逃生艙服務將資金從彩虹橋取出。一旦暫停階段結束，仍然存放在彩虹橋內部的資金將會處于風險之中。
階段4：驗證節點DAO，代理模式，擁有凍結期、可暫停、逃生艙、固定接口等功能/特點
在本階段中，我們將向完全去中心化和無需許可的治理模型過渡，該模型與NEAR的共識機制是一致的，能夠更新彩虹橋和連接器的實體是一個驗證節點DAO。完成升級需要2/3+1個質押。然而，對于較為嚴重的漏洞，我們仍然保留了安全團隊負責此事。該團隊將能夠暫停彩虹橋和連接器的運轉，并將漏洞通知給驗證節點，該方法保證了彩虹橋用戶能受到最好的安全保障。 注：為了更新以太坊合約，NEAR驗證節點應該在NEAR鏈上投票，之后系統會使用一個新的定制連接器將他們的決策橋接至以太坊。
階段過渡路線圖
階段之間的過渡應該經過社區同意，且很有可能取決于彩虹橋的使用體驗：用戶活躍度、總鎖定價值、漏洞賞金項目、重大漏洞出現頻率等，現在很難預測階段間的過渡什么時候會發生， 彩虹橋開發團隊致力于開發能夠執行可升級性和治理模式的代碼，不過我們會把過渡的各項指標的決定權交給社區，這與社區決定第二階段主網過渡一事類似。 根據我們對彩虹橋的設想，我們相信過渡至第四階段是我們的終極目標，通往該階段的過程需要對彩虹橋用戶確保安全。
結語
盡管提議的可升級性和治理計劃看起來有些復雜，事實上，該計劃實施了一個簡單的想法：一次只增加最終功能的一小部分.
- 第二階段推出多簽合約和代理模式等操作
- 第三階段推出凍結期、可暫定性和逃生艙等功能
- 第四階段推出去中心化治理
在這些遷移過程中，幾乎沒有刪除任何代碼（除了第四階段中對以太坊合約的多簽治理）。功能發布的順序和他們的復雜度與價值的比例的提升是相對應的，
