Glad to share the latest achievements of our Solana services. Leveraging the high-performance global network service foundation of BlockRazor, the BlockRazor Solana Send Transaction Service has undergone significant speed optimization. In the latest test results, it has shown outstanding performance and is now positioned among the top-tier providers.

Before we dive into the detailed presentation of our test results, please allow us to describe the transaction landing route on Solana. This will help provide a better understanding of what exactly happens when you use the BlockRazor Solana Send Transaction Service.

Transaction landing route on Solana

Validator and Leader

Similar to most blockchain with POS mechanism, Solana Validators are responsible for participating in consensus and completing block production. Anyone can run a validator by staking SOL.

In the block production process, Solana Validators are divided into two roles—Leader and Validator — each responsible for different tasks:

• Leader
  • Produces blocks within the current Slot, which includes collecting transactions and ordering transactions, generating blocks, broadcasting, and ultimately completing state synchronization.
  • On Solana, a Slot lasts approximately 400ms. The Leader role persists for 4 Slots, and an Epoch consists of 432,000 Slots, lasting about 2 days.
  • The Leader role is allocated within an Epoch based on the Validator's staked amount. Validators with higher stakes take on the Leader role for a larger proportion of time during an Epoch.
• Validators
  • Within the current Slot, they propagate transactions, receive and validate shreds, and ultimately complete state synchronization.

SWQoS

