深度剖析智能合约升级——inherited storage

摘要：接上篇合约升级模式介绍笔者改写了一个可用于实践生产的升级框架，需要自取。在介绍合约升级模式中提到了一个可以解决这个问题的方法。深度理解注意为中的低阶方法下文中出现的方法，是我在智能合约中写的一个方法名称，不要混淆。

接上篇：合约升级模式介绍
笔者改写了一个可用于实践生产的升级框架，需要自取。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，方能正常调用和获取返回值。