Unveiling the Speed King in the Blockchain World – Solana

A Performance Report
According to the “Fastest Chains” report released by CoinGecko on May 17th, Solana is the fastest blockchain among large-scale blockchains, with a peak daily average TPS of 1,504 (excluding voting transactions). Sui is the second fastest blockchain, with a peak daily average TPS of 854. BSC ranks third, but its real TPS is less than half of Sui’s.


From this report, it can be seen that Solana and Sui, the top-performing blockchains, are both non-EVM compatible. Furthermore, the average real TPS of eight non-EVM compatible blockchains is 284, while the average TPS of 17 EVM compatible blockchains and Ethereum Layer2 is only 74. The performance of non-EVM compatible blockchains is about four times that of EVM compatible blockchains.
This article will explore the performance bottlenecks of EVM compatible blockchains and uncover the performance secrets of Solana.
Performance Bottlenecks of EVM Compatible Blockchains


First, let’s generalize EVM blockchains to general blockchains. There are several ways for general blockchains to improve TPS:
Improving node performance: By allocating more hardware resources to nodes, node performance can be improved. The hardware requirements of nodes affect the degree of decentralization. For example, Ethereum recommends a configuration of 4 cores CPU, 16GB memory, and 25Mbps network bandwidth, which can be achieved by ordinary user-level devices, resulting in a higher degree of centralization. Solana recommends a relatively higher configuration of 32 cores CPU, 128GB memory, and 1Gbps network bandwidth, which can only be achieved by professional-level devices, resulting in a moderate degree of centralization.
Improving underlying protocols: This includes network protocols, cryptography, storage, etc. Improving the underlying protocols of blockchains does not change the properties of the blockchain itself or affect its operational rules. It can directly improve the performance of the blockchain. However, the underlying technology has low attention in the research field and has not made any major breakthroughs so far.
Increasing block size: Increasing the size of blocks can accommodate more transactions and increase the transaction throughput of the blockchain. For example, Bitcoin Cash (BCH) increased the block size from 1MB to 8MB and later expanded it to 32MB. However, increasing the block size also increases propagation delay, leading to security threats such as increased possibility of forks and DDoS attacks.
Consensus protocols: Consensus protocols ensure that nodes in the blockchain reach a consensus on the state updates of the blockchain. They are the most important security barrier for blockchains. Existing consensus mechanisms used in blockchains include PoW, PoS, PBFT, etc. In order to meet the scalability requirements, general high-performance public chains will improve the consensus protocol and combine it with their own special mechanisms. For example, Solana is based on the PoH consensus mechanism, and Avalanche is based on the Avalanche consensus mechanism.
Transaction execution: Transaction execution only concerns the number of transactions or computing tasks processed in a unit of time. Blockchains like Ethereum execute smart contract transactions in a serial manner. In serial execution, the CPU’s performance bottleneck is very obvious, severely limiting the throughput of the blockchain. General high-performance public chains use parallel execution, and some even propose language models that are more conducive to parallelism to construct smart contracts, such as Sui Move.
For EVM blockchains, the biggest challenge lies in transaction execution due to the limitation of the virtual machine, which is the execution environment for transactions. EVM has two main performance issues:
256-bit: EVM is designed as a 256-bit virtual machine for easier handling of Ethereum’s hash algorithm, which explicitly produces 256-bit outputs. However, the computers running EVM need to map the 256-bit bytes to their local architecture for execution, and one EVM opcode corresponds to multiple local opcodes, making the whole system very inefficient and impractical.
Lack of standard libraries: Solidity does not have standard libraries, and they must be implemented using Solidity code. Although OpenZeppelin has improved this situation to some extent by providing a Solidity implementation of standard libraries (by including the code in contracts or calling deployed contracts via delegatecall), the execution speed of EVM bytecode is far inferior to pre-compiled standard libraries.
From the perspective of execution optimization, EVM also has two major shortcomings:
Difficult to perform static analysis: Parallel execution in blockchains means processing unrelated transactions at the same time, treating unrelated transactions as independent events. Implementing parallel execution mainly involves determining which transactions are unrelated and independent. Currently, some high-performance public chains pre-analyze transactions, but EVM’s dynamic jumps mechanism makes it difficult to perform static analysis on the code.
Immature JIT compiler: JIT compiler (Just In Time Compiler) is a commonly used optimization technique in modern virtual machines. The main goal of JIT is to transform interpreted execution into compiled execution. During runtime, the virtual machine compiles hot code into machine code relevant to the local platform and performs various levels of optimization. Although there are projects on EVM JIT, they are still in the experimental stage and not mature enough.
Therefore, in terms of virtual machine selection, high-performance public chains tend to use virtual machines based on WASM, eBPF bytecode, or Move bytecode, rather than EVM. For example, Solana uses its unique SVM virtual machine and eBPF-based SBF bytecode.
Fastest Chains: Solana


