Since the beginning of this year, the Solana ecosystem has been in a state of rapid development. Particularly, the significant surge of SOL in the past few weeks has refocused attention on this established project. The launch of liquidity staking projects like Marinade Finance, Lido, and Jito has doubled Solana’s Total Value Locked (TVL) compared to the beginning of the year. Collaborations between Solana and entities such as Visa and Shopify have shown users and investors the enormous potential of integrating the Solana ecosystem with real-world consumer applications.

Currently, an increasing number of developers are engaging in building within the Solana ecosystem. In October, Beosin was invited to be a partner at Solana Hackerhouse Shanghai, sharing secure development practices with developers. In this article, Beosin will elucidate secure practices for developing Solana smart contracts, enhancing the security of project smart contracts.

Characteristics and Risks of Solana Accounts

In Solana’s design, all information is stored in account objects, categorized into three types:

1. Data accounts used for storing data, which are further classified into system-owned accounts and Program Derived Addresses (PDAs).

2. Program accounts used for storing executable programs, i.e., smart contracts developed and deployed by users or Solana’s official team. It’s important to note that Solana’s smart contracts can be updated or destroyed.

3. Native accounts referring to programs on Solana. These are smart contracts generated by nodes upon deployment and cannot be updated/destroyed by regular users. However, similar to other smart contracts, they can be invoked by contracts/RPC.

Note: Solana’s programs are essentially similar to smart contracts on other blockchains mentioned in the text.

The comparison between Solana and Ethereum accounts is illustrated in the figure above:

From the diagram, it’s evident that Solana’s unique account model separates data resources and executable programs, enabling swift processing of concurrent transactions. However, the challenge for developers lies in handling relationships between accounts securely. Developers need to be mindful of the following risks related to accounts:

1. Lack of account dependency verification

For a Solana project, different business scenarios entail different hierarchical structures, and there exist dependency relationships between data accounts across these structures. Developers need to precisely understand the dependency between contracts and data accounts and implement constraints to prevent attacks via forged data.

2. Lack of account data verification

During the execution of certain instructions, it’s crucial to verify accounts to ensure the accuracy of the interacting data objects/programs. Solana’s contract developers might overlook consistency checks for the addresses of interacting data/programs.

As depicted in the figure, the main program should verify the address of an external program before invoking it. Otherwise, hackers can launch attacks using malicious external programs.

Solana Smart Contract Security Practices

Apart from mitigating risks associated with Solana accounts, adhering to the following security practices can enhance security while developing smart contracts and running projects:

1. Set up emergency modes

Any smart contract may have undiscovered vulnerabilities. Thus, the project development team should set up an emergency mode within the contract and devise risk mitigation plans to forcibly pause contract operations and fix vulnerabilities when risks arise.

2. Preferentially use the Anchor development framework.

The Anchor framework already contains numerous mature code templates and supports checks on most Solana features, helping to prevent many commonly overlooked detail errors. For instance, when making cross-program invocations using the ‘Program<’info, T>’ type, Anchor aids developers in verifying the address of the called external program. Therefore, for Solana contract developers, we strongly recommend considering using the Anchor framework for contract development in most scenarios.

3. Pay attention to mathematical-related issues

Rust, when handling integer division, truncates the decimal portion, prompting developers to consider precision issues in complex calculations. Developers should round results up/down based on real-world scenarios or apply specific treatment to the computed data. To address integer overflow concerns, it’s recommended for developers to utilize SafeMath or add overflow checks in the Cargo.toml for release mode.

4. Reentrancy check

Solana supports cross-program invocations with a current depth limit of 4, preventing programs from potentially being called from an intermediate state, disregarding the possibility of being called back itself. While Solana’s smart contracts are difficult to attack through reentrancy, it’s advisable for developers to conduct reentrancy checks.3.

5. Solana CLI account closure

If developers use Solana CLI to close a program, they should note that the program account cannot be restored through an upgrade or redeployment.

6. Distinguish types

In Solana contract development, account data is fundamentally a byte array, deserialized by programs into custom account types. If there’s no distinct method to differentiate account types explicitly, programs might use account data beyond the expected parameters.

In the case above, both AdminConfig and UserConfig types possess similar data structures, allowing the UserConfig type to be passed as AdminConfig. This means that as long as the public key stored in the account data matches the transaction signer’s administrator, the admin_instruction command will execute even if the signer isn’t actually the admin.

Developers should conduct authentication and then specify the admin_config type as AdminConfig using ‘Account<’info, AdminConfig>’, applying #[account(has_one=xxx)] to verify the transaction context’s account permission dependencies.

7. Smart contract audits

Auditing smart contracts involves systematic testing and review of contract code to identify potential security vulnerabilities, eliminate risks, ensure the absence of logic flaws, and ensure the code adheres to expected operational procedures and results. Beosin previously completed a security audit for Solana’s NFT project Space Runners within the Solana ecosystem to ensure secure project operations.

Summary

The Solana developer community continues to grow, with Beosin’s prior support of Solana Hyperdrive’s global online hackathon successfully conducted, providing security assistance for the entire Solana ecosystem. Due to Solana’s unique account design and the use of Rust as a development language, there might be oversights concerning code security when developing related smart contracts. Developers can enhance the security of their contracts by following the aforementioned security practices, avoiding common errors and vulnerabilities.

Hence, it’s recommended for projects to seek professional security audit companies for comprehensive security audits before going live.

Contact

If you need any blockchain security services, welcome to contact us:

Official Website Beosin EagleEye Twitter Telegram LinkedIn