jzaki/bls-wallet-aggregator

Consider order of transactions when inserting to db to increase successful execution

Closed this issue · 1 comments

jzaki commented

Primarily to ensure wallets have transactions processed with consecutive increasing nonce values.

If a wallet submits a tx with a nonce+1, before a tx with the current nonce, then naive ordering will have the first received tx fail.
When the aggregator receives a tx, it should have some logic to order transactions, so it can at least start with ensuring wallet nonces appear in order.

jzaki commented

Wallet: requests aggregator to process transaction, passing tx data, signature, as well as the nonce signed for. NB: this nonce is not a parameter in the call to the verification gateway contract, VG gets the next nonce from the wallet contract.
Aggregator:
If given nonce is before next nonce of wallet, or data NOT signed correctly (checkSig), reject.
If data is signed correctly:

  • if identical tx (data, signature) already exists as pending or ready to aggregate, don't add
  • if nonce is not next (ie future), store in db as pending
    • if pending count > 1000, remove earliest added tx (can refine logic in a future issue)
  • If nonce is next nonce of wallet, then store in db as ready to aggregate
    • then check for pending txs for next set of consecutive
      Eg if a wallet's next nonce is 3, and there are txs with nonce 4 and 5 pending, then once a tx of nonce 3 is received it will store 3, 4, and 5 as ready to aggregate (removing 4 and 5 from pending).

Periodically check pending txs' wallet nonces for readiness. That is a wallet's tx+nonce in pending has had prior nonce txs processed; via other aggregators, or the wallet UI itself.