# Sam's Reply to [Implications of EIP-3074 inclusion](https://notes.ethereum.org/@yoav/3074-implications) ## Potential centralization vectors ### 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. Using 4337 without a relayer requires just as many signatures. Perhaps I'm missing the point of this argument? I don't speak for all the authors of 3074 in this, but I believe adding `nonce` to the signed message was a mistake for exactly this reason. > 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. Would every product trying to sponsor EOAs with 4337 have to write their own invoker, or would one be sufficient for most use cases? In other words, does the non-trivial work need to be repeated often, or can experts (like the 4337 team) do the hard work once and everyone benefit? > 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. This is already the case today, is it not? My hunch is that most transactions are submitted through Infura/Alchemy/etc. because those are the services EOA wallets use. Those services can already block access to contracts, and Ethereum's mitigation for that attack is spinning up your own node. All you need for 3074 to implement batching is a regular node and an on-chain contract. This is no worse than the above. ### Permissioned innovation > Due to lack of privilege separation, any use case requires granting full account access to the invoker. This is the same threat model as deploying a smart contract wallet. When you deploy a contract, it obviously begins with full privileges on the account. > E.g. if you want someone to sponsor your gas you need to give an invoker full account access. Here you imply that the "someone to sponsor your gas" is the same person who wrote the invoker. That is a bit of a dishonest implication (and I assume an unintentional one.) A user can authorize a well-vetted invoker contract, then use a completely untrusted relay and be confident that only the operations allowed by the invoker will be performed. You only need to trust the invoker, not the relay. > As a result of this security design, wallets will have to whitelist invokers and not let users choose. I would argue that this applies to smart contract wallets as well. I seriously doubt that the Safe user interface would let you replace the implementation with Coinbase Smart Wallet without a lot of friction. If I am wrong here, I'm happy to be corrected. > 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. I fear I am beginning to sound like a broken record, but this is already the case today. One example I'm familiar with because of my work with [WTF](https://wtf.allwallet.dev/): `eth_signTransaction`. [MetaMask doesn't support it](https://github.com/MetaMask/metamask-extension/issues/3475). Supporting an invoker contract is roughly analogous to supporting a `wallet_*` RPC method. Wallets can choose not to support an endpoint just as much as they can choose to not support an invoker. They have equally permissioned innovation. ### Censorship resistance & inclusion lists Unfortunately I am not up-to-date on inclusion lists. If 3074 has bumped censorship resistance from Prague, that's probably a mistake. However, if inclusion lists can and need to be re-worked to support 3074, then maybe the answer is delaying both. ## User Security > [EIP-3074] violates security principles like the principle of least privileges (giving invokers unlimited access in order to perform any operation) You always have to start from full privilege and drop privileges as you go. That's the case for smart contract wallets. EOAs, on the other hand, have *no way to drop privileges today*. The only way to delegate control of your account is to hand over your private key. There is no way to, for example, limit how much ether your delegate can transfer. EIP-3074 introduces privilege dropping for EOAs. EIP-3074 is _explicitly_ about enabling the principle of least privileges. Instead of having to give your delegate your private key, you can give them an authorization with limits defined in code. Yes, there are other ways to enable limited authorizations like specific transaction types, but using the EVM to express these limitations is arguably the most flexible and powerful. > 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. Unfortunately, I 100% agree. EIP-3074 will see users lose funds in more hacks. Wallet-specific invokers will end up being vulnerable. Some wallets might not implement whitelists, and users will sign authorizations to malicious invokers. There are likely many more application layer attacks that'll pop up because of EIP-3074. I don't believe that these are valid arguments to stop 3074. If we wanted to prevent application layer attacks, we wouldn't have built a turing complete application layer (or Ethereum as a whole)! We give developers extremely powerful tools because we believe in their ability to get things right eventually. The fear of bugs in applications cannot hold us back from innovating on the protocol. ## 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)). Neither does [EOF](https://eips.ethereum.org/EIPS/eip-3540), [triggerable withdrawals](https://eips.ethereum.org/EIPS/eip-7002), or [putting hashes in state](https://eips.ethereum.org/EIPS/eip-2935). Just because a feature isn't on the AA roadmap doesn't mean it isn't useful. > 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. `ecrecover` is just as quantum-unsafe, and has no mechanism for future compatibility. Whatever solution we implement for quantum cryptography, we can also apply to 3074. Besides, EIP-3074 is designed to be extended with more signature types. > 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. I'd argue the opposite, in fact. 3074 can be extended in such a way that EOAs and Smart Contracts can be treated the same way (perhaps with a special EOF section for auth validation.) If 3074 is extended in that way, it fully abstracts the differences between EOAs and SCW. ### 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. If EOAs are ever removed entirely, I don't see why `AUTH` and `AUTHCALL` couldn't be removed as well. If EOAs are not removed, then it isn't really technical debt. ## A possible alternative path > RIP-7560 adds a new transaction type [...] My major objection to transaction type based approaches is that the enshrine a single set of inputs, and a single algorithm for verification/execution. For example, EIP-3074 based batching can support arbitrary conditions, complex atomicity/fallback operations, etc.; and time-based EIP-3074 invokers could support "valid on weekdays between 9am and 5pm". You can't do that kind of arbitrary validation with just transaction types. You need the EVM.