以太坊的proxy contract pattern

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合约示例

具体参看:

参考资料

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

Guess you like

Origin blog.csdn.net/mutourend/article/details/120286790