Provide some insight on the importance of smart contract security audits from the perspective of a project development team and community members. This article, like the last, will remain relatively high-level to appeal to the layman’s crypto user.
The first part is directed at Development Teams while the second part is directed at anyone that interacts with a contract address (though I highly suggest both groups read both parts!) In the previous article for this series, 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 the last 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.Dear Project Development Teams:
Your projects are important to you. Your code-base, sacred in elevating your idea to actualization, and the its flawless execution vital to its success. Code is King. Essential to that success is security.
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 really should get an expert opinion.
This concludes the first part of this blogpost. In it, I’ve demonstrated to the developer community the importance of having an audit done, touching the three major points that
(1) Developers generalize chunks of code, making strict scrutiny unlikely. By knowing their code like the back of their hand, it becomes impossible for them to see their own code for the first time and scan for vulnerabilities.
(2) There is much on the line when launching a contract. Both from the perspective of the code-illiterate users that put massive amounts of value in the hands of a team, and the reputability of a project that hinges on the safety of its users’ funds.
(3) Successful auditing practices are built on experience, procedures, and a critical mentality. With iterative best-practices and a developed skill-set, auditors are able to leverage their focused past for the purpose of auditing.
In the next installment, I will show how an audit is advantageous to the community — I.e. Any individual that interacts with a blockchain project and smart contract code.