What is the significance of Solana reaching 100,000 TPS under ideal conditions?

In the past two days, there has been more discussion about Solana's 100,000 TPS. The reason is that @cavemanloverboy did run 100,000+ TPS on the Solana mainnet, but most people did not understand the meaning behind this data:

1) First, Cavey's experiment was essentially an extreme test under "ideal conditions." This means it's not the typical performance of the Solana mainnet, and while it will differ from the lab data in the testnet environment, it's roughly the same.

Because he used a noop (no operation) test program. As the name suggests, it only performs the most basic signature verification and directly returns success. It does not perform any calculations, does not change any account status, and does not call other programs. Each transaction is only 200 bytes, far less than the 1kb+ of normal transactions.

This means that the 100,000 TPS test was actually calculated under an abnormal trading environment. It tested the maximum throughput of Solana's network layer and consensus layer, rather than the actual processing capacity of the application layer.

2) Another key to the success of this experiment was the Frankendancer validator client. Simply put, Frankendancer is a hybrid beta version of the Firedancer validator currently under development at Jump Crypto—it grafts Firedancer’s already-completed high-performance components onto the existing Solana validator.

In essence, Solana's node system was rebuilt using the same high-frequency trading technology stack as Wall Street. This performance improvement was achieved through underlying optimizations like sophisticated memory management and custom thread scheduling. Simply replacing some components can result in a 3-5x performance improvement.

3) This test experiment shows that Solana can achieve a TPS of 100,000+ under ideal conditions. So why is it only 3,000-4,000 TPS on a daily basis? There are three main reasons for this:

1. Solana's POH consensus mechanism requires constant voting by validators to maintain its validity. These voting transactions alone occupy over 70% of the block space, which reduces the performance channel for normal transactions. 2. Solana's ecosystem activities often involve a large amount of state contention. For example, when minting a new NFT or releasing a new MEME, there may be thousands of transactions competing for write permissions on the same account, resulting in a high rate of failed transactions.

3. In order to grab MEV benefits, the arbitrage robots in the Solana ecosystem may send a large number of invalid transactions, resulting in a waste of resources.

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

A key aspect of the Alpenglow consensus upgrade is the shift of voting transactions off-chain, freeing up 70% of the space available for regular transactions. This also reduces confirmation times to 150 milliseconds, bringing Solana's DEX experience very close to that of a CEX. Furthermore, the activation of a local fee market prevents the embarrassing situation where a single popular Fomo application causes network congestion.

In addition to performance optimization and improvement, the key benefit of Firedancer is that it achieves client diversity, allowing Solana to be like Ethereum with multiple clients such as Geth Nethermind, which directly improves decentralization and single point node failure.

above.

Therefore, those who are knowledgeable about the discussion of Solana's 100,000 TPS actually see it as a sign of confidence in Solana's future upgraded client and consensus protocol , while those who are not familiar with the matter are trying to use the TPS arms race to make Solana more visible (although the TPS competition is already outdated). However, if you understand the meaning behind the experiment, it is still quite rewarding. I will share it with you for some popular science.