Technical Details of ZeppelinOS

by Manuel Araoz

Last week, we announced ZeppelinOS, the operating system for smart contract applications.

We highlighted that “the rate of innovation in building decentralized applications is limited by the manual and duplicative efforts developers must make to ensure basic usability and security.”

ZeppelinOS aims to solve this problem. Based on our experience working to secure dozens of projects in the space, we are now building an open-source, decentralized platform of tools and services on top of the EVM to help developers rapidly deploy, upgrade and manage secure smart contracts.

We have classified the features of the OS into 4 categories of services:

• the ZeppelinOS Kernel Standard Libraries,
• Smart Contract Development Tools,
• Smart Contract Interaction Tools,
• Off-Chain Tools.

Let’s dive into each of these.

Kernel Standard Libraries

The Kernel is the foundational layer of ZeppelinOS: an on-chain set of upgradeable standard libraries offering common functionality and services that developers can call from within their smart contracts.

Common Functionality

The goal for the ZeppelinOS Kernel is to provide a set of functions for the smart contracts that run on top of it, requesting services from the OS rather than re-implementing them from scratch.

These functions will be available as an on-chain standard library of reusable contracts and functions, heavily inspired by OpenZeppelin, and held to the same security standards.

These libraries will enable developers to do the following (and more):

• Create and customize your own ERC20 Token.
• Create a capped, refundable, and/or whitelisted crowdsale contract.
• Create a trustless bug bounty.
• Create pausable, ownable, and balance-limited contracts.
• Set up a token vesting or token locking contract.

Security Patches and Continuous Improvement

As a secure base layer that smart contracts communicate with on-chain, we open up the possibility of delivering opt-in upgrades to our users. This enables ZeppelinOS core developers to roll out optional security mitigations and patches as soon as a vulnerability is found, instantly protecting all users of the smart contracts that sit atop the OS.Through the same mechanism, ZeppelinOS will always be in a state of continuous development and improvement: the OS will be upgraded based on the proxy library pattern, which we’ve developed through experiments with the Aragon team.

This is how it works: users will be incentivized to review patches and vouch for their correctness. This is necessary to avoid the possibility of a single party upgrading (i.e. changing) all contracts in the OS without control from the community, while providing a mechanism of fast response in the event of a critical security issue acknowledged by the majority. Given the sensitivity of upgrades in the context of smart contracts, we will enable developers to choose between automatic upgrades and manually activated ones on a per-contract basis.

Shared bug bounties

Bug bounties have become a standard practice for smart contract development, as a means to attract auditors to inspect critical code. By having a layer of code shared between applications, users of the OS can place collective bounties on common critical kernel modules. This will be implemented by a decentralized governance bounty pooling mechanism, to be explained in a future post. In this way, security researchers are incentivized to look at the code in a cost-effective manner. This won’t require every smart contract developer to individually disburse large prizes or get their own researchers to have their code audited.

Contract Development

Besides a set of common libraries, the OS will also provide tools aimed at making smart contract development and maintenance easier for developers.

Attack Management

Experience has shown that bugs will always be present in a codebase. As smart contracts become more complex, the probability of bugs appearing increases, becoming more attractive targets for attacks.

ZeppelinOS will provide an emergency toolbox for dealing with attacks. Triggering an emergency pause, reverting to a previous uncompromised state, or forking a contract are some of the tools we have been working on. This work was part of OpenZeppelin and we’ll continue improving on it for the OS.

Upgrade Management

In addition to having upgrades of the ZeppelinOS Kernel itself, the underlying implementation will be made available to users of the OS to enable upgradeability of their own smart contracts. This allows rolling out contract-specific security patches, as well as the progressive deployment of features, using whichever update governance mechanism developers see fit.

Thin Deployments

By enabling the usage of on-chain libraries through proxies instead of repeatedly including common bytecode, deployments will be smaller in size and cost less gas. This will also lead to an improved smart contract development experience.

Smart Contract Interaction Tools

One of the key points of ZeppelinOS is to provide a shared environment where distributed applications can easily interact and interchange services. This is akin to an operating system where processes can cooperate by sending and receiving messages, leveraging the power of an ecosystem of shared services. The OS will provide various mechanisms for inter-contract communication and networking, such as publish-subscribe messaging, message queues, and shared storage. This will enable decentralized application developers to plug-and-play third-party building blocks, like IFTTT recipes for smart contracts.

Scheduling

Contract code execution is synchronous and linear, allowing the possibility to call other contracts but restrained to a single execution thread. To support more complex operations, applications require off-chain infrastructure.

As a means to support richer execution models, the OS will provide a smart contract async execution scheduler, where different parties can offer to execute async operations and securely call back into the contract to resume its operations.

