Even elementary school students can understand! What is the difference between Solana's programming model and ETH?

Written by: Foresight News, Alex Liu

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

Smart Contracts, 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 Ethereum. (Oh no, code and data are coupled) Smart contracts are also Ethereum accounts, referred to as contract accounts, which have balances and can be the subject of transactions, but cannot be manipulated by individuals, as they run on the network as programs.

Executable code running on Solana is referred to as an on-chain program. These programs interpret the instructions sent in each transaction. These programs can be directly deployed to the network core as native programs or published by anyone as SPL programs.

• Instructions: Instructions are a unique term for Solana on-chain programs. On-chain programs consist of instructions, which are the smallest unit for executing 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 a minimal number of computational units or break expensive operations into multiple instructions.

• Native Programs: Native programs provide the functionality required by validating nodes. The most famous of these is the System Program, which is responsible for managing the creation of new accounts and transferring SOL between two accounts.

• SPL Programs: SPL programs define a series of on-chain activities, including the creation, exchange, and lending of tokens, as well as creating staking pools and maintaining on-chain domain name resolution services. Among them, the SPL Token Program is used for token operations, while programs like the Associated Token Account Program are commonly used for writing other custom programs.

You call them smart contracts, I call them on-chain programs; we may use different terms, but they both refer to code running on the blockchain. Zhang San, Li Si, and Wang Mazi are all names; their qualities still need to be assessed in 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 from Ethereum, storing 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 serves as a 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), meaning Solana's programming model decouples code and data.

In contrast, Ethereum accounts mainly reference EVM state, where smart contracts contain both code logic and need to store user data. This is often considered a design flaw inherited from EVM's history.

Don't underestimate this difference! Solana smart contracts are fundamentally harder to attack than blockchains with coupled programming models (like Ethereum):

In Ethereum, the "owner" of a smart contract is a global variable corresponding to each smart contract. Therefore, calling a certain function may directly change the contract's "owner."

In Solana, the "owner" of a smart contract is data associated with the 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" account to call that function. This step is not easy, as Solana smart contracts typically involve multiple input accounts and manage their relationships through constraints (e.g., ` account1 . owner == account2 . key `). The process from "preparing the correct account" to "launching the attack" is sufficient for security monitors to proactively detect suspicious transactions related to the creation of "fake" accounts associated with smart contracts before an attack occurs.

Ethereum's smart contracts are like a vault with a unique password; once you have that password, you gain full ownership. In contrast, Solana's is like a vault with many passwords, but to gain access, you not only need to figure out how to obtain the password but also understand which password corresponds to which number to unlock it.

Programming Language

Rust is the primary programming language for developing smart contracts on Solana. Its performance and security features make it suitable for the high-risk environment of blockchain and smart contracts. Solana also supports C, C++, and other languages (though less commonly). The official SDKs for Rust and C 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), which can then be deployed on the Solana chain and executed through the Sealevel parallel smart contract runtime.

Due to the high difficulty of getting started with Rust, which is not specifically tailored for blockchain development, many requirements lead to redundant code and the need to reinvent the wheel. (Many projects in production use the Anchor framework co-created by Backpack and Armani to simplify development.) Many newly created programming languages specifically for 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 primarily developed using the Solidity language (which has a syntax similar to JavaScript, with code files having a .sol extension). Due to its relatively simple syntax and more mature development tools (such as the Hardhat framework and Remix IDE), it is generally considered that the development experience on Ethereum is simpler and more enjoyable, while the difficulty of getting started with Solana development is higher. Therefore, despite Solana's current popularity, the number of developers on Ethereum still far exceeds that on Solana.

Under specific conditions, top racing cars do not run faster than modified cars. Rust is like a top racing car, powerfully ensuring Solana's performance and security, but it was not born for the track of on-chain program development, which instead increases the difficulty of driving (development). Using public chains based on Rust and tailored for on-chain development languages is akin to modifying this racing car to make it more suitable for the road conditions. Solana is at a disadvantage in this regard.

Conclusion

Solana's smart contract programming model is innovative. It provides a stateless smart contract development approach, uses Rust as the primary programming language, and features an architecture that separates logic from state, offering developers a robust environment for building and deploying smart contracts while ensuring security and performance, albeit with a 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.