by Manuel Araoz
As mentioned in our Development Roadmap Part One, the smart contract industry is in urgent need of the ZeppelinOS Kernel.
The Kernel is a smart contract library deployed on the blockchain that provides a set of basic functionality and services for smart contracts using ZeppelinOS. It’s supported by a decentralized upgrading mechanism which uses a vouching mechanism governed by ZEP token holders.
Because the Kernel is the foundational layer of ZeppelinOS, we’re focusing all of our efforts on its development. The following roadmap outlines how our team will devote the next 12 months.
The Kernel has various sub-modules, each with its own implementation challenges:
The first stage will be launching a prototype of the Kernel as an on-chain library, starting with the current functionality found in the OpenZeppelin framework. On top of that, we’ll add a proxy mechanism that allows a central party to upgrade the code. You can see an initial version of how this will work in our ZeppelinOS Labs repo.
Next, we’ll develop the token-based upgradability governance mechanism, in which ZEP holders can vouch for specific versions of the Kernel and thus signal their approval of particular versions of the reusable modules. This will allow the Kernel to operate in a decentralized manner for the first time.
We plan to have a livenet version of the token-governed upgradeable Kernel working by Q2 of 2018.
After we launch the most critical component—the Kernel upgradable standard libraries—we’ll spend the last half of 2018 improving it. We’ll also be building the development tools to accompany the use of the Kernel.
First, we’ll build the payout mechanisms to incentivize development and auditing of different versions of the Kernel, plus the contract development tools needed to support opt-in automatic upgrades. Next, we’ll build the Scheduler and the Oracle interfaces.
As a means to support richer execution models, the operating system will provide a bounty-based smart contract async execution scheduler through the use of a standardized set of signaling events. In it, different parties can offer to execute async operations and securely call back into the contract to resume operations.
In order to accomplish this, we will gather the community to build standards and write code for both the scheduler clients and the providers who wish to offer the execution calls of async operations. This will enable a more flexible programming environment, where contracts can request future executions.
Finally, we’ll focus on building a standard interface for smart contracts to access information currently unavailable from on-chain apps. Examples include current prices for ETH, ERC20 tokens, gas, and other digital assets, as well as network data such as transaction pool size, average mining block times, etc. We’re working with our friends at SmartContracts.com / Chainlink to implement these in collaboration, allowing any user of ZeppelinOS to use the Chainlink decentralized oracles network.
As we continue development, we’ll be releasing additional information covering the details of our roadmap. Stay tuned for part three, where we’ll cover the platform’s SDK.