Smart Contracts Security — The Aerospace Way
Smart contracts development should be done with the highest level of quality assurance, just like aerospace has been doing things for the last 40 years.
There is a thick book (with a dry name DO-178) that provides guidelines for software development in aerospace. It is a single source of truth when it comes to development, QA and audits. It is written by independent organization with participation of industry players and various governing bodies like the FAA. This is probably the single most significant effort that made airplanes as safe as they are right now.
Ethereum smart contracts are nowhere near those levels of safety at the moment. Smart Contract security is paramount to wider adoption of Ethereum so let’s go down and explore how such set of guidelines might look for crypto.
The Aerospace way
First off, lets have an overview of DO-178 and the way it is being developed.
It comes down to assessment and mitigation of risk. The framework has 5 levels of risk:
- Catastrophic — Failure may cause a crash. Error or loss of critical function required to safely fly and land aircraft. (Loss of control, RUD, etc.)
- Hazardous — Failure has a large negative impact on safety or performance, or reduces the ability of the crew to operate the aircraft due to physical distress or a higher workload, or causes serious or fatal injuries among the passengers. (the pilot has to abort the mission and land immediately)
- Major — Failure is significant, but has a lesser impact than a Hazardous failure (for example, leads to passenger discomfort rather than injuries) or significantly increases crew workload (safety related)
- Minor — Failure is noticeable, but has a lesser impact than a Major failure (for example, causing passenger inconvenience or a routine flight plan change)
- No Effect — Failure has no impact on safety, aircraft operation, or crew workload.
Each subsystem is assigned a risk level, then a set of actions is taken to mitigate those risks. For example, autopilot errors can be catastrophic, so highest level of quality is required. The guideline specifies what models should be used in this case, but does not prescribe specific actions to take. This way everyone knows what has to be done but has freedom to use the tools and processes that fit them best.
Development of the guidelines is done by an independent group (called RTCA) that consists of few full-time members (editors) and can form committees that have specific tasks (e.g. investigation of incidents, proposal of changes, etc). Community contributions are reviewed by the editors and other community members.
Adoption for smart contracts
Let’s imagine a document that unifies reasons behind best practices for smart contract development. There are a few things that it will bring:
- Looking at a document that describes a development process one can clearly say if that process adheres to the guideline document. (Are all the risks considered? Is mitigation adequate? etc.)
- Company that uses compliant development process can have it’s products certified to the standard.
- An auditor has a defined way to conduct the audit and cannot be blamed for missed issues if they were not considered by the guideline.
- An audit covers the full development process and not just the final product.
- Incidents lead to enhancement of the guidelines.
- A common language is used to talk about security and quality in the context of smart contracts.
- An outsider can easily quantify risks of certified contracts (e.g. Contract A’s latest audit was done using guidelines version X, and risks associated with that version are clearly defined. This is especially useful for insurance purposes.)
- Developers will have incentive to make additional audits as guidelines evolve.
- An ecosystem of tools can be created to simplify development and audition of smart contracts.
Multiple companies are tackling creation of best practices for the industry (Zeppelin, ConsenSys), but without a higher lever general document those are fragmented and things can be missed. There is no defined iterative way to evolve them and failures are not teaching the industry as a whole. This calls for adoption of such practice in crypto world.
Next steps
1. Create initial guidelines. This can be done by adopting a minimal set of Aerospace practices. It does not have to cover everything, but it is important to describe an end-to-end flow for at least some things. (e.g. how to identify critical parts, and mitigate critical risks)
2. Establish a framework for iterative development of the guidelines. An independent commission can be created to oversee the development. It can be funded by renting out certification stamp tokens to the companies that want to conduct audits and showed that they understand the guidelines. Additionally, a stamp tokens can be used to mint audit tokens that contain audit results and the source code in an immutable manner.
3. Call industry to adopt. Major players should start using the guidelines and certifications, discuss and change underlying principles collectively.
Ethereum Improvement Proposal
Join the conversation and share your thoughts in EIP 889. We are interested in the best ways to organize iterative development of the guideline, as well as inputs from other industries such as financial, medical, telecom.
