The first half of this topic is directed at Development Teams while the second half is directed at anyone that interacts with a contract address (though I highly suggest both groups read both parts!) In What is a Smart Contract Security Audit, I talked in some depth about the current take on security in the blockchain space. Notably, security is currently under-emphasized even though decentralized applications (dApps) are coded in immutable smart contracts, putting vast amounts of value at the mercy of a few flaws. I also introduced the Audit, a method used to ensure system integrity by looking through contracts with a fine-toothed comb for the express purpose of finding vulnerabilities. Here, I will expand on the topics covered in that article (I implore you to read it if you have not!) but from the perspective of its value for project developers and general community members that interact with any contract address. This installment will concern itself with the developers.
Recall an instance in which you were writing something important. After the content was written, you’ve studied the material with great attention, looking intently for flaws: Spelling errors, an improper grammar splice, a missing word, etc. Satisfied with your robotic analysis, you send off the email/letter/message and the instant you do, you spot an error. You’ve written waht instead of what in the second sentence. Wonderful. How did you miss such a simple error given your meticulous investigation? The short answer is that the brain is complex and requires substantial energy to function. As a result, your brain has adapted to shortcut certain functions like scrutinizing each and every word for flaws. Instead, your brain generalizes information. It takes a slice of an instance and projects what it should be, based on knowledge, your past experiences, and expectations. By preemptively stitching up a picture of what should be, your brain can handle higher order tasks like comprehension and analysis — Useful for developers writing complex code! Take this as a cautious example: The letters of each word are jumbled up, but the first and last letter are correct. You’d be hard pressed to find an English-speaker who couldn’t understand the message (contingent only on an individual’s mastery of the English language). We are able to abstract the letter-by-letter stitching of the word to a brain subroutine that can reorganize what is there to what it should be. Even an algorithm optimized for language processing would not have the success rate that humans do. This brain process proves especially deadly for the developers due to the complexity of their task. Smart Contracts are complex in nature and Solidity is an odd language. To quickly stitch together a view of how a contract is built without getting into the weeds, developers must be able to generalize large swaths of logic. They do so by structuring code and scripts in unique ways that is productive for generalizing information. The ability to abstract certain functions of a program make it extremely difficult to theorize execution in unintended ways and so ways to exploit code are illusive. For similar reasons, internal audits may not capture all vulnerabilities either, as the team is likely to understand what the intent behind the script and glaze over swaths of code otherwise notices by third parties. This phenomenon must be understood as a dangerous roadblock to securing a contract. By offloading the work to a qualified pair of eyes that do not suffer from generalization blindness, the risks against your valuable project are drastically reduced.
In other words: It is impossible to trick the brain into thinking it is seeing something for the first time if it has been involved from the start! A fresh set of eyes is essential.
Let’s briefly touch on what is at stake when deploying a contract on the Ethereum blockchain. To do this, consider the November Parity Wallet Hack, a notable breach of security within the crypto community. (I say notable because 513,000+ Ether was frozen from access.) TL;DR: Parity used a library contract already on the Ethereum blockchain as a means to optimize gas usage for their multi-sig wallets. However, a function in the Parity code, if properly called, allowed for anyone to turn that library contract into a personal wallet. This wallet can then be suicided, wiping all data stored in the library-turned-wallet. This is exactly what happened, and all the multi-sig wallets stored in the library address were wiped and funds inaccessible. ELI5:A flaw in the code was exploited by a Solidity noob and hundreds of millions in USD were wiped out by a few cents. What are we to learn from this case? There is a lot on the line when considering the security of code. Malicious agents (or even naively stupid enthusiasts) do not suffer from the blindness that I described above and can/will exploit those flaws. Whether you are a small project aiming to add minimal value in your little corner or a huge wallet that is used by projects to hold their token sale funding, you are responsible is twofold:
You have an ethical responsibility to secure your contracts to the best of your technical/financial abilities in order to secure the safety of your users’ funds, as they’ve put their trust in your project. In a place with naive hopefuls who don’t do their appropriate research, we’ve heard tell of cases where people have put more money than they should into crypto. While the ultimate responsibility falls unto them, it is a team’s obligation to protect users in whatever way they can.The reputability of your own project is on the line whenever you publish a contract to an address. A flaw that becomes exploited severely diminishes the credibility of your blockchain solution. No matter how much effort you’ve put into securing your contracts, one unnoticed vulnerability will plant seeds of doubt in the minds of users. Such a vulnerability can stain months or even years of dedicated work. Conversely, third party audits that provide details reports of identified vulnerabilities and fixes gives users the peace of mind they need to know a thorough review has been done, as the results are transparent.
In other words: There is a lot on the line, both ethically and for the sake of your project. Development teams do not want to skimp on security measures.
To complete a successful audit, auditors need to have a different mentality from a developer, moving from a “Does it work” to “Can I break it” mindset. To capitalize on this mindset, there also exist certain procedures and steps so auditors can do their work effectively, similar to development teams that have roadmaps and protocols to ensure the success of their project. These processes are vastly different for the developer and for the auditor. A key distinction is that the audit process is predicated on the advantage that being an auditor has: Auditors have no previous interaction with the contract code-base and do not suffer from generalization blindness. Professional services firms have been able to set and iterate on these procedures to establish best practices in the auditing space. Each client and project allows for the firm to build on their process: Tweaking, adjusting, and innovating from each experience. In time, the auditor starts to build soft and hard skills specific to his/her craft; skill undeveloped by a developer. The auditor is now able to look in the right places, prod the right elements of code, notice patterns from previous projects, and intuitively get a grasp for unseen vulnerabilities. This plays a key role in the advantage of an audit. Auditors, trained for the tasks of specifically auditing through a specific lens and steps, learn and iterate their methodologies and are able to pull from previous experiences as their knowledge-base to provide the best possible audits.
In other words: You should get an expert opinion.