Original author: Foresight News, Alex Liu
Solana is a high-performance blockchain platform designed to support dApps, known for its speed and scalability, which is achieved through a unique consensus mechanism and architectural design. This article uses Ethereum as a comparison object to briefly introduce the characteristics of Solana's smart contract programming model.
Smart contracts, on-chain programs:
Programs running on Ethereum are called smart contracts, which are a series of codes (functions) and data (status) located at a specific address on Ethereum. (Oh no, the code and data are coupled) Smart contracts are also Ethereum accounts, called contract accounts, which have balances and can be traded, but cannot be manipulated by humans and are deployed on the network to run as programs.
The executable code running on Solana is called an on-chain program, which interprets the instructions sent in each transaction. These programs can be deployed directly to the core of the network as native programs, or published by anyone as SPL programs.
Instructions: Instructions are a special term for Solana on-chain programs. On-chain programs are composed of instructions, which are the smallest unit to perform a specific operation: every Solana transaction contains one or more instructions. Instructions specify the operation to be performed, including calling a specific on-chain program, passing accounts, input lists, and providing byte arrays. Instructions have computational limits, so on-chain programs should be optimized to use a small number of computational units, or split expensive operations into multiple instructions.
Native Program: A native program that provides the functions required by a verification node. The most famous of these is the System Program, which is responsible for managing the creation of new accounts and the transfer of SOL between two accounts.
SPL Program: defines a series of on-chain activities, including the creation, exchange, lending, creation of staking pools, maintenance of on-chain domain name resolution services, etc. Among them, SPL Token Program is used for token operations, while Associated Token Account Program is often used to write other custom programs.
You call it a smart contract, I call it a chain program. Everyone has different terms, but they all refer to the code running on the blockchain. Zhang San, Li Si, and Wang Mazi are all names of people. Their quality still needs to be examined in other aspects.
Account model and data decoupling:
Similar to Ethereum, Solana is also a blockchain based on an account model, but 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. The fields defined by an account 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 distinguish which program the account is used as state storage. These on-chain programs are read-only or stateless: program accounts (executable accounts) only store BPF bytecode and do not store any state. The program will store the state in other independent accounts (non-executable accounts), that is, Solana's programming model decouples code and data.
The Ethereum account is mainly a reference to the EVM state, and its smart contract has both code logic and needs to store user data. This is generally considered to be a design flaw left over from the history of the EVM.
Don’t underestimate this distinction! Solana smart contracts are fundamentally harder to attack than blockchains with coupled programming models like Ethereum:
In Ethereum, the smart contract "owner" is a global variable that corresponds to the smart contract one by one. Therefore, calling a function may directly change the contract "owner".
In Solana, the "owner" of a smart contract is data associated with an account, not a global variable. An account can have multiple owners, rather than a one-to-one association. For an attacker to exploit a security vulnerability in a smart contract, he or she not only needs to find the problematic function, but also needs to prepare the "correct" account to call the function. This step is not easy because Solana smart contracts typically involve multiple input accounts and manage the relationship between them through constraints (such as `account 1.owner==account 2.key`). The process from "preparing the correct account" to "launching an attack" is enough for security monitors to proactively detect suspicious transactions that create "fake" accounts associated with smart contracts before an attack.
Ethereum’s smart contract is like a safe with a unique password. As long as you get the password, you can get full ownership. Solana’s is a safe with many passwords, but in order to obtain permission, you not only have to find a way to get the password, but also figure out the number corresponding to the password before you can open the lock.
programming language
Rust is the primary programming language for developing smart contracts on Solana. Because of its performance and security features, it is suitable for the high-risk environment of blockchains and smart contracts. Solana also supports C, C++ and other languages (very uncommon). Official Rust and C SDKs are provided to support the development of on-chain programs. Developers can use tools to compile programs into Berkley Packet Filter (BPF) bytecode (files with a .so extension), then deploy them to the Solana chain and execute the logic of the smart contract through the Sealevel parallel smart contract runtime.
Since the Rust language itself is difficult to use and is not customized for blockchain development, many requirements require reinventing the wheel and redundant code. (Many projects in production use the Anchor framework created by Backpack co-founder Armani to simplify development) Many newly created programming languages dedicated to blockchain development are based on Rust, such as Cairo (Starknet) and Move (Sui, Aptos).
Many projects in production use the Anchor framework
Ethereum smart contracts are mainly developed in Solidity (syntax is similar to javascript, and the code file has a .sol extension). Due to the relatively simple syntax and more mature development tools (Hardhat framework, Remix IDE...), we usually think that Ethereum's development experience is simpler and more refreshing, while Solana development is difficult to get started. So even though Solana is very popular now, in fact, the number of Ethereum developers is still far greater than Solana.
Under certain road conditions, a top-level racing car cannot run as fast as a modified car. Rust is like a top-level racing car, which effectively guarantees the performance and security of Solana. However, it was not designed for on-chain program development, which makes driving (development) more difficult. Using a public chain based on Rust and customized for on-chain development is equivalent to modifying this racing car to make it more adaptable to road conditions. Solana is at a disadvantage in this regard.
Summarize
Solana's smart contract programming model is innovative. It provides a stateless smart contract development method, uses Rust as the main programming language, and an architecture that separates logic from state, providing a powerful environment for developers to build and deploy smart contracts, ensuring security and performance, but with greater development difficulty. Solana focuses on high throughput, low cost, and scalability, and remains 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/
