Contracts Roadmap: January - March 2020

[nventuro]

We're redesigning our open-source processes at OpenZeppelin, aiming to boost transparency and increase community participation.

Part of that effort is giving more visibility on our medium term goals, both to set expectations for our users on upcoming features and improvements, and to provide clarity over our priorities to contributors that want to help improve the library.

At a high-level, we're going to be focusing on the following goals:

• Migrating to Solidity v0.6
• Implementing New Features by the Community
• Reducing Library Complexity

Migrating to Solidity v0.6

As the industry advances and new practices and standards evolve, we’ll need to do some work to keep our status as the go-to library for Smart Contracts, including staying up to date with the latest releases of the Solidity language.

Solidity v0.6 was released in December 2019, and we expect the community at large to migrate their code to it over the next couple of months: many users are already waiting for us to support it.

Unfortunately, the migration to v0.6 is not straightforward: it requires the design of new features and documentation to guide users through the process. We’re in close contact with the Solidity team to try and find approaches that will simplify the transition.

We expect to have an initial beta release by early February with iterative improvements based on user feedback. The aim is for the final release to be out in early March.

Implementing New Features by the Community

As the space matures, new developer needs come up. We’ve identified two highly requested initiatives, for which we’ve seen the need in both security audits and user requests. These are expected to be largely community-driven.

The first one is the ERC1155 token, a new standard that is gaining popularity as a successor to ERC20 and ERC721. We already have an initial draft of the code in our repository: we’d have to work on adding test cases and documentation.

The other candidate is a library for fixed-point arithmetic. This comes up a lot in DeFi, and rolling a custom solution can be very tricky. There are some open-source projects we can leverage here, notably Fixidity, a library developed by two community members, used by PoolTogether, and audited by Quanstamp.

We plan on relying on help from the community for implementing these initiatives. Both are reasonably well-defined and scoped, and are great options for experienced developers willing to collaborate with the library. On our end, we will provide support to the implementers and review their solutions.

Reducing Library Complexity

We experienced some friction during 2019 when deciding which new things to add to the library, which led to an overall reduction of community activity on the repository. We believe this is related to Contracts’ goal not being clearly defined, and to the complexity of the library.

We’ll perform a number of breaking changes on the v3.0 release. The contracts will be less coupled to each other, thus lowering the barrier for new contributions for both developers and reviewers, and making maintenance easier.

In concrete terms, we’re planning on:

Decoupling the Default Access Control Library

Contracts currently provides Roles, an opinionated Access Control solution which works for most scenarios. It also provides ERC implementations built on top of it (such as ERC20Mintable). However, we have seen that many users prefer to use their own access control libraries. To cater for them, we will ship all ERC extensions without an integrated access control solution, though making it easy to combine them with Roles. This will also improve maintainability by reducing the number of contracts in the library.

Unifying ERC Extensions

Every ERC implementation in Contracts has multiple flavours and extensions. For example, ERC20 is complemented by ERC20Detailed, and ERC721 by ERC721Metadata and ERC721Enumerable. We will unify some of these optional extensions into a single contract to reduce the complexity of the code.

Removing Crowdsales

Crowdsales were one of the most popular features of Contracts during the ICO craze of 2017 (back when the library was called zeppelin-solidity!). Fortunately, this is no longer the case. We have seen a decline in the usage of Crowdsales, and decided to remove them from v3.0, given the complexity of migrating them to Solidity 0.6. They will still be available on v2.5 in Solidity 0.5, and we encourage our community to fork them to migrate them to Solidity 0.6 if there is interest.

Providing Out-Of-The-Box Contracts

To cater for beginner users, we will add a set of ready-to-use standalone contracts for the most popular combinations of ERC extensions, such as a preminted ERC20, or a mintable ERC721. These will not cover the entire space of possible combinations, but we hope will serve as guides for new combinations that our users want to build.

This means the library will be much smaller and leaner, only providing the tools required to build a larger system, complemented by a small set of out-of-the-box contracts.

For technical reasons, these changes will be part of the v3.0 release (along with the Solidity v0.6 migration).

[nventuro]

As part of our work on reducing complexity, we'll move along with the initiative to revamp our Access Control solution, which will let us remove related contracts (ERC20Mintable, MinterRole, PauserRole, and so on) and have the users instead build permissioned systems on their own.

Related discussion will be carried out on the Redesigning Access Control forum post.

[bohendo]

We expect to have an initial beta release by early February with iterative improvements based on user feedback. The aim is for the final release to be out in early March.

Is any info available re an updated release schedule?

Thanks, stay safe out there 🙏

[abcoathup]

Hi @bohendo,

The final release candidate for OpenZeppelin Contracts 3.0 is out:
https://forum.openzeppelin.com/t/openzeppelin-contracts-v3-0-final-release-candidate/2583

As with all release candidates, the final release will follow one or two weeks later. This is so that community members get a chance to share their thoughts on the upcoming changes before they are made final.

[Amxx]

Hi @bohendo,

As with all release candidates, the final release will follow one or two weeks later. This is so that community members get a chance to share their thoughts on the upcoming changes before they are made final.

This was 13 days ago. Any clue when the 3.0 will be out? Hours? Days? Weeks?
(I have a platform audited and ready to deploy based on 3.0.0-rc.1, would be great if I could deploy with 3.0.0 "official")

[frangio]

@Amxx In the next one or two days.

[nventuro]

v3.0.0 is finally out!

This concludes tasks on this roadmap. Head over to the Q2 2020 roadmap for upcoming features!