Update Base Fees

sRFC
1

Title: Updated Base Fees

Summary

I had written an article about base fees and how the base fees should look depending on the cluster size.

I want to hear from the community about their opinion. There are multiple approaches to change the base fees.

→ Constant base fees

→ Linear base fees

→ Brackets based base fees

→ Exponential base fees

I will explain the pros and cons of each in a few words.

Why change base fees ?

Currently, base fees are constant 5000 lamports / signature. So cost of executing transaction on the cluster is measured in SOL than in USDC. If SOL becomes more expensive, then it will be more expensive to execute transactions for the user, while if SOL becomes less expensive, then it will be harder for the validator to keep running the cluster.

The base fee is constant and is not based on the block space used by the transaction. So user pays the same base fee if they execute transactions consuming 10K CUs, 100K CUs or a million CUs. Base fees should consider the resources used to execute the transaction on the cluster. This makes everyone send transactions requesting the maximum CU possible of 1.4 million CU. If transactions are not correctly estimated for consumed CU, the scheduler finds it difficult to schedule the transactions and fill the block completely, wasting some of the block space.

By changing the base fees based on CU requests, we can calculate the resource usage in CU appropriately and charge the user based on resource utilization.

Who will control the base fees

The base fees could be controlled by DAO or Multisig, giving them control over one or multiple variables. Various communities, validators, and developers can be part of the DAO. The current proposition does not consider this part, as it could be figured out later.

Requirement of new base fees

  • Should be based on resources used by the transaction.

  • Optionally discourage spamming.

  • Optionally encourage optimization of code by the programs.

  • Should be in interest of “most” of the community. (i.e should not be too expensive for user nor punitive to run a validator)

In general we have to find a middle ground to encourage dapp devs to write optimized programs, for users to send transactions with better estimates for resource use at the same time not discourage existing users to use Solana. It should also encourage validators to pack the block the fullest i.e consuming 48 M CU.

Impact

This proposal Validators, Dapps and everyone who uses Solana cluster to send and execute transactions.

New Base Fees

Constant base fee

Formula:

Base Fee = constant value

Pros:

  1. Easy to calculate fee for transaction.
  2. Already implemented just need to update the constant value.

Cons:

  1. Does not discourage spamming of network.
  2. Does not discourage large transactions consuming lot of CUs.
  3. Does not encourage optimization of the programs.
  4. Does not represent resource utilization.

Linear base fee

In this model base fee will be linearly dependent on the CU requested with a minimum floor value of the base fees. The rate at which base fee will increase will be called rate of change of base fees or just Rate.

Formula:

Base Fee = round(max( Minimum Base fee value, Rate * CU requested ))

Pros:

  1. Relatively easy to calculate.
  2. Encourages optimization of programs.
  3. Encourages sending transactions with proper CU estimates.
  4. Rate can be controlled by DAO or MultiSig.
  5. Rate can be changed according to SOL/USD oracle price.
  6. Depending on MinValue, can incentivize validator to prioritize smaller transactions.

Cons:

  1. Hard to find correct Rate which will please everyone.
  2. Lower value of rate will not discourage sending of large transactions nor encourage program optimization.
  3. Higher value of rate may discourage users away from solana.

Bracketed base fee

Formula:

Base Fee = (0 to bracket_1) * rate 1 + (bracket_1 to bracket_2) * rate 2 …..

Pros:

  1. Relatively easy to calculate.
  2. Encourages optimization of programs.
  3. Encourages sending transactions with proper CU estimates.
  4. Can disincentives sending of large transactions.

Cons:

  1. Any multisig or DAO will have multiple parameters to set.
  2. Can have some weird behaviors.
  3. May need some different burning rates for different rates.

Exponential base fee

Consider a multiplier multiplier that has to applied to a certain CU CU multiplier (i.e we want transaction requesting 1 million CU pay 5 times the minimum value then multiplier is 5 and CU multiplier is 1 million).

Formula:


Base Fee = round( Minimum Value * multiplier ^ (CU requested / CU multiplier) )

Pros:

  1. Encourages optimization of programs.
  2. Encourages sending transactions with proper CU estimates.
  3. Rate can be controlled by DAO or MultiSig with 3 params.
  4. Rate can be changed according to SOL/USD oracle price.
  5. Will disincentivize spamming and heavy transactions.
  6. Incentivizes sending of smaller transactions.

Cons:

  1. Relatively hard to calculate.
  2. Will make users to split transactions doing multiple instructions into multiple transactions.
  3. Need to update burn rate so that validators do prefer executing heavy transactions.
  4. Relatively hard to get consenseus over the variables.

As a community I would like to have your opinion .

1 Like