Proxy Libraries in Solidity

This is a joint post by Zeppelin Solutions and Aragon.

We recently read some articles about neat tricks and hacks one can do in Solidity. Specifically, Jorge Izquierdo’s article on Library Driven Development and Simon de la Rouviere’s article on ThrowProxy.

That got us thinking about using those ideas to turn Zeppelin into an upgradeable blockchain-deployed library. Currently, Zeppelin is a collection of secure and community-vetted contracts for anyone to use. This is work towards creating security standards and industry best practices. But in order to use them, developers have to download our code and deploy parallel copies of it alongside their application-specific contracts.

This has several disadvantages:

Deployment gas costs.

Code repetition in the blockchain.

Bug fixes and updates need to be deployed independently on each project (or, even worse, Ethereum has to hard fork to fix a contract’s problems).

What if we could have a deployed version of a library in the blockchain, which all projects using Zeppelin could link directly? That’s the idea behind Solidity’s libraries. The problem is, once a library code is deployed, it’s immutable. For Zeppelin, being able to fix security vulnerabilities and add more reusable modules is key for our users. Thus, we’d need some mechanism to upgrade the contract’s code.

Some attempts to do this are Martin Swende’s generic proxy and Arachnid’s upgradeable contract, but have their drawbacks and can’t be used for libraries.

Our idea: Use a normal contract, but call it as a library (use delegatecall instead of call )

Result: It works!

Proposed implementation

Code: https://github.com/maraoz/solidity-proxy/blob/master/test/test.es6

Check it out and please give us feedback! We’ll be evaluating how to use this new technique to turn Zeppelin into a deployed upgradable library in the next few weeks.

On a more technical level, our solution flow looks like this: