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 in a series of articles, this article mainly introduces some knowledge you need to know before developing Solana:

Background of the birth of Solana

How Solana generates blocks (Consensus operation)

Solana core concepts: account model, PDA, transactions and fees, clusters, etc.

Solana birth background

Solana was founded in 2017 by Anatoly Yakovenko. Anatoly chose the name Solana as a nod to Solana Beach, a small beach town north of San Diego where they lived and surfed for three years while working at Qualcomm.

Prior to founding Solana, Anatoly spent many years working at Qualcomm, Mesosphere, and Dropbox, and has extensive experience in high-performance networking and distributed systems.

He recognized that blockchain’s scalability bottlenecks limited its potential for large-scale application. 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.

Solana Consensus - How to generate blocks

Note: The Solana consensus algorithm document is somewhat outdated. The content of this part is based on the in-depth Solana consensus and my understanding.

Solana is a proof-of-stake (PoS) blockchain. The consensus algorithm follows two stages: 1. Select validators to produce blocks. 2. Other validators vote on the blocks and accumulate enough After multiple votes, the block is finally confirmed.

Select a validator

In Solana’s protocol, there are two important words related to time intervals: Epoch and slot:

Slot: Validator The time unit for generating blocks. One block can be generated per time slot, and each time slot lasts 400 milliseconds.

Epoch: At the beginning of each Epoch, the Solana network will randomly elect a sequence of validators (called leaders) based on the pledge weight and previous blocks. This leader sequence is responsible for the execution of the Epoch. Within the block, the leader sequence remains fixed during this period, and each leader can process 4 S continuously.lot (i.e. 4 blocks), each Epoch lasts approximately two days (containing 432,000 Slots). Until the next Epoch, the leader will be regenerated.

In the above figure, each colored block represents a block, different The colors represent different verified blocks.

I won’t go into details about random election here (mainly because I don’t understand it). At the beginning of each Epoch, the verifier will know which slots require him to produce blocks.

But there are two problems that need to be solved here:

How does the validator know that it is its turn to produce a block? If you only rely on network communication, and the previous validator tells the next validator, it is likely to miss valuable block time due to network delay (or the previous validator is offline). After all, the block time is only 0.4 seconds.

How to stuff as many transactions as possible into a block. If, like Ethereum, one transaction is executed one after another, many transactions cannot be accommodated in such a short period of time.

Solana’s most important innovation - POH, is mainly used to solve these two problems.

Block

In order to achieve high performance, Solana introduces 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 according to the same sorting sequence. In order to allow the transaction sorting sequence to be verified, Solana uses the POH historical proof hash chain to determine the order of transactions.

PoH works by creating a series of cryptographic hashes (SHA256 algorithm), each hash calculation using the previous hash value , this ensures 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 transaction data as part of the input when calculating the hash, and you can determine Sequence of transactions. And this sequence is parallelizable, verifiable and tamper-proof.

The current leader validator will continue to receive transactions from the RPC server and other validators. After preliminary verification (such as verifying transaction signatures and account balances), the POH hash will be added. Sorting in the calculation of the chain, that is, giving each transaction a full, verifiable chronological tags, and then execute transactions in parallel.

In Solana, the entire transaction processing process is split into multiple interconnected stages (transaction verification stage, POH sorting stage, execution stage, broadcast stage), forming a pipeline. Different stages can process different batches of transactions in parallel and overlapping, that is, different CPU cores or GPUs are simultaneously processing the verification of one batch of transactions and the execution of another batch of transactions (called banking).

The execution of transactions is also parallel. Transaction execution arranges parallelism based on the read and write dependencies of the account, groups transactions according to dependencies, and executes them in different threads/CPU cores/GPU tasks in parallel.

If the accounts operated by 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 order to avoid data inconsistency.

Now we understand the process of Solana’s block generation. In this way, Solana can process a large number of transactions in a single Slot (about 400ms).

POH - Synchronized Clock

There is another question, how does the verifier know that it is its turn to produce a block?

Each hash operation requires a minimum of time, and each hash calculation requires the use of the previous hash value. This ensures that parallelization is not possible. 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 current Slot leader is responsible for generating these PoH chains (blocks).

In fact, no validator is calculating the PoH chain (an empty Hash chain without transaction data) in the background. If the previous leader (or multiple previous leaders) has not published a block (or The current leader has not received), as long as the number of hashes required by the Slot is passed, the current leader can generate blocks on time.

As shown in the figure below, Slot3 is offline, and the verifier of Slot4 fills the PoH sequence for slot3.

Verification and voting blocks

The verification process of the block includes verification of block metadata and recalculation The PoH hash verifies and replays all transactions from the block and updates the ledger.

After the verification is passed, voting represents the verifier's commitment to a block. The more entrusted rights (coins) the verifier holds, the greater the weight of the vote.

