原文: https://medium.com/zeppelin-blog/proxy-libraries-in-solidity-79fbe4b970fd
- 合约多次部署需要耗费gas
- 区块链上代码重复
- bug修复和更新需要重新部署
解决办法: 使用一个普通合约, 但是像库一样调用它(用delegatecall替换call)
实现
https://github.com/maraoz/lib
https://github.com/maraoz/lib/blob/master/test/test.js
技术框图:
面向用户的合约不是直接与已部署的库的地址相关联，而是链接到“Dispatcher”。 在编译和部署时，这是很好的，即使Dispatcher没有实现库的任何方法，如果字节码有一个有效的地址，部署将是成功的。
当交易进入时，主合约认为它通过delegatecall调用与其链接的库。 但实际上，这个delegatecall被替换,连接到dispatcher。
这是事情变得有趣的地方。 一旦dispatcher在其fallback函数中捕获delegatecall，它会确定库代码的正确版本是什么，然后再次使用delegatecall重定向该调用。 一旦库返回，返回结果送给主合约。
限制
- dispatcher需要知道库调用的返回的内存大小.现在是通过函数签名和返回类型进行映射的方式来解决.
- delegatecall用evm直接实现, 你只能在下面的情况使用: 两个合约具有相同的storage.因为库没有storage,所以把Dispatcher也做成没有storage,这就是为什么有一个专门的DispatcherStorage来存储需要的数据,而且DispatcherStorage需要在字节码中进行硬编码.
后续工作
允许用户数据迁移,当库升级的时候(数据结构可能改变), 迁移机制可以参考 : https://github.com/golemfactory/golem-crowdfunding/blob/50100b27a7c6841ed430a028d100f5d45ba08fb1/contracts/Token.sol#L85
代理中的存储布局合理性检查。
紧急情况下的合约执行任意代码。