A Performance Report
CoinGecko released a report titled “Fastest Chains” on May 17th, which revealed that Solana is the fastest blockchain among large-scale blockchains, with a peak daily average of 1,504 transactions per second (TPS) (excluding voting transactions). Sui is the second fastest blockchain, with a peak daily average of 854 TPS. BSC ranks third, but its real TPS is less than half of Sui’s.
From this report, it can be observed that Solana and Sui, which have the best performance, are both non-EVM compatible blockchains. 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 approximately four times higher than 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
Firstly, let’s generalize EVM blockchains to general blockchains. To improve TPS, general blockchains usually adopt the following methods:
1. Enhancing node performance: Improving node performance by allocating hardware resources. The hardware requirements of nodes affect decentralization. For example, Ethereum recommends a configuration of 4-core CPU, 16GB memory, and 25Mbps network bandwidth, which can be achieved by ordinary user-level devices, but it has a higher degree of centralization. Solana recommends a relatively higher configuration of 32-core CPU, 128GB memory, and 1Gbps network bandwidth, which can only be achieved by professional-level devices, leading to a moderate level of centralization.
2. 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 the operating rules of the blockchain. It directly improves the performance of the blockchain. However, the underlying technology has low attention in the research field, and there have been no major breakthroughs so far.
3. Increasing block size: Increasing the size of blocks can accommodate more transactions and thereby improve the transaction throughput of the blockchain. For example, Bitcoin Cash (BCH) increased the block size from 1 MB to 8 MB, and later expanded it to 32 MB. However, increasing the block size also increases propagation delay, which can lead to security threats such as increased forking possibilities and DDoS attacks.
4. Consensus protocols: Consensus protocols ensure that all nodes in the blockchain reach a consensus on the state updates of the blockchain. They are the most important security gate for blockchains. Existing consensus mechanisms used in blockchains include PoW, PoS, PBFT, etc. To meet the scalability requirements, high-performance public chains generally improve the consensus protocols and combine them with their own special mechanisms. For example, Solana is based on the PoH consensus mechanism, while Avalanche is based on the Avalanche consensus mechanism.
5. Transaction execution: Transaction execution only concerns the number of transactions or computational tasks processed within a unit of time. Blockchains like Ethereum execute smart contract transactions in a serialized manner. In serialized execution, the performance bottleneck of the CPU is evident, severely restricting the throughput of the blockchain. High-performance public chains generally adopt parallel execution methods and propose language models that are more conducive to parallelism to build 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 of transactions. EVM has two main performance issues:
1. 256-bit: EVM is designed as a 256-bit virtual machine to facilitate the handling of Ethereum’s hash algorithm, which produces a 256-bit output. However, the computer running EVM needs to map the 256-bit bytes to the local architecture to execute them. One EVM opcode corresponds to multiple local opcodes, making the whole system inefficient and impractical.
2. Lack of standard library: Solidity does not have a standard library, so it needs to be implemented using Solidity code. Although OpenZeppelin has improved this situation to some extent by providing a standard library implemented in Solidity (by including the code in the contract or calling the deployed contract using delegatecall), the execution speed of EVM bytecode is far inferior to precompiled standard libraries.
From the perspective of execution optimization, EVM still has two major shortcomings:
1. Difficult to perform static analysis: Parallel execution in blockchains means that unrelated transactions are processed simultaneously, treating them as independent events. The main challenge in implementing parallel execution is determining which transactions are unrelated and independent. Currently, some high-performance public chains perform static analysis on transactions in advance, but EVM’s dynamic jumps mechanism makes it difficult to perform static analysis on the code.
2. Immature JIT compiler: JIT compiler (Just In Time Compiler) is a commonly used optimization method in modern virtual machines. The main goal of JIT is to transform interpreted execution into compiled execution. At runtime, the virtual machine compiles hot code into platform-specific machine code and performs various levels of optimization. Although there are projects for EVM JIT, they are still in the experimental stage and not mature enough.
Therefore, when it comes to choosing a virtual machine, 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 “Ethereum killers” due to its Proof of History (PoH) mechanism and low-latency high-throughput capabilities.
The core of PoH is a simple hash algorithm similar to Verifiable Delay Function (VDF). Solana implements this function using a sequence of preimages resistant hash functions (SHA-256) that runs continuously, using 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, enabling efficient verification on multi-core systems. While there is an upper bound on hash speed, hardware improvements may provide additional performance gains.
Solana Consensus Process
The PoH mechanism creates verifiable and ordered event records within the network. The timing based on PoH allows the Solana network to rotate leaders in a predictable and transparent manner. This rotation occurs at fixed time intervals, known as slots, which are currently set to 400 milliseconds each. This leader rotation mechanism ensures that every participating validator has a fair chance to become a leader, maintaining decentralization and network security by preventing any single validator from gaining too much power on the network.
During each slot, the leader proposes a new block that includes transactions received from users. The leader validates 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 examine the content of the block, ensuring the validity of 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 Solana network security 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 Solana can confirm leaders in advance, it does not require 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 signature is verified on the GPU, the data is passed to the CPU for transaction execution and eventually returned to the kernel space for data persistence. This division of data into different hardware components and multiple processing stages is known as pipelining, 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 read-write locks. The Solana transaction scheduler has a separate queue managed by each thread, which processes transactions sequentially and independently. It attempts to lock (read-write lock) the accounts of the transactions and execute them. Transactions with account conflicts are executed later. This multi-threaded parallel execution technique is known as 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 reduces the leader’s bandwidth usage.
During the voting process, validators use a consensus mechanism specifically designed 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 persistence of blocks, Solana has developed the Cloudbreak database, which partitions account data structures in a specific way to benefit from the speed of sequential operations and uses memory-mapped files to maximize SSD efficiency.
To alleviate the burden on validators, Solana transfers data storage from validators to a node network called the Archiver. The transaction history of the state is split into many fragments and uses erasure coding. Archiver is used to store fragments of the state, but it does not participate in consensus.
Conclusion
Solana’s vision is to become a blockchain that scales with the speed of hardware. Therefore, Solana maximizes the CPU, GPU, and bandwidth capabilities available in today’s computers to maximize performance. The theoretical maximum speed can reach 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 the DePIN/AI track at the beginning of the year or the recent popular Meme track, Solana has shown tremendous potential.
After the launch of Ethereum ETFs, Solana has also become the cryptocurrency with the highest call for the next ETF, although the SEC still categorizes Solana as a security and will not approve other cryptocurrency ETFs in the short term. But in the crypto market, consensus means value, and Solana’s consensus may be becoming as invincible as Bitcoin and Ethereum.