# A note on EIP-3074 Given the recent resurgence of interest in EIP-3074, I wanted to take a moment to highlight some of the important aspects of the EIP and how I imagine it will be adopted into the day-to-day usage of Ethereum users. ![image](https://hackmd.io/_uploads/HyxsD2nHa.png) ### The same, but different EIP-3074 is usually framed as an alternative to [ERC-4337](https://eips.ethereum.org/EIPS/eip-4337). That [isn't exactly](https://x.com/adietrichs/status/1731398490230554886?s=20) true. In the case of EIP-3074, the main goal is to delegate control of your EOA to a smart contract. It quacks like Account Abstraction because it supercharges EOAs with smart contract wallet functionality, but at the end of the day, it is still an EOA. Stolen key means total loss ([although there are some mitigations for lost keys](https://x.com/lightclients/status/1420437798226735106?s=20)). EIP-3074 makes no consideration for transaction sponsoring / relaying, which is the meat of ERC-4337. The idea being developers will build systems on top of EIP-3074 which solve this. It turns out ERC-4337 actually is that system, and the team has painstakingly addressed every edge case to deliver a robust user op relaying system that is safe for users and bundlers alike. So the framing of EIP-3074 vs. ERC-4337 glosses over the minutia of the two proposals. EIP-3074 allows EOAs to be used _within_ ERC-4337 and sets the stage for future EIPs, like EIP-5003, which will allow EOAs to permanently upgrade to smart contract wallets. ### A new way of writing wallets One complaint from the ERC-4337 camp is that EIP-3074 will fragment a community which has been notoriously difficult to herd already, causing the momentum built around ERC-4337 to wane. There is certainly some truth to the complaint, but I think the concern is overblown. The immediate point is that EIP-3074 makes EOAs compatible with ERC-4337. Eventually we want everyone on smart contract wallets. But many users today do not have them and migrating is annoying. Giving EOAs the ability to behave like a smart contract wallet w/o the manual migration will bring all users forward in terms of UX of the chain. If EIP-3074 does usher in [a new way](https://ethereum-magicians.org/t/validation-focused-smart-contract-wallets/6603) of writing wallet, [who](https://x.com/adietrichs/status/1731401385898320127?s=20) is to say it's the wrong way? `AUTH` and `AUTHCALL` are extremely powerful tools in developer toolboxes. Let them eat cake! ### The future is multi-chain (they say) As we move into a world were there are many EVM chains users are interacting with, it becomes more important for there to be some consistency across chains. Overtime people become comfortable with their address. It is a reassuring sight in a sea of confusing hexadecimal strings. Although it's possible in theory for ERC-4337 to be supported on every chain, you need 1) the entry point contract deployed on The Chain Of The Week™ 2) a universal `create2` deployer (maybe same as 1) and 3) the bundling infra deployed in order to utilize your familiar account on another chain. Definitely a lot of work to get the ecosystem up and running, whereas all the chains just support EOAs out of the box. ### Snowbirds The merits of EIP-3074 are certainly debatable, however one point that most parties agree on is the need for [migration](https://en.wikipedia.org/wiki/Snowbird_(person)). There are millions of active EOAs on Ethereum mainnet alone. Without some protocol-assisted migration mechanism, the transition will be slow and painful for users. There have been several proposals over the years on how to reach such an end state. The best post on this is probably Sam's piece on the [future of accounts](https://ethresear.ch/t/a-brief-note-on-the-future-of-accounts/12395). Without rehashing every proposal here, EIP-5003 seems to be a clear winner over the others. The strongest point in its favor is that EOAs can have their migration sponsored and bundled, whereas many others require the user to actually have ether. ### Back to the Future There are a handful of future considerations that might be important to note: * The biggest weakness of EIP-3074 currently is its inability to spend ether from the authorized account. This is due to [an invariant](https://eips.ethereum.org/EIPS/eip-3074#source-of-value) in the protocol which allows block builders to statically determine the validity of txs. Removing this restriction would unlock a ton of desired functionality. It also seems reasonable to do so with a bump in gas cost for `AUTHCALL` when `valueExt` is non-zero. It's something we'll need to discuss with ACD though. * Moving beyond secp256k1 signatures is possible using the validation-focused wallet design mentioned above. Although this is not really relevant for the initial iteration of the EIP, it is something to consider if EIP-3074 centric tx relaying systems take off as it further simplifies the design of such systems. * To bundle 5003 or not. As EOA migration is one of the most highly desired protocol changes which EIP-3074 sets the path for, it is a question as to whether `AUTHUSURP` should simply be included in EIP-3074 (or 5003 be tightly coupled). My feeling is the status quo is appropriate: let it be an optional add-on to 3074 and allow the core teams to decide. It would be great to see it live alongside 3074 and I don't see fundamental blockers, but I do want to be cautious and avoid overwhelming core teams and testers. It may simply better to send it in a future fork. ### The time is now Developers have wanted EIP-3074 since around [2020](https://x.com/schin_tomar/status/1372655000954966017?s=20). Three years later, they're still asking. There is clearly some merit in the feature, and in regret-minimization terms, including EIP-3074 seems low. It is unequivocally useful today and may set the scene for innovations in the future, be that new wallet designs or simply EOA migration. As the discussions around the Prague upgrade start up in the coming months, the greatest ask I have is to share your support in the [network upgrade thread](https://ethereum-magicians.org/t/prague-electra-network-upgrade-meta-thread/16809/20) and on the [ACD agendas](https://github.com/ethereum/pm/issues). We're also investigating the possibility of deploying to L2s in the meantime, so similarly to the ACD agenda, showing support on the RollCall will go a long way. And of course, in true crypto governance fashion, we must continue the memetic warfare on twitter.
Last changed by  
 
matt
4909

Read more

Light client session

What is a light client?

10/11/2023
KademliaCon

What: a conference about p2p, focused on DHTs, discovery, and gossip. When: Thu, Aug 31, right after SBC; 10am-5pm. Where: Fischer Conference Center @ Arrillaga Alumni Center, Stanford. Why: to improve the performance and security of permissionless protocols Brought to you by: Ethereum Foundation and volunteers. The recordings for 2022 can be found here. Registration The conference is currently full. Thank you for all your applications!

8/30/2023
Account Abstraction Link Tree

This is an rough outline of the major contributions to the topic of Account Abstraction over the years. Of course, it is not exhuastive and varies a bit on the exact domains of Account Abstraction (protocol, ERC, wallets, etc) that it touches. I hope you will find it useful. 2022 EIP-5003: Insert Code into EOAs with AUTHUSURP (Q) EIP-5792: Wallet Abstract Transaction Send API (M) A brief note on the future of accounts (Q) 2021

11/20/2022
Summer Projects

JSON-RPC Specification There are several opportunities to contribute to the JSON-RPC specification. A few examples are: Automated testing Mostly writing go to integrate into Hive. See the example JSON-RPC tests here. The idea is to intercept both the requests and responses and validate them against the spec schema. Improve documentation tooling There is a frontend for the documentation written in typescript that could use improvements. The code for that UI is here. It's using the React framework which is super popular and would be a great thing to learn if you want to do more frontend engineering. Improve documentation

2/1/2022
Read more from matt
Published on HackMD