Taking stock of the "routines" in DeFi contract audits, have you fallen into the trap?

Before the DeFi project is officially deployed, the security audit of the contract can not only conduct a global check on the project's code specifications, vulnerabilities, and business logic, but also play a certain role in shaping the image of the project party in the investment market.

When market investors select projects, if the project party has contract audit experience and publicly discloses information such as the auditor and audit report, the credibility of the investment will undoubtedly be greatly improved. In addition, the project party's perfect security stance construction awareness will also invisibly give the project additional value.

At the same time, DeFi project parties should maintain long-term business cooperation with security audit companies during their operations, which will be of great benefit to both security management and business expansion. After all, in the long-term development of the project, the phased security audit mechanism can timely discover and effectively help solve overall and local risk problems.

So, what are the main processes, contents and characteristics of DeFi contract audits, and what are those "routines"?

Routine 1: "Pulse diagnosis" in the early stage

After reaching a contract audit cooperation relationship with the DeFi project party, we will assign a security testing team with relevant project audit experience to provide special services based on the overall situation of the project, including architecture, business design, etc. At the same time, we will clarify the scope of project testing and the focus of corresponding needs. The main contents of the early "pulse" include:

1. The DeFi project party shall provide authentic and effective technical, code, document and other information required for the audit.

2. Before officially entering the testing phase, the security team will conduct a comprehensive assessment of the provided materials to determine the cycle.

3. Determine the scope of testing services, including targeted modules, local codes, comprehensive security audits, etc.

4. Complete the relevant requirements, that is, the final confirmation of source code, application program, file information, and test environment.

In order to conduct strict security audits on the code standardization, security, and business logic of DeFi project contracts, after the test is clear, the conventional ways to handle contract audits are:

• Formal Verification

• Static Analysis

• Dynamic Analysis

• Typical Cases

• Manual review

Routine 2: Formal Verification

Formal methods are the most reliable means of achieving secure and trusted software. They use mathematical symbol systems to give strict definitions and formal proofs of software correctness and security. Among them, strict definitions are called formal specifications, which are logical expressions that describe software functions or characteristics in a clear and concise manner.

In contract auditing, formal methods use qualitative requirements to prove that a program does not have a certain type of security vulnerability. On the other hand, traditional testing methods use checking whether the code runs as expected on a set of selected inputs to show whether the program has a security vulnerability, but this cannot prove that the same type of security vulnerability does not exist.

In addition, traditional testing methods can easily miss errors triggered in rare or malicious scenarios, as well as errors caused by a large number of "impossible events" occurring in succession. However, formal methods can discover these subtle errors by clarifying the intent of the code and providing complete coverage of the input space, thereby enhancing the security and reliability of the program.

Professor Yang Xia, the founder of Chengdu Lianan and an expert in formal verification research for many years, said,

“Traditional verification methods cannot exhaust all possible situations, but formal verification can do so. This method is the most reliable and effective for smart contract vulnerability detection.

As a customized tool developed for Ethereum smart contract security testing, Chengdu Lian'an's Beosin-VaaS one-click smart contract automatic formal verification tool can accurately locate the code location containing risks and point out the causes of risks. It can effectively detect common security vulnerabilities in smart contracts with an accuracy of more than 97%, providing "military-grade" security verification for smart contract codes. "

Routine 3: Code Standard Audit

In the code standard audit, the main test items are:

Compiler version issues may cause various known security issues. Developers should specify in the code that the contract code uses the latest compiler version and eliminate compiler warnings.

At the same time, the Solidity smart contract development language is in rapid iteration, and some keywords have been deprecated by the new version of the compiler, such as throw, years, etc. In order to eliminate the hidden dangers that may be caused, the keywords that have been deprecated in the current compiler version should be disabled.

In smart contracts, redundant code reduces code readability and may require more gas for contract deployment, so it is necessary to find and eliminate redundant code. In addition, whether the functions in the SafeMath library are used correctly for mathematical operations in the contract needs to be strictly checked.

