Recently there has been significant debate surrounding the security failure of the Parity multisig wallet. Late last year, a user accidentally disabled the entire Parity contract, resulting in a loss of over 500k ETH, today worth over $300m USD. Catastrophic security failures aren’t new to Ethereum. The most significant being DAO security failure of 2016, which resulted in a contentious hard fork that split Ethereum into both Ethereum and Ethereum Classic.

The community decision in EIP 779 to hard fork Ethereum was highly controversial at the time, so it should be no surprise that EIP 999 to hard-fork Ethereum is also contentious, and the community is concerned that it may lead to a similar split of the blockchain. While I’m not interested in weighing in on on the pros and cons of EIP 999, I am interested in explaining how if smart contract development was approached more like aerospace engineering, these types of issues could be avoided.

Photo by Tirza van Dijk

The Web Developer Mindset

While smart contracts are written in Solidity, the bulk of the way that users interact with the contract is through web3, a javascript frontend implementation. Because of this, many teams developing web services with smart contracts as an enabling technology run their production process exactly like they would with web development.

To oversimplify web development: new features and bug fixes are developed and tested in a development branch, and subsequently moved to staging. When code is deployed to production, the rigorous reviews and testing during development should ensure that there are no fatal flaws with the web service, and the transition to production is seamless. Often, users are unaware of updates pushed to production, unless a new feature pops up. For example, a new tool for taking photos of their lunch on social media. This is web development working correctly. At least in a perfect world.

Security breaches occur in web development. Just ask Equifax, Yahoo! and the DNC. While data privacy is not maintained in these breaches, we are not seeing hacks liquidate entire banks or delete content from websites. These security breaches can be closed, service can be restored, and the entire system could be restored to a previous state.

Photo by NASA

Deploying Crypto Into Space

So if developing smart contracts is not like web development what is it? Forgive me for being the hammer that sees nothing but nails, but my career in aerospace has me thinking about deploying smart contracts like writing mission critical software for satellites, not websites.

Given that web3 is a subset of frontend web development, it makes sense at first glance to apply the same processes. However, the large sums of money at stake in smart contract development often dwarf the cost of NASA missions — the recent launch of the Transiting Exoplanet Survey Satellite came in around a cool $200m USD.

The cost of developing and launching satellites has come down several orders of magnitude in the past 15 years but, physical access to satellites once in orbit is still an impossibility. Only multi-billion dollar satellites such as the ISS or the Hubble Space Telescope, are serviced in orbit. Because of this restriction, satellite software systems must be designed to be fail safe. Aerospace generally accepts that because it may be impossible to write perfect code, failures must be recoverable without exception. NASA has highly rigourous software standards & QA processes that ensure mission success.

Perhaps it is time for a new philosophy in smart contract security theory: deploying code to the blockchain should be analogous to launching code into space. Smart contracts should be created with development practices that are slow, meticulous and methodical; with deeply ingrained best practices, safety standards, and readiness levels. The agile paradigm of “move fast and break things” has no place in smart contract development, and developers can’t rush to deploy code and fix bugs later. These major security failures are excellent opportunities for blockchain self-reflection. Had the community taken smart contract security more seriously after EIP 779, then EIP 999 would not even be under consideration. Developing secure code is not impossible, it’s just rocket science.