increase prioritization fee

[tao-stones]

This is for issue solana-labs/solana#31453

[eugene-chen]

What is the reason to change the units of the prioritization fee, rather than just adding a minimum? Is the change significantly easier to implement this way, or are there other factors to consider?

[tao-stones]

What is the reason to change the units of the prioritization fee, rather than just adding a minimum? Is the change significantly easier to implement this way, or are there other factors to consider?

Thinking "units of the prioritization fee" as tick size of local fee market, it feels nature to adjust tick size instead of impose minimal fee, tho they are not necessary exclusive to each other.

My intuition is too small of tick size doesn't help establish local fee market, specifically with current micro-lamport as unit. For example, a TX with 200_000 CU, it'd pay 1 lamport if cu-price is set to 1 microlamport, or 2, 3, 4, or 5. (As the prio fee has to round up to lamport).

Implementation is that difficult, solana-labs/solana#31469 is ready for review that sets tick size to 1_000 microlamport.

[apfitzge]

If the SIMD is accepted and we take this path, once this PR is merged we should update bench-tps's randomized compute units, otherwise none are prioritized at all iirc.

[tao-stones]

If the SIMD is accepted and we take this path, once this PR is merged we should update bench-tps's randomized compute units, otherwise none are prioritized at all iirc.

solana-labs/solana#32079 for it

[mschneider]

it seems counter-intuitive that adding a minimum barrier for prioritization (squashing a lot of users into the 0 priority regime) is actually helping with congestion. doesn't it effectively create random choice on that bracket, leading to subjectively worse congestion effects?

[tao-stones]

it seems counter-intuitive that adding a minimum barrier for prioritization (squashing a lot of users into the 0 priority regime) is actually helping with congestion. doesn't it effectively create random choice on that bracket, leading to subjectively worse congestion effects?

As a rational user, if I checked and found it'd take more than I willing to pay to get priority for a fair chance to land my transaction at the moment, I may decide to hold it. That'd be one transaction less. If I am a market maker, I may pay a higher prio fee to pull quotes, pause continuous quoting till congestions ease to the point I able to resume.

But those are just some thought experiments, maybe far away from what reality turns out to be.

[apfitzge]

Several suggestions and nits with the wording.

I have no major concerns with the implementation. I think we still need to get feedback from others, specifically the community, on whether this is economically a good and reasonable change.

[tao-stones]

Several suggestions and nits with the wording.

I have no major concerns with the implementation. I think we still need to get feedback from others, specifically the community, on whether this is economically a good and reasonable change.

Thank you for suggestions!

[tao-stones]

Hi @eugene-chen @godmodegalactus @mschneider @SpaceMonkeyForever , can't find you guys from the Reviewers list, sorry tagging.

[godmodegalactus]

I prefer a little bit moving the decimal places and making it milli-lamports per cu instead of keeping it micro-lamports per CU. Will be little bit harder but better over long-run. But overall SIMD looks good.

[tao-stones]

I prefer a little bit moving the decimal places and making it milli-lamports per cu instead of keeping it micro-lamports per CU. Will be little bit harder but better over long-run. But overall SIMD looks good.