Solidity handles errors using state recovery exceptions, which undo all changes made to the state in the current call and all its children, and flag an error to the caller.

The functions assert and require can be used to check conditions and throw exceptions when the conditions are not met. The assert function can only be used to test internal errors and check non-variables. The require function is used to confirm the validity of conditions, such as whether input variables or contract state variables meet the conditions, or verify the return value of external contract calls.

The Ethereum virtual machine consumes gas to execute contract code. When the gas is insufficient, the code execution will throw an out of gas exception and cancel all state changes. Contract developers need to control the gas consumption of the code to avoid function execution failures due to insufficient gas.

In addition, whether the visibility of the contract function meets the design requirements and whether the fallback function is used correctly in the current contract need to be strictly checked.

Trick 4: DeFi security vulnerability audit

Currently, business logic vulnerabilities are the most common in DeFi projects. Due to the imprecise design of the project's business logic, it is very likely to cause internal imbalances in the project under certain circumstances.

It should be noted that DeFi projects are developed based on blockchain smart contracts and have many features beyond the traditional financial system, such as:

• A single transaction can initiate multiple internal transactions, and can be rolled back if failed

• Deflationary Tokens

• The contract code cannot be modified

At the same time, contract permission errors are also common in audits, that is, visibility modification errors of functions in contracts. Usually, this is due to the lack of effective verification of callers and parameters, resulting in functions being called by malicious users, causing huge losses.

Similar to traditional security issues, incorrect permission configuration and invalid security checks will bring huge risks to the system. However, the difference is that the immutability of smart contracts means that such problems may not be effectively fixed even if they are discovered.

In addition, reentrancy vulnerabilities are also a focus of the audit. Specifically, when a contract initiates a call to the outside, the attacker can use the characteristics of the contract call to repeatedly call the function, causing errors in the expected execution order of the contract, thereby stealing the assets of the target account.

In the audit, code errors also occur frequently. This is mainly due to some coding errors caused by the mistakes of developers. Common ones include unit errors, forgetting to multiply precision, and usage errors. In the YAM vulnerability incident, the code forgot to multiply precision when performing elastic adjustment rebase, as shown in the figure:

While ensuring in-depth detection of codes and vulnerabilities, the project business also has relevant audits on business logic and implementation, including inspections of basic information of tokens involved in DeFi projects and confirmation of functions related to token standards, especially the review and risk analysis of minting, destroying tokens, changing owners and other special permissions.

Many projects have the logic of proxy transfer. When dealing with this logic, many project parties will directly ask users to authorize the maximum value of tokens to the project party’s contract, as shown in the following figure:

In this way, the contract has the right to transfer all the user's funds. In addition, there is the problem of double authorization. When the project party's website is authorized, it initiates two authorizations, one to the contract address and one to the external address. If the user is not careful about this, he will face great financial risks.

Routine 5: Audit Report

Contract auditing ultimately serves the security of funds in DeFi projects, and many problems in this regard are related to improper functions and algorithms. Therefore, contract auditing is to point out the content that may cause financial risks, that is, potential risks and problems such as code, vulnerabilities, and logic that need to be corrected urgently.

In addition to basic information such as the audit time, duration, and auditor, the audit report will also reflect investment warnings for the project. The core content of the audit report is to reflect the audit results of the inspected smart contract in multiple aspects and dimensions such as design and code implementation. At the same time, the report will point out various risk issues found and inform the project party for repair.

Through the audit report, the risk components of the contract, including potential attacks and vulnerabilities at different levels and levels, will be detailed. However, the eye-catching word "pass" in the security audit report should not be the only basis for investors to make investment decisions.

Conclusion

Contract audit is not good news for the project itself, but a necessary security work before going online, which is of great significance to both the project party and investors.

The speculative market may be violent or depressed. If you do not follow the routine, you will eventually be subject to the "routine". A quick glance at it shows that only the peak of safety, which is to prevent trouble before it happens, stands tall.