Smart Contracts are how things get done on the Ethereum and plasma ecosystem. When someone wants a task done, they initiate a smart contract with the parties involved. This technology is a crucial part of a blockchain network, and any vulnerability can result in the loss of millions of dollars.
To understand more about why and how we can bulletproof a Smart Contract, we sit down Quantstamp security engineer, Kacper.
Who are Quantstamp?
Quantstamp is a full-stack blockchain security company. We began as a Y-Combinator backed startup whose goal was to design a decentralized network for running security scans over Ethereum smart contracts. Since the beginning, we’ve provided expert smart contract security audits. We also offer smart contract monitoring software and enterprise blockchain consulting services. Quantstamp are blockchain-agnostic, working with a multitude of technologies which span over private and public blockchains, and off-chain solutions.
What is a smart contract audit and how do you go about it?
A smart contract security audit is a technical assessment of a blockchain application and related artifacts. In each audit we review a range of artifacts and aspects of the application: documentation, design and architecture, code, and tests. The goal of a security audit is to find vulnerabilities, check if code conforms to specification, and assess whether it adheres to best practices. A vast majority of our audits include manual and automated parts.
In the manual part we have three independent auditors going over the artifacts on their own. Once they are done, they share the notes and compile a report. In the automated part we run software tools over the codebase. It is important to note that manual and automated parts complement each other.
Why are smart contracts security audits so Crucial?
The majority of smart contracts handle digital assets, for example, ether or ERC20 tokens, so they become attractive targets for attackers. On public blockchains, anybody may interact with the deployed code, and, consequently, if there is a vulnerability, it is likely to be exploited. Unlike in traditional software, many blockchains favor immutability so it is relatively difficult to patch the deployed code if a bug is found. For these reasons, smart contracts go through security audits to detect any issues with the code before it gets deployed and used in the real world.
What are some of the challenges encountered during a blockchain smart contract audit?
Oh, there are multiple. First, there are still projects for which a security audit is an afterthought instead of an activity that should be part of the development process. Second, during the audit we want to assess whether the code’s functionality matches the author’s intent. It is often challenging due to missing or incomplete documentation and specification. Third, on the technical side, one needs to understand how a specific blockchain and related technologies work since they rely on different assumptions. Finally, when we issue a report, not all clients are happy with the results. For example, they would prefer to have a clean report that shows no vulnerabilities. Sometimes it takes a while to convince them that it is in their best interest to have the issues fixed and to inform users of potential risks.
Can you explain the usual Smart Contract vulnerabilities that are exposed during audits?
Projects differ and so do the vulnerabilities and their severity levels. We see different flavors of front-running, issues with the implemented logic, arithmetic issues, centralization of power, improper user authentication, and incorrect accounting for the handled digital assets.
How can everyday users ensure that the projects they’re engaging with don’t have these vulnerabilities/are secure?
Overall, one cannot guarantee that there are no vulnerabilities in the code, but the more attention the project gets, the likelihood of serious issues getting unnoticed tends to decrease. Perhaps the easiest way is to check whether the project underwent a security audit. From what I have seen, a number of projects that take security seriously, do not mind sharing their audit reports with the public. Some projects also setup public bug bounties where anyone is welcome to hack the code. If users are technically inclined, they may try doing their own review of the code
Can you take us through the entire audit process for OmiseGO?
Sure. The audit process followed our usual steps, although there was one significant difference. We began with scoping the code to assess the required effort. We ran the automated analyses and performed independent reviews of the artifacts. However, instead of waiting to share the final notes, OmiseGO asked us to inform about any issues in real-time so that they can fix them during the audit. I liked this approach since: 1) the audit and code fixing were happening in parallel and shortened the whole process, and 2) their main goal was to discover and fix issues instead of just having a good-looking report.
Based on Quantstamp auditing standards, what are the indicators of a well-designed smart contract? And how do these qualities translate into a reliable network?
I do not have any hard data, however, I noticed that well-written code. i.e., code that conforms to best practices, is well documented, and is accompanied by a thorough specification, has very good chances of being well-designed. It shows that the authors put significant thought and effort into the smart contract. Also, it helps the auditors to focus on finding vulnerabilities instead of listing minor issues with the code. I believe that, in the end, that helps with building more reliable applications.
Quantstamp is one of the two companies who audited our testnet, checking for vulnerabilities within the OMG Network.