Analysis of Solana's Technical Architecture: Is a New Spring Coming?

Solana is a high-performance blockchain platform that uses a unique technical architecture to achieve high throughput and low latency. Its core technologies include the Proof of History (POH) algorithm, which ensures transaction order and a global clock, the Leader Rotation Schedule, and the Tower BFT consensus mechanism, which improve block production speed. The Turbine mechanism optimizes large block propagation through Reed-Solomon encoding. The Solana Virtual Machine (SVM) and the Sealevel parallel execution engine accelerate transaction execution speed. These are all architectural designs that enable Solana to achieve high performance, but they also bring some issues, such as network outages, transaction failures, MEV problems, rapid state growth, and centralization issues.

The Solana ecosystem is developing rapidly, with various data indicators showing significant growth in the first half of the year, particularly in the fields of DeFi, infrastructure, GameFi/NFT, DePin/AI, and consumer applications. Solana's high TPS and its strategy focused on consumer applications, coupled with a relatively weak brand effect in the ecosystem, provide abundant entrepreneurial opportunities for entrepreneurs and developers. In terms of consumer applications, Solana showcases its vision for promoting the application of blockchain technology in broader fields. By supporting initiatives like Solana Mobile and building SDKs specifically for consumer applications, Solana is committed to integrating blockchain technology into everyday applications, thereby enhancing user acceptance and convenience. For example, applications like Stepn provide users with novel fitness and social experiences by combining blockchain and mobile technology. Although many consumer applications are still exploring the best business models and market positioning, the technological platform and ecosystem support offered by Solana undoubtedly provide a strong backing for these innovative attempts. As technology continues to develop and the market matures, Solana is expected to achieve more breakthroughs and success stories in the field of consumer applications.

Although Solana has gained significant market share in the blockchain industry due to its high throughput and low transaction costs, it also faces fierce competition from other emerging public chains. Base, as a potential competitor in the EVM ecosystem, is seeing a rapid increase in the number of active addresses on its chain. Meanwhile, Solana's total locked value ( TVL ) in the DeFi sector, although it has reached an all-time high, is also being quickly captured by competitors like Base, with Base's financing amount surpassing Solana for the first time in Q2.

Despite achieving certain accomplishments in technology and market acceptance, Solana needs to continuously innovate and improve to meet challenges from competitors like Base. In particular, Solana needs to continuously optimize its technical architecture and network protocols in areas such as improving network stability, reducing transaction failure rates, addressing MEV issues, and slowing the rate of state growth, in order to maintain its leading position in the blockchain industry.

Technical Architecture

Solana is known for its high TPS and fast Finality brought by its POH algorithm, Tower BFT consensus mechanism, Trubine data transmission network, and SVM virtual machine. We will briefly introduce how each of its components works, how they achieve their high-performance goals for architectural design, as well as the drawbacks and derived issues that arise from this architectural design.

POH algorithm

POH(Proof of History) is a technology that determines global time; it is not a consensus mechanism, but rather an algorithm that determines the order of transactions. The POH technology originates from the most fundamental cryptographic SHA256 technology. SHA256 is commonly used to compute data integrity, where given an input X, there is a unique output Y, thus any change to X will result in a completely different Y.

In the POH sequence of Solana, the integrity of the entire sequence can be ensured by applying the sha256 algorithm, which also confirms the integrity of the transactions within it. For example, if we package transactions into a block and generate the corresponding sha256 hash value, then the transactions in this block are confirmed; any changes will result in a change in the hash value. Subsequently, this block hash will serve as part of the next sha256 function's X, adding the next block's hash. Thus, both the previous and the next blocks are confirmed, and any changes will lead to a different new Y.

This is the core meaning of its Proof of History technology, where the hash of the previous block serves as part of the next sha256 function, similar to a chain, with the latest Y always containing a proof of history.

In the transaction flow architecture diagram of Solana, the transaction process under the POH mechanism is described. A Leader node is generated among all the chain validators in a rotation mechanism called Leader Rotation Schedule. This Leader node collects transactions, sorts and executes them, generates a POH sequence, and then generates a block to be propagated to other nodes.

In order to avoid single point of failure at the Leader node, a time limit has been introduced. In Solana, time is divided into epochs, with each epoch containing 432,000 slots(. Each slot lasts for 400ms, and within each slot, the rotation system will allocate a Leader node for each slot. The Leader node must publish a block)400ms( within the given slot time; otherwise, this slot will be skipped, and the next Leader node for the slot will be re-elected.

Overall, the Leader node uses the POH mechanism to finalize all historical transactions. The basic time unit of Solana is a Slot, and the Leader node needs to broadcast blocks within a slot. Users submit transactions to the Leader through RPC nodes, the Leader node packages and sorts the transactions, then executes them to generate a block, which is propagated to other validators. Validators need to reach a consensus through a mechanism on the transactions within the block and their order, and the consensus used is the Tower BFT consensus mechanism.

) Tower BFT consensus mechanism

The Tower BFT consensus protocol is derived from the BFT consensus algorithm and is a specific engineering implementation of it. This algorithm is still related to the POH algorithm. When voting on a block, if the validator's vote itself is a transaction, then the block hash formed by the user transaction and the validator transaction can also serve as historical proof, uniquely confirming the transaction details of which user and the voting details of the validator.

