# Implications of EIP-3074 inclusion *Special thanks to Vitalik and the AA team for feedback and review.* [toc] There are some transaction workflows that the EVM currently does not support well, and are commonly demanded by dapps and users, including transaction sponsorship and batching. While ERC-4337 and its successors (eg. RIP-7560) are fully equipped to handle these concerns, these "full AA" proposals are still some time away from being ready for full adoption. Hence, there has recently been interest in adding short-term EVM improvements to handle these functionalities. If done well, this could significantly improve functionality and security. The leading proposal in this regard is EIP-3074. However, EIP-3074 has some key weaknesses, both in its security implications and, importantly, in its relative lack of forward-compatibility with an account abstraction roadmap that solves what EIP-3074 does not solve (eg. the majority of motivating use cases that guided AA development beginning with 2016-era proposals like [EIP-86](https://eips.ethereum.org/EIPS/eip-86) as well as in later proposals like [EIP-2938](https://eips.ethereum.org/EIPS/eip-2938#motivation)). This post lists what some of these weaknesses are. A future post will expand on a path forward, which takes a simplified version of a feature of "full AA" and makes it available for EOAs, solving for the same use cases as 3074 with more forward-compatibility and less risk. ## Potential centralization vectors We need to improve Ethereum's account model, but without introducing new centralization vectors. 3074 brings some potential vectors which we should consider: ### Centralizing infrastructure Using 3074 without a relay is hard, even for simple use cases like [batching](https://github.com/anton-rs/3074-invokers/blob/main/src/BatchInvoker.sol). It requires signing twice: once for the AUTH and once for the transaction. Asking users to sign twice is bad UX, so many use cases will use relays. It's [possible](https://notes.ethereum.org/@yoav/eip-3074-erc-4337-synergy#An-EIP-3074-invoker-as-the-ERC-4337-account-logic-of-an-EOA) to implement an invoker that works as a 4337 account and uses a permissionless mempool, but it's not trivial. Users and devs usually take the path of least resistance. In 3074 this path is a centralized relay. Fast-forward 2 years, I'm afraid most 3074 transactions will come from a small set of relays run by centralized service providers. Dapps will assume that features like batching are available and may stop supporting flows that don't require it, so users may end up with relays as the only viable option, which means we lose censorship resistance. I hope to be proven wrong, and that we'll see everyone taking the harder path and keeping things decentralized, but I'm not optimistic about it. ### Permissioned innovation Due to lack of privilege separation, any use case requires granting full account access to the invoker. E.g. if you want someone to sponsor your gas you need to give an invoker full account access. As a result of this security design, wallets will have to whitelist invokers and not let users choose. People wrongly blame wallets for attempting to become gatekeepers when they say they'll maintain a whitelist. Wallets have a legitimate reason to whitelist - user safety. However, the fact that they'll do it will make them gatekeepers nonetheless. When dapps want to use a UX improvement enabled by 3074 they'll assume the wallet can do what the most popular wallets whitelisted. They can't assume that any other invokers exist, since most users won't be able to AUTH them. It won't make sense for dapps to support improvements that only a less-popular wallet has. Therefore only the most popular ones will get to add invoker functionalities. Others will be able to implement invokers but they'll be largely ignored. It would be wrong to blame any wallet for causing this, but 3074 will naturally give popular wallets control over innovation. ### Censorship resistance & inclusion lists Ethereum is cheaper to censor than people realize, due to how block building works right now. The remedy was supposed to be inclusion lists. Censorship resistance is one of our core values. This makes inclusion lists one of the most urgent Ethereum upgrades, far more urgent than account abstraction or 3074. 3074 is incompatible with inclusion lists, and caused [EIP-7547: Inclusion lists](https://eips.ethereum.org/EIPS/eip-7547) to get excluded from the next fork. This was the biggest disappointment for me - that core devs would prioritize 3074 over censorship resistance. It's true that inclusion lists in their current form are incompatible with both AA and 3074, but they'd work well for EOAs which are currently the core of the network. IMHO we should have included EIP-7547 to provide EOA censorship resistance in pectra, and then continue iterating on a solution that would work with 3074 and AA. ## User security I won't elaborate about the problems with the 3074 security model - I [wrote](https://ethereum-magicians.org/t/a-case-for-a-simpler-alternative-to-eip-3074/6493) about [it](https://discord.com/channels/595666850260713488/718596092828057631/1209174029898879056) many [times](https://t.me/c/1863441549/20896). The TL;DR is that it violates security principles like the principle of least privileges (giving invokers unlimited access in order to perform any operation), the principle of least astonishment (user signs an opaque auth, not knowing whether it can be used once or multiple times, and not being able to simulate it to understand the full effect). Ethereum's account model is complex for users and thus introduces security risks. We need to improve it, not to weaken it. After 3074 inclusion I expect we'll see more rugpulls, replay attacks, wallets drained. I hope to be proven wrong here as well. ## Gets us farther away from account abstraction ### Not a part of a coherent AA roadmap 3074 doesn’t solve AA. It does not support use cases such as social recovery of a compromised account, key rotation, M-of-N multisig, switching to quantum resistant signatures, spending limits and timelocks, etc, which have been the core motivators for AA since 2016 (see, eg. the example use cases in EIP 86 here (https://github.com/ethereum/EIPs/issues/86)). Quantum computers, by conservative estimates, are expected to become operational in 10-20 years; a major goal of the AA roadmap is to de-enshrine ECDSA, and make quantum-safe accounts "first class". EIP 3074 goes the other direction, enshrining an inherently non-quantum-safe opcode. This would be fine if it were part of a coherent pathway, where we get functionality like batching and sponsorship now, in a way that is nicely forward-compatible with a fuller version that would cover these use cases later. But 3074 does not; it starts a parallel track where both protocol code and ecosystem infrastructure for 3074 are completely separate from what is being built for full account abstraction. This also has political risk, because it creates or reinforces constituencies that are invested in two different technical directions. This may delay the path to full AA. ### Technical debt 3074 will create a technical debt we may never be able to pay. The AUTH and AUTHCALL opcodes would have to stick around in the EVM, despite eventually becoming superfluous due to contract wallets; this adds a permanent complexity increase to developing and maintaining EVM implementations. The invariants around how calling into accounts work will permanently change. Instead of having one way to do things like batching or gas abstraction, wallets will have to maintain two parallel methods. ## A possible alternative path Based on feedback we've collected on RIP-7560 (native AA), we started thinking about ideas that would make the path more incremental. We've been working on rearchitecting the implementation [path toward full AA](https://notes.ethereum.org/@yoav/AA-roadmap-May-2024), in such a way that the first step is almost 3074 equivalent. RIP-7560 adds a new transaction type (4) which is equivalent to an ERC-4337 UserOp. It specifies things like `paymaster` to enable gas abstraction independently of the account, initcode for deploying the account in the first transaction, etc. We then realized that there's no reason to use TransactionType4 only for smart accounts. The same type could be used for things like incremental [EOA improvements](https://github.com/eth-infinitism/RIPs/pull/1/files). EOA support in TransactionType4 enables features similar to 3074 (e.g. gas abstraction, batching, delegation) and offers certain advantages over other EOA improvement proposals: - Consistent with the native AA roadmap. Wallets won't need to support two standards. - Enables EOAs to use the existing paymasters. - Requires less trust than EIP-3074 for most common use cases. Gas abstraction and batching don't require entrusting a contract with full account access. Therefore no whitelisting required. - No need for relays or specially-crafted 4337 invokers. EOAs will use the AA mempool. - Enables EOA migration to AA using paymasters (as opposed to [EIP-7377](https://eips.ethereum.org/EIPS/eip-7377)). E.g. migrate an account that has USDC without sending it ETH ahead of the migration. - Enables signature aggregation for EOAs (combined with the [aggregation RIP](https://github.com/eth-infinitism/RIPs/pull/2/files)), which could save significant amount of network fees for rollups. - Not introducing further technical debt that will slow us down when we move to quantum-resistant signatures. It's an early draft, but with community feedback this proposal could be further improved to support additional EOA flows. Taking this path will give EOA users similar benefits to 3074 as part of a broader roadmap and without introducing the technical debt of two parallel paths. Along with [other improvements](https://github.com/eth-infinitism/RIPs/pulls) it can ultimately get us to full AA.