Soft Deprecation For Nonce Transactions

[MaxResnick]

Durable nonces are going away! Hooray! But their removal will take some time while we wait for custodians migrate over. In the meantime, the existance of durable nonce transactions, is causing a few problems.

1. Durable nonces are being coopted for durable nonce spam leading to gunk in the scheduler.
2. The existance of high priority durable nonce spam is blocking the implementaiton of SIMD 0297 (relax invalid nonce) which itself is a prereq for bankless leader which is a prereq for Constellation.

So this discussion is to propose a soft Deprecation for Nonced Transactions that involves setting their priority fee to 0. Custodians, who's use cases are not time sensitive, will still be able to land durable nonce transactions since the marginal priority fee in Solana blocks is 0 almost always. We will however, be able to implement SIMD 0297 and get rid of the durable nonce transaction spam for landing since it will be deprioritized in the scheduler so there would be no incentive to do it.

Now there are a few ways to implement this change.

1. The clients could implement it on their own; however, I suspect MEV clients would then wish to fork to reverse this change since it might increase revenue in the short term while we wait for everyone to migrate over to the new landing game.
2. We could simply stop the collection of transaction fees for nonced transactions in addition to (1)
3. We could burn the priority fees from nonced transaction (a harder to implement protocol change than 2 but would not waste the scraps from nonced transactions)

Some data:

Marginal fee: In a recent 10000 block random sample from the last epoch, the marginal non vote not Jito bundle transaction had a prio fee of 0.

In the last epoch:

• 16.1M / 521M txs are durable nonce (~3.1%).
• 1,975 / 6,621 SOL in priority fees come from nonce txs (~30%).
• 86% of nonce txs pay a priority fee vs ~28% network-wide.
• avg prio fee Per fee-paying tx: ~142k lamports (nonce) vs ~35k (non-nonce)

Concentration:

555 of 103,672 nonce fee-payers (0.5%) have >1,000 total txs.
Those 555 account for 97.5% of nonce txs (15.6M / 16.0M) and 70% of nonce priority fees (1,389 / 1,975 SOL).

rank	fee_payer	total_txs	nonce_txs	nonce_priority_SOL	nonce_tx_fee_SOL	% all durable nonce priority	% all epoch tx fees
1	2CQgjc…zctFG	21,352	4,140	201.419	201.439	10.20%	2.151%
2	REDACTED	1,966,320	1,186	116.308	116.314	5.89%	1.242%
3	57stAM…4DyZ	2,168	970	94.648	94.653	4.79%	1.011%
4	5brv79…LyAr	1,513	509	90.590	90.592	4.59%	0.967%
5	BSHdFz…JqLD	3,812	3,667	47.990	48.009	2.43%	0.513%
6	popo3R…MuHz	3,388	3,334	46.702	46.718	2.36%	0.499%
7	hnu5iB…1CYN	5,117	4,309	45.474	45.495	2.30%	0.486%
8	2mqrin…jwdY	2,133	2,101	36.807	36.817	1.86%	0.393%
9	hnu69n…7wC	1,580	480	33.527	33.529	1.70%	0.358%
10	3fZftz…Bf6u	3,067	2,960	33.060	33.075	1.67%	0.353%

[apfitzge]

The existance of high priority durable nonce spam is blocking the implementaiton of SIMD 0297 (relax invalid nonce) which itself is a prereq for bankless leader which is a prereq for Constellation.

As far as I recall, there was a shift in priorities away from SIMD-0297 to full nonce removal, and was unrelated to spam.
The reason for this shift is because the relaxation on nonce requirements allows txs to appear in history multiple times. This has negative impacts on things like RPC, where we now have to implement handling of duplicate txs in history. It was deemed far riskier and not worth the changes when we plan to fully remove them - though I didn't think it'd take us this long to get a replacement and start the 6mo counter to nonce death.

So this proposal does nothing to free us up to for 297's implementation.

Something like this could be a good forcing function to get nonces out of activity we did not anticipate.

2 seems like the easiest option to implement - we can simply ignore priority fees on nonced transactions.
Do not disallow since that could break already signed txs. It keeps the changes isolated to a couple spots (compute budget handling & txv1 config handling), for a feature we expect to exist as a temporary measure.

Alternatively we could implement better explicit nonce behavior in the scheduler, which makes their effect much less impactful on other txs.

[MaxResnick]

I don't think a discarded tx need not apear in the transaction history. We should treat it the same way as a tx that we filter out. Basically if it doesn't change state why does the hash need to be persisted into the tx history?

[apfitzge]

I think this is separate from this SIMD discussion. But, I imagine there are several things that gets broken if we have txn data in the block that does not actually appear in RPC data or is otherwise pretended as not existing.

[2501babe]

yes the soft blocker on both 290 and 297 was that we would have to tolerate committing the same transaction (same signature / message hash) arbitrarily many times. from there the discussion moved onto "well we want to get rid of nonces anyway, lets just get rid of nonces"

aside from that, nonce spam is already a problem, adding in a feature that writes every discard to chain just creates another problem

[bw-solana]

I'm in favor of doing something to disincentivize nonce spam.

Out of the options you listed, I'm cool with 2.

But I find myself favoring the option of filtering out duplicate nonces in the scheduler. Something like key based on sig/nonce after sigverify and only maintain the highest PF one.