As aforementioned, less than 10% of AA is 4377. But you are missing my point: gas abstraction does not define AA. 4337 proponents like yourself sure seem to think it is mandatory. It is not. You also prove the point I make that you object to as ad-hominem; you are trying to disqualify other more successful forms of AA in order to make 4337 seem more relevant. Indeed it’s so irrelevant that it’s losing to word of mouth non-standardized practices.
1 Like
It can abstract gas if you are willing to trust the invoker to access all of your assets. Invokers will be whitelisted with prejudice by wallets (rightly so) so this won’t be that useful to developers.
Like what? You said EIP 3074 isn’t AA and that 4337 is less than 10%. So what’s the other 90%? And why are you so angry?
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.
1 Like
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?
1 Like
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:
- It is not “really” a key rotation, since the private key is still the most important ruler here. If it is stolen, the user is screwed really bad.
- Still the extra gas for the bundler since it is an ERC, etc.
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.
1 Like
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.
1 Like
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?
- Key rotation - can a smart contract standard replace the EOA’s ECDSA key?
- Spending limits - can a smart contract standard prevent the use of the ECDSA key to drain the EOA?
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.
1 Like
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?).
3 Likes
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.
1 Like
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.
1 Like
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.
2 Likes
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.
1 Like
-
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.