Async execution helps solve an inherent problem of the Ethereum execution model: a transaction that spans multiple actions by a smart contract is paid by the user who initiates it. For example, a function execution protected by a multisig contract is funded entirely by the last user to approve it. By allowing anyone else to execute the function in exchange for a bounty, we can decouple the user who requests the action from the one who pays for its gas costs.

The OS will define the required standards and provide reference implementations, for both the scheduler clients and the providers.

Marketplace

Much as traditional mobile app marketplaces act as central hubs for mobile users to browse and purchase available services, one of the central features of ZeppelinOS is a marketplace for contracts, where services can be purchased, sold, and integrated into applications.

Developers will be able to register new services in the marketplace, which will be discovered and accessed by client smart contracts. We envision multiple payment models, such as pay-per-call, one-time fees, or subscriptions for fixed periods of time, all of which can be managed through common payment interfaces.

This will be not only a central key in fostering collaboration between smart contracts, but also a way of allowing contracts to have off-chain interactions. Marketplace apps can be a mix between on and off chain implementations, providing services such as file storage, mail sending, push notifications, off-chain intensive computation, or machine-learning services.

State Channel Support

Blockchain transactions are limited by block mining times and fees. This caused the development of alternative off-chain transaction exchange protocols that could be consolidated back to the blockchain after multiple operations. State Channels is one of such proposals, designed specifically for the EVM.

The OS will incorporate state channel support through common protocol specs and reference implementations, plus all the on-chain infrastructure necessary for discovery, arbitration and finalization of state channels. Besides providing a cheaper communication mechanism, this also opens the door for integration with off-chain payment networks in the platform.

Blockchain Information Provider

The OS will provide trusted ways to access information on the blockchain currently unavailable from smart contracts, such as current ETH price, gas price, transaction pool size, average mining block times, etc. This will be implemented either as an oracle providing updated information per request, or as calls to Kernel contracts which are continuously updated by a trusted external source.

Off-Chain Tools

As an addition to the on-chain services offered by ZeppelinOS, the platform will provide a set of off-chain tools aimed at simplifying the development, debugging, testing, deployment, and monitoring of decentralized applications.

Analytics & Monitoring

Contract transactions and events provide invaluable insight on the usage of a deployed application, analogous to end-user actions and events performed on a web page. The OS will provide an off-chain analytics dashboard to aggregate on-chain generated contracts events and transactions for insight on their usage. It will also help monitoring the health of each contract, by keeping record of the transaction error rate and failure-associated events, triggering alerts through user-defined rules.

Platform as a Service

One of the current major challenges is not in contract development itself, but in the deployment and management stages that come once the code is ready. The OS will provide an easy to use interface for this, including:

• Triggering automated testing and security analysis of contracts.
• Deploying the contracts to the blockchain, and optionally managing upgrades.
• Providing user-friendly web interfaces for reading data and managing the contracts once deployed.
• Providing secure and reliable connections to the Ethereum network, via infrastructure providers such as Infura.

The Platform as a Service approach also includes acting as a one-stop platform for integration with other contracts, providing a user interface for the discovery and management of marketplace-offered services.

Continuous Integration for Contracts

Automated testing through continuous integration providers has become an industry standard, as a means to increase the confidence on the project health by checking its tests in a separate environment at every stage of development. However, this requires a testing environment with conditions as similar as possible as production. As such, ZeppelinOS shall provide the required services, including replaying previous transactions using the updated codebase to compare generated outcomes.

Automated Code Analysis

Static analysis is a long-running research field in academia, with occasional ports to industry-level tools. These techniques can yield enormous benefits towards the identification of potential bugs and vulnerabilities. As such, and given the high security requirements of decentralized applications, applying these strategies to smart contracts code is a must.

Having access to the code powering the smart contracts applications, ZeppelinOS will offer automated code analysis services with increasingly powerful rules and techniques, preventing inadvertently deploying unsafe code, and alerting owners of existing running contracts of newly found vulnerabilities.

Developer Tools

Developer experience for smart contract developers is really bad. The tools are immature, break often, and debugging is very frustrating. Part of the off-chain tools the ZeppelinOS platform will provide are debugging, testing and infrastructure frameworks to make smart contract developers’ lives happier. We’ll also contribute to existing toolchains such as pyethereum, truffle/testrpc and web3.js.

Next steps

We hope this post has helped clarify some of the more technical questions around the different components of ZeppelinOS, and how they will enhance smart contract development and management process. This is an ambitious endeavor and we’ll need your help to make it happen, so please join our Slack and share your feedback with us..

If you are looking for ways to contribute to ZeppelinOS, the best starting point is to help with the development of the OpenZeppelin framework, as it will be the basis from which the ZeppelinOS Kernel Standard Libraries will be built.

During the upcoming days we’ll be releasing more information about ZeppelinOS, stay tuned!