Interpreting the Truth Behind Solana TPS

Author: Haotian

In the past few days, discussions around Solana's 10 W TPS have increased, mainly because @cavemanloverboy has indeed achieved over 100,000 TPS on the Solana mainnet, but most people have not fully understood the significance behind this data:

1. First, the cavey experiment is essentially a limit test under "ideal conditions". This means that this is not the normal performance of the Solana mainnet, and there is a difference from the laboratory data in the testnet environment, but it is not far off.

Because he adopted a noop (no operation) empty operation test program, which, as the name suggests, only performs the most basic signature verification and directly returns success, without performing any calculations, changing any account status, or calling other programs, and each transaction is only 200 bytes, far lower than the normal transaction of 1 kb+.

This means that the 10 W TPS test was calculated under abnormal trading conditions, testing the maximum throughput of the Solana network layer and consensus layer, rather than the actual processing capability of the application layer.

2. Another key to the success of this experiment is the Frankendancer validator client. Simply put, Frankendancer is a "hybrid test version" of the Firedancer validator being developed by Jump Crypto—integrating the high-performance components of Firedancer that have been completed onto the existing Solana validators.

It is essentially a reconstruction of the Solana node system using the high-frequency trading technology stack from Wall Street, achieving performance improvements through fine memory management, custom thread scheduling, and other low-level optimizations. However, replacing only some components can achieve a 3-5 times performance increase.

3. This test experiment shows that Solana can achieve a TPS of over 100,000 under ideal conditions. So why is the daily TPS only around 3,000-4,000? In summary, there are roughly three reasons:

1. The POH consensus mechanism of Solana requires Validators to continuously vote to maintain it, and these voting transactions occupy more than 70% of the block space, which narrows the performance channels left for normal transactions.

2. The ecological activities of Solana often have a large amount of state competition behavior. For example, when minting new NFTs or releasing new MEMEs, there may be thousands of transactions competing for write access to the same account, resulting in a high failure rate of transactions.

3. Arbitrage bots in the Solana ecosystem may send a large number of invalid transactions to capture MEV profits, resulting in resource wastage.

4. However, the upcoming full deployment of Firedancer and the consensus upgrade of Alpenglow will systematically address these issues.

One of the key points of the Alpenglow consensus upgrade is that it moves voting transactions off-chain, effectively freeing up 70% of space for regular transactions, while reducing confirmation times to 150 milliseconds, allowing Solana's DEX experience to come very close to that of CEX. Additionally, the activation of the local fee market can avoid the embarrassing situation of network congestion caused by the Fomo frenzy of a single program.

The benefits of Firedancer, in addition to performance optimization, are crucially that it achieves client diversity, allowing Solana to have multiple clients like Ethereum's Geth and Nethermind, directly improving decentralization and single point node failure.

Above.

So, the discussion about Solana's 10 W TPS is actually a confidence in Solana's future upgrades to its client and consensus protocol for those who understand the field. For those who do not, they attempt to give Solana presence through a TPS arms race (even though TPS comparisons are outdated). However, if you understand the significance behind the experiment, there's quite a lot to gain. Let's popularize this and share it with everyone.