Source: Denglian Community
This is a series of articles introducing Solana development.
Solana is a high-performance blockchain platform that achieves high throughput and low latency through a unique consensus mechanism and account model.
As the first article in a series, this article mainly introduces some knowledge you need to know before developing Solana:
Background of Solana
How Solana produces blocks (consensus operation)
Solana core concepts: account model, PDA, transactions and fees, clusters, etc.
Solana was founded by Anatoly Yakovenko in 2017. Anatoly chose the name Solana to pay tribute to Solana Beach, a small beach town north of San Diego where they lived and surfed for three years while working at Qualcomm.
Before founding Solana, Anatoly worked for Qualcomm, Mesosphere, and Dropbox for many years and has extensive experience in high-performance networks and distributed systems.
He recognized that the bottleneck of blockchain in scalability limits its potential for large-scale applications. Inspired by time synchronization technology in distributed systems, he proposed the concept of Proof of History (PoH). Used for time synchronization between computers that do not trust each other.
Let’s take a look at how Solana uses PoH to achieve efficient synchronization between validators.
Note: The Solana consensus algorithm document is a bit outdated. This part of the content is based on the reference to In-depth Solana Consensus plus my understanding.
Solana is a Proof of Stake (PoS) blockchain. The consensus algorithm follows a two-stage process: 1. Elect validators to produce blocks 2. Other validators vote on the blocks. After enough votes have been accumulated, the blocks are finally confirmed.
In the Solana protocol, there are two important time interval related words: Epoch and Slot:
Slot: The time unit for validators to generate blocks. Each slot can generate one block, and each slot lasts 400 milliseconds.
Epoch： At the beginning of each Epoch, the Solana network will randomly select a validator (called leader) sequence based on the staked weight and the previous block. This leader sequence is responsible for producing blocks in that Epoch. The leader sequence remains fixed during this period. Each leader can process 4 slots continuously (that is, 4 blocks). Each Epoch lasts about two days (containing 432,000 slots). Until the next Epoch regenerates the leader.
In the above figure, each colored block represents a block, and different colors represent different verified blocks.
Random elections are not explained in detail here (mainly because I don’t understand them). At the beginning of each Epoch, the validator will know in which slots he needs to produce blocks.
But there are two problems that need to be solved:
How does a validator know when it is his turn to produce a block? If it only relies on network communication, and the previous validator tells the next validator, it is very likely that due to network delays (or the previous validator is offline), it will miss the precious block time. After all, the block time is only 0.4 seconds.
How to cram as many transactions as possible into a block. If it is similar to Ethereum, where transactions are executed one after another, it is impossible to put many transactions in such a short time.
Solana’s most important innovation - POH, is mainly used to solve these two problems.
In order to achieve high performance, Solana introduced parallel processing of transactions, dividing the sorting and execution of transactions into two stages, so that the execution stage can be processed in parallel.
When other validators verify transactions, they also perform verification in the same sorting sequence. In order to make the transaction sorting sequence verifiable, Solana uses the POH historical proof hash chain to determine the order of transactions.
PoH creates a series of encrypted hashes (SHA256 algorithm), and each hash calculation needs to use the previous hash value, so that the next hash always occurs after the previous hash, so the POH hash chain combined with the mind data can determine the transaction order.
You only need to add the transaction data as part of the input when calculating the hash to determine the sequence of transactions. And this sequence is parallel, verifiable and tamper-proof.
The current leader validator will continuously receive transactions from the RPC server and other validators. After preliminary verification (such as verifying transaction signatures and account balances), it will be added to the POH hash chain calculation for sorting, that is, each transaction is labeled with a global, verifiable time sequence label, and then the transactions are executed in parallel.
In Solana, the entire transaction processing flow is divided into multiple interconnected stages (transaction verification stage, POH sorting stage, execution stage, broadcast stage) to form a pipeline. Different batches of transactions can be processed in parallel and overlapped between different stages, that is, different CPU cores or GPUs are processing the verification of a batch of transactions and the execution of another batch of transactions at the same time (called banking).
Transaction execution is also parallel. The transaction execution arranges the degree of parallelism based on the read and write dependencies of the account, and the transactions are grouped according to the dependencies and executed in parallel in different threads/CPU cores/GPU tasks.
If the accounts of the two transactions are completely different or both are read-only, they can theoretically be executed at the same time; if there is a write conflict, they must be executed in sequence to avoid data inconsistency.
Now we understand the process of Solana block generation. In this way, Solana can handle a large number of transactions in a single slot (about 400ms).
There is another question, how does the validator know when it is his turn to generate a block?
Each hash operation requires a minimum time, and each hash calculation needs to use the previous hash value. This ensures that parallelization is impossible. Therefore, the PoH hash chain can be used as proof of the passage of time.
In Solana, each block (PoH hash chain) must contain 12,500 hashes. The leader of the current slot is responsible for generating these PoH chains (blocks).
In fact, no validator is calculating the PoH chain (empty Hash chain without transaction data) in the background. If the previous leader (or multiple previous leaders) did not publish the block (or the current leader did not receive it), as long as the number of hashes required by the slot is passed, the current leader can generate the block on time.
As shown in the figure below, Slot3 is offline, and the validator of Slot4 fills the PoH sequence for slot3.
The block verification process includes verifying block metadata and recalculating the PoH hash. It will verify and replay all transactions from the block and update the ledger.
After verification, the validator's commitment to a block is expressed through voting. The more delegated equity (coins) the validator holds, the greater the weight of the vote.
Usually, validators will choose the heaviest chain to produce blocks and vote. If the block of the previous leader fails to reach the current leader, a fork may occur:
In the case of a fork, the validator calculates the total stake-weighted votes for each subtree and chooses the one with the most votes. If a block receives at least two-thirds of the stake-weighted votes, the block is confirmed.
When developing on Solana, the biggest difference from Ethereum is the different account model.
Solana accounts are very similar to Linux files. Everything is an account. It is a storage unit. They come in many forms:
User account: an account controlled by a private key, usually generated for the user by the wallet software.
Program Accounts: Accounts used to store executable bytecode (smart contract code).
Data Accounts: Accounts that store state information, such as the number of specific tokens held by a user.
Native Program Accounts: These are special pre-deployed program accounts that perform various core functions of the network. These include system programs, voting programs, and BPF loaders.
<span ) 10px 10px / 40px no-repeat ;height: 30px;width: 100%;margin-bottom: -7px;border-radius: 5px;'>
Solana's program account (i.e. smart contract) is stateless, read-only, and does not store any data/status. Data is stored in independent data accounts.
When you call a function of a Solana contract, we need to pass the data account used to the function. It is easy to execute transactions that do not depend on each other concurrently.
If you know EVM, you will know that state data is also stored in the contract. Take a counter as an example. In the EVM contract, the value of the counter is stored in the contract account. In Solana, two accounts must be created: one is the program account to store the program code, and the other is to store the value of the counter.
Rent is a way for Solana to reduce state bloat, requiring accounts to maintain a minimum balance to remain active. Rent ensures that the network will eventually reclaim unused or underfunded accounts. If the account maintains a minimum balance equivalent to two years of rent, it can be rent-free.
In addition to the benefits of concurrent execution, the design of Solana's accounts can also bring program reusability. There is a large amount of identical ERC20 code on Ethereum.
Solana is different. When creating a new token, there is no need to redeploy smart contracts. Instead, just create a new account, called a minting account, which defines the number of tokens, their names, who can mint more tokens, etc.
The account used to store program data is the PDA,
Ordinary user accounts have public keys/addresses that correspond to a point on the ed25519 elliptic curve, and the private key is used to sign to prove the authority to modify the account.
Program Derived Addresses (PDA) are accounts generated outside the curve using bump (even if the output deviates from the value of the curve). PDA requires three main parts: the parent program ID, a set of seeds, and a jump value. The seed is an array of strings, usually a specific seed related to a state variable set in the program to create a data structure similar to a hash table. To generate the corresponding PDA.
It can be deduced that the program of the PDA is its owner, and only this program can modify the data of the PDA.
A transaction we send to the Solana network consists of four parts:
One or more instructions (instructions)
An array of accounts to read or write (account_keys)
One or more signatures (signatures)
The most recent block hash (recent_blockhash)
An instruction is the smallest execution logic on Solana. Instructions specify the execution program, all accounts involved, and the operation data. Instructions call programs to update state (for example, calling a token program to transfer tokens from your account to another account), and the program interprets the data in the instruction and operates on the specified accounts.
Instructions are similar to function calls on Ethereum smart contracts.
The execution of multiple instructions in a transaction is atomic, and all instructions either succeed together or fail together.
Solana uses the most recent block hash to indicate the validity of a transaction, but when we want to make a transaction, we extract the most recent blockhash from the cluster to create a valid transaction. The transaction is valid within 150 blocks after the most recent blockhash. If this time is exceeded, the transaction needs to be re-initiated.
Solana does not have the concept of Nonce for transactions in Ethereum.
Solana transaction fees are very different from Ethereum's gas mechanism. Transaction fees are related to the number of signatures included in the transaction (lamports_per_signature). The base fee is currently set to 0.000005 SOL (5k lamports) per signature. This is a one-time fee for the right to use network resources. It needs to be paid to the network in advance regardless of how many resources are actually used to execute the transaction (or whether the transaction is executed at all). 50% of the fee is paid to the validator node that produces the block, and the remaining 50% is destroyed.
If you want to increase the priority of your transaction [optional fee], you can set a "compute unit price". This price is used in conjunction with the compute unit limit to determine the priority fee of the transaction.
The default compute unit limit is 200,000 CUs per instruction. If the amount of computation is large, the maximum can be set to 1.4 million CUs. Solana transactions will pre-request a specified number of compute units (CUs). If this number is exceeded, the transaction will fail.
In addition, Solana transactions will also be subject to transaction packet size limits. The Solana network follows a maximum transmission unit (MTU) size of 1280 bytes, which is consistent with the IPv6 MTU size constraint to ensure fast and reliable transmission of cluster information over UDP. After calculating the necessary headers (40 bytes for IPv6 and an 8-byte fragment header), 1232 bytes are still available for the packet. The combination of signature and message cannot exceed this limit.
A Solana cluster ( cluster ) is a group of validators that work together to process transactions and maintain their own ledger. Solana has several different clusters, each with a specific purpose:
Clusters correspond to different Ethereum networks.
Localhost: Local development cluster at the default port 8899. The Solana Command Line Interface (CLI) comes with a built-in Test Validator that can be customized to the needs of individual developers without any airdrops or rate limits. Development Network (Devnet): A value-free sandbox environment for testing and experimenting on Solana. Test Network (Testnet): A testing ground for Solana core contributors to experiment with new updates and features before they reach the mainnet. It is also used as a testing environment for developers to perform performance testing
Mainnet Beta: A live, permissionless cluster with real-world transactions occurring. This is the “real” Solana that users, developers, token holders, and validators interact with every day
Each cluster runs independently and is completely unaware of the existence of the other clusters. Transactions sent to the wrong cluster will be rejected to ensure the integrity of each running environment.
This article introduces the core concepts of Solana, including its account model, block generation mechanism, and transaction fee structure.
After understanding these basics, we will start to develop applications for Solana.
How Solana works - How it works
In-depth Solana consensus - from forks to finality
Peter Todd has gone into hiding for safety reasons after an HBO documentary claims he is Satoshi Nakamoto with filmmaker Cullen Hoback backing it. This controversy raises questions: Is it a publicity stunt, or could there be truth to Todd's denial?
CatherineA former CEO lost nearly all his savings after connecting to a close friend's WiFi, which allowed the friend to take control of his device and steal $450,000 from his cryptocurrency wallet. After an investigation, he recovered some of the funds but learned a hard lesson about trust and the risks of using public networks.
WeatherlyIn Russia, individuals using cryptocurrency are increasingly hiring arsonists and other criminals on the dark web, with some perpetrators as young as teenagers. This trend raises an important question: are young people being lured into the realm of crypto-driven crime?
Kikyo中国研究团队据称利用D-Wave量子计算机攻破了传统加密算法，包括保护银行账户和加密钱包的机制。这一消息在全球引发广泛关注，尽管研究细节尚未完全披露，其对加密货币和其他加密技术的影响仍在评估中。
WeiliangAnthropic has launched two new AI models, Claude 3.5 Sonnet and Claude 3.5 Haiku, featuring improved coding abilities and performance. The Sonnet model can now interact with computer interfaces directly, allowing it to automate tasks, while the Haiku model aims to deliver high efficiency and low latency for user-facing applications.
WeatherlyMeta cautiously reintroduces facial recognition, testing it on 50,000 celebrities to combat "celeb-bait" scams and reduce deepfake ads. But is this enough to stop compromised accounts, or is more action required?
CatherineTesla recently transferred its entire Bitcoin stash of 11,509 BTC to new wallets, sparking speculation about a possible sell-off. However, blockchain analysts believe these movements are just wallet rotations, indicating that Tesla still owns the Bitcoin and may be preparing for future strategic moves.
AnaisA man from China, Jiangsu, accumulated significant debt after losing money in cryptocurrency and gambling. To cover his losses, he committed fraud by borrowing against luxury cars he didn't own, which led to his arrest and a three-year prison sentence for contract fraud.
Weatherly本周一，菱传媒爆料，前台北市长柯文哲因涉嫌京华城案被羁押，相关调查发现其加密货币冷钱包已被查扣。然而，由于缺少钱包的私钥和助记词，检调遇到技术瓶颈，调查进展受阻，或将延长羁押期限。专家指出，即便无助记词，USDT等加密资产仍有可能通过申请冻结处理。
AlexTelegram game Tomarket has set new requirements for its 31 October TOMA token airdrop on TON. Players must reach Bronze status and include a tomato emoji in their username to qualify. The key question: will TOMA fade after the hype, or achieve lasting success?
Catherine