What's fun? What's interesting? What do you think life is? 1. Solana overview similar to Bitcoin and Ethereum, Solana also has one kind of non-permission (permissionless) range, Bitcoin and Ethereum, Solana's outstanding feature is its trading ability, an
What's fun? What's interesting? What do you think life is?
1. Solana Overview
Similar to Bitcoin and Ethereum, Solana is also a permissionless blockchain
Compared with Bitcoin and Ethereum, Solana’s outstanding feature is its transaction parallel processing capability and the resulting high throughput (Transactions per Second, TPS)
Solana’s average block time is about 400 ms; In comparison, the average block time of Bitcoin is about 10 minutes and that of Ethereum is about 15 seconds.
Solana peak TPS is about 65,000; In comparison, the average TPS of Bitcoin is about 7, and that of Ethereum is about 15~30 (can be increased to thousands through L2 expansion)
While Solana increases TPS, it will not bring about a significant increase in transaction fees.
Solana’s parallel transaction processing mechanism is called “Sealevel”
The above advantages of Solana are due to its unique transaction data structure; Unlike Bitcoin and Ethereum, Solana requires each transaction to explicitly list all accounts involved, including which accounts to read data from and which accounts to write data to.
The above specifications are called Upfront Account Declarations (UAD)
Based on UAD, Solana can distinguish between conflict transactions (Conflict Transaction) and non-conflict transactions (Non-conflict Transaction) when running.; Non-conflicting transactions are processed in parallel and conflicting transactions are processed sequentially
Based on UAD, when Solana packages transactions, only transactions that access the same account will have a bidding relationship (that is, the priority of being packaged and executed is determined based on the level of transaction fees). This mechanism ensures that transaction fees will not increase significantly even during peak trading periods. It is called the Local Fee Market; In contrast, in Bitcoin and Ethereum, a bidding relationship will occur between any two transactions, causing transaction fees to increase significantly with the surge in transaction volume, which is called the Global Fee Market.
Solana account model
Similar to Ethereum, Solana also uses the Account Model to maintain state information, that is, the world state is regarded as the Key-Value Pairs of "Account-AccountInfo"
Ownership reflects the ownership of the account. Only the owner of the account can modify the account status (except for increasing the account balance, that is, any role can increase the designated account balance, and only the owner can deduct the designated account balance); All Solana account information, that is, AccountInfo, contains the Ownership keyword
Authority reflects the usage rights of the account. Only authorized accounts can spend the corresponding balance.; A typical example is the Ownership field in Token Account. Although it is written as Ownership, its actual function is Authority, which is used to specify the account that has the authority to spend the token balance.
In Solana, the owners of all wallet accounts are System Program; The Owner of all Programs is "BPF Loader Upgradeable"” ; The Owner of all PDAs is the Program that generated the PDA. ; Specifically, the owner of Token Program is BFP Loader ; On the contrary, Token Program is the owner of Mint Account, Token Account, and ATA.
In Solana, the account owner and authority are often different. Take the wallet address as an example.
Its Owner is System Program, and its Authority is the user who controls the wallet, that is, Key Pair
According to Solana's design, even if the user controls the Key Pair, he cannot directly control the wallet account because he is not the owner of the wallet account.
If the user wants to operate the corresponding wallet account and perform transfer (i.e. deduct the account balance), he needs to issue the transaction and sign it.; After the System Program has verified that the signature is correct (confirming the Authority identity), then modify the wallet account status as the Owner and deduct the balance.
Solana’s token issuance relies on the Token Program; Token Program belongs to SPL, so Solana token is sometimes called SPL Token
Wallet Account (Wallet Account) that performs ordinary transfer tasks, also called ordinary account, key pair account, is uniquely controlled by the public key and private key pair defined on the elliptic curve Ed25519
Program Account that stores smart contract metadata, and Data Account that stores actual logic and related status data; This data account is also called Program Deriven Data (PDA) ; Unlike smart contracts on Ethereum, which are not updatable (i.e., a program address, or Program ID, can only point to a specific logic), thanks to the above-mentioned design of separately maintaining metadata, logic, and status, Solana smart contracts, that is, programs (Programs) are updatable.
Mint Account (Mint Account) that implements "coin issuance" and maintains token metadata, Token Account (Token Account) used to track which accounts hold how many tokens of a specific type, and the "summary" version of the token account Associated Token Account (ATA); Among them, ATA is a special PDA
Solana accounts include:
Solana implements a series of special Programs, called Native Programs, including System Program, BPF Loader and ATA Program; The above program is pre-deployed at a fixed address (Fixed Address), similar to the pre-compiled contract in Ethereum, so it is also called Solana Program Library (SPL)
Unlike Ethereum, Solana accounts have concepts such as "Ownership" and "Authority"
SOL price trend (From https://coinmarketcap.com/currencies/solana/)
Similar to Bitcoin and Ethereum, Solana also has its own native token called SOL
Solana’s SOL is similar to Ethereum’s ETH, both are larger token units
Similar to Ethereum, Solana tokens are generally circulated in smaller units, called ; Its status is equivalent to that of Ethereum
Rust-base Program compilation process
Similar to the fact that transaction/smart contract execution in Ethereum relies on the Ethereum Virtual Machine (EVM), Solana also has the concept of Solana Virtual Machine (SVM)
The difference between EVM and SVM
Unlike EVM, which has a clear meaning in Ethereum, that is, a bytecode interpreter/executor, SVM still lacks a clear definition or specification in Solana. There are two understandings in the Solana community: Narrow View and Broad View.
In a narrow sense, SVM refers to eBPF (extended Berkeley Packet Filter) used to interpret and execute bytecode.; Specifically, it refers to sBPF (solana Berkeley Packet Filter) customized by Solana based on eBPF. ; More strictly speaking, Solana initially used rBPF (rust Berkeley Packet Filter) customized based on eBPF, then customized sBPF based on rBPF, and discarded rBPF. ; Therefore, rBPF is the fork of the eBPF, and the sBPF is the fork of the rBPF ; Currently, in the Solana specification, the definition that is closer to the above understanding is the SVM instruction set architecture, that is, the SVM ISA (Instruction Set Architecture), which is a register-based and RISC-Like architecture (EVM is based on the stack, that is, Stack-based)
Broadly speaking, SVM refers to a complete set of runtime (Runtime) including transaction packaging, processing, source code compilation/interpretation/execution, or transaction execution stack (Transaction Execution Stack). The concepts involved include
Transaction Processing Unit (TPU)
Transaction packaging and execution stage (Banking Stage)
Rust official compiler rustc, package management tool cargo
Low Level Virtual Machine (LLVM)
High-Level Intermediate Representation (HIR), and Typed HIR (THIR)
Mid-level Intermediate Representation (MIR), and LLVM intermediate representation LLVM IR
Abstract Syntax Tree (AST), and Control Flow Graph (CFG)
Executable and Linkable Format (ELF)
Macros in Rust-base Program
Solana generally uses Rust to write Programs
Function-Like Macro
Attribute-Like Macro
Derive Custome Macro
Commonly used smart contract programming languages for Ethereum include Solidity and Vyper
Rust is a strongly-typed programming language and does not support object-oriented
In Solana, a major feature of Programs written in Rust is the use of macros (usually accompanied by!, such as msg!, println!), including:
Solana Program development based on Rust currently has two relatively mature frameworks, namely Anchor and Pinocchio
PoH uses the number of iterations of SHA-256 as a timer
Unlike Bitcoin and Pre-Merged Ethereum, which both adopt the Proof-of-Work (PoW) consensus mechanism, Solana, like Post-Merged Ethereum, both adopt the Proof-of-Stake (PoS) consensus mechanism.
Unlike Bitcoin, Ethereum, etc., which use seconds (s) to measure time, Solana uses the number of executions (Ticks) of SHA-256 to measure time.
PoH is the iterative execution of SHA-256, that is, the output of the last SHA-256 will be used as the input of the next SHA-256, thus forming a Verifiable Delay Function (VDF); The characteristics of VDF are that it is difficult to calculate and easy to verify. ; Specifically, VDF can only be executed sequentially, but can be verified in parallel.
The time units involved in Solana include Tick, Slot and Epoch; 12,800 iterations of SHA-256 execution are called a Tick, 64 Ticks form a Slot, and 43,200 Slots form an Epoch ; Each Slot generates a Block ; Since the optimization of SHA-256 on different hardware is close to the limit, there is almost no difference in the time it takes to execute iterative SHA-256 on different hardware. It takes about 0.48ms to execute SHA-256 once, and one Slot takes about 400 ms (that is, Solana’s average block generation time) ; One Epoch is about 48 hours
Slot is the smallest unit of block proposals in Solana, and Epoch is the smallest unit of Solana governance. Governance includes token staking and incentive distribution, etc.
Compared with Ethereum, the outstanding feature of Solana's use of PoS is the introduction of Proof-of-History (PoH) as a cryptographic clock (Cryptographic Clock) or decentralized timestamp (Decentralized Timestamp), ensuring the distributed consistency and verification of the transaction execution sequence without relying on centralized timing nodes.; In Post-Merged Ethereum, implementing distributed timestamps relies on Network Time Protocol (NTP)
It should be noted that PoH is not the Solana consensus itself, but the underlying tools relied upon to achieve consensus.
Based on the PoS consensus mechanism, the voice/priority of a node in Solana is proportional to the proportion of the number of its pledged tokens in the total number of tokens.; During transaction processing, the higher the proportion of tokens pledged by the relay node, the more likely it is that the transactions forwarded by it will be packaged. This mechanism is called Stake Weighted Quality of Service (SWQoS).
Based on the PoS consensus mechanism, Solana uses node voting to determine the effective Block and solve the fork problem.; Solana uses customized Byzantine Fault Tolerance to reach consensus around node voting, called Tower Byzantine Fault Tolerance (TBFT)