Transaction Fee Mechanisms - Notes

Notes on how solana transaction fee mechanisms work

Starting from scratch

What are TFMs?

They basically:

Determine what transactions are included into a given block
Determine the fees given for a transactions
How and to whom the fees are distributed

Solana TFM

Has a blocktime of ~400ms
Block size limit 48M CUs
Writable Acconunt limit per block of 12M CUs
Tx Size Limit per block of 1.4M CUs

Additionally, a fixed 5k lamport per signature fee is applied. On top of that we find priority fees which users can add to improve their inclusion probability. These are calculated per CU requested. The following instructions are used for setting them:

SetComputeUnitLimit: Set maximum amount of CUs allowed to cosumed (top is 1.4M CUs by design). This will tell the SVM that when executed, the tx can at max consumed this # of CUs. If not specified, it defaults to # of instructions * 200k CUs which ends up being more expensive than actually required
SetComputeUnitPrice: price in micro-lamports of the priority fee to pay per every CU requested. Basically, Tx Priority Fee = (Tx CU Limit) * (CU Price). Regardless of the tx using all CUs requested or not, this fee is paid in full.

Fee Burn

Both priority fee and base fee are 50/50 burned/send to the leader. Base fee is always required while priority fee is optional but increases the probabilities of block inclussion. However, there are other ways of manifesting the desired to be prioritize as happens with Jito clients

Solana Scheduler

Solana block producers have the power to order tx arbitrarily within a block with the goal of optimizing profit. As well, due to solana tx specifying what accounts would be read and written, this allows the scheduler to sort which tx can be executed concurrently (tx that do not touch the same state can be executed in parallel) Within a block a maximum of 12M CUs can be used for sequential writes to a single piece of state. This number funny enough is the max CUs that can be processed by a single thread per slot (400ms). From there, we can also realize that the block limit 48M CUs is basically the limitation of 4 threads that the scheduler uses for non-voting transactions (12M * 4 = 48M). Future implementations of the scheduler could increase the number of threads, thus the CUs per block.

The scheduler has a non-deterministic way of prioritizing tx with higher priority fees whhich accounts for an not that reliable prioritization.

Validators in Solana are constantly building blocks so that txs can be in an in-progress state and then executed before the slot ends and organize them by priority fee. Additionally, the default multi-threaded solana scheduler adds jitter to the mix so that Txs are randomly assigned to one of the four threads (each maintaining its own queue of txs waiting for execution). Then priority fees are used for prioritizing txs intra-thread.

This fact explains the non deterministic beahviour of the scheduler as, even with the priority fee set, txs are randomly assigned making them have a higher priority only on their local thread not on the whole scheduler.Basically, it would be more a matter of what tx was received before rather than it bening based on the priorty fee. Some FIFO-like structure

This could be pictured as: an scenario where two transactions want to update the same state. They have different priority fees (one higher than the other one), the tx with the lowest priority fee could be excuted before the other if it falls into a thread where no other tx has a higher priority fee.

With the addition of Jito-Solana Client, the probability of this scenario happening decrease as they hold their own scheduler implementation introducing a 200ms bundle auctions that run in parallel to block production as well as their private mempool.

Shortcomings of solana's current TFM

Incentive to spam

As the scheduler still works in a FIFO-like manner (due to priority fee inclussion inefficiencies), despite the increasing priority fees, spamming transactions is still the go-to mechanism for ensuring tx inclusion. It is true that priority fees can help in creatin circumstances, but spamming is a substantial incentive for ensuring inclusion

Additionally, Solana's naive FPA (first price auction) makes it more realiable to spam the network for inclussion , s there is not a reliable DSIC (Dominant Strategy Incentive Compatible), thus making users have to guess what other users are bidding in order to get their tx included. This reality makes spaming easier and more user-friendly than calculating correctly the FPA.

50/50 Burn/Validator Payout

The payout protocol is not OCA-proof (ability of a system to handle situations where participants (or nodes) reach agreements through off-chain mechanisms, which are not directly observable on the blockchain itself.), where coalition of block producer and X number of isers can profit from reporting truthfully. An example solution for this scanerio would be Jito_solana's out of protocol auctions where 100% (minus Jito's cut) is paid to the validators (block producers) instead of burning the 50%. However, priooty fees are not the same as Jito tips as priority fees are only paid if successfully executed

Lack of Privileged Transaction Types

Voting is treated as any other transaction in Solana, meaning that it has to pay for the costs of such transaction, and such costs are overcharge with regards to the CUs consume. On the other hand, we have the rewards recevied based on such transactions, that are calculated based on stake

Innceficiency of CU usage & request

Not all CUs have the same base fee despite of their value (1M or 100k) and even if it just consumed 50k CUs is still paying the same base fee. This can lead to overestimating the compute needed within a block, leading us to an efficiency loss at scheduler level.

Costless to write lock accounts

Txs in Solana specify upfront all the accounts they will read or write when executing but this mechanism can be used for locking an account at effectively no cost. Once a tx specifeis a transaction it wants to write to, that account is locked until tx is finished, which can be a vector for spamming attacks as otehr related accounts are also locked

Solana new Scheduler

The new scheduler to be instroduced in v1.18, updates the scheduler from a ThreadScheduler to a CentralScheduler, where it uses a prio-graph scheduler that generates and acyclic graph with all the transactions Additionally, it keeps track of locked accoutns on read and writes to reduce the read-locking during periods of high activity.