以太坊的proxy contract pattern

Posted 2021-10-02 mutourend

1. 引言

智能合约一旦在以太坊上部署，就不可修改，若合约有漏洞，唯一的解决办法是找到并利用该漏洞，以比黑客更快的速度将资产转移到安全的账号。

尽管智能合约一经部署不可升级，但是，可建立a proxy contract architecture that will allow you to use new deployed contracts as if your main logic had been upgraded。

即，所有的message calls都将通过Proxy Contract直接指向最新部署的Logic Contract。部署新版本的Logic Contract合约升级时，只需修改Proxy指向新部署的合约地址即可。

Zeppelin提供了3种upgrade proxy模式：

• 1）Inherited Storage
• 2）Eternal Storage
• 3）Unstructured Storage

这3种模式都依赖底层的delegatecalls。Solidity提供了delegatecall函数，但是该函数仅返回true/false来表示调用是否成功，并不支持对返回值进行操作。
这3种模式的主要区别在于，用不同的方式来解决相同的技术难题：how to ensure that the Logic Contract does not overwrite state variables that are used in the proxy for upgradeability。

需要理解一下两个关键要点：

• When a function call to a contract is made that it does not support, the fallback function will be called. You can write a custom fallback function to handle such scenarios. The proxy contract uses a custom fallback function to redirect calls to other contract implementations.
• Whenever a contract A delegates a call to another contract B, it executes the code of contract B in the context of contract A. This means that msg.value and msg.sender values will be kept and every storage modification will impact the storage of contract A.

借助calldatacopy和returndatacopy，可实现calldata的传入 和 结果的传出。

2. Upgradeability using Inherited Storage

3. Upgradeability using Eternal Storage

4. Upgradeability using Unstructured Storage

5. Proxy合约示例

具体参看：

• 第一个Proxy合约

参考资料

[1] Openzeppelin博客 Proxy Patterns
[2] Openzeppelin docs Proxy Upgrade Pattern
[3] 示例 第一个Proxy合约