A challenge we face when there has been a major upgrade or change to a language or protocol is to bootstrap the experience necessary to audit code in the new language.
Although Cairo 1 is substantially different to Cairo 0, the problem is not as daunting as it might first appear, and we can do more than point out good practices and wait for vulnerabilities to come to light by being exploited.
This article will therefore suggest an approach that can be used now when auditing Cairo 1 contracts.
We can informally categorise the potential issues as
- Smart Contract Issues
- Starknet Issues
- Cairo Issues
Smart Contract Issues
Cairo code runs in a similar context to Solidity contracts, so we can look for issues such as
- Correct Access control
- Sanitising / checking function inputs for validity
- For upgradable contracts ensuring initialisation is done correctly (likely only once, and by an administrator)
Issues that are particular to Starknet that we wouldn’t see on EVM include
- Storage clashes due to name clashes
- The view function decorator not being enforced, allowing unintended state change
- Issues arising from the fact that accounts are handled differently, such as needing to check Ethereum address bounds
- Messaging between L1 and L2 needs checking for authorisation and correct addressing. This area can be difficult to test, and therefore may be under tested.
Cairo specific Issues
The mismatch between datatypes in Solidity and Cairo brings new challenges to developers. In particular the correct handling of the emulations of 256 bit datatypes by splitting a value into ‘high’ and ‘low’ pieces needs care, and the range of values should be checked when using these.
Furthermore arithmetic, particularly that needed for DeFi can be complex and tricky to implement in Cairo, and there are fewer libraries available to help. This also applies to associated comparison operations such as ‘less than, greater than’ , which need greater care than their Solidity counterparts, their inputs should be range checked.