# Meta Transactions x Account Abstraction

## Relayer calls into AA

#### Idea
The general idea is that AAs support intra-transaction calls, after `PAYGAS` is executed. In this case, a user with no ether would submit a candidate transaction to a relayer. The relayer would decide if it would like to pay for the transaction. If they decide yes, they would craft a transaction, wrapping the user's transaction, and submit it on-chain. The relayer's account would verify their transaction and execute the `PAYGAS` opcode. Immediately after this, the relayer would call the user's account, passing in the user transaction. The user account would process the validity of the transaction. If valid, it would check to see if a `PAYGAS` has already been issued, and skip over it to continue the remaining execution if so. This would allow external call from the user account to properly hydrate `msg.sender`.

#### Problem

Imagine a user $A$ asks a relayer $R$ to relay $N$ transactions. $R$ also creates $N$ transactions, wrapping each of $A$'s transactions. Before $R$'s transactions are mined, $A$ submits a transaction with a much higher gas price than $R$, causing it to be included before $R$'s transactions. This creates a griefing vector against $R$ since $A$ can always submit transactions to $R$ which should pay out to them, and then front run them to drain $A$. Inversely, if $A$ submits a large number of transactions and then a single transaction which is relayed by $R$ and the relayed transaction is included, it could potentially invalidate all the transactions submitted by $A$.

## `PAYGASFROM` opcode

#### Idea

Introduce a new opcode `PAYGASFROM` whose arguments are `gasprice`, `from`, and `calldata`. Once executed, the `from` account will be called with the calldata to verify that it plans to pay for the execution of the transaction. Upon successful verification, it will update any replay protection mechanisms and then return control to the original entry point to continue execution.

#### Problem

Unlike the relayer calling into the AA, this solution shifts the validation burden to miners. For example, the relayer $R$ could give users $U_{1..N}$ a signature promising to pay for their transactions. This will fill the mempool with $N$ transactions. Then $R$ could front run the transactions and drain their account, causing all $N$ transactions to become invalid and unable to be included in the block.

## Expose two nonces

#### Idea

A user can invalidate an arbitrary number of transactions in the current construction of the mempool by submitting some number of transactions starting at nonce $N$, and then submit a conflicting transaction with nonce $N$ that drains the account of ether. This is acceptable because the miner can quickly invalidate transactions from that account without i) rerunning them (just checking `msg.value` + `gasprice` * `gaslimit`) and ii) affecting the validity of other transactions.

Let's modify the transaction format to have 2 new fields: `payer` and `payer_nonce`. This is in addition to the already existing `nonce`. Now we can statically order transactions into a dependency graph. To insert a transaction into the graph, we first check to see if either of the nonces conflict with any other transactions in the mempool. If they don't, they should run the normal validation against the transaction and if it turns out to be valid, insert it into the graph. If there is a conflict, the miner will need to verify that a cycle was not introduced into the graph. This operation can be done in linear $O(V+E)$ time.

#### Problem

My hypothesis is that this is the simplest form of access lists. In this instance transaction depend on each other in atomic chunks rather than via storage slots. I believe that generalizing this further will only increase the cost of checking for cycles. It's unclear if the cycle check (or a insertion heuristic) is intractable to perform on-the-fly while creating blocks.