SIMD-0290: Relax Fee Payer Constraint

[apfitzge]

No description provided.

[tao-stones]

make it strictly cheaper to process invalid fee payer transactions compared to valid fee payer transactions of the same construction.

Can you say more about why "cheaper to process" invalid transaction that uses request (or default) CUs? Does it refer to request_cu usually greater than actual_cu, therefore fee/requested_cu will be smaller than fee/actual_cu (which is the case for valid transaction), therefore invalid fee payer transactions will have lower priority?

[apfitzge]

Using assumption that checking fee payer is a constant cost regardless of whether it can pay fees or not (not really true, but for the cost-model it is what we assume).

Then we 3 paths, and the things we do:

1. Account exists and has enough funds:
   • check if fee payer account exists
   • check fee payer account balance
   • execution
2. Account exists and doesn't have enough funds:
   • check if fee payer account exists
   • check fee payer account balance
   • (stop early)
3. Account does not exist:
   • check if fee payer account exists
   • (stop early)

^ we do less work, i.e. don't need to do any execution checks if the fee payer cannot pay.

[tao-stones]

wrt "default", if SIMD-0172 is approved, default will be zero, or a small number (chances are smaller than its would-be actual CUs).

[buffalojoec]

Maybe I'm missing something, but doesn’t this open up an attack surface where I can spam the network with transactions from invalid fee payers? If SIMD-0172 is active, I can also artificially inflate CU requests per tx, consuming a large portion of the block’s CU budget with zero cost.

Since these transactions are still stored in the block, even if they aren't executed, I could embed arbitrary data into the instruction buffers and use the chain as a rent-free storage or broadcast layer. Anyone could then retrieve that data later over RPC, effectively turning Solana into a no-cost messaging layer.

[apfitzge]

Since these transactions are still stored in the block, even if they aren't executed, I could embed arbitrary data into the instruction buffers and use the chain as a rent-free storage or broadcast layer. Anyone could then retrieve that data later over RPC, effectively turning Solana into a no-cost messaging layer.

You can send them sure, but why would a (non-malicious) leader include them if they do not provide income? They wouldn't. In fact, any transactions that cannot pay fees is a sign of a bad leader not doing what they should.
The proposal is 100% not suggesting these transactions should be included. Just that they can, because we need to eliminate the dependence on state for validity if we want to go async.

[buffalojoec]

You can send them sure, but why would a (non-malicious) leader include them if they do not provide income? They wouldn't. In fact, any transactions that cannot pay fees is a sign of a bad leader not doing what they should.

Have we considered how a leader would know this, without knowing anything about the account's state?

[apfitzge]

Have we considered how a leader would know this, without knowing anything about the account's state?

Nothing states the leader doesn't know the account state - the leader can have scheduling of only what it knows the state of (or at least a minimum bound on balance).
Again the purpose of this is not to allow the leader to pack transactions without knowing if they can pay fees...they should know or be pretty sure it has enough to pay the transaction otherwise they lose out on income.

This also isn't the same as being fully synced up on execution. Let's consider 2 scenarios:

1. A fee paying account signing many transactions often, strictly used as fee-payer.
2. A fee paying account signing infrequent transactions

In case 1, lets start at slot N with a balance of 100_000 lamports.
Tx1 w/ fee payer X lands in slot N, spending 10_000 lamports. X not passed to any ixs.
Tx2 w/ fee payer X lands in slot N+2, spending 50_000 lamports. X not passed to any ixs.
Tx3 w/ fee payer Y lands in slot N+2, mutates X (but not signed by X).
I'm leader at slot N+4. Without executing Tx3 I don't know the exact balance since X may have been sent additional lamports, but I don't care, since I know the balance must be >= 40_000. So when I'm leader in slot N+4, if I see a Tx4 w/ fee payer X that pays 30_000 I'm 100% sure that I can safely include the tx. And I didn't need to execute any of the transactions.

In case 2, lets say we have a starting balance of 100_000 lamports as of slot N.
I'm leader at slot N+100. No transactions touched acount X in slots [N,N+99].
I can safely include txs from X paying up to 100k safely since I know it's not been changed. And I didn't need to execute any of the previous slots to do so - I only need to check which accts have been touched, and how.

[buffalojoec]

I'm leader at slot N+4. Without executing Tx3 I don't know the exact balance since X may have been sent additional lamports, but I don't care, since I know the balance must be >= 40_000. So when I'm leader in slot N+4, if I see a Tx4 w/ fee payer X that pays 30_000 I'm 100% sure that I can safely include the tx. And I didn't need to execute any of the transactions.

But doesn't this imply that you're keeping track of at least the state transition function for the lamports field? So are all nodes supposed to just do some high-level speculative accounting for the fee payer to keep a cache of every possible fee payer and their best guess as to a range in which their balance could conceivably be by the time they are requesting to pay for a new transaction that you are about to pack?

I'm also under the assumption that block execution will lag behind block production by (n != 0) slots, so for n blocks, all of this fee payer accounting must be done.

[apfitzge]

Yes, if leaders do not want to waste their blockspace (they don't) AND want to be able to fall behind in execution they will have some way to estimate fee payer balance - in many cases this will not require full execution and can be done much much faster than execution. How they do this is an implementation detail so doesn't belong in a SIMD. It does not have to be what I described above, leaders could include only fee-payers with state they are fully synced up on.

Leaders are highly incentivized to be as close to the tip as possible since that is how they will have the best fee-payer balance estimates, and thus likely leads to more fees collected.

[buffalojoec]

@apfitzge okay thanks for the discussion! The leader incentive-based approach to avoiding chain spam makes sense to me. If you have a crappy "fee payer funded probability graph", you aren't making money!

How they do this is an implementation detail so doesn't belong in a SIMD.

Fair, but it doesn't hurt to be forward-thinking about protocol features that can make this easier to estimate, if need be.

[apfitzge]

@Benhawkins18 think this is ready to merge.