ERC-4337 is an opt-in, no-consensus-change account model.
Yes, being an ERC implies some limitations but keeps a lot of flexibility (including full support on all existing blockchains, almost from day one)
The question is not how gas-inefficient it is, but how usable it is, and how it maps with the endgame account model we want Ethereum to have.
That’s all ERCs.
The most successful AA implementations are MEV bot contracts. The most successful ones are general-purpose. Check out their 1byte and 2byte ABIs. Compare their gas costs to 4337. They are innovating much faster but also much quieter than 4337. You should take some time to look into their code. You can learn a lot about how user accounts should be written.
Because 4337 proponents say ridiculous things like this the OP:
- Unnecessary: given that account abstraction (ERC 4337) is already on mainnet and we are on the way to having gas efficient native account abstraction in the protocol and standardized on all the rollups
Well, did you compare the scope of functionality and security guarantees provided? If they’re equivalent that would be great. Maybe there can be some cross pollination. I suspect it isn’t apples to apples, you can save a lot of gas by doing more stuff off chain in a way that relaxes security constraints and opens up various attacks vectors. My understanding is ERC 4337 is complex because it was designed by a team that spent a lot energy making sure they didn’t overlook attack vectors.
Why is that ridiculous? Because you think 4337 consumes too much gas? A couple of things 1) gas is less of a concern on rollups, where most account activity is expected to happen moving forward 2) The team is working on native account abstraction that will save gas costs, but this requires consensus changes, which take time to make.
Seems to be making a mountain out of a molehill, OP seems to not understand that EIP-3074 is the only pathway to native AA atm. Now, let’s talk about making consensus, quoting people from Twitter and Vitalik’s posts from 3 (!!) years ago is exactly not the way to go about it, in fact, it should be done based on the merits of EIP-3074 as intended to be put into the protocol today.
Having no in-protocol AA solution has been terrible for DX and UX alike, now is it great that ERC-4337 has got us half of the way? Sure - but it still doesn’t let us have a native way for delegating access to a contract, which is exactly what EIP-3074 provides - that is the crucial point that OP seems to be missing. And if we’re really taking an all-encompassing view, let’s not forget that there is a myriad of centralized apps and chains, and EIPs such as EIP-712 that have obvious footguns but we don’t go at them with pitchforks in the air because it’s effective at what its purpose is, so this entire post, especially combining with those screenshots screams to be a logical fallacy.
Let’s split this claim to two parts:
EIP-3074 being a pathway to native AA
Care to point out how 3074 takes us to native AA? One that is actually AA, including validation? How does it enable basic AA features like key rotation, spending-limit enforcement, and in general making the account’s validation logic, well… arbitrary?
EIP-3074 being the only pathway to native AA
You mean because the geth team will veto anything based on RIP-7560 which actually aims to provide full native AA?
I am not a big fan of this EIP per se (I agree that on its own it is a diversion from the endgoal), but it seems that it would enable cheap migration into EIP4337 for EOA users: an EOA user can grant its EIP4337 “side-account” full access to his funds. Not sure whether this option has been explored yet, but it allows the users to interact within the realm of account abstraction, without having to think about migrating their funds. This is a bad version of EIP-5003, just in case it wont get accepted 
The drawbacks of this approach are obvious:
However, if this approach is pushed forward enough, it can open much wider doors towards migration to EIP4337 and to RIP-7560 which is very similar to it in the future. I am not aware on the internal discussions with the geth team, but probably it is a big feature for them, and the main reason why it can not be implemented is because cost / risk ratio is bad (where “risk” are the chances that it won’t get used). Having a gradual approach where EOAs partially migrate to EIP4337 accounts can give more time for wider adoption of the complete AA standards.
You mean because the geth team will veto anything based on RIP-7560 which actually aims to provide full native AA?
Would prefer if you didn’t put words into my mouth, or assume some intent (where none) of core devs, the core question to answer here would be how much enshrinement we want at the protocol level. This is where EIP-3074 strikes a very good balance, where protocol changes are simple, implementable and do not carry forward to an unmanageable situation. I’m not against full native AA, or for that matter, RIP-7560, I just think this is a good measure towards forward-compatible native AA, and superior to the current alternatives like ERC-4337.
How does it enable basic AA features like key rotation, spending-limit enforcement, and in general making the account’s validation logic, well… arbitrary?
Why should Ethereum as a protocol care about some of these factors yet? Isn’t it better to have EIP-3074 in conjunction with a smart contract standard (TBD) that handles it, seems simple enough to do through social coordination, and also to clarify, I’m not against future EIPs that do choose to enshrine some of those factors, where I do definitely disagree is that we need a fully-featured native AA (in particular, spending enforcements and the likes) on the protocol level, if anything, we should have the ideal amount of enhancement on top of EIP-3074 that gets us some of the way towards a RIP like RIP-7560.
I wasn’t putting words in your mouth, nor assuming a nonexistent intent. The intent has been demonstrated on multiple occasions (specifically re RIP-7560). But it has nothing to do with 3074 so I’ll leave it at that.
Can you briefly describe the roadmap that starts with 3074 and ends with full native AA? I find it hard to see a clear path there. 3074 significantly improves EOA but it remains an EOA with all its limitations. Full native AA means that smart accounts are a 1st class citizen and do not depend on an EOA, and further empowering EOA doesn’t seem like a step in that direction.
“superior” indicates that they try to solve the same problem, and one does it better than the other. I addressed that misconception in ERC-4337 vs EIP-3074: False dichotomy - HackMD
ERC-4337 aims to be a first step in the direction of full AA (where the entire account is abstracted from the protocol, including validation). EIP-3074 aims to improve EOA. They are not comparable.
The protocol shouldn’t care about any specific feature. It should abstract the account and let users build whatever they want on top of that.
It can’t. No smart contract can cause the ECDSA key to stop working. And if you kill the key by using EIP-5003, you end up with a smart contract account like Ethereum had from day 1 - which is a 2nd class citizen that cannot send a transaction and needs the help of another EOA.
In the two examples I gave, how can a smart contract standard work?
That’s a feature implemented by users, not by the protocol. That’s the whole point. We need to abstract the account and let users build features. ERC-4337 and RIP-7560 don’t add any built-in features to accounts. Not even things like batching. Instead they abstract everything and let the user build the account. (It does add gas abstraction outside the account, because that’s a protocol feature rather than account feature).
What does this enhancement look like? Can it look significantly different from RIP-7560 and still fully abstract the account, make it a 1st class citizen (can send transactions), without giving up the permissionless mempool required for censorship resistance (or expose the network to DoS by ignoring the transaction invalidation problem)?
I suspect that an attempt to extend 3074 towards full AA will end up quite similar to 7560 (if not outright using 4337). Otherwise it’ll give up on important properties such as censorship resistance.
See Can EIP-3074 and ERC-4337 be used together? - HackMD
There isn’t one. Only what you heard on RollCall and a couple of similar public conversations. Currently RIP-7560 is being implemented on a geth fork, and the reth team is also looking into implementing it there. The implementation is probably quite similar to what you did at zksync - the distance between that and 7560 is not big, and is getting smaller as we split 7560 and make some parts optional.
I agree - see my post above. It can certainly help with the adoption of 4337 by making it free to experiment, and even free to deploy a non-EOA smart account. From that perspective 3074 will push 4337 forward, but I’m concerned about other implications of 3074 that still make it a step in the wrong direction.
A few (very distant) observations (building on the theme here in terms of security and paths to endgame):
Ethereum’s executing a rollup centric roadmap that prioritizes moving end users to L2 and architecting L1 to best support this transition.
A key value prop of rollups is that they’re not constrained by innovations on L1. We’re seeing this trend strength with the addition of RollCall and the RIP process and we expect to see innovation on L2+ outpace iteration on L1.
Given that, and given that there’s consensus that the best canonical endstate is native AA, it seems like it’s worth at least considering what is the best shot to sprint to native AA (and separately EOA migration) on L2.
I think 3074 is useful, but way more so on L1 where the cost benefits and legacy community are both substantial, than L2 where it feels more like a compromise/afterthought versus the best architecture in a vacuum.
Points (1) and (4) seem potentially a bit incongruent where Ethereum itself is focusing on supporting end user adoption of rollups but the EIP process in this case prioritizes existing users on Ethereum. This is not necessarily a bad thing, but to some of the points above, I wish there had been a broader discussion on priorities, tradeoffs, and target endgames before an inclusion announcement.
Net its not necessarily a bad outcome wrt to 3074 (there are some noted synergies, still thinking about how this should fit in to the evolution of user accounts on rollups in the long term) but something that might be worth flagging as EIPs and RIPs continue to evolve separately with perhaps different focuses.
High level, I think this EIP doesn’t support the core L1 roadmap and signifies a lack of alignment on what L1 Ethereum is trying to compete on. I think the ecosystem-wide answer is, at least currently, as a settlement (I understand there’s some nuance with that term) layer, and with 4844 and the move to full danksharding, a DA layer for rollups. My interpretation of “rollup centric” is that we shouldn’t be optimizing for e.g. user swaps on L1. The customers of L1s are rollups and the featureset of L1 should prioritize exclusively that. None of the features mentioned in the “ideal endstate” really optimize for end user activity at scale. My main concern is because Ethereum is trying to compete on everything, it will end up not doing any one thing as well. This might be controversial, but at this point I think L1 Ethereum should actually actively dissuade end user onboarding and actively promote user activity migration to rolllups. The amount of complexity and dependencies being baked into the system is high and split brain between rollup optimization and user optimization won’t help that out (https://www.hyrumslaw.com/). Trying to compete for end users on L1 misses the boat of building global scale permissionless byzantine resistant systems. Because of that, I actually think 3074 would have been a lot less controversial as an RIP, but candidly either way, it actually feels premature. There’s almost certainly a lot of throwaway work and a degree of settlement at a local maximum with no clear and viable path towards the desired endgame. Let certain more agile networks differentiate on that and have the market drive that demand (Polygon’s already working on an implementation, why not just see if it works as expected there first?).
This makes sense and would probably give EIP 3074 campaigners pause if it was really about user onboarding and UX on L1.
I’ve argued elsewhere there’s a simpler explanation for why none of these arguments seem to land: that EIP 3074 is an example of a special interest protocol lobbying effort designed to benefit Consensys/Metamask.
EIP 3074 was shot down in 2021. It only regained traction after Matt the author moved from Consensys into the Geth team and started leveraging Geth’s position as the majority execution client to social engineer support from the other “core devs”. Other execution client devs don’t want an adversarial relationship with Geth. Behind the scenes Matt discourages work on native AA, speaking on behalf of the Geth team saying they won’t support it. In public he laments how we’re not making progress on UX because “core devs” don’t care about users. It’s quite cynical.
They have cheap gas only because they are so under-utilized. You cannot count on gas being worthless because spam isn’t actually free, at least not for the execution layer.
Core devs know each other but they aren’t exactly friends and they don’t agree on priorities. Their common interest is in not wasting their own time.
It is easy to believe conspiracy theories about your opponents. Many Ethereum developers (including myself) are ex-Consensys because it was a huge company. This doesn’t mean they have a huge interest in advancing Consensys’ interests, even if they have stock. This is because Consensys is internally decentralized to the extent that there is little coordination or contact between projects. Consensys is simply too toxic and unfocused to have members of one team advancing another team’s interests, never mind spies infiltrating core development. lightclient is advancing 3074 because he believes it is good, not because he is a puppet for his former employer.
I agree. So does working on things Matt says Geth won’t support count as wasting their time?
That could prove why an EIP was not included, but not why an EIP was included.
Have you seen @MrSilly’s comments on the Protecting the EIP process from special interests + examples & case study thread? William’s comment–if it’s actually ad hominem–pales in comparison to what you see there. And that’s not counting the number of tweets I’ve seen suggesting EIP-3074’s authors are mercenaries operating on behalf of a wealthy overlord.
I get that ERC-4337 infrastructure providers are uncertain about what EIP-3074 means for their business model and operations going forward. That’s a legitimate concern. But it’s disingenuous to have that much reactionary comments on the proposal from various people–many of whom are trying to paint EIP-3074 as 100% bad because it doesn’t necessarily align with ERC-4337.
As someone who’s worked at Consensys, I can confirm most (if not all) of the statements here. I think people on the outside look at Consensys and see a huge, monolithic megacorp operating like some sentient entity and moving chess pieces all over the board. But it’s far from the truth–you only need to see how many teams are there to understand how difficult it is coordinate the collusion @MrSilly is describing. (Pretty sure I met less than 10% of the company’s employees at the time I left.)
A decent number of people have the same notion of the EF, too. If you don’t see the EF as a loosely organized group of individuals, and perceive it as some centralized organization instead, then it makes sense to say the EF is coordinating to interfere with the EIP process (as some have indeed said in the past)…even if that’s untrue.
Besides, people talk about Matt/Sam holding CSI stocks so much–even when former employees are filing lawsuits to make sure their equity retains its value. Not sure what to make of that information–but I think it can at least (rightfully) dilute the strong assumption that the promise of equity is enough to get core developers to play secret agents.
Isn’t it easier to herd everyone to the door you want when you’ve locked the others?
You think other client devs want the majority client on their bad side?
If the majority client can in practice veto EIPs by refusing to implement them, anyone that hopes to one day get an EIP included better be very careful about displeasing them. That’s a lot of power to trust to a tiny group of devs. They’ve earned our respect as client developers, not as Ethereum’s governance overlords. Maybe we shouldn’t argue with them too much on client optimisations, but as soon as they start throwing their weight around with contentious changes to security models and the UX roadmap I believe we have reasons to be very worried.
That’s the beauty of incentives, people can coordinate themselves around them. You don’t need to believe in some massive conspiracy to take the influence of financial incentives seriously. What I’ve heard from my ex-Consensys friends is almost everyone that worked for the company was underpaid and the company relied strongly on equity to retain them. The promise was that something would work and you’d get exposure to it. Unfortunately Consensys failed at almost everything. The only success stories were Metamask and to a lesser degree Infura.
If you also left Consensys with equity, you stand to gain financially from Metamask’s success, as do all the other current and former Consensus employees with equity. I wish I could find someone to explain to me what is so great about EIP 3074 who doesn’t have that conflict of interest. It should be possible to find someone like that, but so far if there is one consistent feature of all the EIP 3074 supporters / apologists I’ve seen so far is that they have upside in Metamask.
Look, your conflicts of interests shouldn’t prevent all of you from proposing improvements or participating in the discussion, but to the protect the integrity of Ethereum and credible neutrality of the governance process you should at least avoid abstain from voting on it in ACD. I doubt the money is worth your reputations. You think I’m the only person who is concerned? Most people just prefer to stay away from the drama. It’s unpleasant. You risk making enemies for life. Not getting that next job. You’d rather just be working on a research problem or code, hoping someone else sorts it out. I was one of them.
While there are plenty of effective counter-arguments to MrSilly’s points, I don’t believe this is one of them.
While it’s true that Consensys may have been unable to internally coordinate their teams in the past (or present), it’s illogical to trust that a corporation won’t attempt to align their internal teams to maximize their profit in the future.
It’s particularly illogical to use the “Don’t worry, Consensys teams don’t coordinate.” argument to counter arguments that are specifically focused on the power that Consensys could acquire if they actually coordinated. “Consensys didn’t coordinate well in the past.” is not a rebuttal to “If Consensys coordinated, they would have a monopoly around ‘X’.”
It’s also just not true. Metamask’s default RPC is Infura. SMG (a newly acquired Consensys company) is helping with OFAs that involve both.
Instead, effective rebuttals should focus on:
And let’s be clear - Consensys isn’t the only company that warrants a microscope. There are multiple companies whose relationship with the authors is relevant context for any EIP that directly impacts their operations:
Note that I’m not saying that EIPs should be rejected if they’re proposed by companies that can benefit from them.
I am saying that the employment / interests of the authors adds important context to the EIP, and that this context warrants special consideration.
As an outsider, I’m also very concerned by the tribalism that’s manifesting here. Pointing out conflicts of interest is a good thing that is necessary for a transparent and fair governance. The demonization of those who voice their concerns - regardless of whether or not those concerns are valid - is a strong disincentive for others to speak out. I personally have had multiple people message me their support but who are afraid to say anything publicly, largely because they directly interact with or depend on Consensys in one form or another.
I understand that many of you have known each other for the better part of a decade and have spent time working together at the EF, Consensys, or other companies that have existed since the start of Ethereum. Many of you are “Ethereum OGs” and you’ve developed trust for each other over a long period of time. Many of you have loud, respected voices that assist in propagating your views and your trust assumptions. But trust assumptions shouldn’t be propagated - just because you trust your friend doesn’t mean that everyone should, which is why I implore you to avoid the instinct to “close ranks.” I implore you to avoid treating those concerned about the actions of your trusted friends as hostile, even when the concerned individual’s views are entirely unfounded.
Currently, voicing concern about a Consensys monopoly is political suicide. The concerned individual is painted as a hostile conspiracy theorist by several prominent names in the Ethereum community. This fundamentally undermines the whistleblower’s ability to build the relationships needed to succeed in DeFi.
We must fix this. The current environment, where people are afraid to voice their concerns about powerful companies, is not sustainable or desirable. From the outside looking in, it definitely isn’t congruent with what I thought Ethereum’s values were.
It’s actually worse because even participating in that discussion is too scary for most community members. Most just want to keep their heads down and stay out of “the drama”. Wish I realized how true this was when I originally on protecting the EIP process from special interests. In retrospect, it may have been more productive to post separately regarding the specific concerns around EIP 3074 being promoted by those who had conflicts of interests. That way community members that believe we should make improvements to the EIP process could talk about that without worrying too much they’re making powerful enemies.
This is very true. I took a break from posting on EM after account abstraction devs reached out to me and asked me to stop criticizing EIP 3074 or the underhanded methods used to campaign for it. Why would they ask me to shut up? Because they’re afraid some powerful “core devs” will hold them guilty by association. “The core devs are the governance team. We are secondary”
I took a break for a couple weeks, but with all due respect to the account abstraction team, I believe the problems with ACD & governance are upstream of the specific dispute around account abstraction and are possibly more consequential. Better to hack at the root than hack at the leaves.
So at the risk of pissing everyone off even more I felt like I had to explain why I strongly disagree with this common misconception that client devs are “the governance team” or that it is a good idea for them to have any special powers to settle disputes: