摘要：接上篇合約升級模式介紹筆者改寫了一個可用于實踐生產的升級框架，需要自取。在介紹合約升級模式中提到了一個可以解決這個問題的方法。深度理解注意為中的低階方法下文中出現的方法，是我在智能合約中寫的一個方法名稱，不要混淆。

接上篇：合約升級模式介紹
筆者改寫了一個可用于實踐生產的升級框架，需要自取。https://github.com/hammewang/...
同時歡迎討論，微信xiuxiu1998

鑒于以太坊智能合約一旦部署，無法修改的原則，所以智能合約升級應當遵循如下兩點規則：

邏輯可升級；

存儲可繼承；

第一點很好理解，可以把代理合約和邏輯合約看成插座和插頭的關系，需要升級的時候把老的插頭拔下，再插上新的即可。

對于第二點，存儲可繼承，不僅僅是存儲結構的繼承，而且在存儲內容上，實現擴展：舊存儲內容不變，新存儲內容繼續追加。這個過程類似于城市化的推進，城市的邊緣可以一圈一圈擴大，但是如果要尋址到老城區的XX路XX號，無論城市怎么擴大，拿著這個門牌號依然可以找到那棟老建筑。

升級目的中的第一點是相對好實現的，只要改變調用的邏輯合約地址就可以了；而為了實現第二點，就要保證合約執行環境上下文保持一致。在介紹合約升級模式中提到了一個可以解決這個問題的方法：delegatecall。把關鍵代碼再貼一遍：

 assembly {
    // 獲得自由內存指針
    let ptr := mload(0x40)
    // 復制calldata到內存中
    calldatacopy(ptr, 0, calldatasize) 
    // 使用delegatecall處理calldata
    let result := delegatecall(gas, _impl, ptr, calldatasize, 0, 0)
    // 返回值大小
    let size := returndatasize
    // 把返回值復制到內存中
    returndatacopy(ptr, 0, size)

    switch result
    case 0 { revert(ptr, size) } // 執行失敗
    default { return(ptr, size) } // 執行成功，返回內存中的返回值
 }

這樣做，實現了把邏輯合約(_impl)中的方法拉到代理合約中執行，遵循代理合約的上下文（如存儲、余額等），通過這種方式實現了執行上下文一致性。

注意：
delegatecall為assembly中的低階方法；
下文中出現的delegateCall方法，是我在智能合約中寫的一個方法名稱，不要混淆。

delegatecall的目的是可以維持執行環境中上下文的一致性，一種很典型的應用場景就是調用library中的方法，用的就是delegatecall。下面來具體介紹一下delegatecall的特點。

假設personA調用了contractA中的functionA，這個方法內部同時使用了delegatecall調用了contractB中的functionB，那么對于functionB來說，msg.sender依然是personA，而不是contractA.

請看下面的合約：

pragma solidity ^0.4.24;

contract proxy {
    address public logicAddress;
    
    function setLogic(address _a) public {
        logicAddress = _a;
    }
    
    function delegateCall(bytes data) public {
        this.call.value(msg.value)(data);
    }
    
    function () payable public {
    address _impl = logicAddress;
    require(_impl != address(0));

    assembly {
      let ptr := mload(0x40) 
      calldatacopy(ptr, 0, calldatasize) 
      let result := delegatecall(gas, _impl, ptr, calldatasize, 0, 0)
      let size := returndatasize 
      returndatacopy(ptr, 0, size) 

      switch result
      case 0 { revert(ptr, size) }
      default { return(ptr, size) }
    }
  }
    
    function getPositionAt(uint n) public view returns (address) {
        assembly {
            let d := sload(n)
            mstore(0x80, d)
            return(0x80,32)
      }
    }
}

contract logic {
    address public a;
     function setStorage(address _a) public {
         a = _a;
     }
}

這時分別部署proxy和logic，之后把logic.address賦值給proxy中的logicAddress變量。調用getPositionAt(0)會發現返回的也是logicAddress的值，結果如下圖：

這時，如果調用proxy中的delegateCall并傳入0x9137c1a7000000000000000000000000bcb9c87f53878af6dd7a8baf1b24bab6a62fe7aa（9137c1a7是setStorage的方法簽名），意為用delegatecall調用logic中的setStorage方法，這時會發現proxy中的logicAddress發生了變化，變成了我們剛剛傳入的值。如下：

