A Reanalysis of Solana's Technical Architecture: Is a Second Spring Coming Soon?

Solana is a high-performance blockchain platform that utilizes 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 enhance block production rates. 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, especially in DeFi, infrastructure, GameFi/NFT, DePin/AI, and consumer application fields. Solana's high TPS and its strategy focused on consumer applications, along with the relatively weak brand effect of its ecosystem, provide abundant entrepreneurial opportunities for entrepreneurs and developers. In terms of consumer applications, Solana demonstrates its vision for advancing 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 instance, applications like Stepn combine blockchain and mobile technology to offer users novel fitness and social experiences. Although many consumer applications are still exploring the best business models and market positioning, the technological platform and ecosystem support provided by Solana undoubtedly offer strong backing for these innovative attempts. With further technological development and market maturation, Solana is expected to achieve more breakthroughs and success stories in the consumer application field.

Although Solana has gained a 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. A certain trading platform, as a potential competitor in the EVM ecosystem, is rapidly increasing its number of active addresses on-chain. Meanwhile, although Solana's total locked value (TVL) in the DeFi sector has reached a historic high of (, competitors like this trading platform are quickly capturing market share, and the financing amount of this trading platform's ecosystem has also surpassed Solana for the first time in Q2.

Although Solana has achieved certain accomplishments in technology and market acceptance, it needs to continually innovate and improve to address challenges from competitors such as certain trading platforms. In particular, Solana needs to continuously optimize its technical architecture and network protocols to maintain its leading position in the blockchain industry, especially in improving network stability, reducing transaction failure rates, addressing MEV issues, and slowing down state growth.

![Re-exploring Solana's technical architecture: Is a second spring coming?])https://img-cdn.gateio.im/webp-social/moments-224796bc8e080649730bb8736334abba.webp(

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, and the drawbacks and derived issues brought about by 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 establishes the order of transactions. The POH technology is derived from the most fundamental cryptographic SHA256 technology. SHA256 is typically used to compute data integrity; given an input X, there is exactly one unique output Y, so 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 determines 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 within this block are confirmed. Any changes will result in a change of the hash value. Subsequently, this block hash will serve as part of the X in the next sha256 function, adding the hash of the next block. Thus, both the previous block and the next block 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 proof of history.

![Reinterpret Solana Technical Architecture: Is a Second Spring Coming?])https://img-cdn.gateio.im/webp-social/moments-46a028270f3c2da92e7056c17c1d9e16.webp(

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

In order to avoid a 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 lasting 400ms. In each slot, the rotation system allocates a Leader node within that 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 following 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 send transactions to the Leader through RPC nodes, and the Leader node packages, sorts, and executes the transactions to generate blocks, which are then propagated to other validators. The validators need to reach a consensus through a mechanism on the transactions and their order within the block, and the consensus mechanism 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 considered a transaction, then the block hash formed by the user transaction and the validator's transaction can also serve as historical proof, uniquely confirming the transaction details of which user and the voting details of the validator.

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

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 to approve, then this block can be confirmed. The benefit of this mechanism is that it saves a lot of memory, as only the hash sequence needs to be voted on to confirm the block. However, in traditional consensus mechanisms, block flooding is generally used, where a validator that receives the block will send it to surrounding validators, which causes a large amount of redundancy in the network, as a validator receives the same block more than once.

In Solana, due to the large number of validators voting on transactions and the efficiency brought by the centralization of Leader nodes along with a 400ms Slot time, this leads to a particularly high overall block size and block generation frequency. When large blocks are propagated, they can put significant pressure on the network. Solana uses the Turbine mechanism to address the propagation issues of large blocks.

( Turbine

The Leader node splits blocks into sub-blocks called shreds through a process known as Sharding, with the size specification based on the maximum transmission unit MTU), representing the maximum amount of data that can be sent from one node to the next without being divided into smaller units, measured in units of ###. Data integrity and availability are then ensured by using the Reed-Solomon erasure coding 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 50% packet loss rate. In actual testing, the packet loss rate of Solana is approximately 15%, so this scheme is well compatible with the current Solana architecture.

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

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

1. Create a node list: The root node will compile all active validators into a list, and then sort them based on each validator's stake in the network, which is the amount of staked SOL, (. Those with higher weights will be placed in the first tier, 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 approximate shape of the entire tree can be established. This parameter will affect the propagation rate of shreds.

Nodes with a higher equity share, when tiered, can advance to a higher level, allowing them to obtain complete shreds in advance. At this point, they can restore the complete block. Conversely, nodes at lower tiers, due to transmission loss, will have a reduced probability of obtaining complete shreds. If these shreds are insufficient to construct complete fragments, the Leader will be required to retransmit directly. At this time, data transmission will move inward within the tree, while the nodes at the first tier have already constructed complete block confirmations. The longer it takes for validators at the lower tiers to complete block construction and cast votes.

The idea behind this mechanism is similar to the single-node mechanism of the Leader node. During the block propagation process, there are also some prioritized nodes, which are the first to obtain shreds to assemble complete blocks in order to achieve voting consensus. Pushing redundancy to a deeper level can significantly accelerate the process of Finality and maximize throughput and efficiency. Because, in fact, 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 the virtual machine for state transitions, if the Leader node has a slower SVM processing speed during transaction execution, it will reduce the overall throughput of the system. Therefore, for SVM, Solana has proposed the Sealevel parallel execution engine to accelerate the transaction execution speed.

In SVM, instructions consist of four parts, including program ID, program instructions, and a list of accounts for reading/writing data. By determining whether the current account is in a read or write state and whether the operation for state change has conflicts, parallelization of transaction instructions for accounts with no state conflicts can be allowed, with each instruction represented by the Program ID. This is also one reason why the requirements for Solana's validators are high, as it requires validators' GPUs/CPUs to support SIMD### Single Instruction Multiple Data( and AVX Advanced Vector Extensions capabilities.

Ecological Development

In the current development process of the Solana ecosystem, there is an increasing tendency towards practical utility, such as Blinks, Actions, and even Solana Mobile. The direction of application development supported by the official also.