This article compares the public chain Solana with the second largest public chain, Ethereum, and briefly introduces the differences between the two in terms of smart contract programming models.
Table of Contents:
Smart Contracts and On-chain Programs
Account Model and Data Decoupling
Programming Languages
Conclusion
Solana is a high-performance blockchain platform designed to support dApps, known for its speed and scalability. This is achieved through its unique consensus mechanism and architectural design. This article uses Ethereum as a comparison and briefly introduces the characteristics of Solana’s smart contract programming model.
Smart Contracts and On-chain Programs:
Programs executed on Ethereum are called smart contracts, which are a series of code (functions) and data (state) located at a specific address on Ethereum. Smart contracts are also Ethereum accounts, known as contract accounts. They have balances and can be used as transaction objects, but cannot be manipulated by individuals, and are deployed on the network for program execution.
On the other hand, executable code executed on Solana is called on-chain programs, which can interpret the instructions sent in each transaction. These programs can be directly deployed to the network core as native programs or released by anyone as SPL programs.
Instructions:
Instructions are unique terms for Solana’s on-chain programs. On-chain programs consist 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 minimal computational units or divide expensive operations into multiple instructions.
Native Programs: Native programs provide the necessary functions for validating nodes. The most famous one 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 token creation, exchange, lending, creating pledge pools, and 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 write other custom programs.
While some call it a smart contract and others call it an on-chain program, both refer to code executed on the blockchain. Just as Zhang San, Li Si, and Wang Mazi are all names, their qualities need to be examined in other aspects.
Account Model and Data Decoupling:
Similar to Ethereum, Solana is also based on an account model blockchain. However, Solana provides a different account model from Ethereum to store data in a different way.
In Solana, accounts can store wallet information and other data. The fields defined by 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 distinguish which program the account is used to store the state. 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 stores the state 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 EVM states. Smart contracts on Ethereum not only have code logic but also need to store user data. This is generally considered a design flaw inherited from the EVM’s history.
Do not underestimate this difference! Solana’s 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 the smart contract one-to-one. Therefore, calling a certain function can 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, not a one-to-one relationship. In order for an attacker to exploit a security vulnerability in a smart contract, they not only need to find a problematic function but also need to prepare the “correct” account to call that function.
This step is not easy because 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 an attack” is sufficient for security monitors to proactively detect suspicious transactions related to the creation of “fake” accounts associated with smart contracts before the attack.
In Ethereum, smart contracts are like a safe with a unique password. Once you have the password, you have complete ownership. On the other hand, Solana’s smart contracts are like a safe with many passwords. To obtain permission, you not only need to find a way to get the password but also figure out 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 the high-risk environment of blockchain and smart contracts. Solana also supports C, C++, and other languages (less common). The official SDK provides Rust and C to support the development of on-chain programs. Developers can use tools to compile programs into Berkeley Packet Filter (BPF) bytecode (files with the .so extension) and deploy them to the Solana chain to execute the logic of smart contracts through parallel execution with Sealevel.
Due to the high learning curve of the Rust language itself and it not being specifically tailored for blockchain development, many requirements result in redundant code and reinventing the wheel. 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 created by Armani from the Backpack co-creation to simplify development. On the other hand, Ethereum smart contracts are mainly developed using the Solidity language (syntax similar to JavaScript, with .sol as the file extension). Due to its relatively simple syntax and more mature development tools (such as Hardhat framework, Remix IDE, etc.), Ethereum is usually considered to have a simpler and more enjoyable development experience than Solana, which has a higher learning curve. Therefore, despite the current high popularity of Solana, the number of Ethereum developers is still much larger than that of Solana.
In specific scenarios, a top racing car may not run faster than a modified car. Rust is like a top racing car, guaranteeing the performance and security of Solana, but it is not born for the race track of on-chain program development. Instead, it increases the difficulty of driving (development). Public chains that adopt languages based on Rust and tailored for on-chain development are equivalent to modifying this car to make it more adaptable to the road conditions. In this aspect, Solana is at a disadvantage.
Conclusion:
Solana’s smart contract programming model is innovative. It provides a stateless smart contract development method, uses Rust as the primary programming language, and has an architecture that separates logic from state. This provides 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, making it the ideal choice for developers seeking to build high-performance dApps.
Related Reports:
Detailed Explanation of EIP-7706 Proposed by Vitalik: Multi-dimensional Gas Concept for Unlocking L2 Scalability in Ethereum
Modularity is King! Why the Monolithic Architecture of Ethereum EVM is Dead?
Knowledge Sharing: Detailed Explanation of Cosmos Ecosystem Smart Contract Chain Juno Network