智能合約開發時升級策略

本文是對以太坊中可升級智能合約開發領域的各類實現策略的總結 ，目的是彙總迄今爲止的相關資源，以幫助咱們在設計開發智能合約時，考慮如何對其進行升級和更新。

100％可智能合約開發升級機制

目前有兩種主要策略用來實現可升級的智能合約：

• 使用代理合約
• 將邏輯和數據分離成不一樣的合約。

這兩種方法要解決的根本問題是如何更新合同的邏輯，同時仍然保留對合同狀態的訪問。

代理智能合約

代理合約使用delegatecall操做碼將函數調用轉發到可更新的目標合約。 因爲delegatecall保留了函數調用的狀態，所以能夠更新目標合約的邏輯，而且狀態將保留在代理合約中以供更新後的目標合約的邏輯使用。 與delegatecall同樣，msg.sender將保持代理合約的調用者身份。

因爲最近的拜占庭硬分叉，如今能夠獲取函數調用的返回大小了，所以與Nick Johnson首次提出的方法相比，目前這種方法能夠通用。 在Daonomic的文章中能夠看到一個通用代理合約的例子，你能夠更詳細地瞭解這個機制。

智能合約開發分離邏輯和數據

這中方法到將智能合約拆分兩個合約：

• 包含數據（變量，結構，映射等）以及getter/setter的數據合約
• 包含如何更新這些數據的業務邏輯的邏輯合約

邏輯合約經過setter更新數據，而數據合約只容許邏輯合約調用setter。 這容許在保持數據不變的同時更換實現邏輯，從而實現徹底可升級的系統。

經過引導用戶使用新的邏輯合約（經過諸如ENS的解析器）並更新數據合約的權限來容許新的邏輯合約 執行setter，就能夠實現合約的更新。

查看Thomas Wiesne的視頻以更好地瞭解這一機制。

使用鍵值對數據模型分離邏輯和數據合約

這種策略的工做原理與上述相似，只是不使用最終指望數據結構（struct，mapping等）來定義合約數據模型，全部數據都被抽象化並存儲在鍵值對中，而後使用一個標準的命名系統以及sha256散列算法用於查找數據值。

能夠查閱David Rugendyke的文章以更好地理解這種機制。

部分智能合約開發時可升級策略

建立一個徹底可升級的合約聽起來不錯，但須要一個很大的妥協：保證合約的不可變性。 所以在不少狀況下 實現部分可升級的合約多是更合理的選擇。

在此策略中，智能合約的核心功能能夠保留爲不可升級。 其餘可能不太完整或更復雜的組件則採用可升級策略實施。

這方面已經有一些很好的案例：

• 以太坊名稱服務ENS：ENS核心合約是一個很是簡單的合約，不能更改。域名註冊商則能夠由管理員升級。 域名註冊商是一個合約工廠，若是使用一個新的域管理器，它能夠與之前的全部數據狀態從新連接，而不會有太多麻煩。
• 0xProject：603DEX（去中心化交易所）核心智能合約能夠徹底升級，而代理合約（每一個用戶一個）保持不變。0x「代理」合約（不一樣於前面介紹的代理策略）包含用戶資金和相關設置。 因爲這個緣由，它不是0x合約系統的可升級部分。

其餘挑戰

• 在全部狀況下，都須要對是否保持智能合約的不變性進行取捨。
• 建立可選的可升級智能合約系統對用戶來講是可能而且有價值的，可是增長了複雜性。
• 對Solidity編譯器的更改可能會破壞新舊合約之間的兼容性。
• 制定可升級策略時須要考慮gas開銷。

結論

沒有一個策略是完美的，選擇正確的策略取決於要實施的智能合約。 全部策略都很是複雜，智能合約設計人員應該對他們所選擇的可升級策略很是瞭解，以免安全漏洞。

• 爲了建立一個可升級的智能合約，代理機制彷佛是最好的全面策略，由於它容許程序員將可升級機制與合約設計區分開來，這使得一切變得更容易，而且會產生更少的錯誤，而錯誤是咱們須要升級合約的主要緣由。
• 在最簡單的核心邏輯不變的狀況下，採用部分升級策略也是保持用戶信任的好主意。
• 首先設計不可升級的智能合約系統，而後制定可升級的策略，這是一種實用且理想的方式。