OpenZeppelin Framework Proposal and Development Roadmap

by Manuel Araoz

OpenZeppelin is a new smart contract development framework for the Ethereum Virtual Machine EVM focused on security, modularity, and code reusability. At Zeppelin Solutions, we started this initiative to gather the community around building new security standards and sharing efforts in smart contract development.

Most of this proposal is based on our experience building and maintaining other open-source projects like Bitcore and Streamium Feel free to give feedback on what you think could be improved.

Motivation

Smart contract security is hard. We need better tools for developers and teams to build the next generation of blockchain-based smart contract applications. There is yet no community-standard code to help write smart contracts in a safe way. We’re introducing OpenZeppelin as a way to discuss, learn together, and build tools for a safer decentralized finance ecosystem.

Principles

The core development principles we want to base OpenZeppelin on are:

• Security in Depth
  We strive to provide secure, tested, audited code. To achieve this, we need to match intention with function. Thus, documentation, code clarity, community review and security discussions are fundamental.

• Simple and Modular
  Simpler code means easier audits, and better understanding of what each component does. We look for small files, small contracts, and small functions. If you can separate a contract into two independent functionalities you should probably do it.

• Naming Matters
  We take our time with picking names. Code is going to be written once, and read hundreds of times. Renaming for clarity is encouraged.

• Tests
  Write tests for all your code. We encourage Test Driven Development so we know when our code is right. Even though not all code in the repository is tested at the moment, we aim to test every line of code in the future.

• Check pre-conditions and post-conditions
  A very important way to prevent vulnerabilities is to catch a contract’s inconsistent state as early as possible. This is why we want functions to check pre- and post-conditions for executing its logic. When writing code, ask yourself what you are expecting to be true before and after the function runs, and express it in code.

• Code Consistency
  Consistency on the way classes are used is paramount to an easier understanding of the library. The codebase should be as unified as possible. Read existing code and get inspired before you write your own. Follow the style guidelines. Don’t hesitate to ask for help on how to best write a specific piece of code.

• Regular Audits
  Following good programming practices is a way to reduce the risk of vulnerabilities, but professional code audits are still needed. We will perform regular code audits on major releases, and hire security professionals to provide independent review

For more info and a proposed code style guide Check our CONTRIBUTING document on GitHub

Implementation

We’re starting with Solidity tools because Ethereum is currently the most popular smart contract development platform. Working with Solidity also makes our tools compatible with Rootstock and some private blockchain systems like IBM’s Blue Horizon

But our vision of improving smart contract development security standards is platform agnostic. Our plans for the future involve working on tools for Bitcoin, Tendermint, Bloq Ora, or whatever platform developers are using to build smart contract apps.

Some modules and components we’re looking to implement soon for Solidity are:

• Pull payment helpers:
  Lots of security problems (including the infamous TheDAO hack can be prevented by using a pull payment strategy (as opposed to pushing payments with send). We already have a simple PullPaymentCapable.sol contract, but more comprehensive tools, documentation and examples are needed.

• Contract life-cycle tools:
  Most contracts nowadays are deployed to the blockchain without much thought about what will happen to them in the future. We’d love to build tools to better manage several contract death strategies, contract transfer of ownership, contract upgradeability, contract pausing and resuming, etc.

• Fault tolerance and Automatic bug bounties:
  Automatic detection of faults, and tools to recover from inconsistent states. Simple tools to limit the amount of funds managed by contracts. We’re also working on, and looking to improve, bug bounty contracts to have automatic payouts to security researchers that can break our contract’s invariants.

• Reusable basic components:
  Many common modules are still reimplemented from scratch for each new project. We’re looking to build standard contracts for token issuance, crowdfunding, voting, betting, payroll, revenue sharing, etc.

• Explore formal verification ideas:
  Formal verification of contracts is an active research area. Integrating this work into OpenZeppelin can provide interesting security guarantees to our contracts. Formal verification means statically analyzing contract code to formally prove correctness and/or problems.

• Better oracle interfaces:
  An important part of smart contract development is how to interact with off-blockchain data sources. An interesting idea to explore is to do inversion of control, where oracles call contracts (to communicate outside truths) through a common interface method, and can implement their oracle logic as wanted: trusted expert, closed voting, open voting, API wrapper. Instead of contracts requesting data from oracles, oracles inform contracts of data changes.

• Better code reuse tools:
  Current Solidity code reuse is based on copy-pasting or downloading existing code from other repositories. Mature ecosystems have good code repository management systems such as NodeJS’ npm or Ruby’s gems An interesting variation in Ethereum is the possibility of reusing code already deployed to the blockchain. We’re planning to build tools that allow to easily link your contracts to deployed libraries.

All these points are already in our GitHub issue tracker. Bear in mind that this is just a proposal based on the work we’re interested in at Zeppelin Solutions. We’re happy to hear your thoughts and ideas on what to work on next. We want OpenZeppelin to be community-driven and community-maintained. Join us!

If you look at our repo now, you’ll see some commits already there, but most of the work is ahead, and we want you to be a part of it!

Roadmap

The rough project roadmap for the following months is:

Sep 2016. Make OpenZeppelin public and start development.

Oct 2016. Gather community around it and build first tools for existing smart contract projects.

Nov 2016. Develop first proof of concept of a simple fully OpenZeppelin-based real organization. Security audit code and first major OpenZeppelin release.

Dec 2016. Deploy said proof of concept organization and maintain it. Further OpenZeppelin development to more components based on community needs.

Jan 2017. Develop the OpenZeppelin organization as a smart contract using OpenZeppelin eat your own dogfood. Model incentives for contributions to the project (e.g.: tokens assigned for each merged commit).

Feb 2017. Deploy OpenZeppelin organization to the blockchain. Plan next 6 months.