Thanks for input. Weighted the option of changing unit to milli-lamport or keeping micro-lamport as is. Decided keeping unit as-is could speedup rollout with less impact on users. (besides, it'd be milli-lamports when TransactionHeaderParameter takes over, would it?)

[godmodegalactus]

I prefer a little bit moving the decimal places and making it milli-lamports per cu instead of keeping it micro-lamports per CU. Will be little bit harder but better over long-run. But overall SIMD looks good.

Thanks for input. Weighted the option of changing unit to milli-lamport or keeping micro-lamport as is. Decided keeping unit as-is could speedup rollout with less impact on users. (besides, it'd be milli-lamports when TransactionHeaderParameter takes over, would it?)

Yes we can think like moving it to milli lamports when we migrate to TransactionHeader.

[mschneider]

Sorry, it took me a while to answer here again. I'm against this change, because the proposed motivation for the change and it's impact don't actually align well.

Prioritization fee is intended to be used sensitively during congestion,
provides advanced users a tool to access particular resources when contented
with a meaningful fee, while other users may opt to delay access to avoid
paying extra fee. When local fee market functions as designed, it provides
economic incentives to reduce congestion.

There is barely any congestion on write locked accounts, hence people don't use the priority fee mechanism as designed.

Given the low usage of the blockchain <100k DAU, the network has on average 100M CU / day for each of them in capacity. In addition a congestion hotspot can use up to 25% of the networks capacity, which rarely happens, most dapps have <10k DAU. Given the large difference between network and dapp DAU, the 25% capacity limit seems to be too large, 2-10% would be more adequate. MAX_WRITABLE_ACCOUNT_UNITS could be adjusted to 1-5M CU (number of banking threads should be proportionally increased). This would directly put more pressure on high CU users to set priority fees.

[tao-stones]

Thanks for inputs. I don't disagree there are various possible methods that can help on better utilization of priority fee. Often these solutions are not exclusive to each other. IMHO, the proposal is one step towards to the right direction, with minimal impact (in the sense that priority fee has yet been widely and actively adapted). I would argue that now probably is the best time to take this step to update priority fee's unit (eg tick size of local fee market) to a sensible and sustainable level.

[y2kappa]

I seems to be a disconnect between the motivation section of the proposal and the change. How is the change going to improve the problem, and what is the problem? What problems are currently caused by the current implementation and who is complaining about them?

---

I don't seem to understand source of the motivation for this change. You're saying that someone is left at a disadvantage because other set a minimum fee to always get priority? This doesn't seem to have anything to do with fairness and disadvantages.

Therefore, some payers set priority even if there is no contention, potentially distorting local fee market, and leaving other users at a disadvantage;

This is a competitive fee, a pvp situation, that everyone has to decide on, there is no fairness or "advantage" or "disadvantage" here. How does changing the tick size for the the priority fee make the market "fairer"?

Is there anyone that is currently complaining about this?

[tao-stones]

How does changing the tick size for the the priority fee make the market "fairer"

By "fairer" I mean a larger tick size helps to reduce undercutting concerns, hence it'd be "fairer" to average users that don't use compute-unit-price too frequently. Perhaps I should choose a different word, but the concern is, with smaller tick size, transactions can cut to the front of queue with economically trivial price. Besides the complexity introduced, this can harm market quality.

[y2kappa]

How does changing the tick size for the the priority fee make the market "fairer"

By "fairer" I mean a larger tick size helps to reduce undercutting concerns, hence it'd be "fairer" to average users that don't use compute-unit-price too frequently. Perhaps I should choose a different word, but the concern is, with smaller tick size, transactions can cut to the front of queue with economically trivial price. Besides the complexity introduced, this can harm market quality.

Makes sense. The average user will not change their behaviour, they will still not pay anything extra because the wallets haven't really implemented this feature. All you do is just force the ones that already pay the extra compute fee to pay more, nothing else. This is just pure extra revenue for the validators, nobody else. I don't see how this improves the market quality in any way.

Going back to the original problem: what problem are we trying to solve? Increasing tick size will not do anything for the average user, will just make it more expensive for others and improve validator revenue. This is an artificial revenue increase, not market driven. If it would have been market driven the bidding war would already raise the priority fee.

[ptaffet-jump]

Thanks for inputs. I don't disagree there are various possible methods that can help on better utilization of priority fee. Often these solutions are not exclusive to each other. IMHO, the proposal is one step towards to the right direction, with minimal impact (in the sense that priority fee has yet been widely and actively adapted). I would argue that now probably is the best time to take this step to update priority fee's unit (eg tick size of local fee market) to a sensible and sustainable level.

I agree with Tao on this. This proposal isn't going to solve everything, but it's low-hanging fruit to eliminate the corner case in which people get some priority without actually paying any more.

[ryoqun]

hi, i've started on thinking congestion control recently. ref: #61

i know this proposal is carefully written to minimize the community churn. however, I'm still not sure this tick size increase helps the situation.

at least, i think we need more visibility into current working to meaningfully evaluate this and other banking/base fee proposal.

firstly, i think current per-slot analysis/reasoning is too coarse. other than the final moments of well-published nft mints, every day arb opportunities are sporadic and instantaneous. And, solana's real-time streaming block generation isn't like (batched) auction at all. on top of it, cu limits and multi-threaded banking heavily hamper faithful prioritization adherence by leaders.

nextly, i think another problem is lack of proper tooling for bots to look into past individual gas wars. as there's no mempool in solana, i guess it's really hard for them to study the priority fee dynamics... the first step would be publish the banking trace files.. so, i guess currently bots are setting some fixed random priority fee, adjusting daily or so after overall win rate at that time scale. in a say, priority fee is working now. however, tick size increase won't help to change their status-quo behavior to be more reactive to local fee markets.

sorry if this sounds too much of ranting... i just want to make solana better... all in all, i don't believe any kinds of changes create a vibrant local fee markets at slot granularity.

instead, i think we should seek other approaches... #61 is one of them with single-threaded & no cu limits & intra-block exponential local base fee increase. :)

[0xSol]

This SIMD has been inactive for 6 months. The status changed to Stagnant per current SIMD process. Close it for now, but feel free to reopen with new updates if still relevant, or create a new SIMD as needed.