WeiFund is a crowdfunding portal built on Ethereum. Along with the portal interface, WeiFund offers a StandardCampaign sample contract that allows anyone to rapidly assemble a crowd fund offering. Alternatively, campaigns are allowed to “roll their own” smart contract code.
Given the wide variety of crowdfunding implementations supported by WeiFund, we at WeiFund have initiated a campaign rollout readiness framework to encourage campaigns to publicly and transparently demonstrate the due diligence the campaigns do (or do not) perform prior to campaign launch. WeiFund campaign rollout readiness provides a template for campaign release best practices. It is our hope that this process demonstrates its value and is applied to smart contract system releases in general.
What is campaign readiness? To a great extent, readiness assessment is a measure of security assessment with the goal of creating an environment for secure contract system rollouts. (Other dimensions of readiness assessment, — such as investment readiness or legal readiness — are in the pipeline, but not yet available.)
Recently, there has been an increasingly widespread and healthy sentiment that smart contract systems benefit when they are considered to share properties with hardware systems in terms of construction and deployment readiness. Software can be frequently and painlessly modified where hardware once deployed will exist as deployed until failure or end of life.
The WeiFund rollout readiness index encourages campaigns to view their smart contract systems with a deeper level of analysis. The rollout readiness framework provides a mechanism for campaigns to think through various dimensions of security associated with smart contracts and front-load that effort prior to campaign launch.
The first step we at WeiFund took when constructing the rollout readiness framework is to apply the concept of a readiness index to smart contract systems. We considered software engineering security best practices —including code reviews, static analysis, dynamic (runtime) analysis, external audits, bug bounties, phased rollouts — applied them specifically to Solidity and smart contract systems, and aligned them with the readiness index.
In the sections below we present a detailed look into the components of smart contract system rollout readiness.
Having several experienced sets of eyes look at the smart contract system (SCS) codebase is the first element of due diligence. We use the ConsenSys security best practices guide as a starting point. Using this guide as a requirements document, several reviewers analyze the SCS holistically (as a whole, from the top down, with a view of how components interact) and decomposed (line by line, from the bottom up). The reviewers attest to any violations they identify against the presumed requirements specification.
Static analysis is an automated analysis of the source code or byte code. The Ethereum solidity-browser has recently incorporated elements of static analysis, and the community around Solidity is rapidly developing formal verification mechanisms.
The static analysis component of the rollout readiness framework simply leverages the available tools during the assessment period to identify any issues with the code that can be revealed with an automated static analysis.
Dynamic (or runtime) analysis is the most heavy-weight component of the readiness assessment. Attack vectors are probed, and test coverage and results are documented.
Anti-fragile management of the keys responsible for Smart Contract System administration (e.g., distribution of funds, SCS configuration/operation) is of upmost importance. Key management policies should be documented, vetted and thoroughly understood.
In addition to the internal analyses, an external audit of high quality is very valuable. In our experience, an external audit not only identifies issues with the particular SCS under assessment — it typically instills better practices and habits among the contract developers and architects reflecting on the assessment that carries over to later projects.
A bug bounty program is established to incentivize the community to work on behalf of the SCS by revealing weaknesses, vulnerabilities and brittleness before funds of campaign contributors are at risk.
A phased rollout of the SCS into production is recommended as an additional mechanism of defense in depth. The phased rollout serves as a guard against immature contracts holding a mature level of funds.
Bringing the components together and presenting this large amount of information into an at-a-glance, digestible visualization is not a trivial task. Currently, our visualization result looks something like this:
This captures the performance of the test coverage combined with the coverage of the requirements specification for each component of the rollout process in a balanced, comprehensible format.
Learn more about WeiFund at our readthedocs page.