by Manuel Araoz
We’ve already discussed the technical details of ZeppelinOS and published a first draft of the whitepaper. Now, we’d like to introduce our development roadmap with an estimated timeline of when we’ll distribute each component of the platform.
Read more in our Development Roadmap Part Two.
We think it’s important to share our plans with the community for a few reasons. First, it creates an accountability mechanism for our progress. Second, it gives developers a better understanding of how the project will evolve, granting them a space to provide valuable feedback. Lastly, it helps projects understand when they can expect to use each component.
We divided the roadmap into three stages:
This post will provide the rationale for the way we structured our development timeline. Future posts will cover the details of each stage.
The first and most important component of ZeppelinOS is the Kernel. Today, smart contract developers suffer from the lack of standard upgradeability mechanisms to fix security vulnerabilities or introduce new features to their apps.
For example, Zeppelin recently helped Augur migrate their REP token to a new version because the contract contained a critical vulnerability. This had to be done by re-deploying a new fixed instance of the token and migrating the balances, which had tremendous operational and gas costs (~19 ETH was spent in gas costs alone).
This inefficiency needs to change if we’re going to see further resources directed toward smart contract technology. That’s why we’re planning to devote the first 12 months of ZeppelinOS development to building the Kernel: an on-chain set of standard libraries with built-in upgradeability.
The smart contract industry also lacks better contract management and analysis tools. Today, the only reliable way to interact with one’s contracts is through command-line tools like geth, truffle, or pyethereum.
The current environment creates a huge technical barrier to entry for anyone looking to deploy smart contracts on the EVM. Even experienced developers can make mistakes using these tools, sometimes resulting in absurd gas fees for failed contract deployment (that one was on me), and it’s really painful to read information on a contract’s state with them.
While security and upgradability are the foundation of smart contracts—without which they would not be viable—we still need to understand and use them more comfortably. We plan to devote the following 12-month period to building several projects to achieve this, including off-chain tools for analytics and monitoring, a contract operation web application, automatic security checks and deployments, and more.
Once security and usability are out of the way, we’ll build tools to enable the future smart contracts we dream about today, with better standards for smart contract interaction. Nowadays, there’s little to no interaction between contracts, apart from multisig wallets used as authentication mechanisms to call privileged functions on other smart contracts.
But for smart contracts to reach their full potential, we envision much more interaction, some even driven by autonomous decision-making processes. To enable those interactions, we need standard ways for contracts to pay each other, hire each other’s services, and asynchronously execute each other’s calls.
This is why the last phase of our plan will be devoted to building the ZeppelinOS Marketplace, the ZeppelinOS Scheduler, State Channel support, and other contract interaction tools.
We’ll be explaining each of the stages in more detail in future posts. Stay tuned for part two.
You can learn more about ZeppelinOS by referencing the project’s website, whitepaper, and blog.