Solana is a high-performance blockchain platform designed to support dApps, known for its speed and scalability achieved through unique consensus mechanisms and architecture design. This article will briefly introduce the characteristics of Solana’s smart contract programming model, with Ethereum as a point of comparison.
Smart Contracts and On-chain Programs:
Programs running on Ethereum are called smart contracts, which are a series of code (functions) and data (state) located at a specific address on the Ethereum network. Smart contracts are also Ethereum accounts, known as contract accounts, which have balances and can be the target of transactions. However, they cannot be controlled by individuals and are deployed on the network to run as programs.
Executable code running on Solana is called on-chain programs, which can interpret the instructions sent in each transaction. These programs can be deployed directly to the network core as native programs or published by anyone as SPL programs.
Instructions: Instructions are unique terms for on-chain programs in Solana. On-chain programs are composed of instructions, which are the smallest units that perform specific operations. Each Solana transaction contains one or more instructions. Instructions specify the operations to be executed, including calling specific on-chain programs, passing accounts, input lists, and providing byte arrays. Instructions have computational limits, so on-chain programs should be optimized to use fewer computational units or split expensive operations into multiple instructions.
Native Programs: These are the native programs that provide the functionality required by the validating nodes. The most famous among them is the System Program, which is responsible for managing the creation of new accounts and transferring SOL between two accounts.
SPL Programs: These programs define a series of on-chain activities, including token creation, exchange, lending, creating staking pools, maintaining on-chain domain name resolution services, etc. Among them, the SPL Token Program is used for token operations, while programs like the Associated Token Account Program are commonly used to develop custom programs.
Account Model and Data Decoupling:
Similar to Ethereum, Solana is also a blockchain based on the account model. However, Solana provides a different account model from Ethereum and stores data in a different way.
In Solana, accounts can store wallet information and other data, and the fields defined for accounts include Lamports (account balance), Owner (account owner), Executable (whether it is an executable account), and Data (data stored in the account). Each account specifies a program as its owner to differentiate which program’s state it is used to store. These on-chain programs are read-only or stateless. Program accounts (executable accounts) only store BPF bytecode and do not store any state. The state is stored in other independent accounts (non-executable accounts). Therefore, Solana’s programming model decouples code and data.
On the other hand, Ethereum accounts mainly refer to the EVM state, where smart contracts exist with both code logic and user data. This is often considered a design flaw inherited from the history of EVM.
This difference should not be underestimated. Solana smart contracts are fundamentally more difficult to attack than blockchains with coupled programming models like Ethereum. In Ethereum, the “owner” of a smart contract is a global variable that corresponds to each smart contract. Therefore, calling a certain function may directly change the “owner” of the contract. In Solana, the “owner” of a smart contract is associated with the account data, not a global variable. An account can have multiple owners, instead of a one-to-one association. To exploit security vulnerabilities in smart contracts, attackers not only need to find problematic functions but also need to prepare the “correct” accounts to call those functions. This step is not easy because Solana smart contracts usually involve multiple input accounts and manage their relationships through constraints (e.g., `account1.owner==account2.key`). The process from “preparing the correct accounts” to “launching an attack” is enough for security monitors to proactively detect suspicious transactions creating “fake” accounts related to smart contracts.
In comparison, Ethereum smart contracts are like a safe with a unique password. Once you have the password, you gain complete ownership. On the other hand, Solana smart contracts are like a safe with many passwords, but to gain access, you not only need to obtain the password but also identify the corresponding number for that password to unlock the lock.
Programming Languages:
Rust is the primary programming language for developing smart contracts on Solana. Its performance and security features make it suitable for high-risk environments like blockchain and smart contracts. Solana also supports C, C++, and other languages, although they are less common. The official SDK provides Rust and C support for developing on-chain programs. Developers can use tools to compile programs into Berkeley Packet Filter (BPF) bytecode (with .so extension) and deploy them on Solana. The execution of smart contract logic is done through the Sealevel parallel smart contract runtime.
However, due to the high learning curve and the fact that Rust is not specifically tailored for blockchain development, many requirements need to be implemented from scratch, resulting in code redundancy. Many new programming languages designed specifically for blockchain development are based on Rust, such as Cairo (Starknet) and Move (Sui, Aptos). In production, many projects use the Anchor framework created by the Armani team to simplify development.
On the other hand, Ethereum smart contracts are primarily developed using the Solidity language (which has syntax similar to JavaScript, with .sol extension for code files). Due to its relatively simple syntax and more mature development tools (such as the Hardhat framework and Remix IDE), Ethereum is generally considered to provide a simpler and more enjoyable development experience compared to Solana, which has a higher learning curve. Therefore, despite the current popularity of Solana, the number of Ethereum developers is still much larger.
In certain situations, a top-level race car runs faster than a modified car. Rust is like a top-level race car, providing strong guarantees for Solana’s performance and security. However, it is not specifically designed for on-chain program development, which actually increases the difficulty of driving (development). Public chains that adopt languages based on Rust and tailored for on-chain development can be considered as modifying this race car to make it more suitable for the road conditions. In this regard, Solana is at a disadvantage.
Summary:
Solana’s smart contract programming model is innovative. It provides a stateless smart contract development approach, uses Rust as the primary programming language, and separates logic from state in its architecture. These provide a powerful environment for developers to build and deploy smart contracts with security and performance guarantees, although it comes with higher development difficulty. Solana focuses on high throughput, low cost, and scalability, making it an ideal choice for developers seeking to create high-performance dApps.
Reference Links:
https://solana.com/docs
https://ethereum.org/en/developers/docs
https://www.anchor-lang.com/