by Manuel Araoz
Check out our step-by-step guide to OpenZeppelin-eth, the EVM package implementation of OpenZeppelin 2.0.
Smart contract development is still in its early days. We’re all still trying to figure out what it will look like and how to polish the developer experience. At Zeppelin and Aragon, this is something we think and care a lot about, and do our best to contribute to. As many of you know, we also like helping the community standardize widely used patterns and adopt software engineering good practices.
Upgradeable on-chain packages
A trend we see coming and want to share and promote is that of upgradeable on-chain packages of smart contract code. We like to call these EVM Packages. This means a smart contract app can reuse on-chain building blocks provided by other developers and opt in to bug fixes and improvements in the future.
As OpenZeppelin was a much-needed step in terms of smart contract code reusability and continuous improvement, we think the next phase of maturity for our industry requires actual bytecode reuse on-chain. During the past two years, we’ve established the basis for writing secure simple modules. We believe the next step in complexity comes from enabling developers to combine existing on-chain code to build new things on top, requiring marginally little additional effort.
We’d like to stress the importance of giving developers full control over which upgrades they want to adopt in their own apps. Any other approach would lead to counterparty risk for developers and users, which is something blockchain technology is looking to reduce, and would thus make no sense in this context. This is why at Zeppelin we’re collaborating closely with Aragon, industry leaders in decentralized governance, on this endeavor.
With a healthy ecosystem of on-chain code, we can promote:
- Separation of concerns: Each EVM Package can be maintained by a separate team, allowing each one to focus on providing the best implementation for each functionality.
- **Complexity by composition: **Instead of every app developer having to understand implementation details of the full stack (e.g., ERC20 tokens, crowdsales, reverse Dutch auctions, quadratic voting mechanisms), they can rely on work by other colleagues and use it as building blocks to make it easier to create more complex systems.
- Free opt-in upgrades: Using upgradeable EVM packages by other developers lets you fix bugs in your own code dependencies for free, making your app more secure. Again, remember that EVM package maintainers can’t automatically upgrade the code you’re using; upgrades are always manually performed, and you can choose when/if to upgrade.
- Granular upgrade governance: Each EVM Package can have its own upgrade governance mechanism for deciding which upgrades to push on-chain. This allows for experimentation with different strategies for different needs (e.g., involving users in upgrade decisions), while also letting developers decide when to follow proposed upgrades.
- Gas cost savings: It makes no sense for every app to redeploy the same code, spending contract creation gas costs each time. While upgradeability proxies do come with increased gas costs for usage, we’re working on optimizing this overhead (and would love your help with this too!).
EVM Packages are already available on ZeppelinOS and aragonOS today. Stay tuned for future posts soon, showing code examples of how you can leverage the power of EVM Packages using aragonOS and ZeppelinOS.
What are your thoughts on EVM Packages?
