Blockchain Security: The Path to Robust Smart Contract Audits
This is the translation of the article “Segurança em Blockchain: O Caminho para Auditorias de Contratos Inteligentes Robustas” from Bellum Galaxy.
In the previous article titled “Web3 Security: Demystifying Immutability and Raising Code Standards”, we discussed the development of clear and objective smart contracts. Today, we’re going to talk about the smart contract audit process.
What is an Audit?
An audit is a meticulous and systematic analysis of a document or organization, aimed at identifying discrepancies between expected and actual functioning. The goal is to ensure the effectiveness of what is being audited.
Smart Contract Audit
In the context of smart contracts, the audit seeks to identify deviations, vulnerabilities, and inefficiencies to enhance security, efficiency, and readiness for production.
However, by being a costly process, many people mistakenly think that an audited project is vulnerability-free. Regardless of the number of audits, vulnerabilities can remain unnoticed. I invite you to pause your reading and visit rekt.news, which lists various exploits that have caused massive losses over the years. Many of these cases were audited, which did not prevent the incidents. On the other hand, Solodit lists numerous exploits identified and avoided during audit processes.
Audit Preparation
Preparation is crucial. Having a GitHub repository with unit tests does not mean being ready for an audit, especially if basic development standards are not followed.
Before considering an audit, answer the 12 questions of the Rekt Test. Then, explore the steps for preparation to maximize the return on investment in audits:
Basic Project Information
Provide information such as the project’s name, website, documentation, and contacts so the audit team can ask questions.
Code Details
Provide the link to the repository and the commit hash that should be audited. The number of contracts in scope, the total lines of code, code complexity, as well as whether your project interacts with external sources. Finally, the percentage of your tests’ coverage.
Contracts within the Audit Scope
Inform all contracts to be audited:
#-- src
| #-- Contract.sol
| #-- Contract.sol
| #-- Contract.sol
| #-- Contract.solProject Details
Describe interactions, features, and other relevant aspects. For example:
- Is the project a fork of another existing project?
- Does the project use rollups?
- Which blockchains will the contracts operate on?
- Does the project use oracles?
Project Risks
Inform the acceptable risks for your project. For example:
- Should we consider risks related to centralization?
- Should we consider risks related to “weird ERC20s”?
Known Issues
What are the problems that have already been identified, and that are outside the scope of this audit? An error in access control that is already being corrected, for example.
Audits & Previous Reports
Provide reports from previous audits.
Project Flowchart
Provide the project’s flowchart. Understanding the context and the normal flow of the project helps to find possible vectors of vulnerabilities.
Project Explainer Video
This step complements the previous one and facilitates the auditors’ familiarization with your project. Be thorough, this video is not an Elevator Pitch; take the necessary time to explore the code.
Others
Inform any other material such as articles, videos, images, or documents that may facilitate the understanding of the project.
Post-Deploy Plan
Will a Bug Bounty Program be created? How will the project monitoring be done? Who is your emergency response team?
Beginning of Audit — First Phase
The audit journey begins with the specialized team taking the reins. The development team must stay alert and available for any communication. Auditors may request additional clarifications at any time, so it is crucial to keep communication channels open and responsive, ensuring an efficient exchange of information. This is a period of intense diligence, where auditors dive deep into the code and documentation to ensure no detail is overlooked or left behind.
Implementation of Corrections — Second Phase
After the initial analysis, the audit team will share a detailed report, highlighting the vulnerabilities found, suggestions for resource optimization (such as gas savings), and improvements in code clarity. This stage is critical for the development team, which must meticulously implement the recommended corrections. It’s a moment of technical rigor and attention, where each adjustment must be made carefully to avoid introducing new vulnerabilities in the process. Continuous collaboration and double-checking are key to the effectiveness of this phase.
Final Review and Conclusion — Third Phase
With the corrections applied, the audit enters its final phase. Auditors return to the starting point, reviewing the modified code to ensure that all identified vulnerabilities have been properly addressed and that no new issues have been inadvertently introduced. This review cycle is crucial for the final integrity of the project, ensuring that the modifications do not compromise the security or functionality of the smart contract. Once the audit team is satisfied with the state of the project, a final report is issued, marking the conclusion of the audit. This document serves as a seal of diligence, indicating that the project has been scrutinized and improved under the guidance of experts.
Conclusion
Although the audit is conducted by external experts, the primary responsibility lies with the development team. Clarity and objectivity in sharing information and supporting materials, and following development standards are essential for the project's success. The efficient use of resources, including the audit’s investment, is crucial.
I encourage independent auditors to create forms based on the provided questions to facilitate audit preparation.
