入口合約調用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：

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