⚖️Solana Bandwidth Markets
Solving transaction delivery, preventing centralization and removing barriers to entry.
Last updated
Solving transaction delivery, preventing centralization and removing barriers to entry.
Last updated
Since the end of 2023, Solana has had a "dropped transaction" issue. Essentially, transactions being submitted & ingested by the validator are simply vanishing due to inefficiencies in the underlying network protocol & contention issues within the Solana validator.
In April 2024, Solana adjusted how Stake-weighted Quality of Service (SwQoS) worked by introducing a minimum required amount of SOL (~15,000 SOL or ~$2,250,000 USD at the time of writing) to be classed as "prioritised" traffic. This "priority lane for transactions" is based on the amount of Solana staked to the given validator initiating the connection.
Solana currently does ~2,000 transactions per second (including votes); however, the inbound transaction amount is far higher than this. With a fixed base fee per transaction only charged once a transaction has been processed, sending the same transaction to many different RPC providers or via Quick UDP Internet Connections (QUIC) directly has been common practice to ensure the highest chance of inclusion in the upcoming block.
Currently, there is no cost associated with sending a transaction to the network by a client, fees are only charged once it's received & processed on-chain. While it is free for the client to send the transaction, it incurs a cost to the validator in the form of additional processing & networking load due to repeatedly parsing/checking the same "spammed" transaction.
Given that leader bandwidth is finite, this also introduces another issue - RPC providers & other large operators now have to attract large amounts of SOL to access sufficient SwQoS for the delivery of their transactions. The current minimum requirement of approximately 15,000 SOL (around $2,250,000 USD at the time of writing) creates a significant entry barrier for new participants, hinders innovation, and poses a long-term risk of centralization, monopolization, and collusion.
There is currently a lot of uncaptured cost on the network at the validator layer, which is not reflected in the current platform fees. Priority & Base fees are only applicable once the transaction reaches finalisation within a block; however, there is uncaptured validator costs based on the network activity prior to the transaction getting to the block.
Currently, RPC providers & validators are incurring all network activity as operational costs - as the network grows & more traffic is pushed into the cluster; these costs will also rise. SwQoS has been implemented to help aid this issue by putting a premium on validator connections; however, there is no way for under-staked validators to access these priority lanes.
Transaction submitted to RPC provider
Transaction routed to the closest RPC provider's validator.
Transaction checked & then forwarded to the leader validators.
If the validator does not have sufficient Stake, their SwQoS may not be enough to forward the transaction successfully.
Depending on the validator's stake, the transaction may need to be forwarded through multiple other validators to reach the leader.
The transaction is rechecked & accepted into the next block the leader is building.
The change in how SwQoS opens the possibility of building a system where transactions incur a network cost based on their usage of the underlying network while ensuring the underlying validator set has minimal processing requirements thanks to deduplication & spam prevention.
To resolve this issue, we must provide an economic penalty to not spam transactions or capture the network cost of spamming transactions. This can now be achieved through a new SwQoS market and an intermediary pending transaction pool, allowing deduplication & prioritisation at a higher level that can then be scaled horizontally.
Another key advantage is that the SwQoS connections are not controlled by a monopoly of providers, allowing for democratic access to the leader's finite resources, thus removing the stifling of innovation, barrier to entry and centralization by larger players.
By introducing a bandwidth market on top of SwQoS, network usage can be captured as an additional cost per transaction. The facilitating validator can then be paid this extra fee in exchange for sending the transaction over the validator's staked connection.
Like priority fees, bandwidth fees are dynamic based on the amount of available staked bandwidth vs the amount in use based on the previous n slots.
Bandwidth is measured in bytes, with the maximum size of a Solana transaction being 1232 bytes.
A minimum fee is calculated based on the network's current capacity vs. the demand for the previous slot.
Any lamports above the minimum fee are used as a priority order for the inbound transactions to be transmitted.
The network fee is distributed to the validator providing the bandwidth.
Introducing a network fee via the staked connections enables validators to run more efficiently as more resources are captured within the fee they receive. The network also benefits from an increase in a clean stream of prioritised transactions, reducing overall operating costs for operators.
An intermediary load balancer between the validators & the client also enables optimisation pre-ingestion without the validator incurring that additional cost, as deduplication can be handled much more efficiently at this layer.
Employing a small pool of pending transactions enables the load balancers and relays to effectively combat spam transactions by having an optimistic view of the next block state & effectively drop transactions that would not meet the network fee or priority threshold.
A market optimised for network/priority fee prioritisation & signature deduplication allows for this validation to be abstracted away from the validator somewhat and then scaled horizontally across multiple load balancers to remove any duplicate transactions & to ensure transactions are delivered within their validity time or failed gracefully with a way for the developer to see why the transaction failed.
This pool does not implement any MeV functionality. Instead it's a "holding pen" for transactions below the network minimum bid that have not yet expired.
A blockhash on Solana is valid for up to 60 seconds based on the commitment level; this allows ample time for a transaction to be retried across multiple blocks (undergoing an additional network cost each time) & provides a timeframe for transactions to be checked rather than being "dropped" as it stands currently.
During periods of high on-chain activity, such as airdrops & token launches, blocks can often fill up or are filled inefficiently due to contention on accounts - By utilising a pool over multiple blocks; transactions can be more efficiently packed for delivery while still maintaining a time series order.
Users can specify a retry amount within the sendTransaction call, which will then be used to intelligently retry based on the current network & priority fee to ensure maximal success on acceptance into the cluster.
Earn additional fees by selling their spare SwQoS bandwidth to others via the Bandwidth Market.
Reduction in overall bandwidth costs due to a decrease in spam being sent via network.
Benefit from both existing MeV & Bandwidth Market Tips. We don't implement any MeV mechanisms at our layer, however validators can still use Jito + Flux for max fees.
Can guarantee a certain level of QoS by adding a network fee, ensuring the transactions are prioritised & delivered via a staked connection.
Improved UX through faster confirmation times.
Provide contextual congestion information to the user via dynamic network fees.
Reduces spam incentive due to higher cost & lower block availability, without the need to increase base fees or block space.
Provides additional context on the lifecycle of a transaction along with a reduction in client-side logic.
Transaction delivery becomes more deterministic.
Long-term scalability through full capture of network resources.
Responsible for ingestion & initial deduplication of inbound transactions looking to use the bandwidth markets.
Due to the composition of a Solana transaction, in-flight signature verification can be done without needing to read the entire transaction packet. Due to this, we can implement multiple additional layers of spam protection:
Deduplication - In-flight signature verification used to dedupe multiple requests of the same transaction
QoS Signer - In-flight payer/signer detection to provide consistent QoS so no single entity can monopolise block space.
IP limits are useless here due to commodity proxies & captcha bypass.
Responsible for managing inbound requests from the Load Balancers & relaying these requests to a validator with sufficient bandwidth to serve the transaction via SwQoS.
Based on the available SwQoS bandwidth & the minimum fee requirements registered by validators, transactions are validated & forwarded to the winning validator providing the bandwidth.
Transactions that fail to meet the minimum market requirement are held in the pending transaction pool & retried per block until expiry or the transaction results in an error state. This data can then be retrieved via the Load Balancer APIs to get "dropped" transaction status details (Fee too low, state invalid, etc.)
A fork of the Solana Labs validator client with the bandwidth markets implemented will be used for initial proof of concept & testing. The goal is to be fully compatible with the Jito client to enable the support of both bundling & bandwidth markets.
In the long term, the aim is to enable support through a sidecar for any Solana validator regardless of what client is being run (such as FireDancer).
Validators running the bandwidth market plugin initiate a TCP connection with the bandwidth relay, registering their identity & fee conditions. This connection is then used to relay winning transactions from the bandwidth market to the validator to reduce networking complexity & provide protocol-level connection liveness.
Like Jito Tips, Bandwidth fees are paid to the validator providing the connection. This fee further increases the incentive to stake SOL & run the bandwidth market plugin. Fees are paid per transaction & credited upon delivery of the transaction across their connection.
Exact market dynamics & fees are still to be determined as the project evolves, along with community feedback to ensure the most optimal model is used upon production launch. Initially, this will start with a simple cost model based on the available bandwidth + the minimum fee set by each validator.
We have been hard at work building up a PoC of both the bandwidth markets & load balancers to showcase the new markets (we already have a demo running on top of Jito bundles), which we aim to have ready by the end of June. Initial tests will be done on Testnet to determine the best fee mechanism to use & to tune based on a wider sample size of transactions.
As the markets rely on having sufficient access to SwQoS connections, we are actively looking for more validators & partners willing to help us test this new mechanism.
Please get in touch & provide feedback so we can further improve the implementation to resolve congestion. Feedback can be submitted via Telegram here - https://t.me/+XD4gqrNlwsI4ODAx
