solana: Consider adding user specified fees to prioritize txs propagation to the leader/block
Problem
No way for users to easily prioritize transactions landing in a block outside of staking directly or indirectly.
Proposed Solution
V0
Ship this asap. Even with deterministic congestion control, an additional user specified priority is necessary. If there is a bug in the validator client and performance stalls, logically the blocks are not saturated and deterministic fees may not trigger. Clients need some way to force their txs to the front of the queue.
- ComputeBudget instruction in #22081 should take a fee argument
- txs should be pulled from connected nodes with QoS by stake weight in #22753
- Cost model should fill writeable accounts using
total fee/total tx costas the priority. Hot accounts will saturate first with highest paying txs, but will not impact the fees for other accounts. - Node should forward remaining forwardable txs based on the priority. The forwarders would need to run the same computation as in step 2, filling one account at a time, otherwise the high priority txs that all saturate one account will starve the other accounts. Once account is filled, txs that write to that account have zero value since they can’t land into the block.
Add an RPC api that given a transaction, checks for lowest possible fees paid by txs in the last 32 blocks and if they are saturated, and lowest possible fee paid for the writable accounts referenced in the tx if those accounts are saturated. the highest of the two should be what the tx should pay to get prioritization. In the design, a fee spike should be write account specific. a hot market that seeing a lot of bots, that specific account will see a fee increase, but all the other ones shouldn’t. This is because once the write limit is hit for the account we can’t add any more txs to the block for that write to that account.
V1
There is enough MEV on the network that a validator would take a bribe that is greater than the 50% of the additional_fee to include a transaction instead, on solana 50% of the fee is burned. Eth EIP 1559 splits fees into a congestion base fee that is burned with a tip that 100% goes to the validator. The challenge for solana is that write lock accounts are saturated independently of blocks, and need their own congestion control.
-
Add a multiplier for unnecessary write accounts, #21883
-
Congestion fee based on the load that doubles when accounts are saturated, and when blocks are saturated. This is tricky because an account could be saturated in block 1, and block 5, if block 2,3,4 are forked, or saturated, fees should double as well.
-
make the tip 100% go to leader, burn the congestion fee
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 11
- Comments: 24 (18 by maintainers)
these are my not-very-well formed stream of consciousness thoughts haha
my main concern would be this stuff breaking down when more people start to run custom validators to maximize profits. you’re specifying you’re willing to pay extra to get processed faster, and as a validator i’d be very happy to accept this extra money! however, the only thing better than receiving 50% of this payment would be 100% of it.
it seems fine for normal users willing to pay for fast tx processing if/when blockspace becomes saturated, but as we’ve seen on ETH it seems hard to enforce this type of ordering forever with automated bots and could even result in PGA-type scenarios. maybe the workaround for this stuff is some type of base fee handled on per-account basis and enforced by the protocol; if you pay less than base fee you’ve produced an invalid block
@buffalu I think incentives can be adjusted later. Eths burn is quite significant and hasn’t caused a massive direct to validator bribe side channel (although there is def some).
the other approach is to double the fees every time an account is saturated or every time a block is saturated. eip1559 is pretty decent way to split the problem, congestion base fee + validator tip. The hard part in solana is the account model. account hotspot congestion occurs first and generally without block congestion.
it just seems inevitable that out-of-band payments will happen (and are already are happening from what im hearing 😢 ), so trying to enforce anything except direct-to-validator or direct-to-staker payment seems like a hard sell
The guarantee is only that they include an equal or greater number of “normal” (i.e. no priority fee paid) transactions, to approximate a twin-queue system, where tx are taken from both queues (It’s not really a queue, but would behave similarly). The intention is to prevent priority fees from spiralling upwards, pricing out regular transactions. A proposed block that doesn’t meet this should be voted against. I don’t understand the account-write saturation, or how fees for that would work. My intention was only to propose an incentive that steers the network back to not needing priority fees at all - i.e. if too many people were paying for priority, and that “queue” was bigger than the unprioritised one, then you’d actually be better off NOT paying priority fees.
No. Compute Budget instructions are handled by the runtime, so need to be visible pre-execution
you wouldn’t earn as much though, right? once the writable account is saturated the value from the additional txs for that account is zero.
When the leader is pulling new txs from the staked nodes we don’t want TXs that saturate a single account to be the only thing it pulls, otherwise the blocks are not going to be full. it will just be that one account and the system would end up in single threaded mode.
There are costs associated with each account read/write, instruction, BPF cycle, cpi, etc. all those are rolled up as a “compute unit”. Ideally the network should run at something like 80% capacity without saturating any single writable account. Once accounts are saturated, the network should automatically increase the base fee for using that resource. The reason for this is because a single writable account that is constantly saturated creates a single thread dependency across processing the chain, it makes it slow for nodes to catch up and leverage multi core environments. Adding automatic congestion control is part of V1.
Why do we need a direct to validator tip/additional fee at all? Let’s say there is a bug that causes something in the validator pipeline to stall, and take a bit more time to process. Number of txs that land in the block drops, so blocks are not logically saturated, but they are saturated in real life. we still need some way for clients to always be able to prioritize txs ahead of every one else.
imo it makes sense for additional_fee to be an extra instruction or CPI?
wallets will probably use a tx instruction with static amount, bots will use CPI with runtime-determined amount (can simulate to determine ordering)
I assumed it was to be built into transactions somehow and validated by other validators before being voted on. Otherwise, it’s not part of any proposal anyway as it’s something completely out of band with the validator software.
Having a standardized field where a user can declare a tip that will go to whatever validator includes it in a block allows the transaction to carry the tip with it, which means that it survives being forwarded, etc.
EDIT: I assume that “tip” is the same thing as the “additional_fee” field that was proposed to be added to the transaction. Is that not so?
yeah something like this seems reasonable. there’s a base cost for access to certain resources that everyone has to pay no matter what. if you want priority access/ordering you can pay extra and have the validator handle it.