這時我們會發現，delegatecall并不通過變量名稱來修改變量值，而是修改變量所在的存儲槽。所以當在proxy中delegatecallsetStorage方法時，修改的并不是address a，而是address a所在的第0個存儲槽的值，而proxy中第0個存儲槽存放的是logicAddress，所以相應就會被覆蓋。

理解到這一步，就可以感受到delegatecall的強大和危險。但同時也帶來一層疑問：雖然使用delegatecall可以使用邏輯合約中的方法改變代理合約中相應位置的變量，但是并沒有起到存儲可擴展呀？不還得事先在代理合約中創建相應變量么？這就相當于在1949年新中國建立的時候，就要規劃以后建設的所有布局，包括共享單車停靠點，這不是有點扯淡么?

這就要說到delegatecall下面一個特點了。

delegatecall還有一個強大的特點就是，可以為proxy中未事先聲明的變量開辟存儲空間。

我們來看下一個例子，代理合約依然使用上面用過的proxy，我們把邏輯合約 變一下：

contract logic2 {
    address public a;
    address public b;
     function setStorageB(address _a) public {
         b = _a;
     }
}

新增加一個address變量，并且只修改第二個address變量。

這時依然重復上一個例子的第一步，把logic2的地址賦值給代理合約中的logicAddress變量。結果如下圖：

然后使用代理合約中的detegateCall方法，調用logic2中的setStorage2方法，傳入data為0x9ea338be0000000000000000000000000dcd2f752394c41875e259e00bb44fd505297caf。之后再調用getPositionAt(1)和logicAddress()方法，結果如下圖：

可以看到logicAddress并沒有發生變化，而第1個存儲槽中的值變成了我們剛剛傳入的值。

這也再次說明了，delegatecall方法并不是按照變量名稱操作的，而是按照變量所對應的存儲槽的位置，對該位置中的值進行操作。因此，我們是不是事先在代理合約中聲明了變量，就并不重要了。

可以傳遞msg.sender

不按照變量名進行操作，而是去找變量對應的存儲槽進行操作（無論變量是否在代理合約中事先聲明）

正因為第二點特性，為合約升級中的存儲擴展提供了可能性；同時，也提出了一個很嚴格的要求：

新合約和舊合約之間必須嚴格遵守繼承的模式，即：

contract newLogic is previousVersionLogic{
    ...
}

               -------             =========================
              | Proxy |           ║  UpgradeabilityStorage  ║
               -------             =========================
                  ↑                 ↑                     ↑            
                 ---------------------              -------------
                | UpgradeabilityProxy |            | Upgradeable |
                 ---------------------              ------------- 
                                                      ↑        ↑
                                              ----------      ---------- 
                                             | Token_V0 |  ← | Token_V1 |         
                                              ----------      ---------- 

代理合約是UpgradeabilityProxy實例，圖中的Token_V0和Token_V1即是邏輯合約的最初版和升級版，它們都必須繼承Upgradeable，同時邏輯合約和代理合約都必須繼承UpgradeabilityStorage，繼承同一套存儲結構，以保證邏輯合約在代理合約中執行時，不會出現變量覆蓋的情況。

注：圖中每個方框的結構從上到下依次是：合約名稱、狀態變量、function、event、modifier

圖中可以更加清晰地看到，代理合約和邏輯合約都必須繼承registry和_implementation兩個狀態變量，并且邏輯合約中沒有修改前兩個狀態變量的相應方法，因此代理合約中的存儲安全。

部署Registry合約

部署邏輯合約的初始版本(V1)，并確保它繼承了Upgradeable合約

向Registry合約中注冊這個最初版本(V1)的地址

要求Registry合約創建一個UpgradeabilityProxy實例

調用你的UpgrageabilityProxy實例來升級到你最初版本(V1)

部署一個繼承了你最初版本合約的新版本(V2)，V2必須繼承V1

向Registry中注冊合約的新版本V2

調用你的UpgradeabilityProxy實例來升級到最新注冊的版本

調用Registry中的transferProxyOwnership方法進行所有權轉移；

須對代理合約的地址套用當前版本的邏輯合約的ABI，方能正常調用和獲取返回值。