SWQoS (Stake-Weighted Quality of Service) is a mechanism in the Solana blockchain network used to optimize transaction and shreds propagation. It allocates network bandwidth and priority based on the validator's stake weight, prioritizing validators with higher stakes by providing them with lower latency and higher throughput. In Solana's official documentation, it is described as follows: "With Stake-weighted QoS enabled, a validator holding 1% stake will have the right to transmit up to 1% of the packets to the leader." (https://solana.com/zh/developers/guides/advanced/stake-weighted-qos)

Jito

Jito Labs is an ecosystem builder on Solana, providing block value enhancement services for validators through tools like Jito-Solana, Jito-Relayer, and Jito-BlockEngine. Below is the chain relationship diagram provided by Jito's official source.

• Jito-Solana
  • An open-source validator client optimized based on the standard client from Solana Labs, enhancing MEV capture and transaction processing capabilities.
• Jito-Relayer
  • A transaction gateway used for receiving and forwarding transactions, including sending transactions to Jito-BlockEngine for auction and to the Leader's Jito-Solana client.
• Jito-BlockEngine
  • Responsible for transaction auctions, receiving Bundles from Searchers, Dapps, and RPC service providers (consisting of Original Tx + Tip Transaction).

Transaction Spread

When a validator becomes the Leader, it may receive transactions from the following sources:

• Jito - Relayer
• Jito - BlockEngine

The Leader sorts the transactions received from the above sources by value. Specifically, the Jito-Solana client prioritizes processing Bundles obtained from the BlockEngine.

Therefore, the process of getting a transaction included can be divided into two stages: the Racing Game and the Bidding Game.

Racing Game

The Racing Game includes multiple routes, and reaching the Leader through any route is possible:

• Jito Route
  • RPC service providers or users send Bundles to Jito-BlockEngine, which then forwards them to the Leader.
  • Since Jito-Relayer sends transactions to Jito-BlockEngine for auction, transactions may also follow the path of RPC → Validator → Jito-Relayer → Jito-BlockEngine, where they are auctioned and assembled into Bundles before being sent to the Leader.
• SWQoS Route
  • Transactions are sent via RPC service providers to other Validators, who then forward them to the Leader through Jito-Relayer.

Bidding Game

After the transaction reaches the Leader, the Bidding Game begins. Once transactions arrive at the Leader, the Leader periodically packages the received transactions until the current Slot ends. When there are conflicting transactions, the transaction with the higher value will be prioritized by the Leader for inclusion, while transactions that lose the Bidding Game will be deferred for later execution.

The above figure illustrates various scenarios of transaction inclusion on the blockchain under the coexistence of Jito and SWQoS routes:

• At the start of Slot 1099, the Leader receives transactions 1, 2, and 5 from the Jito route and transactions 3, 4, and 6 from the SWQoS route. There are no conflicting transactions, so they are packaged in order of value.
• The Leader continues to receive transactions 7, 8, and 9 from the Jito channel, and transactions 10 and 11 from the SWQoS channel. There is a conflict between transaction 7 and transaction 11. Transaction 7 wins the bidding game, and the Leader packages transactions 7 to 11 in order of value.
• The Leader further receives transaction 12 from the Jito channel and transaction 13 from the SWQoS channel. There are no conflicting transactions, so packaging is completed. At this point, Slot 1099 reaches its time limit.
• The final block formed will be ordered as shown in the figure.

Conclusion and Insights

From the transaction inclusion paths on Solana, we can draw the following insights:

• Jito route: Since transactions flow within the Jito ecosystem from the moment they reach the Jito-BlockEngine, the global deployment architecture of Jito and RPC providers results in minimal differences in the RPC-to-BlockEngine phase. Therefore, under a fixed Tip Fee, the performance variation among RPC providers on the Jito route is negligible.
• SWQoS route: Due to the complexity of the validator network and the rotation mechanism of the Leader, network optimization can significantly impact transaction sending performance during the racing game. Choosing an RPC with superior speed performance on the SWQoS route allows transactions to achieve better results in the racing game, enabling them to participate earlier in the bidding game of leader and get included.

Racing Test

Testing Method

Service Comparison: BlockRazor, bloXroute, 0Slot, Temporal

Testing Objective: To compare the degree of network service optimization of various transaction sending service

Testing Regions: Europe - Frankfurt, North America - New York

Testing Process:

• Simulate real usage scenarios of current Solana Dapps—deploying services in specific region and simultaneously sending DurableNonce transactions to multiple RPC providers.
• The endpoints of the RPC providers used for sending are as follows:

Testing Method

• Transactions: The transactions used for testing are Transfer transactions, with consistent Tip and Priority Fee for each transaction:
  • Jito Tip: 0.001 Sol
  • Priority Fee: 0.001 Sol
• Transaction Sending Frequency: Set at 1.6 seconds per transaction. This is because a Leader sustains 4 Slots (~1.6s). Setting the transaction sending frequency to 1.6s per transaction ensures coverage of more Leaders, avoiding sample bias from a single Leader.
• Transaction Tracking and Filtering: Record the landing route for each transaction and filter out transactions that is landed via Jito, retaining only transactions on the SWQoS channel. This is due to two factors:
  1. The Jito route relies on the Jito ecosystem to complete the racing game, resulting in minimal differences in network performance.
  2. We observed subsidy phenomena among RPC providers, where the degree of subsidy significantly impacts the test results for transactions landing via the Jito route.
• Fair Competition in SWQoS Route: Since the Tip and Priority Fee for test transactions are consistent, transactions from each RPC provider are absolutely fair during the bidding game in the SWQoS route. The transaction that ultimately gets included is the winner of the racing game. Therefore, by statistically analyzing the included status of DurableNonce transactions across different RPC providers, the network service performance of RPC providers can be clearly reflected.

Test Results

• Latency Testing: We tested the latency of requests sent from the test server to each service endpoint. The request latency between the test server and each service endpoint is essentially consistent, thus ruling out uncertainties caused by communication delays between the test server and the endpoints.
• Performance in SWQoS Route: BlockRazor performed the best:
  • In the Frankfurt region, 30.12% of transactions reached the Leader first through BlockRazor's service.
  • In the New York region, 39.83% of transactions reached the Leader first through BlockRazor's service, demonstrating a significant lead over other providers.

Getting Started

• BlockRazor currently holds a leading edge in Solana landing capabilities, meeting the diverse needs of speed-sensitive users. If you wish to start using BlockRazor Solana services now, please visit https://blockrazor.gitbook.io/blockrazor/solana/overview.
• In the future, we will continue to optimize the Solana Send Transaction Service from multiple aspects such as performance and security, ensuring the safety of your transactions.
• Additionally, we will soon launch the Solana Shred service. Users with relevant needs are welcome to contact us at any time!