StarkNet Account Abstraction Model - Part 1

📜 Development Proposals Starknet Technical Development
, , ,
16

Hello,

I’ll make a case for nonce abstraction, or at least for the possibility to have more flexibility in nonce management.
Nonce management is hard when you need to send a large number of transactions from a single account, and you can’t multicall them.

  • At least four projects I know have faced this issue (the starknet Edu team, the Empiric team, the Rules team and the snapshot team). And in the Ethereum world it is a widespread problem 1 2 3.
  • If your backend has various processes that need to access the same ressources / wallet, it is quite hard to figure out which nonce to use. Using an incorrect nonce will get your transaction rejected, or stalled.
  • The option is basically “Have all your workload executed sequentially, or have multiple wallets”. But having more wallets, dealing with more keys and adding more permissions in your smart contracts are not necessarily a good thing.

I think nonce abstraction is very useful in the future, but even more so today

  • There is no notion of mempool, so if a transaction is waiting for inclusion but hasn’t been included yet, it is impossible to detect it
  • There is an implicit guarantee of ordering of transactions when I send them to the feeder, but any glitch on StarkWare’s end will mess up ordering and will invalidate all the transactions I sent. This will get worse with optimistic paralelization
  • A transaction with a incorrect nonce is not only bounced back, it is prohibited from being re sent again. Meaning that if I craft a batch of 1k txs, send them at once, and a glitch / error happens at tx 5, all 995 remaining transactions will be discarded AND I have to craft them again and change their payload.
  • This means that currently it is not safe to send more than 1 transaction per block using the same account. That’s little.

A relatively simple solution would be to have the nonce be a two dimensional object. Instead of using [nonce], the wallet/os would use [index, nonce] to check the unicity of a transaction.

  • The OS can still validate that for [index], [nonce] is sequentally incremented
  • It allows operators that need to fire a large number of transactions in paralel to assign indexes to queues, and deal with nonces separately
  • It comes at no cost for regular users. Most users will use index 0 and increment the same nonce, using no extra storage in their contract compared to using a single nonce
30 Likes