Operational Audit Considerations for Smart Contracts
Welcome back to this continuing discussion on audit considerations for smart contracts. In today's blog we will look at the operational audit considerations from Zero Friction's Smart Contract Audit Review process.
Availability of Third-Party Security Audit Report
Perhaps one of the most important operational audit consideration is the examination for the availability of a security audit report. In other words, we want to know if the smart contract has been reviewed by a qualified third-party for any hidden vulnerabilities. Typically the process requires the deployed smart contract be presented as a public repository of specific version where the security auditors can deploy the code into a test environment for their review.
Security audit will likely to involve the use of an automated smart contract analyzer. However, it is important to understand that there is limitation to automated analyzer. Ideally we want to see the use of multiple analyzers vs. one specific analyzer. The analysis should not end there and should be followed with human examination of the coding of the smart contract. Typically the security audit team will likely comprise of two to four individuals and possibly larger depending on the complexity of the application and the underlying contracts.
Keep in mind that the security audit cannot uncover all existing vulnerabilities, and even an audit in which no vulnerabilities are found is not a guarantee for a secure smart contract. However, the audit allows organizations to uncover vulnerabilities that were overlooked during development and areas where additional security measures are necessary.
Upgrade of Smart Contract
Smart contracts are immutable by design. Once you create them there is no way to alter them, effectively acting as an unbreakable contract among participants. However, for some scenarios, it is desirable to be able to modify them such as fixing a programming bug in the contract. The upgrade process must be able to properly handle and migrate any existing states to the new contract without disrupting operations for current users.
The traditional way of upgrading smart contract (based on software development life cycle) is as follows:
Deploy a new version of the contract.
Manually migrate all state from the old one contract to the new one. This approach can be very expensive in terms of gas fees! For example, at the current writing average gas fees on Ethereum is almost $40 per transaction.
Update all contracts that interacted with the old contract to use the address of the new one.
Reach out to all your users and convince them to start using the new deployment (and handle both contracts being used simultaneously, as users are slow to migrate).
From the above steps it is not practical to migrate smart contract using the traditional way. A better approach is through the use of a proxy contract.
As part of standard deployment two contracts are deployed. A proxy contract is what the end users interact with, and implementation contract is the action contract behind the scene. Actions performed by the users with the proxy contract are passed to the implementation contract through the use of a delegate call which allows codes and states to be handled in the context of the caller (proxy) and not of the callee (implementation). Accordingly, only the implementation contract is upgraded to address any contract design and functions, effectively eliminate the needs for Step 2 through 4 under the traditional upgrade process.
Contract Management
The contract owner must maintain access to the smart contract and critical core functions such as fund transfer, pause deposits, and other contract’s emergency circuit breaker mechanisms. This process can be handled using a single-admin or multiple admins. We advocate that smart contracts must be managed by multiple admins as the approach provides significant advantages over the former:
Govern the management of the smart contracts through a majority process.
Offer redundancy and protection against lost/obsolete keys.
Safeguard against actions from a rogue admin (e.g., an insider threat).
Usage of Oracles
Blockchain applications relies on external interfaces (e.g., oracles) to truly bring values to end-users. Modern smart contract design depends on external oracles for real-life data feeds. Oracles has two forms:
software
hardware
Examples of hardware oracles are field devices that monitor temperature and humidity in shipment cargos in case of a logistic application. An example of a software oracles is a price check or an exchange rate pulled from some authority sites.
Since the oracles are not part of the main blockchain consensus, their security mechanism is not safeguarded by the blockchain. In February 2020, the two arbitrage exploits on bZx resulted in a loss of $1 million to the exchange, and highlighted the importance of proper oracle design in smart contract. In both cases, the hacker was able to manipulate the price volatility of a specific asset against the oracle feed in a flash loan smart contract since a single oracle source was utilized. In addition, there was no boundary or limit checks utilized on the data feed which would have flagged an improbable outcome in the price of the asset to disallow the transaction.
Accordingly, we advocate the use of multiple oracles to ensure the accuracy of the data feed supplied. Furthermore, we examine the contract code to ensure that correctness checks are performed to ensure that either the received date or the the computed data are accurate and complete before completing the transaction.
In the next blog, we will close our discussion on audit considerations for smart contracts with a deep dive into technical audit considerations. Bring popcorn. It will be interesting.