Michelson code reviews - part 2
The recent “Curve Finance” hack, enabled by a compiler bug in Vyper that allowed attackers to extract millions worth of assets, finally motivated us to write this second part to our Michelson code reviews blog.
In our first blog we outlined that our approach for smart contract security assessments on Tezos includes the review of the compiled Michelson code. (Spoiler: more difficult and time consuming for bytecode reviews in EVM.)
Our expe0rience so far has proved this approach to be the most effective to spot even more bugs and flaws: the analysis and the review of the contract code after it is compiled allows our expert reviewers to work directly with the code that will be released, and thus executed, on-chain, allowing them to spot even the more subtle issues and potential mistakes introduced during compilation and optimisation of the high-level language.
In the following paragraphs we will provide a few more examples from our experience, where our Michelson code reviews, conducted during security assessments, identified (security) issues in the code under review.
Besides identifying security issues, performing code reviews on the compiled contract code allows our expert reviewers to also spot potential optimisations that can save on gas costs for both the users and the smart contract creators/administrators.
Here are a few more examples, in addition to the deprecation of decorators already mentioned in our first blog post, of (security) issues that can be identified during our Michelson reviews:
Changed operation order in lambda code: The order of operations has been inverted between one compiler version and a new compiler version.
While the first example could be detected through a good understanding of the programming language and careful review, it could be potentially overlooked. On the other hand, the latter can only be spotted through thorough (on-chain) testing.
Some examples of optimisations that we often spot during our Michelson reviews, instead, include:
- Repeated functions and operations that could be turned into lambdas, to save on the size of the contract (storage cost and deserialization costs reduced)
- Repeated access to storage variables that could be temporarily saved, in order to reduce the number of Michelson instructions required to complete the necessary functionality
To prevent such issues and to identify potential optimisations, our recommended approach includes reviewing the resulting Michelson code, to assure the client that our expert reviewers actually analyzed the exact same code that will, ultimately, be deployed and executed on-chain.
Regarding EVM, we also conducted reviews of the resulting bytecode for some projects. However, due to the bytecode’s larger size and its instruction being more atomic in nature, as well as its complexity in storage and code control handling, these bytecode reviews were only feasible for smaller smart contracts or critical sections of the code due to time and budget constraints .
If you would like to undergo a security review or if you have any feedback, please contact us via [email protected].
