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
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.
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.
Lack of (or even less) support for strings can lead the developer to make mistakes.
Generally the most most common exploits are
Economic (for example manipulation of price),
Application logic errors
Poor access control.
The number caused by a language feature is relatively small. That being said, developers coming to a new language are more likely to make mistakes, or use inappropriate designs.
It is fair to say that Cairo 1 security is likely to be benefit from the rust inspired features it has such as borrowing / ownership, better error handling, and the improved developer experience may lead to more robust code.
In time we will see Cairo 1 specific issues, but until then we can still provide meaningful audits of Cairo 1 projects using our existing experience.