Account Abstraction transaction verification and fee payment

[hackaugusto]

This is just a rough outline I'm writing to start talking about the problem.

I believe we want to achieve the following:

• Quickly verify a transaction for 1. being properly authorized 2. having enough assets to pay for its execution 3. being valid for the account's state
  • IOW the rollup shouldn't execute a potentially expensive transaction, to learn at the end that the either 1. the signature was invalid 2. there wasn't enough funds to pay for it 3. the nonce was invalid
• Support account abstraction, which allows for different signature schemes
• Maybe support fees payment with different assets and schemes

Additionally:

• It may be interesting to identify that a transaction is valid, but not finish its execution. Because it is as part of the validation process that the fees are computed, and it is important to know how much a transaction is paying if fees to prioritize them.
  • I think it is better to have resumable execution, instead of invoking the VM twice 1. first only the script to verify the signature and fees, then 2. with the complete code for the whole transaction. Because verifying that the code is available is part of the transaction validation.

One solution for the above is to execute prior to the transaction prologue, code that will 1. call the account's signature verification 2. verify the fee schedule configured by the user can be paid. i.e. the user would provide a vault like structure as part of the transaction, and the code would verify these amounts can be extract from the account's vault. 3. check the provided account hash matches the current account hash (we can do without a nonce in this case, the nonce would only be necessary if we want to support free transactions, to force a change into the account's state). Then as part after the transaction epilogue, the fee schedule vault would be put in a note to transfer the fees to the operator's vault.

Note: This is intentionally hand wavy and I have not thoroughly thought about how to implement this.

[hackaugusto]

One problem that I don't have a solution for, is how to pay fees for the operators for transactions that are executed locally. Perhaps we should be able to wrap these proofs in another transaction, where the outer transaction exists only to pay for the proof inclusion.

[bobbinth]

There is probably a bigger discussion here on the overall fee model. I've been trying to delay this - probably even to after the testnet, but in general, there are different types of fees and maybe we'll unify them into a single gas model, but maybe not. These fees apply to different types of transactions differently:

• For locally-proven transactions:
  • There should be a fee for verifying the proof. This should be pretty straight-forward as there is not much variability in terms of complexity for different proof sizes (i.e., verifying a proof for a 1M cycle transaction is not that much more expensive than verifying a proof for 1K cycle transaction).
  • There should be a fee for how many state updates are needed to record the transaction. This could be driven by the number of consumed notes (because the nullifier DB needs to be update), the number of created notes (because we need to append them to the notes DB), and whether or not an account's state changes.
  • There should be a fee for any additional detail which need to be stored on chain (i.e., for recording full account state or full note details). Basically, there should be a cost for putting more data on chain.
• For transactions proven by the network, all of the above still apply but we also have an additional fee:
  • Fee for proving the transaction. This is the one where we need to make sure transaction execution doesn't go into an infinite loop etc. Overall, the fee should be proportional to the number of executed cycles. The difficult part is ensuring that the transaction can be in fact executed to completion (see also my note on DoS in DOS attack vectors #18).