Solana is a high-performance blockchain platform designed to support dApps, known for its speed and scalability achieved through unique consensus mechanisms and architectural designs. This article will briefly introduce the features of Solana’s smart contract programming model, comparing it with Ethereum for context.

Smart Contracts and On-Chain Programs:

Programs running on Ethereum are known as 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, referred to as contract accounts. They have balances, can be the target of transactions, but cannot be controlled by individuals. They are deployed on the network to run as programs.

In contrast, executable code running on Solana is referred to as On-Chain Programs, which interpret instructions sent with 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 Solana on-chain programs. They consist of instructions that execute specific operations, forming the smallest unit of execution for Solana transactions. Each Solana transaction contains one or more instructions specifying the operations to be performed, 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 provide the essential functionalities required by validator nodes. The most famous is the System Program, responsible for managing the creation of new accounts and transferring SOL between two accounts.

SPL Programs: These define a series of on-chain activities, including token creation, exchange, lending, creating staking pools, maintaining on-chain domain name resolution services, and more. 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 customized programs.

You call it smart contracts, I call it on-chain programs. Different names, but both refer to code running on the blockchain. Just like how Zhang San, Li Si, and Wang Ma Zi are all names, one’s quality should be assessed based on other aspects as well.

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 hold wallet information and other data. The fields defined by an account include Lamports (the account balance), Owner (the account owner), Executable (whether it is an executable account), and Data (the data stored in the account). Each account specifies a program as its owner to differentiate which program’s state it stores. These on-chain programs are read-only or stateless: program accounts (executable accounts) only store BPF bytecode and do not store any state. Programs store their state in other independent accounts (non-executable accounts). Solana’s programming model decouples code and data.

On the other hand, Ethereum accounts mainly serve as references to the EVM (Ethereum Virtual Machine) state. Smart contracts on Ethereum contain both code logic and the need to store user data. This is often considered a design flaw inherited from the history of the EVM.

Do not underestimate this distinction! Solana smart contracts are fundamentally more difficult to attack than blockchains with coupled programming models, such as Ethereum:

In Ethereum, the “owner” of a smart contract is a global variable that corresponds directly to each smart contract. Therefore, calling a certain function could directly alter the contract’s “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, instead of a one-to-one association. For an attacker to exploit a security vulnerability in a smart contract, they not only need to identify the problematic function but also 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 the attack” is enough for security monitors to proactively detect suspicious transactions involving the creation of “fake” accounts related to smart contracts before an attack occurs.

Ethereum’s smart contracts are like a safe with a single unique password. Once you have this password, you gain complete ownership. Solana’s, on the other hand, are like a safe with many passwords. To gain access, you not only need to obtain the passwords but also understand the corresponding identifiers before you can unlock the door.

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 (although less common). The official Rust and C SDKs are provided to support the development of on-chain programs. Developers can use tools to compile programs into Berkeley Packet Filter (BPF) bytecode (files with a .so extension) and deploy them to the Solana blockchain. The logic of smart contracts is then executed through the Sealevel parallel smart contract runtime.

However, due to the high learning curve of the Rust language and its lack of customization for blockchain development, many requirements result in redundant code and reinventing the wheel. To simplify development, many projects in production use the Anchor framework created by the collaboration of Backpack and Armani. Additionally, several new programming languages specifically tailored for blockchain development, such as Cairo (Starknet) and Move (Sui, Aptos), are based on Rust.

Many projects in production use the Anchor framework.

Ethereum smart contracts are primarily developed using the Solidity language, which has 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), Ethereum is generally considered to offer a simpler and more enjoyable development experience compared to Solana, which has a higher learning curve. Despite the current popularity of Solana, the number of developers on Ethereum remains far greater than on Solana.

In specific circumstances, a top-tier racing car will outperform a modified car. Rust, like a top-tier racing car, effectively ensures Solana’s performance and security. However, it is not inherently designed for on-chain program development, which actually raises the difficulty level of driving (developing). Public chains that adopt languages based on Rust and customized for on-chain development can be likened to modifying this racing car to better adapt to the road conditions. Solana is at a disadvantage in this regard.

Conclusion

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

Statement:

1. This article is reproduced from [panews], original title “My grandma can also understand: What is the difference between Solana’s programming model and ETH?”, the copyright belongs to the original author [Foresight News，Alex Liu], if you have any objection to the reprint, please contact Gate Learn Team, the team will handle it as soon as possible according to relevant procedures.

2. Disclaimer: The views and opinions expressed in this article represent only the author’s personal views and do not constitute any investment advice.

3. Other language versions of the article are translated by the Gate Learn team, not mentioned in Gate.io, the translated article may not be reproduced, distributed or plagiarized.