Smart Contracts Review Journey at Functori

What Are Smart Contracts?

Smart contracts are computer programs intended to be deployed and stored on decentralized, digital, transparent, traceable, and irreversible ledgers; at least for public blockchains. A smart contract instance has a state and a set of entrypoints, a sort of public functions, that allow users and other smart contracts to interact with it. Think of a smart contract instance as a RESTful API server where the backend database is the contract's state, and the API's endpoints are the exposed entrypoints.

A deployed smart contract's code is public, meaning anyone can audit it. It is generally immutable, unless some upgrade policy is implemented. Anyone can call its entrypoints, unless explicit restrictions are pre-defined on some of these entrypoints based, e.g., on the caller's cryptographic address.

Smart contracts simplify the exchange of digital goods and services without the need for intermediaries such as banks, notaries, or centralized systems. They have the potential to revolutionize various industries by streamlining processes, reducing costs, and increasing efficiency.

Why Review/Audit Smart Contracts?

Depending on what they are used for, software quality may or may not be an essential matter. For instance, we put a different level of requirements and rigor for a video game compared to banking, airplane, or space rocket software. In fact, an integer overflow in the former would simply lead to a lousy user experience, while it could imply significant human and financial losses in the second. A smart contract that manages a large amount of valuable assets should clearly be classified in the second category.

Let's consider the REST API server example again. When designing or deploying a server, we generally start from a situation where no one can access the services. We then define an access policy (e.g., logical roles and/or machine configuration). Once the rules are written, we can analyze them to see if they are too permissive or restrictive.

On the contrary, smart contracts are primarily designed to be executed in an open environment: both the code and the access policy are public and replicated on several machines. Even if the developer strives to define a consistent access policy, a minor approximation — that would be hurtless for a Web2 centralized architecture — potentially leads to a disaster in the decentralized world of Web3. The DAO's reentrancy bug and the Parity's library self-destruct flaw are typical examples of this claim.

To conclude this section, because smart contracts evolve in an open environment, they don't benefit from a defense-in-depth strategy usually used to secure Web2 infrastructures. Hence, auditing the code is all the more critical.

Our Auditing Process

Regardless of the targeted blockchain, virtual machine, or language, our process for reviewing smart contracts is the same: first, if some documentation or specification is provided, we read it carefully to understand the smart contracts' expected logic and capabilities. Then, we walk through the code to get familiar with it. Generally, it's the phase where we identify the contracts' storage and entrypoints. Depending on the complexity of the logic underlying the smart contracts, we also infer our own specification.

The actual code review phase can then start. We explore the contracts' call graph and carefully read each expression of each function. This phase, which is repeated many times, aims to find flaws in the contracts' logic (compared to the reference specification) or potential bugs due to misusing some language features (e.g., use of Michelson's maps instead of big maps, reentrancy, overflows).

During the phase above, we start a draft report and take notes about our findings. This allows providing feedback to developers proactively so that they begin fixing the code. In some situations, we write tests to confirm a suspected bug. We also redo the calculations if the code involves some non-trivial mathematical formulas.

Our reviews are always conducted by a team of at least two or three engineers. Once we finish the review phase, we polish the draft report and send the final version to the Client. To give an idea, you may want to have a look at the FlameDeFi DEX Smart Contract Review report, which has been made public by FlameDeFi team.

A Feedback From our Conducted Reviews

The most critical bugs are often related to contract logic, and finding those bugs is hard to automate. However, as an example on the simpler side of things, let's provide two of the most frequent error patterns in the contracts we have reviewed so far, and which can be systematically checked for:

• The use of Tezos' sets or maps instead of big maps: tagged as a high or critical issue based on the context, this misuse of Michelson's storage collection could lead to blocking either a user's or the entire contract's assets in the worst case, or to a high gas fee incurring storage deserialized at each call. This is all the more dangerous as unit or small integration tests do not allow spotting this class of issues. As a takeaway, developers should know that Michelson's sets and maps, when they appear as fields of a contract's storage, are fully deserialized at each entrypoint of view invocation. This costs gas, which is bounded and raises the paid fees. On the opposite, big maps are lazy structures. Their values are dynamically fetched from the context on request.

• The use of the abs: int -> nat primitive to convert integers to natural numbers: also marked as critical; this misuse of conversion functions enables breaches that may lead to asset theft from the contract. In fact, developers in such situations don't always consider the consequences if the abs' parameter is negative. For such conversions, is_nat: int -> nat option should be preferred. This function returns None if the argument is not positive, which obliges developers to handle this particular case and think about it.

Conclusion

To conclude this post, we really enjoy reviewing smart contracts and helping projects get more confidence in their dApps. If you have some application that you would like to get reviewed, don't hesitate to hand it over to our experts.