This technical report was written by Alex from the ScaleBit Research Group

0x00 : Introduction

Starknet, a Layer 2 network built atop Ethereum, operates as a Validity Rollup Layer 2, offering high throughput and reduced gas costs while maintaining the robust security levels of Ethereum’s Layer 1. The system’s efficiency stems from its ability to execute computations off-chain, subsequently generating a ZK proof. This proof is then verified on-chain, allowing multiple L2 transactions to be bundled into a single transaction on Ethereum. Smart contracts on Starknet are crafted using the Cairo language and can be seamlessly deployed, enabling users to transmit transactions within this Ethereum-like network.

0x01 : Cairo

Cairo1.0, inspired by Rust, is designed for crafting STARK proofs for general computations and serves as Starknet’s native smart contract language. Starknet, a decentralized Validity-Rollup, utilizes Cairo to power applications on the mainnet, including dYdX, Sorare, and ImmutableX, enabling developers to write secure and efficient contracts.

0x02 : Account Abstraction

Starknet centralizes around account abstraction, where every account is inherently a smart account, eliminating the concept of EOAs. This unique approach across all L1 and L2 chains ensures that all infrastructure, including wallets and block explorers, is tailored for this abstraction. It positions Starknet as the pioneer in a smart ecosystem where developers can build tools and applications knowing this abstraction applies universally, without catering to non-abstracted accounts. This ensures that smart accounts are the sole medium for user-application interactions. Starknet’s native account abstraction also removes the added complexities introduced by Bundlers, as seen in ERC-4337. Instead of adapting infrastructure and tools to interact with Bundlers, the process is streamlined by designating sorters to fulfill the Bundler’s role.

The following diagram illustrates the Starknet transaction flow[1], still drawing inspiration from the design principles of ERC 4337[2].

0x03 : Best pricatise for Starknet security

Access Control:

Issues with access control become evident when a smart contract doesn’t have robust security measures in place, granting access to users who shouldn’t have the authority to execute certain actions. This oversight can result in unpredictable smart contract operations and tampering with confidential information.

Take, for instance, a smart contract designed for creating tokens. If it lacks stringent permission checks, it’s akin to leaving the door open for potential misuse.

In this scenario, the mint function is open for any user to invoke, allowing them to create new tokens. This could pave the way for potential misuse or distortion of the overall token count.

Suggestion:

To address vulnerabilities related to access control, it’s advisable to incorporate robust authorization methods, such as role-based access control (RBAC) or checks for ownership. You have the flexibility to devise a tailored solution or opt for pre-existing frameworks like the ones offered by OpenZeppelin.

Referring to the earlier example, one could introduce an ‘owner’ variable. This owner’s identity would be established during the contract’s initialization. Subsequently, a verification step could be added to the mint function, ensuring that only the designated owner has the privilege to create new tokens.

By fortifying your access control measures, you can guarantee that only those with the right permissions can trigger your smart contract functions, minimizing the chances of unwarranted interference.

Overflow and Underflow

Flow anomalies, namely Overflow and Underflow, are critical considerations in contract programming. Overflow occurs when a numerical computation yields a result that surpasses the storage or representational capacity of a register or memory. A contract susceptible to overflow can exhibit a stark contrast between the anticipated and actual computation outcomes, disrupting the contract’s logic and potentially leading to financial discrepancies. In this segment, we delve into strategies to counteract these challenges in Starknet smart contracts.

Employing the felt252 data type can be problematic. Operations that exceed its valid range can produce erroneous outcomes:

Suggestion:

To sidestep such inaccuracies, opt for fortified data types: Engage with data types like u128 or u256, engineered to adeptly manage overflow and underflow scenarios.

Reentrancy

Reentrancy represents a potential vulnerability in smart contracts, where they inadvertently permit external, unverified code to run within their confines. This risk materializes when a smart contract interacts with another external contract, which in turn, invokes the initiating contract, possibly leading to an endless cycle. Essentially, a reentrancy assault capitalizes on this flaw, enabling malicious actors to incessantly trigger a contract function, setting off an unending loop that could facilitate unauthorized fund withdrawals.

Imagine a gaming contract where only approved addresses have the privilege to create an NFT sword. Once minted, they can activate an sword_received() function to utilize the sword, after which it’s returned to the contract. Yet, there’s a loophole in the NFT contract that makes it susceptible to reentrancy breaches. This flaw could be exploited by a malicious player to continuously produce multiple NFT swords.

A bad actor’s contract could craft the sword_received() function in a way that leverages the reentrancy flaw, enabling them to continuously mint an array of swords.

Reentrancy often finds its application in callback functions . Additionally, in scenarios like flash loans, the lending contract might use callbacks to allow the borrowing contract to utilize and subsequently repay the borrowed amount.

Suggestion:

To safeguard against reentrancy threats, it’s advisable to adhere to the check-effects-interactions paradigm. This means you should prioritize updating the internal state of your contract prior to initiating calls to external contracts. Referring to the provided example, it’s prudent to delist the sender from the whitelist preceding the invocation of the external function.

Adhering to the check-effects-interactions paradigm can significantly diminish the likelihood of reentrancy breaches, thereby preserving the consistency and reliability of your smart contract’s internal framework.

0x04 : CONCLUSION:

In Cairo smart contracts, while common vulnerabilities like reentrancy and access control are addressed, developers should also be wary of other security concerns such as storage conflicts, oracle manipulation, flash loan attacks, and delegate calls. With the ongoing evolution of the Cairo language, the recent release of Cairo 2.2.0[3] ensures most code remains compatible. The transition from Cairo 0 to the latest version has been pivotal in making the language more user-friendly and enhancing security features. However, writing unsafe code is still possible, underscoring the importance of understanding the underlying system, potential pitfalls, and ways to circumvent them.

Reference:

[1] : https://community.starknet.io/t/starknet-account-abstraction-model-part-1/781
[2] : https://eips.ethereum.org/EIPS/eip-4337
[3] : https://community.starknet.io/t/cairo-v2-2-0-is-out/99263

ABOUT SCALEBIT

ScaleBit is a blockchain security team that provides security solutions for Mass Adoption of Web3. With expertise in scaling technologies like blockchain interoperability and zero-knowledge proofs, we provide meticulous and cutting-edge security audits for blockchain applications. The team comprises security professionals with extensive experience in both academia and enterprise. Our mission is to provide security solutions for Web3 Mass Adoption and make security accessible for all.

• Website: https://www.scalebit.xyz/
• Twitter: https://twitter.com/scalebit_