# EIP-3074 alternative via transaction type

## Specification

Add a new transaction type, which is an EIP-2930 tx but adds two new fields:

1. A string of `contract_code` (can be a delegatecall forwarder, to save bytes)
2. A signature (standard `v,r,s`)

At the start of executing the transaction, verify that the contract code of the signer of the signature is empty, and set it to `contract_code`. At the end of the transaction, set the code back to empty.

Note that the signer of the `contract_code` signature, and the `tx.origin` of the transaction, are allowed to be different.

## Conversion of EIP-3074 use cases

In this EIP-3074 alternative design, AUTH and AUTHCALL would get replaced by calls into the EOA. Specifically the intention is that the `contract_code` would be a user wallet, and would expose two functions, `verify` and `execute`.

* AUTH would be replaced by a code to `verify`, which would use TSTORE to locally set `authorized[msg.sender, ...] = True`.
* AUTHCALL would be replaced by a call to `execute`, which would use TLOAD to verify `authorized[msg.sender, ...]`, and then execute from there.

Hence, there is a very simple transformation from "existing 3074 workflows" into workflows under this new scheme.

## Benefits

As mentioned above, this seems like it is compatible with any 3074 workflow, and it would require fairly little work to convert 3074 workflows. It has the added advantage that it is very forward-compatible with endgame account abstraction, without over-enshrining any fine-grained details of ERC-4337 or RIP-7560.

Specifically:

* The contract code that users would need to sign could literally be existing ERC-4337 wallet code.
* The "code pathways" that are used are code pathways that would, in many cases (though perhaps not all), continue to "make sense" in a pure-smart-contract-wallet world.
* Hence, it avoids the problem of "creating two separate code ecosystems", because to a large extent they would be the same ecosystem. There would be some workflows that require kludges under this solution that would be better done in some different "more native" under "endgame AA", but this is relatively a small subset.
* It does not require adding any opcodes, that would become dangling and useless in a post-EOA world.
* It allows EOAs to temporarily convert themselves into contracts to be included in ERC-4337 bundles, in a way that's compatible with the existing `EntryPoint`.
* Once this is implemented, EIP-5003 is "only one line of code": just add a flag to not set the code back to empty at the end.

## Weaknesses

It likely inherits a lot of the criticism of 3074 on the grounds that there are specific pieces of code that users would trust, and wallets would manage these pieces of code, and "who can create by-default-allowed pieces of code" might become a centralization vector. However, it feels like _any_ EIP that attempts to handle the "privilege de-escalation" (aka sub-keys) use case of 3074 would have the same problem.

## Open questions

1. Should the `contract_code` signature also sign over the account's nonce?
2. Should the `contract_code` signature also sign over the CHAINID?
3. Should there be a list of `(contract_code, (v,r,s))` pairs, to set the code of multiple accounts? This could save gas for batches.