EIP 3074’s all or nothing, trust-maximizing security model pulls towards permissioned innovation because it requires a tremendous amount of trust capital to play. Permissioned innovation is the consequence we should expect, because in practice, devs outside a very limited set of players won’t be able to use this. It’s great for Metamask’s ability to innovate, not so great for dapp devs. Should we pretend the protocol exists in a vacuum? You yourself are now advocating whitelisting invokers, losing some vocal supporters in the process. I agree that nothing else makes sense. If whitelisting isn’t the standard best practice straight out the gate it soon will be after an onslaught of scams. Trust minimized security models (eg 4337 paymasters) level the playing field for a much wider range of devs.
I don’t think anyone is seriously advocating implementing complex accounting features in the protocol. 4337 already works without ANY protocol changes. Having some protocol changes will help in the future with efficiency, but even without them full 4337 style account abstraction is already more powerful than EIP 3074 EOAs. What is more relevant is that enshrining EOAs will likely delay Ethereum’s full account abstraction roadmap by creating a less powerful half measure. This will reduce the sense of urgency in developing account abstraction. We’re more likely to get stuck on a local maxima.
Apologies if I am misunderstanding you, but you seriously suggesting that the environment in which the EVM operates is less adversarial than Linux’s? Every bit code on the EVM is transparent. All of its attack surface, every method is immediately exposed. No firewalls. If you exploit it, there’s money at stake. Sudo on Unix systems gave us an endless parade of security headaches even when Unix was still running inside friendly academic networks. As soon as the environment got more adversarial we had to throw it out “all or nothing” as a reasonable security design and replace it with capabilities and mandatory access control mechanisms like RBAC. If sudo isn’t good enough for a Linux server on the Internet, how can it be good enough for EVM account security?
It is much safer to rely on a good trust-minimized security design than rely on a vaporware ecosystem of formally verified contracts. If formal verification were so easy, all the major on-chains contracts would be formally verified. That doesn’t seem to be the case. Besides, formal verification is no panacea. Even if you formally verify the implementation, there’s no way to formally verify the spec for the formal verification process. In practice, EIP 3074’s trust maximized model is going to get us a very limited set of very powerful, non formally verified invokers that support features as as intents.
Wouldn’t you expect the implications of handing over your private key to be much more commonly understood than the implications of authorizing an EIP 3074 invoker? If you agree that’s true, how long until we reach parity? What happens in the meantime?
As someone deeply invested in the vision of Ethereum’s smart contract wallet, advocating 4337, I’m not entirely sure about my stance on the long-awaited 3074 change. It’s not because 3074 is a bad development, but rather because of the differences between the state of its proposal vs where we are at today.
I believe there are some fundamental questions we need to address regarding 3074 to further discuss the implementation:
Is 3074 being implemented to expedite and streamline the transition to 4337? If so, do we have an updated roadmap on this matter? What roadmap exists for EOA wallets implementing AUTHCALL to evolve into fully smart contract wallets?
Is 3074 being accepted to ensure that EOA wallets don’t fall behind in features and user experience compared to smart contract wallets emerging with 4337?
Within this framework, I think it’s essential for all parties to discuss 3074 more openly.
I would expect a wallet developer looking to add support for EIP-3074 will understand the implications. I would not expect an end-user to understand the implication.
I really agreed with your post up until this point. It’s true that dapps want simple compatibility with all wallets, but if EOAs can suddenly add the same interfaces that SCAs can add, then it provides a platform for all wallets/dapps to align around interfaces that can be generalized across both account types. If we can agree on those interfaces (and I think we should be able to agree this interface is not exposing the AUTH opcode directly to dapps), then 3074 creates a path for dapp devs to more easily support all wallets.
This unseats the EOA interface as the “maximum supportable interface” for dapps to rely on, and opens the space for SCAs to participate competitively.
I completely agree that we would be better off with an object-capability security model, like Google’s Fuchsia. The question: How do we migrate there? By adding 3074, we create developer-space for iterating on what a better security model would look like. Yes, it’s a hot wire, but it’s not one intended to be exposed to every site. Instead, it enables iterating on better/safer interfaces.
I’ve been working on one proposal (sure to be replaced by a better one) for a better and more secure interface that 3074 would allow both EOAs and SCAs to expose. It’s an interface that can be agnostic to implementation but also opinionated enough that it provides more coherent guarantees during site connection.
This makes the assumption that any generalized interface is insecure. I think we can agree that exposing AUTH directly to strangers is insecure, but by allowing open-ended community development around wallet-dapp interfaces, we will be able to explore exactly how secure an interface can be made. Can it be fully general? We’ll be able to ask that, and wallets will be free to permissionlessly explore that design space in a standards-driven way.
Without 3074, the mere existence of EOAs will continue to ensure that dapps build for them first (as to not exclude anyone). 3074 is a path to building better interaction patterns.
Can you elaborate on what you mean by this? I’m trying very hard not to straw man you here but I’m interpreting it to mean that not only will your company maintain a white list of which contracts can use AUTH but you’ll also maintain a white list of which dapps can access the white listed invoker contracts. I can’t think of another pattern in which you have a white listed general invoker that not all dapps have access to.
I am saying that invokers enable design of new interaction patterns. I’m not suggesting and have no plans of creating a list of what dapps can connect to wallets, and I don’t know how you got there. A sample elaboration can be found in the permissions standard doc I linked to.
Ah - apologies for the ambiguity of terminology. I believe the confusion is because when you say dapp you’re referring to the frontend, whereas when I say dapp I’m referring to the smart contract.
In my previous post, I described a useful app-contract-embedded invoker pattern:
A lending protocol similar to AAVE, but with a ‘hook’ that executes prior to the liquidation of a borrower’s collateral. The hook would use 3074 to deposit more of the user’s collateral tokens into the lending protocol to avoid the liquidation.
But, as mentioned above, if this app’s smart contract handled the AUTHCALL via a generalized invoker it would look malicious:
That lead me to conclude that a sufficiently generalized invoker is insecure, as using it would be indistinguishable from an attack.
You disagreed:
So my interpretation of your comments came from:
Strangers can use a generalized invoker to do anything that they could do with an app-specific invoker.
You do think a generalized invoker can be secure
You don’t want to expose AUTH directly to strangers
Ergo, you plan to limit which app’s smart contracts can integrate with your generalized invoker
If that interpretation is incorrect, can you help me reconcile why that’s the case? It would help me understand more clearly if you used the specific app/invoker pattern I’ve described here - examples always help add context and clear up ambiguous terminology.
I think the core of this discontinuity is here. I do think so, or maybe I hope so, but I haven’t seen proof that this is true for all people yet. So I build with the goal of allowing us to build out that security, even if we don’t have it yet, in a way that allows staying safe along the way.
As I said to you before, I eagerly welcome any pattern that would make any permission granted safe, but until then, starting from “no invoker”, and gradually expanding and improving the approval/integration process, I think we can make meaningful progress expanding from “cannot do any invoker things” quickly to “can do most desired invoker things”, and we can then gradually chip at “can do any invoker things”.
Like I said to you then, at MetaMask we are also building a wallet plugin system called Snaps, and we’ve been on a basically equivalent journey to make that system permissionless (should be no surprise, since 3074 is basically an onchain EOA plugin system). In fact, I personally intend to use the Snaps system to prototype invoker/sca interfaces that aren’t standards-ready because it’s the easiest way to do it, and any developer with a copy of MetaMask Flask can already do the same, and build their own invoker enabled wallet.
So today, the “developer edition” lets you do whatever, and the consumer edition doesn’t. It’s a pretty common pattern, but again, I’m eagerly searching for better/safer ways of verifying user consent, I’d love to dissolve the distinction and have one safe pattern.
OK I think I see the distinction. Your current plan is not for metamask to whitelist which apps can use a metamask generalized invoker, it’s for metamask to build an extremely limited invoker that all apps can use and then gradually expand that invoker’s feature set while maintaining the ‘all apps can use our invoker’ mindset. Is that correct?
As an “AA” practitioner, I’d like to share my perspective.
Firstly, if " full account abstraction" is the ultimate goal, then we should assess the EIP-3074 standard based on whether it contributes to achieving this goal:
Adoption of EIP-3074 would incentivize DApp developers to immediately start supporting features like batch transactions and gas sponsorship. (Minor benefit)
It would encourage EOA wallets to immediately support some features of contract wallets, allowing users to immediately benefit from partial account abstraction, thereby aiding the transition to full account abstraction. (Moderate benefit)
EIP-3074 may divert the community’s attention away from full account abstraction. (Moderate issue)
The scattered Invoker in EIP-3074 could potentially increase systemic security risks, requiring wallets to make corresponding security improvements. This may necessitate a series of ERCs to enhance security, such as standards for Invoker signatures and wallet interactions. (Severe issue)
Currently, there’s no smooth upgrade path from EIP-3074 to full account abstraction. (Severe issue)
Based on these points, while I do believe EIP-3074 may be exciting for current users, I hope we can discuss clearly how to progress towards the goal of full account abstraction before its implementation.
I agree that this holds true for certain AA features, such as batch transactions, where ERC- 5792 can now be applied and used on a dapp interface with any account. I agree as well for sponsored gas, where a dapp no longer presupposes that an account must have a balance of ETH to transact.
However, this isn’t true for the two examples I mentioned above. Support for EIP-1271 will continue to lack and the assumption that an account can exists on every network will continue exist.
So EIP-3074 can partially help, but at what cost?
When EIP-3074 was first introduced, there was no unified consensus on how we will reach full Account Abstraction. ERC-4337 hadn’t yet been introduced, and this proposal was aimed to enhance the user experience for EOAs in the short term as we figure out a good way for full AA. I tackles some important promises of account abstraction, without fully supporting it.
Fast forward to today, we’ve seen monumental shift in both the development of SCAs and the mindset of developers. We actually have hope for achieving full account abstraction. Wallets that already support EOAs can now offer full SCA functionality without requiring consensus changes, and with a clear path to native account abstraction for networks that opt to implement RIP-7560. Trust Wallet, for example, is already offering users full AA functionality.
So, the question arises: Is EIP-3074 worth the risk of initiating a parallel fragmentation among both users and developers? Are we willing to prolong the use of EOAs indefinitely with only execution abstraction? And perhaps most importantly, should we risk Ethereum’s goal of full account abstraction in exchange for short-term gains in current EOA functionality?
I can see this being a pretty simple improvement that alleviates some of the risks of inadvertent AUTH revocation that could weaken the reliability/“hardness” of commitments that are made using an AUTH message, like what @haydenadamsraised.
It sounds like it wouldn’t affect implementation complexity much since it reuses existing state, so I’d suspect if authors agree, that implementers would follow. For that reason, I’m supportive of this change.
I understand this will be raised on ACDs tomorrow, and welcome anyone to name me as a supporter.
It won’t initiate that fragmentation. The fragmentation already clearly exists, as you’ve documented very well.
If there is ever a design for fully converting EOAs to SCAs, I think we’d all support it! I think what we’re seeing with 3074 (and the minor tweaks that can be made on it to somewhat increase the hardness of the delegation) is that we will never be able to perfectly revoke the meaning of a secret number that someone knows out there. Someone else might honor it.
What I’m saying is: While I would never prolong the usage of EOAs, I am not certain that they can be made anything less than semi-immortal, and so I suggest we augment them as well as we can, while not holding back how well we augment the journey for new users.
I’ve seen this either-or/zero-sum argument again and again in the anti-3074 debate, but I haven’t seen any substance to these claims. Obviously everything has to be weighed beside other things, but 3074 is an incredibly simple change to implement, so I really don’t think it should be treated as blocked by titanically more complicated moon-shots.
I agree that could work out OK if we only have trustworthy invokers. In the real world shouldn’t we expect more grey area? Doesn’t the user need some mental representation of EIP 3074 to understand what a wallet is proposing? We have that problem even with the simpler EOA model. A family member of mine let a scammer create a wallet for them, not realising they’d be able to steal the funds deposited months later.
That seems like splitting hairs. If we generally agree fragmentation is bad, the question should be how to minimise it, not how much worse we can make it. Isn’t there a meaningful difference between fragmentation at the alternative implementation level and fragmentation of the whole stack?
We definitely should not assume everyone who writes invokers are trustworthy! The argument I’m making here is that the threat surface area of wallets doesn’t get worse with invokers. It is a primitive that, like any primitive, can be used for good or bad. Wallets already have 100% control over user funds, and them being able to authorize invokers means that they can enable features for their users that don’t currently exist and delegate a very controlled set of responsibilities to a contract. The act of enabling an invoker must be carefully controlled by wallets (the current defense for users against bad actors).
I obviously wasn’t suggesting we aim to make it worse, and in the post you quoted, suggested a way to remedy it via 3074. This looks like bad faith arguing to me.
Someone (but only one person) should create an issue on each of those repositories letting them know that those are each potentially critical security vulnerabilities. As long as the EVM continues to be mutable, there is no long term guarantee that msg.sender == tx.origin means first call frame.
Adoption of EIP-3074 would incentivize DApp developers to immediately start supporting features like batch transactions and gas sponsorship. (Minor benefit)
EIP-3074 may divert the community’s attention away from full account abstraction. (Moderate issue)