--- featured: false date: 2024-03-20T00:00:00Z difficulty: intermediate seoTitle: "Stake-weighted Quality of Service on Solana" title: "A Guide to Stake-weighted Quality of Service on Solana" description: "Stake-weighted QoS (Quality-of-Service) is an implementation feature which, when enabled, allows leaders (block producers) to identify and prioritize transactions proxied through a staked validator as an additional sybil resistance mechanism." tags: - rust keywords: - guide - stake-weighted QoS - Quality-of-Service - intro to solana development - blockchain developer - blockchain tutorial - web3 developer --- ## What is Stake-weighted Quality of Service (QoS)? Stake-weighted QoS (Quality-of-Service) is an implementation feature which, when enabled, allows leaders (block producers) to identify and prioritize transactions proxied through a staked validator as an additional sybil resistance mechanism. Given that Solana is a proof of stake network, it is natural to extend the utility of stake-weighting to transaction quality of service. Under this model, a validator with 0.5% stake would have the right to transmit up to 0.5% of the packets to the leader and will be capable of resisting sybil attacks from the rest of the network. Operators who enable this feature will improve the security and performance of the network by reducing the likelihood that low-or-no-stake (lower quality) validators are able to “drown out” transactions emanating from higher-quality (higher stake) validators (aka enhanced Sybil Resistance). One potential benefit of implementing Stake-weighted QoS could be realized if certain agreements between Validators and RPC nodes are in place. RPC nodes may land more transactions in blocks by agreeing to peer with Validators, and Validators may sell more capacity to RPC nodes. These agreements must be made directly between RPC operators and Validators and include the implementation of the steps captured below in this doc to complete the peering. ## Who does Stake-weighted QoS benefit? Commercial RPC infrastructure operators and exchanges will likely be among the major beneficiaries of Stake-weighted QoS. RPC operators will be in an ideal position to acquire or negotiate deals with staked validators enabling them to achieve an improved percentage of transactions landed in blocks overall. Exchanges (or other entities) who host their own validator nodes and RPC nodes on the same infrastructure will be able to enable the feature internally, comfortable that the RPC nodes running on their own infrastructure can be trusted. ## Why is Stake-weighted QoS important? 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. In this way, validators with higher stake are guaranteed to receive higher quality of service which prevents lower-quality validator (with less at stake) from maliciously flooding out these transactions, increasing overall Sybil Resistance. Put another way, imagine what the world would be like if cars with one passenger could ride in the carpool lane uninhibited. Soon the carpool lane, which is designed to move more human beings using the same stretch of highway, would be rendered useless. The overall functionality of the highway would be impaired and fewer commuters would be able to reach their destinations. This effect is similar to what happens when low-staked validators are allowed to submit transactions to the Leader with the same priority as high-staked validators. ## Who should enable Stake-weighted QoS? Stake-weighted QoS should be enabled by Validator nodes paired with highly trusted RPC nodes. This is helpful in situations such as running an RPC and Validator in the same infrastructure where the trust level is already high. Stake-weighted QoS works best for high trust configurations and requires the Validator and RPC to come to an agreement in advance prior to enabling the feature. It is strongly recommended that Validators not attempt to enable Stake-weighted QoS with untrusted RPCs. Stake should be applied to block producing validators. It is not necessary, recommended or effective to delegate stake to RPC servers. ## How does Stake-weighted QoS work? With Stake-weighted QoS enabled, RPC nodes paired with a validator gain a “virtual” stake in regards to how that leader treats inbound TPU (Transaction Processing Unit) traffic from that RPC node, something which is not normally possible. By definition, RPC nodes are “unstaked” and “non-voting” aka “non-consensus” and are unable to access the benefits of prioritized transactions by way of staking in the same way that consensus nodes do. How do you use Stake-weighted QoS to land transactions? Enabling Stake-weighted QoS requires configuring a validator node and an RPC node to form a trusted peer relationship. This involves separate configuration steps for both the validator node and the RPC node listed below. Operators wanting to enable Stake-weighted QoS will need the following before starting: A validator with stake running on the network AND A RPC peered to the validator Stake-weighted QoS will not work unless BOTH sides are properly configured. ### Configuring the Validator node On the validator, you'll have to enable `--staked-nodes-overrides /path/to/overrides.yml`. The `--staked-nodes-overrides` flag helps the validator prioritize transactions being sent from known sources to apply stake to their transactions. This can help a validator prioritize certain transactions over known hosts over others, enabling the usage of Stake-weighted QoS with RPCs. RPCs should not be staked in any way. Today, Stake-weighted QoS gives a stake-weighted priority to 80% of a leader's TPU capacity. However, there are configuration options which can be used to virtually assign different stake-weights to TPU peers, including assigning unstaked peers virtual stake. The overrides file for `--staked-nodes-overrides` looks like this: ```yml staked_map_id: pubkey1: 1000000000000000 pubkey2: 4000000000000000 ``` `staked_map_id` contains a map of identity public key to the stake amount in lamports to apply to each RPC. When set, the validator will prioritize QUIC connections with the RPC found at that identity publicKey, assigning an amount of stake to their transactions. The 80% of the leader's TPU capacity will be split proportionally based on the lamport amounts specified in the `staked-nodes-overrides` file and existing cluster stake. ### Configuring the RPC node On the RPC you will have to use `--rpc-send-transaction-tpu-peer` to forward transactions to a specific leader. The exact usage would be `--rpc-send-transaction-tpu-peer HOST:PORT`. The Host is the ip address of the leader you have the `staked-nodes-overrides` enabled on and the Port is the QUIC TPU port of that host. The QUIC TPU port for a leader can be identified by making an RPC call to [getClusterNodes](/docs/rpc/http/getclusternodes). The peering would looking like the following: ![Diagram of RPCs peering with Validator for Stake-weighted Qos](/assets/guides/stake-weighted-qos-guide/peered-RPCs-guide.png) ## Conclusion Stake-weighted QoS is an optional feature which arrived in v1.14 of the Solana client, now known as Agave. Agave is a forked version of the Solana Labs client which has become the active branch used by the Anza team, a spin out organization composed of the former Solana Labs engineering team. The Stake-weighted QoS feature will most likely be useful for RPC infrastructure operators who are in position to establish trusted relationships with staked node operators. It will also be useful for Exchanges, who run both RPC nodes and validator nodes and are able to establish high trust connections internally.