Building a Philosophy of Secure Smart Contracts

The philosophy of smart contract development, part 2. Part 1: The Mindset of a Smart Contract Developer

ConsenSys Diligence is a service that takes raw smart contract code and, using a specialized set of skills, locates potential vulnerabilities in the code, and gives recommendations for fixing them. This is toward the goal of the whole Ethereum ecosystem being better. Our long-term goal is to solve smart-contract security.

When I started working with ConsenSys Diligence I didn’t expect them to so fully live up to their name. Last week I wrote an article about the stringent attitude a developer must take if s/he is to develop smart contracts correctly, and compared and contrasted this attitude to traditional software takes/mentalities. The point of this article was to demonstrate how a developer’s mindset must change if they are going to make the move to developing smart contracts from developing in traditional software frameworks.

One of the earliest audits we completed was the 0x v. 1 audit a little over one year ago. Although we’ve developed a more attractive user interface for our audit reports since then, (e.g. the IICO audit), this earlier report style is grittier and helps the reader sense what an audit is like and how the auditor is knee-deep in code for weeks at a time.

Audits are a messy business. You can’t perform a software audit without getting your hands dirty. You have to get into the mindset of the contract author and think like they think to anticipate what mistakes they might make in their contract code. This allows the auditor — playing the role of a malicious hacker — to find vulnerabilities the contract author would miss.

It also means understanding the code on a level that even the contract authors themselves might not. It means pulling out all the stops to do damage to this contract. This makes for a perfect setting to explain the mindset of a smart contract developer by showing examples of it in practice.

Many people think philosophies are useless unless they translate into action. I happen to agree. For that reason, let’s take a look at the 0x v. 1 audit to see how the higher-level philosophy I explained in my previous post played out empirically through the reports of the Diligence team.

The first thing you might notice when clicking on the 0x audit link posted above is the formality of it. This formality is important because our clients need to know exactly when their audit occurred, and exactly what it was supposed to cover.

It can be dangerous to add last-minute changes to the codebase of an audit, because a thorough software audit requires a body of code and several weeks to chart out all of the interactions between different parts of the code. This means it’s not possible to adequately review a new piece of code that is added to a contract in just a short amount of time. If the code makes function calls into several other parts of the contract (as last-minute code frequently does), then the complexity of the whole contract is increased, not just the extra piece of code.

But it’s not just dangerous to the client, it’s also dangerous to us. It’s dangerous to us because as the auditors of a contract, we are tasked with the expectation of finding any major vulnerabilities in the contract that they might have missed. This means if we fail to identify a vulnerability because of some extra code thrown in at the last minute, the consequences to our reputation will be nothing short of catastrophic. We stand not only to lose business, but also to lose the trust of the ecosystem. This realization takes us back to my previous article where I put some of our philosophy in the same style as The Zen of Python:

Safe is better than unsafe.
Boringness is better than notoriousness.
Constant is better than inconstant.
Straightforward is better than intricate.

All of these properties are a mindset we are required to take on in order to do our audits well. You can see how this is reflected in our request for clients to provide a single, complete contract that is deployed once, rather than bits of contracts deployed piecemeal.

Moving back to the 0x v. 1 audit. From the main page, click on the link that says:

3 — General Findings
You will notice right away the section that says:

3.1 Critical
ConsenSys Diligence found no general issues of critical severity during our review.

Every vulnerability in our report gets a severity rating from 1 to 4. The severity rating can be imagined to be saying: “If you publish this smart contract in its current state…”

1 = Critical; …some people will be able to take all your money and/or halt your contract (i.e. on the level of The DAO Hack, allowing tens of millions of dollars’ worth of ETH to be drained).

2 = Major; …some people will be able to do annoying things that interfere with your business logic significantly.

3 = Medium; …some people, if they’re smart enough, will be able to exploit vulnerabilities in the contract that may or may not lend them an advantage, just for fun. This will affect the smart contract, but is not likely to break it.

4 = Minor; …this is not an actively exploitable issue, but it is something of note. Perhaps a best practice has been violated, or some other rule of thumb can be applied for best results, from a security perspective.

You can imagine the sigh of relief you might breathe then when you get your audit report back and see it says:

ConsenSys Diligence found no general issues of critical severity during our review.

But to best see how ConsenSys Diligence adheres to and applies a consistent philosophy of mind behind our actions, skip down to the part of the review past the Medium and Major issues, and go right to the Minor ones. Minor issues would be easy to leave out of our report, because they don’t necessarily present a threat to security. But because we believe that safe is better than unsafe, we do not do this. We report on every last thing.

Philosophies aren’t always easy to apply. In fact, sometimes they can be downright difficult. But consistency is a strength in smart contracts, as well as humans, and we apply a consistent philosophy of smart contract development behind all our audits. This can be demonstrated by many of our audits, but the 0x audit is especially useful because it’s gritty and demonstrates a high-level of detail very early in the ecosystem, before we developed our more advanced user-interface for our audit reports and before smart-contract auditing was “cool” in the eyes of many people.

We find it a privilege to work with community members like those of the 0x team, and look forward to auditing many more contracts from other members and groups in the community as time goes on. Interested in having your smart contract audited? For a free readiness assessment, e-mail your request to diligence@consensys.net.

Disclaimer: The views expressed by the author above do not necessarily represent the views of Consensys AG. ConsenSys is a decentralized community with ConsenSys Media being a platform for members to freely express their diverse ideas and perspectives. To learn more about ConsenSys and Ethereum, please visit our website.