Your smart contract system's security may be improved by conducting an audit. Besides selecting a high-quality auditor for the job there are several things you can do to ensure you get the most out of your investment.
Following these steps to prepare for an audit will go a long way in achieving the best results.
- Documentation
- Clean code
- Test
- Automated analysis
- Freeze code
- Use a checklist
1. Literature
The less time we spend trying to understand your system, the faster we can dig deeper into your code and the more time we will spend finding bugs. That's why the first thing you can do to improve the quality of your audit is to provide good documentation.
Good documentation starts with a plain English description of what you're building, and why you're building it. It should do this both for the overall system and for each single contract within the system.
A statement of the desired functionality of your system is another indicator of quality documentation. For each contract, it should describe the most important properties or behaviors to keep. It should also describe actions and states that should not be possible.
One of the best examples we've seen is the protocol specification for 0xProject. In particular, their use of flowcharts illustrates well how the system fits together.
Don't let me scare you. Good documentation takes a lot of effort. If you don't have the capacity to set it up, we can help you. Writing our own documentation of code behavior is a great way to understand it. It can even lead us to discover unexpected vulnerabilities and edge cases.
And a pseudocode specification? I emphasized "plain English" above (as opposed to rigid/formal English) because plain English more clearly expresses what you want the code to do. In contrast, the actual code is often so similar to the pseudocode specification that it can be hard to see when they're both describing something you don't actually want.
Pseudocode has its place and can be particularly useful for precisely describing complex math, but it should always be accompanied by a bit of English about what the math is supposed to accomplish.
2. Clean Code
Refined, well-formatted code is easier to read, reducing the cognitive load needed to review it. A little cleanup will allow us to focus our energy on finding bugs.
- Run a linter on your code. Fix errors or warnings unless you have a good reason not to. For Solidity, we like EthLint.
- If the compiler generates warnings, respond to them.
- Delete any comments that indicate unfinished work (eg. TODOor FIXME).
(This assumes this is your final audit before deploying to mainnet. If not, use judgment on what makes sense to leave in.) - Delete any code that has been commented out.
- Delete any code you don't need.
3. Testing
Write tests! A good goal is a test suite with 100% code coverage.
Review the list of test cases for deficiencies. Are your tests primarily aimed at making sure the 'happy path' works? Write tests to verify that unwanted actions are correctly performed protected against, and that the contract fails correctly instead of landing in an unwanted state.
4. Automated Analysis
Ethereum has many good security scanning tools to help you find some of the most common issues. We use some of these during our audits, but you can also run them ahead of time, which will allow us to spend our time hunting down trickier bugs.
Our MythX, which runs multiple types of analyzes at once, is a great place to start. There are several ways to submit your contracts for examination, including plugins for Remix and Truffle as well as CLI tools for Python and JavaScript. You can find other security tools listed in our Smart Contract Audit Best Practices.
It's not essential, but it helps. One caveat is that you'll often get warnings about issues that don't actually exist. If you're unsure if something is wrong, let us know and we'll assess it during the audit.
5. Freeze Code
At the risk of stating the obvious, you should finish developing your smart contracts before we audition them.
If a change happens halfway through an audit, it means the auditors wasted time on the old code. Additionally, auditors should stop and incorporate the change, which can have far-reaching impacts on things like the threat model and other code that interacts with the changed code.
If your code doesn't be ready by the scheduled start date, let us know. It's better to delay altogether than trying to complete an audit while you continue development.
