Technical logic of Solana network operation

Each blockchain network has the distinction of network layer, consensus layer, and application layer. The characteristics of each blockchain network are different, and there are also problems because the design ideas in different layers are different. In this article, we will sort out the operating logic of the Solana network. Through these materials, we can understand why Solana will be better than Ethereum when Ethereum 2.0 is not online.

The general ledger of Ethereum is on the 1.0 chain and is maintained by miners. In 2.0, miners become verifiers, and verifiers use computing devices to build verifiers instead of the original miners. Solana also protects the general ledger through the verifier, but the verifier’s consensus algorithm is different. Through the following sequence, we can understand the process of consensus formation.

Solana cluster

The Solana cluster is a group of validators that jointly maintain the integrity of the ledger. There are multiple clusters.

Create a cluster

Before starting any verification node, you first need to create a genesis configuration. The creation configuration will configure a node with the ability to guide verification, and the second verification node can contact the guide verification node to register as a verification node. Then, other validating nodes will continue to register in any registered members of the cluster.

The verification node will receive all entries from the leader and submit a vote to confirm the validity of these entries. After voting, the verification node needs to store these entries. However, once the validating node finds that there are enough copies, it will delete its own copies.

Join the cluster

The verification node enters the cluster through a registration message sent to the control plane. The console is implemented using the gossip protocol, which means that a node can register with any existing node and expect its registration to propagate to all nodes in the cluster. A node can ensure that it ultimately has the same information as every other node, but no node can review this information. The time required for synchronization of all nodes is proportional to the square of the number of nodes participating in the cluster.

Send the transaction to the cluster

The client sends the transaction to the transaction processing unit (TPU) port of any verification node. If the node is in the role of verification node, it forwards the transaction to the designated leader. If in the leader role, the node bundles the incoming transactions, timestamps them, creates an entry, and then pushes it to the dataplane of the cluster. After entering the data center, the transaction will be verified by the verification node, thereby effectively adding the transaction to the ledger.

Confirm transaction

The Solana cluster can confirm up to 150 nodes in sub-second time, and plans to expand to thousands of nodes. Once fully implemented, the confirmation time is expected to only increase with the logarithm of the number of verification nodes, which has a very high base. After the network grows to a certain size, it will become too slow to achieve sub-second confirmation. The time it takes to send a message to all nodes is proportional to the square of the number of nodes. If the blockchain wants to obtain a low confirmation rate and try to use the network to do so, it will be forced to concentrate on a few nodes.

Therefore, the following technology combinations can be used to achieve scalable confirmation:

Use the VDF sample to time-stamp and sign the transaction. Divide the transaction into several batches and send each transaction to a separate node, while each node shares its batch with the peer node. Repeat the previous step recursively until all nodes have all batches.

Solana rotates leaders at regular intervals (called slots). Each leader can only generate entries during his assigned time period. The leader therefore timestamps the transaction so that the verification node can find the public key of the designated leader. Then, the leader signs the timestamp so that the verification node verifies the signature and proves that the signer is the owner of the designated leader’s public key.

Next, divide the transaction into batches so that the node can send the transaction to multiple parties without having to make multiple copies. For example, if the leader needs to send 60 transactions to 6 nodes, it will divide the set of 60 transactions into batches of 10 transactions and send one transaction to each node. This allows the leader to put 60 transactions on the network instead of 60 transactions per node. Then, each node shares its batch with peer nodes. Once the node has collected all 6 batches, it will reconstruct the original set of 60 transactions.

This technology can be called (Turbine Block Propogation) Turbine Block Propogation.


Fast and reliable synchronization is the biggest reason for Solana’s ultra-high throughput. Solana adopted the historical proof PoH algorithm. The leader node with the encrypted proof “time stamp” proves that a certain period of time has passed since the last confirmation. To prove that all the data hashed into the proof must have happened before the proof. The node then shares the new block with the verification node, and they can verify the evidence.

Blocks can be transmitted to the verification node in any order or even delayed for several years. Through this reliable synchronization guarantee, Solana can break the block into smaller batches of transactions, called entries. Before any consensus is reached, the entry will be transmitted to the verification node in real time.

From a technical point of view, Solana has never sent a block, but will use this term to describe the verification node voting on the entry, and finally obtain confirmation. In this way, Solana’s confirmation time can reach 800 milliseconds. In this mode, if a consensus cannot be reached on an event, the node simply needs to roll back its state.

Leader rotation

Each verification node uses the same algorithm to select the expected leader. When the verification node receives a new signed ledger entry, it can be certain that an entry is from the expected leader. The sequence of slots assigned to each leader is called the leader schedule.

A validating node will reject blocks that have not been signed by the slot leader. The identity list of all slot leaders is called the leader schedule. The leader schedule is generated through regular local recalculation. It assigns the slot leader for a period of time called an epoch. The schedule must be earlier than its allocated time period, so that it ensures that the accounting status of the calculation plan can finally be determined. This duration is called the leader schedule offset time. Solana sets the offset time to the slot duration until the next epoch. In other words, the leader plan of an epoch is calculated by the state of the ledger at the beginning of the previous epoch. The offset of an epoch is relatively arbitrary, and it is assumed that the time is long enough so that all validating nodes will determine their ledger status before generating the next plan. The cluster can choose to shorten the offset time to shorten the time between the pledge change and the leader’s plan update.

When the running time is longer than one epoch without partitions, the schedule can only be generated at the epoch boundary of the root fork. Since the schedule is used for the next epoch, any new pledges pledged to the root fork will not be activated before the next epoch. The block used to generate the leader plan is the first block to cross the epoch boundary.

If the partition is shorter than an epoch time, the cluster will operate as follows:

Verifiers constantly update their root forks when voting.

Every time at the height of the slot at the edge of the epoch, the validating node will update its leader schedule.

Write at the end

It is precisely because of the changes to the consensus that Solana faced the market as a high-performance public chain when it was born. The modified version of proof-of-stakes used by it was revised again on top of the proof-of-stakes performance, with the goal of higher performance. , The purpose of this is that even after the emergence of Ethereum 2.0, the network will still be competitive.

However, the competitiveness embodied by this consensus is in application, not in its own technical challenges. In the eyes of some technical personnel with pure beliefs, Solana may be a bit too centralized, but in a huge market, the blockchain network faces different audiences, which will reflect different advantages and disadvantages, and can also be developed differently.

Posted by:CoinYuppie,Reprinted with attribution to:
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Leave a Reply