Forward the Original title ‘小学生也能看懂！Solana 的编程模型，究竟和 ETH 有啥区别？’

Solana is a high-performance blockchain platform designed to support dApps. It is known for its speed and scalability, achieved through a unique consensus mechanism and architectural design. This article uses Ethereum as a comparison object to briefly introduce the characteristics of the Solana smart contract programming model.

Smart contracts and on-chain programs:

Programs running on Ethereum are called smart contracts, a series of codes (function) located at a specific address on Ethereum and data(state). (Oh, the code and data are coupled) Smart contracts are also Ethereum accounts, which are called contract accounts. They have balances and can become transaction objects, but they cannot be controlled by humans and are deployed on the network to run as programs.

The executable codes running on Solana are called on-chain programs, and they can interpret the instructions sent in each transaction. These programs can be deployed directly into the network core as native programs, or published by anyone as SPL programs.

1. Instructions: Instructions are unique terms for programs on the Solana chain. On-chain programs are composed of instructions. They are the smallest units that perform specific operations: one or more instructions are included in each Solana transaction. Instructions specify the actions to be performed, including calling a specific on-chain program, passing an account, a list of inputs, and providing a byte array. Instructions have computational constraints, so on-chain programs should be optimized to use a small number of computational units or to split expensive operations into multiple instructions.

1. Native programs: These are programs that provide the necessary functionalities for validating nodes. The most notable one is the System Program, which is responsible for managing the creation of new accounts and transferring SOL between two accounts.
2. SPL programs: These define a series of on-chain activities, including the creation, exchange, and lending of tokens, as well as the creation of staking pools and the maintenance of on-chain domain name resolution services. Among these, the SPL Token Program is used for token operations, while the Associated Token Account Program is commonly used for writing other custom programs.

You call them smart contracts, I call them on-chain programs. Different terms, but they both refer to the code running on the blockchain. Just like Alice, Bob, and John are all names, and their actual qualities need to be assessed by other aspects.

Account model, data decoupling:

Similar to Ethereum, Solana is also a blockchain based on an account model, but Solana provides a different account model than Ethereum and stores data in different ways.

In Solana, accounts can save wallet information and other data. Account-defined fields include Lamports (account balance), Owner (account owner), Executable (whether it is an executable account), and Data (data stored in the account). Each account designates a program as its owner to distinguish which program the account is used as a state store for. These on-chain programs are read-only or stateless: the program account (executable account) only stores BPF bytecode and does 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. Its smart contract not only has code logic, but also needs to store user data. This is often considered a design flaw left over from the EVM’s history.

Don’t underestimate this distinction! Solana smart contracts are fundamentally more challenging to attack compared to blockchains with a coupled programming model like Ethereum.

In Ethereum, a smart contract “owner” is a global variable that corresponds one-to-one with the smart contract. Therefore, calling a function might directly change the contract “owner.”

In Solana, however, the “owner” of a smart contract is data associated with an account rather than 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, they not only need to find the problematic function but also need to prepare the “correct” accounts to call that function. This step is not easy because Solana smart contracts typically involve multiple input accounts and manage their relationships through constraints (such as account1.owner == account2.key). The process from “preparing the correct accounts” to “launching an attack” gives security monitoring personnel enough time to proactively detect suspicious transactions related to the creation of “fake” accounts associated with the smart contract before the attack occurs.

Ethereum smart contracts are like a vault that uses a unique password; once you get this password, you gain full ownership. In contrast, Solana’s smart contracts are like a vault with many passwords. To gain access, you not only need to obtain the passwords but also figure out which password corresponds to which lock to open it.

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 blockchain and smart contracts. Solana also supports C, C++, and (very unusually) other languages. The official SDK for Rust and C is provided to support the development of on-chain programs. Developers can use tools to compile the program into Berkley Packet Filter (BPF) bytecode (the file has a .so extension), then deploy it 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 get started with 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-creator Armani to simplify development) Many newly created programming languages dedicated to blockchain development are based on Rust, such as Cairo (Starknet), Move (Sui, Aptos).

Many projects in production use the Anchor framework

Ethereum smart contracts are mainly developed in Solidity language (the 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 generally think that the development experience of Ethereum is simpler and more refreshing, while Solana development is more difficult to get started. So even though Solana is very popular now, in fact the number of developers on Ethereum is still far more than Solana.

Under certain road conditions, top racing cars are not as fast as modified cars. Rust is like a top-level racing car, which effectively guarantees the performance and safety of Solana. However, it is not designed to develop this track for on-chain programs but instead causes an increase in the difficulty of driving (development). Using a public chain based on Rust and developing a custom language for the chain is equivalent to modifying the racing car to make it more suitable for road conditions. Solana is at a disadvantage here.

Summary

Solana’s smart contract programming model is innovative. It offers a stateless approach to smart contract development, using Rust as the primary programming language and an architecture that separates logic from state. This provides developers with a robust environment for building and deploying smart contracts, ensuring security and performance, though it poses a higher development difficulty. Solana focuses on high throughput, low cost, and scalability, making it the ideal choice for developers currently looking to create high-performance dApps.

Disclaimer：

1. This article is reprinted from [Foresight News]. All copyrights belong to the original author [Alex Liu]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.