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
Judge Torres has issued a directive for Ripple and the SEC to jointly propose a briefing schedule concerning the matter of XRP institutional sales. Consequently, the trial has been adjourned.
CatherineThe FTX founder is set to address the jurors directly, seeking to substantiate his assertion that he neither committed nor conspired to commit fraud.
KikyoAccording to ZachXBT, Yahya Maghrab's role primarily involved conducting lookups on X/Twitter accounts through his panel, facilitating scammer Skenkir in identifying potential US targets for SIM swap attacks.
DavinIn the midst of a crypto market rally, the NFT sector stands apart, resolutely bearish despite the broader crypto surge.
JasperSpain strategically positions itself within the realm of the digital euro, signaling a transformative trajectory for the financial landscape.
Hui XinCrypto Sleuth ZachXBT has unveiled that an entity conducted a sizable transfer, about 4,800 BTC, from the depths of the Abraxas darknet market to a Bitcoin mixer.
CatherineCapital A Bhd, the parent company of AirAsia, led by CEO Tony Fernandes, is in the process of securing over $1 billion in financing through a combination of debt and equity. This strategic move is aimed at reshaping the company's future and expanding its financial horizons.
JoyMastercard and MoonPay are looking at ways to make online payments even smoother. They teamed up to pioneer Web3 technologies in experiential marketing & consumer engagement.
YouQuanAside from Mark Lamb, the case also names Roger Ver as a defendant.
ClementTraditional UK banks have recently tightened their stance on cryptocurrency-related activities, resulting in numerous account closures and stricter policies. This shift in the financial landscape has prompted around 38% of crypto investors in the UK to switch banks.
Jasper