We’ve already discussed the technical details of zeppelin_os 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 divided the roadmap into three stages:
- 0–12 months: zeppelin_os Kernel and Contract Development Tools
- 12–24 months: zeppelin_os Platform and SDK
- 24+ months: zeppelin_os Marketplace and Contract Interaction Tools.
This post will provide the rationale for the way we structured our development timeline. Future posts will cover the details of each stage.
zeppelin_os Kernel and Contract Development Tools (0–12 months)
The first and most important component of zeppelin_os 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 zeppelin_os development to building the Kernel: an on-chain set of standard libraries with built-in upgradeability.
zeppelin_os Platform and SDK (12–24 months)
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.
zeppelin_os Marketplace and Contract Interaction Tools (24+ months)
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 zeppelin_os Marketplace, the zeppelin_os 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.