近期開發基于以太坊的智能合約，為實驗室的分布式電商系統提供可信的“第三方信用擔保”功能。

由于初期項目需求變動會比較頻繁，并且智能合約一經發布于區塊鏈上就無法修改，即使智能合約中有Bug需要修復或者業務邏輯變更，它也不能直接在原有的合約上直接修改再重新發布。因此在即將發布第一版之前，需要結合業務場景考慮合理的升級改造機制。

初版的智能合約主要包括如下功能：

1. 買家創建訂單，合約記錄訂單基本信息并且需要買方向合約支付交易費用
2. 賣家取消訂單，賣家在發貨前可以取消訂單，合約自動將交易費用退回給買家
3. 賣家發貨，合約記錄相應訂單的物流信息，修改訂單狀態
4. 買家確認收貨，合約將交易費用轉移至賣家，并且修改訂單狀態為已完成
5. 基本的訂單查詢功能

通過簡單的需求介紹，可以看出合約中會保存著交易費用，訂單數據以及基本的電商交易流程動作。

起初寫的智能合約全部集中在一個contract，里面會保存交易費用，訂單數據以及電商交易的全部流程。一旦發布就不能修改（哪怕是添加一個方法，修改方法邏輯以及數據中添加新的字段，，，），因為重新發布新的合約之后，之前的訂單數據以及交易費用全部在舊的合約中，從工程的角度來看，同時維護新舊合約（也許好多個舊合約，，，，）簡直不能更糟糕。

因此決定將業務邏輯和數據從合約代碼層面就做好分離，即合約分為了兩類：邏輯合約以及數據合約。邏輯合約通過訪問數據合約獲得數據，并對數據做邏輯處理，然后寫回數據合約，專注于對數據的邏輯處理和對外提供服務。邏輯合約不存儲任何狀態；數據合約專注于數據結構定義與所存儲數據的讀寫接口。

邏輯合約與數據合約存在操作關系，邏輯上分為四類：

1. 邏輯合約與數據合約 1對1
2. 邏輯合約與數據合約 1對多
3. 邏輯合約與數據合約 多對1
4. 邏輯合約與數據合約 多對多

根據本項目的業務場景，采取邏輯合約與數據合約1對1的關系（后續業務復雜，可以改造為多對1），綜上，初期的設計圖如下：

首先進行數據與邏輯的分離。

數據合約包括狀態，以及每個狀態對應讀寫方法（set&&get），部分代碼如下：

邏輯合約因為僅包含業務邏輯，不會存儲任何的數據狀態，因此使用Solidity的library進行編寫。

library的好處是它是單實例，只會更新一個library文件，不會像contract那樣因為各種依賴產生‘漣漪’效應，對于經常變動的業務邏輯代碼，使用library每次更新會節省大量gas消耗。

library是需要被合約調用才能執行的，調用library的contract（下面簡稱A），使用的delegatecall方法，因此library執行的上下文環境在A中，也就是library的msg.sender是A，并且可以直接修改A中的storage。直白說，A調用library，就是把library的代碼import到自己的內部執行了。

因為業務邏輯合約使用了library編寫，library的調用是需要合約觸發的，因此需要一個入口合約，來去調用library操作數據合約，而且對于本項目的實際需求，上面將數據以及邏輯進行分離后，忘記了一個重要的方面，就是資金存儲，引入入口合約后，正好解決了這個問題，客戶端調用入口合約代碼，將資金充入入口合約，并且由入口合約進行資金的轉移過程。

入口合約調用library來去操作數據合約的數據，因此在入口合約中，需要引入調用的library（或者是library的interface），這樣子，如果library添加一個新的方法，不僅library需要更新，入口合約也是需要更新的，而入口合約的作用包括交易資金托管以及調用library方法，更新發生時，需要有適當的方法將舊的入口合約資金轉移到新的入口合約中，因此寫了kill函數，當更新發生時，將新的合約地址作為參數，執行如下舊合約的kill方法：

上面反復提到“入口合約調用library來去操作數據合約的數據”，這個地方使用到了using這個Solidiy關鍵詞。

using關鍵詞是Solidity的contract引用library時使用，例子如下：

pragma solidity ^0.4.15;
library SomeLibrary? {
?function add(uint self, uint b) returns (uint) {
?? return self+b;
?}
}
contract SomeContract {
?? ?
??? using SomeLibrary for uint;
?? ?
??? function add3(uint number) returns (uint) {
??????? return number.add(3);?? ?
??? }
}

using SomeLibrary for uint 意思是在SomContract合約中，uint類型的參數可以直接調用SomeLibrary的方法，并且將uint自身作為第一個參數傳遞到library的方法中。

回到項目中，“入口合約調用library來去操作數據合約的數據”,即調用library方法的同時，需要將數據合約作為參數提供給library，因此代碼可以寫成如下：

在入口合約初始化的時候，將數據合約賦值給tradeData，因為有了using LogicLibrary for address, 因此address類型的tradeData可以直接調用library的方法，并且將其自身（數據合約的地址）傳遞給了library。

按照上面的方式改造，在測試過程中，發現當執行查詢數據的時候，合約間返回非定長類型的string，會出錯，上stackexchange的Ethereum板塊中，找到如下解答：

也就是說Solidity對于合約外部調用，返回變長類型的字段，EVM是不支持的。回到項目本身，因為訂單數據中定義了多個string類型數據，沒有辦法去改變數據結構，因此采取折中的辦法，對于查詢操作，客戶端直接讀取數據合約（缺點是目前的設計方案數據合約是不可改的，但是對于查詢，可以將數據合約中全部狀態寫好get方法，并由客戶端對返回的狀態進行整理是可以滿足需求的）。

本項目智能合約使用了Truffle進行開發編寫，對于升級改造之后的部署腳本，代碼如下：

對于Library與Contract的關聯，是通過deployer.link實現在字節碼級別上的，并不需要合約代碼顯式寫出來。

經過上述實踐，智能合約成功完成可升級的改造，架構圖如下：

經過上面改造，基本滿足實驗室分布式電商智能合約的升級需求，但是這種方式應用到其他實際場景中，可能存在的問題包括數據合約無法修改；讀寫操作客戶端需要對兩個合約進行操作；缺少proxy合約（使得智能合約升級對于客戶端dapp無感知）等。所以智能合約的升級改造，還是要和實際需求相結合，此文盡量滿足本身項目需求的同時，使用業內通用方法來去實踐，若有不足，望批評指正。

1. Writing upgradable contracts in Solidity：https://blog.colony.io/writing-upgradeable-contracts-in-solidity-6743f0eecc88

2. Solidity’s ‘using’ keyword：https://medium.com/@gus_tavo_guim/soliditys-using-keyword-c05c18aaa088

3. One reason to start using Solidity Libraries：

出處：智能合約的可升級改造實踐/#背景起因

版權申明：內容來源網絡，版權歸原創者所有。除非無法確認，我們都會標明作者及出處，如有侵權煩請告知，我們會立即刪除并表示歉意。謝謝。

-END-

架構文摘

ID：ArchDigest

互聯網應用架構丨架構技術丨大型網站丨大數據丨機器學習