Will it prevent replay? If T is 3 and say LastNonces is currenlty 1,2,3 and I submitted 4 transactions with nonces 4,5,6,7, then the sequencer can pick anyone. Say it picks them as 6 (last becomes 2,3,6), 5 (3, 6, 5), 4 (6, 5, 4) and 7 (5, 4, 7). Now 6 can be replayed. I think that ‘max’ instead of ‘last’ solves this.
Who pays for the T storage cells? Can it be 1M?
22 Likes
we should still maintain order (like today), so 5,4 can’t be played after 6.
I think that’s what you meant by “max”, but it’s not instead, it’s in addition to the last nonces.
In other words, the suggestion is to add a predicate to today’s logic (which asserts that the executed nonces are monotonically increasing).
Only today it’s simply looking at a single number (i.e. T = 1). And with this we’ll have some history.
So the logic can be - accept only if transaction.nonce > min(LastNonces) and transaction.nonce is not in LastNonces.
Maybe another way to look at it is that each contract has T “available slots” to allow for transactions to execute, and while a transaction is not included, it’s “holding” a slot, and when included in a block (by some definition of finality), the slot is “freed”.
24 Likes
After thinking about it some more, I think this needs to be refined a bit.
In this suggestion we keep T last largest nonces per account (T configurable per account).
And the condition to check for a given transaction’s nonce (n) is whether the n > min(LastNonces) and n not in LastNonces.
This, combined with the maintenance of the T largest nonces, should give us a safe solution.
21 Likes
Understanding the rationale behind this limitation, will this limitation still be used to spam the network with txs that can’t be validated?
22 Likes
What limitation exactly are you referring to?
20 Likes
Regarding all suggestions, I would like to mention that when nonces are not “continuous”, then it means sequencers will have more opportunity for MEV since they can censor some transactions and insert others and there will be no way to invalidate that.
In the case of [index, nonce], this can happen if there are some transactions with index 0 and some with index 1. The sequencer can ignore a tail of transactions with index 0 and still insert those with index 1.
In the case of the largest nonces, it is even easier to ignore.
Contrast this with the single sequentially incremented nonce, a sequencer cannot include a tx with nonce n without also including all txs with nonce less than n in the pool.
26 Likes
I believe the benefits of nonce abstraction outweigh the side effects of having nonce abstraction. One such use case I feel is with session keys, they would benefit a lot with a 2D array. The session key → nonce mapping would allow multiple authorised entities to call the wallets in parallel without waiting to get the correct nonce.
I feel that leaving the implementation of the nonce to the account can open interesting nonce variations, while the sequencers pick up transactions that are most beneficial for them.
23 Likes