Whitepaper: Comparisons of Latency across the Solana Ecosystem

Authors: Manuel Kreutz, Noah Hein

What is latency, and why does it matter?

Applications built on blockchain technology are expected to drive the next wave of innovation in the consumer internet experience. Today we are starting to see this with blockchain-native applications like Audius in music, Chingari in social media, and Axie Infinity in gaming – major disruptive companies, but whose users are still measured in the tens of millions. These are early days, with the next wave of applications expected to have hundreds of millions or even billions of the Internet’s 4.6 billion global users.

One of the most prominent issues standing in the way of mass consumer adoption of blockchains is speed. Many dominant blockchain technologies are slow by modern network standards. A single transaction on Bitcoin can take more than 10 minutes.  Ethereum is faster, but transactions can still take 30 seconds to confirm.

Just how much does speed matter from a consumer perspective? Consider: 10 years ago, Amazon found that every 100 milliseconds of latency cost them 1% of sales.  And more recently, Akamai, analyzing more than 10 billion user visits across multiple top retail sites found that 100 milliseconds delays reduced conversion rates 7%, while 53 percent of mobile site visitors left pages that took longer than three seconds to load.

Up-and-coming blockchains such as Solana have architectures optimized for greater speed (for instance, Solana can support transaction speeds of 65,000 transactions per second). But measuring latency from a consumer perspective is more than just choosing the right blockchain. Even for blockchains like Solana with performance focused setups, multiple factors can impact the end user experience. One of those factors is the infrastructure that blockchain applications use to connect to the chain itself.

Defining latency and comparing latency across different configurations

As a provider of Solana blockchain infrastructure as a service, QuickNode wanted to create an objective and data-driven method to compare the speed of service for developers connecting to the Solana blockchain using the QuickNode network compared to alternatives. One element of the benchmarking compares QuickNode’s network speed to commonly used public endpoints that anyone building on Solana can access (“public RPC endpoints”). The second element of the benchmarking compared QuickNode to a competing node infrastructure provider.

The benchmarking breaks out latency into two main components: load time and block-height recency. Load time is the easiest to understand and measures the response time in milliseconds for a user to get a response back from the node after sending a request. This metric directly impacts the user experience as it relates to responsiveness and page loading for blockchain powered applications, and has the closest parallels to the Amazon and Akamai studies previously cited. The second component, block-height recency, is harder to understand and more blockchain-specific, but equally important. Block-height shows how close one is to the most up-to-date information that the blockchain has available, which gets added to the blockchain through the continuous addition of new blocks at the end of each chain. Essentially this corresponds to accuracy around having the most up-to-date data.

Ethereum has an average block added once every 13 seconds, so it is relatively easy to stay up to date on the latest transactions. But speed-focused chains like Solana add blocks every 4/10ths of a second, which means that every one second delay can result in a 2 to 3 block lag in transaction monitoring or accuracy. Some implications around the importance of block-height are more obvious: for example, for an arbitrage trader, having access to more up-to-date information has an obvious advantage over the competition. But even for a non-trading application, access to more recent block-height data has an advantage. For an application broadcasting information for customers to act on, stale information, even by a few seconds, opens up that application to vulnerability. Malicious actors can manipulate the users of that application, leading to a poor experience. Thus having up-to-date blockchain information is not just an advantage, but a baseline necessity for any application powered by blockchain.

To run the benchmarking exercise for both load time and block-height recency, QuickNode ran a script that made parallel calls of “getBlockHeight” across 8 global locations. Those calls were sent to QuickNode’s network, the two public-facing Solana RPC endpoints, the Solana foundation-hosted API cluster, a Project Serum-hosted API node, and a competing Solana infrastructure provider. The calls were made once per second, and the resulting data, pertaining to block-height and load time, were logged at each of those locations (to account for geographical variations) for the duration of the test period, which ran from Nov 8th through the 14th. The results were then compiled and are presented below.

Results

Load Time

When looking at load time, the average response time for the QuickNode network ranged from 3.92ms to 56.40 ms with a median time of 15.36ms. For the public endpoints (average of the Solana foundation-hosted API cluster and a Project Serum-hosted API node), the response times ranged from 65.75 ms to 217.10ms with a median time of 126.67ms.

Comparing the median response time between QuickNode and the public RPC endpoints, QuickNode was 8.25x faster. The difference is just over 100ms, and while not directly comparable, corresponds to the Amazon and Akamai studies mentioned previously which reference 100ms of added latency reducing sales by 1%, and conversion rates by 7%.

When comparing QuickNode’s service to the competing RPC provider. The range of the QuickNode service was the same, and had a median response time of 15.36 ms.  For the competing RPC provider, the response times ranged from 206.64 ms to 388.35 ms, and the median response time was 292.87 ms.

Comparing the median response time between Quicknode and the competing RPC provider, QuickNode was 19x faster. The difference between the two medians was more than 275ms.

Block-Height Recency

When looking at block height recency, we pulled data showing the average number of blocks that the QuickNode network was ahead or behind over a period spanning from Nov 9 - 15th. Comparing the median block height advantage of QuickNode versus the average of the public RPC endpoints, QuickNode was ahead by .374 blocks. At a rate of a new block added every 4/10 of a second, that translates to a 0.15 second advantage. Comparing the median block height advantage of QuickNode versus another provider, QuickNode was ahead 7,500 blocks, which translates to a nearly 50 minute advantage.

Conclusions

Latency matters and for blockchain applications to ultimately drive widespread consumer adoption, businesses and developers building blockchain-powered applications will need to have a strategy that comprehensively addresses latency to provide a good user experience. And that strategy involves more than just choosing the right chain, but ultimately the infrastructure that’s used to connect to a chain, whether public RPC infrastructure or a nodes as a service provider such as QuickNode.

By now quantifying latency, looking through the lens of both Load Time and Block Height Recency, we are attempting to bring some transparency and data-based observations to contribute to conversations around this important topic so decision-makers can make informed decisions. And by sharing our methodology, we hope we can kick start more conversations across the industry on this topic. We are in the early days, but we believe infrastructure decisions can be critical differentiators in bringing the next generation of Web3 applications to fruition.

About the Authors:

Manuel Kreutz is a Co-Founder and CTO of QuickNode, a leading blockchain as a service company. He has more than 15 years of experience building distributed networks and content delivery networks at 100bn requests / month type scale.

Noah Hein is a Technical Content Editor at QuickNode. A self-taught software developer, his focus is helping both traditional Web2 and newer Web3 developers have access to the the most cutting edge Web3 trends in development.

Appendix

Original script can be found here.

Need help with your project or have questions? Contact us via this form, on Twitter @QuickNode, or ping us on Discord!

About QuickNode

QuickNode is building infrastructure to support the future of Web3. Since 2017, we’ve worked with hundreds of developers and companies, helping scale dApps and providing high-performance access to 16+ blockchains. Subscribe to our newsletter for more content like this and stay in the loop with what’s happening in Web3! 😃