Relax Fee-Payer Constraint

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 3. Account exists and doesn't have enough funds: - check if fee payer account exists - check fee payer account balance - (stop early) 5. 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.

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

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?

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 inf

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 = 40000. So when I'm leader in slot N+4, if I see a Tx4 w/ fee payer X that pays 30000 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

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.

@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.

@Benhawkins18 think this is ready to merge.