# A case for a simpler alternative to [EIP 3074](https://eips.ethereum.org/EIPS/eip-3074)

The `AUTH`/`AUTHCALL` mechanism is very appealing from a developer's point of view. It gives anyone the ability to come up with an invoker that can implement different batching strategies (e.g. supporting multiple nonces for better parallelism), gas abstraction models, complex account abstraction methods, etc.

The flexibility comes from being completely unopinionated about how this mechanism is used. Instead of requiring the developer to conform to a particular pattern, we require the user to sign an invoker-parsed `commit` hash, and let each developer set discretionary restrictions based on the commit.

However, this flexibility comes at an extremely high security cost. I would like to make a case for a simpler alternative that would get us most of the benefit at a much lower risk.

Why is signing an AUTH `commit` riskier than signing a transaciton to any other buggy/malicious contract?

When signing a transaction to a contract, the user takes a known risk of losing assets controlled by that contract. The user could sign an approval transaction to an ERC20 contract, approving a malicious DEX contract. The malicious DEX contract could then withdraw the user's entire balance of that ERC20. But... it cannot withdraw the user's tokens from other ERC20 contracts without requiring specific approvals. Nor can it do anything else on behalf of the user. The approval is specific.

EIP 3074, on the other hand, requires the user to sign a blank cheque and assume that the invoker is honest and not buggy. A malicious/buggy invoker could **do anything on behalf of the user** - access any asset owned by the user, vote on behalf of the user, take ownership of any contract owned by the user, etc.

Worse yet, the invoker can do it now and **in the future**, because the nonce implementation is controlled by the invoker. A buggy/malicious implementation of the nonce logic could allow replaying the user's past transactions. Combined with buggy logic of other parts of the `commit` verification, it could be used to perform any future action on behalf of the user. Even if the bug is discovered, the user has no way to revoke that blank cheque. The EOA is compromised forever.

Writing a correct invoker is tricky and we are almost certain to get it wrong occasionally. The [*non-exhaustive list of checks/pitfalls/conditions that invokers should be wary of*](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-3074.md#secure-invokers) at the end of the EIP gives us a glimpse of that. This list will inevitably grow, possibly through a painful discovery process.

Furthermore, a malicious actor could implement a honest-looking invoker with an intentional subtle bug which will be exploited after a lot of EOAs AUTH that invoker.

The attack may go unnoticed for a long time if it doesn't steal from the user directly or immediately.

***Governance hijacking example***

- EveSwap, a malicious DEX, implements an invoker for its users. It sponsors their gas through its airdropped EVE token and batches their approve+transfer transactions.
- EveSwap's invoker appears honest and never steals user tokens because that would be discovered immediately.
- Users are happy. Trades are cheap and successful, nothing bad happens for months.
- However, every time someone trades AliceSwap governance tokens, ALI, it self-delegates the user's AliceSwap voting rights.
- Once delegation crosses a threshold, EveSwap hijacks AliceSwap through a governance proposal.

EveSwap users are unlikely to notice this process because their trades are always successful, but the end result is devastating for AliceSwap.

***Cross-chain replay example***

The EIP rightly suggests that the `commit` should cover `chainid`. However, this is not enforced by the protocol, just the invoker. An invoker with the same address on another chain might skip this check (or any check for that matter).

- EveSwap lives on the EVM-compatible BobSpongeChain, which also supports EIP 3074. It deploys a honest invoker there.
- Users trade on BobSpongeChain using the invoker, and then use a bridge to move their assets to Ethereum.
- EveSwap uses the same deployment key to deploy a different invoker on Ethereum, at the same address. The Ethereum invoker doesn't check the `commit` at all. It just checks `ownerOnly` and acts as a generic AUTH/AUTHCALL proxy for its owner.
- EveSwap hijacks the Ethereum EOAs of all its users and gets away with all their assets.

The users never transacted on Ethereum, and the invoker running on BobSpongeChain went through rigorous security audits and was found to be secure. And yet, everyone lost their assets.

Ethereum prevents this through the replay protection in [EIP-155](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-155.md). AUTHCALL doesn't. By delegating all `commit` checks to the invoker, we lose any transaction protections offered by Ethereum. The attack is possible because protection becomes discretionary. If this EIP is accepted, the AUTH message must include `chainid` explicitly, not as part of the `commit`.

**What can we do instead?**

My proposal is to implement a more opinionated mechanism that enforces the meaning of the `commit` at the protocol level. The commit structure will be typed (as in [EIP 712](https://eips.ethereum.org/EIPS/eip-712)) so the wallet will present it in a user-readable format. The user will know exactly what the transaction will look like, and have confidence that it cannot be replayed later on any chain, without relying on the honesty and competence of an individual developer who implemented the invoker.

A possible implementation:

`AUTH` will replace the `commit` hash with a typed structure containing a list of authorized calls. For each call, {nonce,to,gas,calldata,value,chainid} will be specified. The signature will be verified, and the entire list will be saved as `authorized_transactions` instead of the `authorized` address variable.

`AUTHCALL` will get a new arg, `index`, which points to an address in the list created by the last `AUTH`.

The EOA's nonce will be incremented on each `AUTHCALL`. Not a nonce stored by the invoker, but the actual account nonce.

Pros:
- User gets full visibility into what's going on.
- Security is enforced by the protocol.
- Still allows batching and account abstraction.

Cons:
- Opinionated about the nonce implementation and doesn't support parallelism.
- Transactions of complex invokers become cumbersome because the user has to see and accept a list of all the calls.

A different implementation could support a different nonce scheme. But whatever mechanism we use, MUST be enforced by the protocol rather than the invoker.

Complex invokers that perform a large number of user calls should arguably be prevented anyway. Complex operations should be implemented as a normal smart contract rather than attempt to implement an algorithm using multiple EOA calls.

**Alternative: entirely avoid the hard fork**

Another option is to avoid the AUTH mechanism altogether, and solve the account abstraction and batching problems through an alternative mempool as [suggested by @vbuterin](https://notes.ethereum.org/@vbuterin/alt_abstraction)

Pros:
- No need for a hard fork. The new type is supported through smart contracts and nodes that are aware of them.
- Can be used to implement anything that EIP 3074 could be used for, without introducing additional risk.

Con:
- Not backward compatible with existing EOAs. Users will need to deploy a contract wallet and move assets to it.

Unless the requirement is to support existing EOAs without migration, this seems to be the safer option.