In the Tower BFT algorithm, it is stipulated that if all validators vote on the block and more than 2/3 of the validators vote in favor (approve), then this block can be confirmed. The benefit of this mechanism is that it saves a lot of memory, as it only requires voting on the hash sequence to confirm the block. However, in traditional consensus mechanisms, block flooding is generally adopted, where a validator receives a block and then sends it to surrounding validators, which can cause a lot of redundancy in the network, as a validator receives the same block multiple times.

![Re-exploring Solana's Technical Architecture: Will It Welcome a Second Spring?]###https://img-cdn.gateio.im/webp-social/moments-46a028270f3c2da92e7056c17c1d9e16.webp(

In Solana, due to the large number of validator voting transactions and the efficiency brought by the centralization of leader nodes along with a 400ms slot time, this results in a particularly high overall block size and block production frequency. When large blocks are propagated, it can put significant pressure on the network. Solana uses the Turbine mechanism to address the issue of large block propagation.

) Turbine

Leader nodes split blocks into sub-blocks called shreds through a process known as Sharding, with a specification size of MTU###, which is the maximum amount of data that can be sent from one node to the next without needing to split it into smaller units, measured in units of (. Data integrity and availability are then ensured by using the Reed-Solomon erasure code scheme.

By dividing the block into four Data Shreds, and then using Reed-Solomon coding to encode the four packets into eight packets to prevent packet loss and damage during data transmission, this scheme can tolerate up to a 50% packet loss rate. In practical tests, the packet loss rate for Solana is approximately 15%, so this scheme can work well with the current Solana architecture.

In the underlying data transmission, UDP/TCP protocols are typically considered. Due to Solana's high tolerance for packet loss, the UDP protocol is used for transmission. Its disadvantage is that it does not retransmit when packets are lost, but its advantage is a faster transmission rate. In contrast, the TCP protocol retransmits multiple times upon packet loss, which greatly reduces transmission rate and throughput. With Reed-Solomon, this solution can significantly increase Solana's throughput, achieving a 9-fold increase in real-world environments.

After Turbine shards the data, it uses a multi-layer propagation mechanism to spread it. The Leader node will hand over the block to any block validator before the end of each Slot, and then the validator will shard the block into Shreds and generate erasure codes. The validator will then initiate the Turbine propagation. First, it needs to propagate to the root node, and then the root node will determine which validators are at which layer. The process is as follows:

1. Create a node list: The root node will compile all active validators into a list, then sort them based on each validator's stake in the network, which is the amount of staked SOL, with the higher weights positioned in the first layer, and so on.

2. Node Grouping: Then each validator located in the first layer will also create their own node list to build their own first layer.

3. Layer Formation: Nodes are divided into layers from the top of the list. By determining the values of depth and breadth, the overall shape of the tree can be determined. This parameter will affect the propagation speed of shreds.

Nodes with a high equity share, when classified in the hierarchy, will be at a higher level, allowing them to obtain complete shreds in advance. At this point, they can restore the complete block. Nodes at lower levels, due to transmission loss, will have a reduced probability of obtaining complete shreds. If these shreds are insufficient to construct a complete fragment, the Leader will be required to retransmit directly. At this time, data transmission will move towards the internal tree, and the first-level nodes have already constructed the complete block confirmation. The longer the time it takes for the validators at the lower levels to complete the block construction and then vote.

![Revisiting Solana's Technical Architecture: Is a Second Spring Coming?])https://img-cdn.gateio.im/webp-social/moments-d55d3cfbc13036ed0d5747abb521cc1a.webp(

The idea behind this mechanism is similar to the single-node mechanism of a Leader node. During the process of block propagation, there are also some prioritized nodes that first obtain shreds to assemble a complete block to achieve the voting consensus. Pushing redundancy to a deeper level can significantly accelerate the process of Finality and maximize throughput and efficiency. Because in reality, the first few layers may represent 2/3 of the nodes, so the voting of subsequent nodes becomes irrelevant.

) SVM

Solana can process thousands of transactions per second, mainly due to its POH mechanism, Tower BFT consensus, and Turbine data propagation mechanism. However, as a virtual machine for state transitions, if the Leader node is slow in executing transactions, the processing speed of the SVM will lower the overall system throughput. Therefore, for the SVM, Solana proposed the Sealevel parallel execution engine to speed up transaction execution.

In SVM, instructions consist of four parts: the program ID, program instructions, and a list of accounts for reading/writing data. By determining whether the current account is in read or write mode and whether there are conflicts with the operations that will change the state, the parallelization of transaction instructions that do not conflict with the state can be allowed, with each instruction represented by a Program ID. This is also one of the reasons why the requirements for Solana's validators are high, as validators are required to have GPUs/CPUs that can support SIMD( single instruction multiple data) and AVX advanced vector extension capabilities.

![Reinterpreting Solana's Technical Architecture: Will It迎来第二春?]###https://img-cdn.gateio.im/webp-social/moments-e9bc35d0c790496c59c20979e5af1491.webp(

Ecological Development

In the current development process of the Solana ecosystem, there is an increasing tendency towards practical utility, such as Blinks and Actions, and even Solana Mobile. The official supported application development direction is also more inclined towards consumer applications rather than an endless internal competition for infrastructure. With Solana's current sufficient performance, the variety of applications is richer. In the case of Ethereum, due to its lower TPS, therefore,