Diving into SiMD 0050 - 10/07/2023

SiMD 0050 and Solana Transaction Fees

Gas Fees and Priority Fees:

The Ethereum Landscape:

As per the definition from Ethereum, Gas refers to the fee required to pay for the compute unites needed to execute a transaction on Ethereum Blockchain, be it a succession or failure.

Mathematically, Gas Fees = (units of gas used) * (base fee + priority fees)

Base Fee is the fees set by the protocol as the fees for using the computation resources. After the Ethereum London upgrade,

• Every block has a base fee or a reserve price.
• The base fee is calculated independently for each block.
• It is determined by the blocks before a block, thus becoming predictable for users.

Priority Fee is the fees set by the user as a tip to incentivise miners to include a transaction in the block.

Calculating Fees on Solana:

Solana is known for its fast transaction speed at a low fees. Yes, you get fast transactions with fees lower than ethereum’s base fees. Only Possible On Solana

Let’s get into the math of calculating transaction fees on Solana:

If F(T) is the Fee per compute unit.

F(T) = (additional_fee + base_fee) / requested_compute_units

Consider two transactions T1 and T2 in the pending queue with F(T1) > F(T2). Then-

• T1 should be processed before T2.
• If another transaction is ahead of T1, then T2 should not be scheduled before T1. Else, it may create chances of starvation for the transaction T1 which has got higher fees than T2.

The priority fees is calculated by,

priority fees = (compute budget) * (compute unit price)

where compute budget = (no. of instructions in the transaction) * (compute units limit)

The Solana Transaction Pipeline:

Let’s now go through the Solana transaction pipeline and how a transaction gets prior to another one.

SigVerify: It verifies the signatures of the transaction to ensure that they are valid ans secure.

Scheduler: Think of this as a traffic controller. It receives the transactions from SigVerify and controls their distribution to the further stages.

Banking Stage Threads: These are the ones dealing with the actual execution of a transaction. These threads perform the computation and the parallel processing.

Changes Proposed by SIMD-0050

(SiMD)Solana iMprovement Doc #0050 suggests that the cost of prioritization(the additional fees paid to prioritize a transaction) should be significant enough compared to the base fees. It ensures that the users who are paying for the prioritization are paying a substantial amount.

It says that the existing prioritization fee is relatively small when compared to the base fee. Therefore, if some users set priority even when not required, creates an uneven condition for the normal users.

It also highlights a point, that the current scenario of calculation of priority fee does not care much about the compute_unit_limit.

compute_unit_limit is the maximum number of compute units allocated for a transaction. It completely depends upon the complexity of the transaction.

Data from 49857481 transactions from Mainnet-Beta was taken out of which 5414935 were non-voting transactions. It showed that the total priority fees paid was only 6.64% of the total base fees.

breakdown of transaction fees and priority fees data source: https://github.com/solana-labs/solana/issues/31755#issuecomment-1559755419

Proposed Changes

The SIMD proposes the change to round off the compute_unit_price to nearest 1,000 microLamports. Thus, if a transaction will have priority fee less than 1,000 micro Lamports, it will not be given the priority status and no priority fee will be charged for them. Thus, treating them as a normal transaction.

The SIMD also suggests an alternative to change the unit of compute_unit_price from micro Lamports to milli Lamports. But it will require an update in the compute_budget instruction that uses milli Lamports as a unit to be co-existing with the existing instruction that uses micro Lamports and gradually shifting to the proposed unit and followed by deprecating the earlier used micro Lamports unit.

Impacts if the proposal is accepted:

1. Voting Transactions (the transactions used for consensus and block validation) will not get any impact as they do not need a prioritization fees.
2. No impact on the transactions that do not set compute_unit_price. These make up around ~32% of the non-voting transactions.
3. Impacts on transactions with compute_unit_price:
   1. The users will use the compute_unit_price very wisely and using them when priority is really-really needed.
   2. Users can also use RPC Endpoint’s getRecentPrioritizationFees to get the latest stats and set the compute_unit_price accordingly.
   3. A good way will be to set the compute_unit_price in terms of 1,000 microLamports as this will be the standard unit.

Some noticeable QnA from the discussion:

Q: Why not directly add a minimum required priority fees? Is it really needed to change the units? A: It feels more natural to adjust the units compared to add the unnecessary trailing zeroes. It helps to establish a more meaningful and effective local fee market by rounding off to the nearest 1,000 microLamports.

Q: When less users will pay for prioritization, more users will fall into the lowest priority bracket and leading to randomisation of transaction scheduling. Thus, leading to more congestion. A: The change in the priority fee will have different effects for different types of users.

• Considering a Rational User:
  • When Prioritization Fee will be significantly greater than the urgency of the transaction, a rational user will prefer delay in the transaction.
  • It will also lead to less transactions submitted for the priority and thus, decreasing the network load and ultimately leading to faster processing of remaining transactions.
• Considering a Market Maker: Market Makers are the participants in the market who provide liquidity by quoting prices and bidding for assets.
  • A market maker will of course be willing to pay higher transaction fees to get their bidding transactions into the priority.
  • In the case of a highly congested network, they may want to pause their continuous quoting and conserve their resources. They may resume the quoting when the congestion gets lower.

Q: How does this make the market “fairer”? A: The larger units of the prioritization fee will result in the prioritization being used wisely and therefore less prioritization of transactions. It gives fairness for average users and ultimately, benefiting the validators.

More QnA is available on the Pull Request page of the proposed SiMD: https://github.com/solana-foundation/solana-improvement-documents/pull/50