A Performance Report

CoinGecko's "Fastest Chains" report released on May 17th shows that Solana is the fastest blockchain among large-scale blockchains, with a peak daily average real TPS of 1,054 (excluding voting transactions). Sui is the second fastest blockchain, with a peak daily average real TPS of 854, and BSC ranks third, but its real TPS achieved is less than half of Sui's.

From this report, it can be seen that the best-performing Solana and Sui 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 uncover Solana's performance approach.

Performance Bottlenecks of EVM Compatible Blockchains

First, we generalize EVM blockchains to general blockchains. To improve TPS of general blockchains, there are several common approaches:

• Improve node performance: By allocating hardware resources to improve node performance, the hardware requirements of nodes will affect the degree of 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, resulting in a high degree of decentralization. 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, resulting in a moderate degree of decentralization.
• Improve underlying protocols: This includes network protocols, cryptography, storage, etc. Improving the underlying blockchain protocols does not change the blockchain's own properties or affect the blockchain's operating rules, but can directly improve the blockchain's performance. However, the underlying technology has low attention, and there have been no major breakthroughs in the research field so far.
• Enlarge blocks: Increasing the size of blocks can accommodate more transactions, thereby increasing the transaction throughput of the blockchain. For example, Bitcoin Cash (BCH) increased the block size from 1MB to 8MB, and later expanded to 32MB. However, enlarging blocks also increases propagation delay, leading to security threats such as increased likelihood of forks and DDoS attacks.
• Consensus protocols: Consensus protocols ensure that various nodes of the blockchain reach consensus on the state updates of the blockchain. Consensus mechanisms used in blockchains include PoW, PoS, PBFT, etc. To meet the scalability requirements, high-performance public blockchains generally improve the consensus protocol and combine it with their own special mechanisms, such as Solana's PoH-based consensus mechanism and Avalanche's avalanche-based consensus mechanism.
• 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 serial manner. In serial execution, the CPU's performance bottleneck is very obvious, severely limiting the blockchain's throughput. Generally, high-performance public blockchains adopt parallel execution, and some even 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 constrained virtual machine, i.e., the execution environment of transactions. EVM mainly has two performance issues:

• 256 bits: EVM is designed as a 256-bit virtual machine, aiming to handle Ethereum's hash algorithm more easily, as it explicitly produces 256-bit outputs. However, the computer actually running EVM needs to map the 256-bit bytes to the local architecture for execution, where one EVM opcode corresponds to multiple local opcodes, making the entire system very inefficient and impractical.
• Lack of standard library: Solidity does not have a standard library, and it must be implemented using Solidity code. Although OpenZeppelin has somewhat improved this situation by providing a Solidity implementation of a standard library (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 from that of 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 simultaneously, treating unrelated transactions as independent events. The main challenge of implementing parallel execution is determining which transactions are unrelated and independent. Currently, some high-performance public blockchains will pre-analyze transactions, but EVM's dynamic jump mechanism makes it difficult to perform static analysis.
• Immature JIT compiler: JIT compiler (Just In Time Compiler) is a common optimization method used in modern virtual machines, with the main goal of transforming interpreted execution into compiled execution. At runtime, the virtual machine compiles hot code into machine code relevant to the local platform and performs various levels of optimization. Although there are EVM JIT projects currently, they are still in the experimental stage and not mature enough.

Therefore, in terms of virtual machine selection, high-performance public blockchains mostly 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 renowned for its PoH (Proof of History) mechanism and low-latency high throughput, and is one of the most famous "Ethereum killers."

The core of PoH is a simple hash algorithm similar to a Verifiable Delay Function (VDF). Solana uses a hash function resistant to sequential pre-image attacks (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, validation can be done in parallel, achieving efficient validation 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 serves as a reliable and trustless time source, creating verifiable and ordered event records within the network. Based on PoH timing, Solana network allows for leader rotation in a scheduled and transparent manner. This rotation occurs at fixed time intervals, known as slots, with each slot currently set at 400 milliseconds. This leader rotation mechanism ensures that every participating validator has a fair chance to become a leader, serving as an important mechanism for maintaining decentralization and security in the Solana network, preventing any single validator from gaining excessive power on the network.

During each slot, the leader proposes a new block containing transactions received from users. The leader validates 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 known as block production, and other validators in the network must vote on the validity of the block. Validators check the content of the block to ensure the validity of transactions and compliance with network rules. If a block receives the majority of stake-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, but instead moves to the next time slot, providing an opportunity for the next leader to produce blocks, and the entire 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 Approach

Since the Solana network can confirm leaders in advance, Solana does not need a public memory pool to store user transactions. When users submit transactions, RPC servers convert them into QUIC packets and immediately forward them to the leader's validators. This method is called Gulf Stream, allowing for rapid leader rotation 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 process of dividing data into different hardware components is called pipeline technology, maximizing hardware utilization and speeding up block verification and transmission.

As Solana's transactions explicitly specify which accounts to access, Solana's transaction scheduler can execute transactions in parallel using a read-write lock mechanism. Each thread of the Solana transaction scheduler has its own managed queue, processing transactions sequentially and independently, attempting to lock (read-write lock) transaction accounts and execute transactions, with conflicting transactions being executed later. This multi-threaded parallel execution technique is called Sealevel.

During the process of leader block propagation, QUIC packets (optionally using erasure coding) are divided into smaller packets and distributed to validators with a layered structure. This technology is called Turbine and is primarily aimed at reducing 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 continue block production; instead, block producers continuously monitor valid new votes and incorporate them into the current block in real-time. This consensus mechanism is called TowerBFT, ensuring a more efficient and streamlined consensus process, thereby improving overall performance by merging fork votes in real-time.

For the block persistence process, Solana has developed the Cloudbreak database, partitioning account data structures in a specific way to benefit from the speed of sequential operations and using memory-mapped files to maximize SSD efficiency.

To alleviate the burden on validators, Solana has shifted data storage from validators to a node network called Archiver. The historical record of transaction states is fragmented and uses erasure coding. The Archiver is used to store fragments of the state but does not participate in consensus.

Conclusion

Solana's vision is to become a blockchain that scales its software with the speed of hardware, utilizing all available CPU, GPU, and bandwidth capabilities in today's computers to maximize performance, with a theoretical maximum speed of 65,000 TPS.

It is 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 in the early DeFi/NFT space or the recent popular meme space, Solana has shown tremendous potential.

Following the launch of Ethereum ETF, Solana has also become the most anticipated next ETF, although the SEC still categorizes Solana as a security and will not approve other cryptocurrency ETFs in the short term. However, in the crypto market, consensus equals value, and Solana's consensus may be becoming as unshakable as Bitcoin and Ethereum.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。