Solana is known as one of the most famous “Ethereum killers” due to its PoH (Proof of History) mechanism and low-latency high-throughput capabilities.
The core of PoH is a simple hash algorithm similar to Verifiable Delay Functions (VDFs). Solana uses a hash function (SHA-256) with sequence pre-images resistance, which runs continuously and uses the output of one iteration as the input for the next. This computation runs on a single core of each validator.


Although sequence generation is sequential and single-threaded, verification can be done in parallel, thus achieving efficient verification on multi-core systems. While there is an upper bound on the speed of hashing, hardware improvements can provide additional performance gains.


Solana Consensus Process
The PoH mechanism creates verifiable and ordered event records within the network. PoH-based timing allows the Solana network to rotate leaders in a predictable and transparent manner. This rotation occurs at fixed time intervals, known as slots, each currently set at 400 milliseconds. This leader rotation mechanism ensures that every participating validator has a fair chance to become a leader, and it is an important mechanism for maintaining decentralization and security in the Solana network, preventing any individual validator from gaining too much power on the network.
During each slot, the current leader proposes a new block that includes transactions received from users. The leader verifies these transactions, packs them into a block, and then broadcasts the block to the rest of the validators in the network. This process of proposing and broadcasting blocks is called block production, and other validators in the network must vote on the validity of the block. Validators check the contents of the block, ensure the validity of the transactions, and compliance with network rules. If a block receives a majority of weighted votes, it is considered confirmed. This confirmation process is crucial for maintaining the security of the Solana network and preventing double spending.
When the current leader’s time slot ends, the network does not stop or wait for block confirmation. Instead, it moves on to the next time slot, providing an opportunity for the next leader to produce blocks, and the whole process starts again. This approach ensures that the Solana network maintains high throughput and resilience, even if some validators encounter technical issues or go offline.
Solana’s Performance Secrets
Since the Solana network can confirm leaders in advance, it does not need a public memory pool to store user transactions. When a user submits a transaction, the RPC server converts it into QUIC packets and immediately forwards them to the leader’s validators. This approach, known as Gulf Stream, allows for fast leader transitions and pre-execution of transactions, reducing the memory load on other validators.
Solana’s block data is brought into the kernel space and then passed to the GPU for parallel signature verification. Once the signatures are verified on the GPU, the data is passed to the CPU for transaction execution and finally returned to the kernel space for data persistence. This division of data into different hardware components and multiple processing stages is called pipeline technology, which maximizes hardware utilization and speeds up block verification and transmission.
Since Solana’s transactions explicitly specify which accounts to access, Solana’s transaction scheduler can execute transactions in parallel using a read-write lock mechanism. Solana’s transaction scheduler has a queue managed by each thread, which sequentially and independently processes transactions, attempting to lock (read-write lock) the accounts of the transactions and execute them. Transactions with account conflicts will be executed later. This multi-threaded parallel execution technique is called Sealevel.
During the process of propagating blocks, the leader divides QUIC packets (optionally using erasure coding) into smaller packets and distributes them to validators with a hierarchical structure. This technique, known as Turbine, primarily aims to reduce the leader’s bandwidth usage.
During the voting process, validators use a consensus mechanism tailored for forking votes. Validators do not need to wait for votes to continue block production; instead, block producers continuously monitor valid new votes and incorporate them into the current block in real-time. This consensus mechanism, known as TowerBFT, ensures a more efficient and streamlined consensus process, thereby improving overall performance.
For the process of block persistence, Solana has developed the Cloudbreak database, which partitions the account data structure in a specific way to benefit from the speed of sequential operations and uses memory-mapped files to maximize SSD efficiency.
To reduce the burden on validators, Solana transfers data storage from validators to a node network called Archiver. The transaction history of the state is split into many fragments and uses erasure coding. Archivers are used to store the fragments of the state, but they do not participate in consensus.
Conclusion
Solana’s vision is to become a blockchain that scales its software with the speed of hardware. Therefore, Solana maximizes the performance by utilizing all the CPU, GPU, and bandwidth capabilities available in today’s computers, with a theoretical maximum speed of 65,000 TPS.
It is precisely because of Solana’s high performance and scalability that it has become the preferred blockchain platform for handling high-frequency transactions and complex smart contracts, whether it is in the early DePIN/AI track or the recent hot Meme track. Solana has shown tremendous potential.
After the launch of Ethereum ETF, Solana has also become the cryptocurrency with the highest expectation for the next ETF, although the SEC still classifies Solana as a security and will not approve other cryptocurrency ETFs in the short term. However, in the crypto market, consensus means value, and Solana’s consensus may be becoming as invincible as Bitcoin and Ethereum.