Back

Solana Network Upgrades

, by Solana Labs
Solana Network Upgrades

In order to strengthen the Solana network in the face of massive user growth and adoption, engineers have been working on a number of upgrades. This page will allow the greater Solana community to see how these upgrades are progressing.

Last updated 25 July 2022

QUIC

STATUS: 🟡 Testing on testnet, mainnet beta rollout expected soon. Prior to activation: adoption by RPC providers
Follow progress on Github.

Solana uses a custom raw UDP-based protocol to pass transactions between RPC nodes and the current leader. Since UDP is connectionless and lacks both flow control and receipt acknowledgments, there is no meaningful way to discourage or mitigate abusive behavior. In order to affect control over network traffic, Solana's transaction ingestion protocol are being reimplemented atop QUIC, a protocol built by Google, designed for fast asynchronous communication like UDP, but with sessions and flow control like TCP. Once adopted, there will be many more options available to adapt and optimize data ingestion.

QUIC was released onto Mainnet Beta as part of v1.10.25 but was disabled, pending re-enablement in a later 1.10 or 1.11 release. After adoption, UDP will be disabled.

Stake-weighted QoS

STATUS: 🟡 In progress
Follow progress on Github.

Leader network bandwidth has a fixed capacity and to effectively use it, stake-weighting is a must in order to end the current practice of indiscriminately accepting transactions on a first-come-first-served basis, without regard for source. Given that Solana is a PoS network, extending the utility of stake-weighting to transaction quality of service is a natural choice. Under this model a node with 0.5% stake will have the right to transmit at least 0.5% of the packets to the leader, and the rest of the network and no combination of the remaining stake will be able to fully wash them out. Stake-weighted QoS is in parallel development with QUIC today. Stake-weighted QoS will be baked into QUIC enablement.

Fee markets

STATUS: 🟡 In progress
Follow progress on Github.

Once ingested, transactions can still contend for modifying shared account data.  This contention has been dealt with by a simple first-come-first-served similarly to network data ingestions, leaving users no means to express the urgency of their transactions’ execution. Given that anyone can submit transactions to the network, stake-weighting is not suitable for this prioritization.  Instead a new instruction is being introduced into the Compute Budget program, offering users the ability to specify an arbitrary “additional fee” to be collected upon execution of the transaction and its inclusion in a block. The ratio of this fee to the requested compute units will serve as a transaction’s execution priority weight. Additional fees will be treated identically to the base fee today.

Fee markets will be implemented after QUIC is fully adopted and UDP is disabled.

Resources

Share article