Usually, the validator will choose the heaviest chain to produce blocks and vote, if the previous leader appearsIf the block 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 selects the one with the most votes. A block is confirmed if it receives at least two-thirds of the stake-weighted votes.

Solana Core Concept Solana Account

When developing on Solana, the biggest difference from Ethereum is that the account model is different.

Solana accounts are very similar to Linux files. Everything is an account, which is a storage unit. They come in many forms:

User account: controlled by a private key Account, usually generated for the user by the wallet software.

Program account: An account used to store executable bytecode (smart contract code).

Data account: An account that stores status information, such as the number of specific tokens held by the user.

Native program accounts: These are special pre-deployed program accounts that perform various core functions of the network. Includes system program, voting program and BPF loader.

Solana's center Program accounts (i.e. smart contracts) are stateless, read-only and do not store any data/status. Data is stored under separate data accounts.

When you call a function of the Solana contract, we need to pass the data account used to the function. It is easy to have transactions that have no interdependencies execute concurrently.

If you know EVM, you will know that status 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, used to store the code of the program, and one account is used to store the value of the counter.

Renting is Solana’s way of reducing state bloat by requiring accounts to maintain a minimum balance to remain active. Rentals ensure that the network eventually reclaims unused or underfunded accounts. Rent is waived if the account maintains a minimum balance equal to two years' rent.

The design of Solana’s account, in addition to the benefits of concurrent execution, can also bring program reusability. There are a large number of identical ERC20 codes on Ethereum.

Solana is different, there is no need to redeploy smart contracts when creating new tokens. Instead, just create a new account, called a minting account, which defines the number of tokens, their names, who can mint more tokens, etc.

Program Derived Addresses (PDA: Program Derived Addresses)

The account used to save program data is PDA,

Ordinary user accounts have public keys/addresses, and they correspond to ed25519 ellipse A point on the curve where the private key is used to sign to prove authority to modify the account.

Programmed Derived Addresses (PDAs) are accounts generated outside the curve using bump (i.e. the value of the output deviating from the curve). A PDA requires three main parts: a parent ID, a set of seeds, and a hop value. A seed is an array of strings, usually set to a specific seed associated with a state variable in a program to create a hash table-like data structure. to generate the corresponding PDA.

The program that deduces the PDA is its owner, and only this program can modify the data of the PDA.

Transaction

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)

Recent block hash (recent_blockhash)

An instruction is the smallest execution logic on Solana. The instruction specifies the execution of the program, all accounts involved, and operational data. The instruction calls the program to update the status (for example, calling the token program to transfer tokens from your account to another account), the program interprets the data in the instruction, and performs operations on the specified account.

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 the transaction, but we want to trade, the most recent blockhash will be pulled from the cluster to create a valid transaction. Transactions are valid 150 blocks after the most recent blockhash. If the change time is exceeded, the transaction needs to be reinitiated.

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), and the basic handling fee Currently set to 0.000005 SOL per signature (5k lamports), which are one-time fees paid to the network in advance for the right to use network resources, 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 verification node that generated the block, and the remaining 50% is destroyed.

If it wants to increase the priority of its transactions [optional fee], it can set a "calculation unit price". This price is used in conjunction with the compute unit limit to determine the transaction's priority fee.

The default calculation unit limit is 200,000 CU per instruction. If the calculation amount is relatively large, you can set the maximum to 1.4 million CU. Solana transactions will pre-request a specified number of compute units (CUs), and if this number is exceeded, the transaction will fail.

In addition, Solana transactions are subject to transaction packet size restrictions. The Solana network follows a maximum transmission unit (MTU) size of 1280 bytes, which is consistent with the IPv6 MTU size constraint to ensure that cluster information is transmitted through UDP. Fast and reliable. After counting the necessary headers (40 bytes for IPv6 and an 8-byte fragment header), 1232 bytes are still available for the packet, and the combination of signature and message cannot exceed this limit.

Solana Cluster

Solana cluster (cluster) is a group of validators that jointly process transactions and maintain their own ledger data (ledger). Solana has several different clusters, each with a specific purpose:

The clusters correspond to different Ethereum networks.

Localhost: The local development cluster located on the default port 8899. The Solana Command Line Interface (CLI) comes with a built-in test verifier that can be customized to individual developer needs without any airdrops or encountering rate limits

Development Network (Devnet) :useA value-free sandbox environment for testing and experimenting on Solana

Testnet: A testing ground for Solana core contributors to experiment with new updates and features before they reach mainnet. It is also used as a testing environment for developers to conduct performance testing

Mainnet Beta: a live, permissionless cluster where real-world transactions occur. 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 other clusters. Transactions sent to the wrong cluster will be rejected to ensure the integrity of each operating environment.

Summary

This article introduces the core concepts of Solana, including its account model, block generation mechanism, and transaction fee structure.

After understanding these basic knowledge, we will start to develop applications with Solana.

Reference articles

How Solana works - working principle

In-depth Solana consensus - from forks to finality

< /mp-style-type>