A performance report
The Fastest Chains report released by CoinGecko on May 17 showed that Solana is the fastest among large blockchains, with a maximum daily average real TPS of 1,504 (voting transactions have been removed). Sui is the second fastest blockchain, with a maximum daily average real TPS of 854. BSC ranks third, but the real TPS achieved is less than half of Sui.
From this report, we can see that Solana and Sui, which have the best performance, are both non-EVM-compatible blockchains. Furthermore, the average real TPS of 8 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 4 times that of EVM-compatible blockchains.
This article will explore the performance bottlenecks of EVM-compatible blockchains and reveal the performance of Solana.
Performance bottlenecks of EVM-compatible blockchains
First, we generalize the EVM blockchain to the general blockchain. Generally, if a blockchain wants to improve TPS, there are generally several ways to do it:
Improve node performance: Node performance can be improved by piling up hardware resources. The hardware requirements of the node will affect the degree of decentralization. For example, the recommended configuration of Ethereum is CPU 4 cores, memory 16G, network bandwidth 25Mbps, which can be achieved by ordinary user-level devices and has a high degree of centralization; Solana recommends a relatively higher configuration of CPU 32 cores, memory 128G, network bandwidth 1Gbps, which can only be achieved by professional-level devices and has a general degree of centralization;
Improve underlying protocols: Including network protocols, cryptography, storage, etc. Improving the underlying protocols of blockchain does not change the properties of the blockchain itself, nor does it affect the operating rules of the blockchain. It can directly improve the performance of the blockchain, but the underlying technology has low attention and there are no major breakthroughs in the current research field;
Block expansion:Increasing the size of blocks can include more transactions, thereby increasing the transaction throughput of the blockchain. For example, Bitcoin Cash (BCH) expanded the block size from 1 MB to 8 MB, and then to 32 MB. However, expanding the block size will also increase the propagation delay and cause security threats, such as increasing the possibility of forks and DDoS attacks;
Consensus protocol:The consensus protocol ensures that all nodes in the blockchain reach a consensus on the status update of the blockchain. It is the most important security gate of the blockchain. The consensus mechanisms that have been used in the blockchain include PoW, PoS, PBFT, etc. In order to meet the needs of scalability, high-performance public chains generally improve consensus protocols and combine their own special mechanisms, such as Solana's consensus mechanism based on PoH and Avalanche's consensus mechanism based on avalanche;
Transaction execution:Transaction execution only cares about the number of transactions or computing tasks processed per unit time. Blockchains such as Ethereum use a serial method to execute smart contract transactions in blocks. In serial execution, the performance bottleneck of the CPU is very obvious, which seriously restricts the throughput of the blockchain. Generally, high-performance public chains will adopt a parallel execution method, and some will also propose a language model that is more conducive to parallelization to build smart contracts, such as Sui Move.
For EVM blockchains, since the virtual machine, that is, the execution environment of the transaction, is limited, the biggest challenge lies in transaction execution. There are two main performance issues with EVM:
256-bit:EVM is designed as a 256-bit virtual machine to make it easier to handle Ethereum's hashing algorithm, which explicitly produces 256-bit output. However, the computer that actually runs EVM needs to map 256-bit bytes to the local architecture for execution. One EVM opcode will correspond to multiple local opcodes, making the entire system very inefficient and impractical;
Lack of standard library:There is no standard library in Solidity, and you have to implement it yourself with Solidity code. Although OpenZeppelin has improved this situation to a certain extent, they provide a standard library implemented by Solidity (by including the code in the contract or calling the deployed contract in the form of delegatecall), the execution speed of EVM bytecode is far slower than that of the pre-compiled standard library.
From the perspective of execution optimization, EVM still has two major shortcomings:
Difficult to perform static analysis:Parallel execution in the blockchain means processing unrelated transactions at the same time, and treating unrelated transactions as events that do not affect each other. The main challenge in achieving parallel execution is to determine which transactions are unrelated and which are independent. At present, some high-performance public chains will perform static analysis on transactions in advance, and the dynamic jump mechanism of EVM makes it difficult to perform static analysis on the code;
JIT compiler is immature:JIT compiler (Just In Time Compiler) is a common optimization method used by modern virtual machines. The main goal of JIT is to turn interpreted execution into compiled execution. At runtime, the virtual machine compiles the hot code into machine code related to the local platform and performs various levels of optimization. Although there are EVM JIT projects, they are still in the experimental stage and are not mature enough.
Therefore, in terms of the choice of virtual machines, high-performance public chains are more likely to use virtual machines based on WASM, eBPF bytecode or Move bytecode rather than EVM. For example, Solana uses its own unique virtual machine SVM and eBPF-based bytecode SBF.
Fastest Chains: Solana
Solana is known for its PoH (Proof of History) mechanism and low latency and high throughput, and is one of the most famous "Ethereum killers".
The core of PoH is a simple hashing algorithm similar to a verifiable delay function (VDF). Solana is implemented using a sequence preimage resistant hash function (SHA-256) that runs continuously, using the output of one iteration as the input for the next. This computation runs on a single core per validator.
While sequence generation is sequential and single-threaded, verification can be done in parallel, resulting in efficient verification on multi-core systems. While there is an upper bound on hashing speed, hardware improvements may provide additional performance gains.
Solana Consensus Process
The PoH mechanism acts as a reliable and trustless source of time, creating a verifiable and ordered record of events within the network. PoH-based timing allows the Solana network to rotate leaders in a predetermined and transparent manner. This rotation occurs at fixed intervals of 4 slots, each currently set to 400 milliseconds. This leader rotation mechanism ensures that every participating validator has a fair chance to become a leader, and is an important mechanism for the Solana network to maintain decentralization and security, preventing any single validator from gaining too much power on the network.
Each slot period, the leader proposes a new block containing transactions received from users. The leader verifies these transactions, packages them into a block, and then broadcasts the block to the rest of the network's validators. 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 to ensure that the transactions are valid and comply with the network's rules. If a block receives a majority of the votes from the stake weight, the block is considered confirmed. This confirmation process is critical to maintaining the security of the Solana network and preventing double spends.
When the time period of the current leader ends, the network does not stop or wait for block confirmation, but moves to the next time period to give the subsequent leader a chance to produce blocks, and the whole process starts over. This approach ensures that the Solana network maintains high throughput and remains resilient even if some validators experience technical problems or go offline.
Solana Performance
Since the Solana network can confirm leaders in advance, Solana does not need a public memory pool to save users' transactions. When a user submits a transaction, the RPC server converts it into a QUIC packet and immediately forwards it to the leader's validator. This approach is called Gulf Stream, which allows fast leader transitions and pre-execution of transactions, reducing the memory load of other validators.
Solana's block data is brought into 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 finally returned to kernel space for data persistence. This process of dividing data into multiple processing steps of different hardware components is called pipelining technology, which can maximize hardware utilization and speed up the verification and transmission of blocks.
Since Solana's transactions explicitly specify which accounts to access, Solana's transaction scheduler can use the read-write lock mechanism to execute transactions in parallel. Each thread of the Solana transaction scheduler has its own queue, which processes transactions sequentially and independently, attempts to lock (read-write lock) the account of the transaction and execute the transaction, and transactions with account conflicts will be executed later. This multi-threaded parallel execution technology is called Sealevel.
The process by which leaders propagate blocks divides QUIC packets (optionally using erasure coding) into smaller packets and distributes them to validators in a hierarchical structure. This technique is called Turbine and is primarily intended to reduce the leader's bandwidth usage.
During the voting process, validators use a consensus mechanism for fork voting. Validators do not need to wait for votes to proceed with block production; instead, block producers continuously monitor for valid new votes and incorporate them into the current block in real time. This consensus mechanism is called TowerBFT, and by merging fork votes in real time, Solana ensures a more efficient and streamlined consensus process, thereby improving overall performance.
For the persistence process of blocks, Solana 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 the efficiency of SSDs.
To reduce the burden on validators, Solana transfers data storage from validators to a node network called Archiver. The historical record of transaction status is split into many fragments and uses erasure coding technology. Archiver is used to store fragments of status, but does not participate in consensus.
Summary
Solana's vision is to become a blockchain whose software scales at the speed of hardware, so Solana makes full use of all CPU, GPU and bandwidth capabilities available in today's computers to maximize performance, with a theoretical maximum speed of 65,000 TPS.
It is precisely because of Solana's high performance and scalability that Solana 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 hot Meme track, Solana has shown great potential.
After the launch of Ethereum ETF, Solana has also become the cryptocurrency with the most calls for the next ETF, although the SEC still lists Solana as a security and will not approve other cryptocurrency ETFs in the short term. But in the crypto market, consensus is value, and Solana's consensus may be becoming as indestructible as Bitcoin and Ethereum.