While Solana’s core runtime is still under rapid development, its design of smart contracts has been fairly stable. In this article, I’d like to elaborate why Solana is more secure from the perspective of smart contracts.
At a high level, there are two main reasons:
Consider a smart contract containing an arbitrary security flaw, say, it has a buggy function X that allows an attacker to change the owner of the smart contract.
In Ethereum, owner is a global variable that is one-to-one associated with the smart contract, such that calling X will directly change the “owner”.
In Solana, owner is a piece of data associated with an account instead of the smart contract. The owner is not global, but there can be many accounts and owners. To change the “owner”, the “right” account must be supplied when calling X.
In other words, in order to exploit this security flaw, an attacker must not only find the buggy function X but also prepare the “right” account to call X.
In reality, preparing the “right” account is non-trivial because a Solana smart contract typically deals with multiple input accounts and enforces their “relationships” by constraints, e.g., account1.owner==account2.key.
The attacker must prepare all those input accounts and satisfy all their constraints, which (if not impossible) typically requires creating “fake” accounts through additional transactions.
Importantly, the gap from “preparing the right accounts” to “launch the attack” permits security monitors to proactively detect suspicious transactions that create “fake” accounts related to the smart contract before the attack.
Attacking Solana smart contracts typically requires two phases: account preparation and attack execution. The first phase can be detected by on-chain monitoring, allowing time to throttle the second phase.
Solana runtime enforces various constraints at the transaction level, such as
Solana’s CPI design essentially eliminates the possibility of reentrancy attacks. Whereas Ethereum relies on application-level states to restrict reentrancy, which is error-prone.
Logging enables observing a smart contract’s runtime behavior in real-time, which is the building block of fine-grained security monitors.
Solana allows orders of magnitude more on-chain logging than Ethereum (msg! vs emit).
Logging is expensive on Ethereum. A single logging operation (emit) costs hundreds or even thousands of gas (see doc): gas_cost = 375 + 375 * num_topics + 8 * data_size + mem_expansion_cost
In contrast, logging is cheap on Solana (100 compute units cost by a system call). Considering the 1.4M max compute budget, a Solana transaction can allow tens of thousands of logging operations.
Even regardless of gas price, an Ethereum smart contract cannot do much logging due to its gas limit (this explains why logging is rare on Ethereum).
Compared to Ethereum, the intensive logging capability makes Solana promising to embrace more comprehensive security defenses against attacks.
sec3 is a security research firm that prepares Solana projects for millions of users. sec3’s Launch Audit is a rigorous, researcher-led code examination that investigates and certifies mainnet-grade smart contracts; sec3’s continuous auditing software platform, X-ray, integrates with GitHub to progressively scan pull requests, helping projects fortify code before deployment; and sec3’s post-deployment security solution, WatchTower, ensures funds stay safe. sec3 is building technology-based scalable solutions for Web3 projects to ensure protocols stay safe as they scale.
To learn more about sec3, please visit https://www.sec3.dev