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:
First, Solana’s programming model decouples code and data. This is significant, because it makes Solana smart contracts fundamentally more difficult to attack than blockchains with coupled programming models, such as Ethereum.
Second, Solana’s execution model (particularly the design of various execution constraints) rules out a large category of attacks such as reentrancy; meanwhile it allows more transparent real-time monitoring and more comprehensive security defenses than Ethereum.
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):
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 founded by leading minds in the fields of blockchain security and software verification. Sec3's mission is to create a decentralized future that is secure. Sec3 team is currently building a trustworthy platform for securing Solana projects.