EIP-3074: AUTH and AUTHCALL opcodes

[ankurdubey521]

@oren

How about nonceManagerAddress being able to be either an EOA or a smart contract, in both cases it checks the nonce of the account like today’s implementation. And when it’s a smart contract, it’ll use the CREATE opcode in order to increase its nonce

Yup, that is what we’re proposing above.

1. t can also be used by smart contracts as a “nonce oracle” - till now contracts did not have access to the nonce of accounts. Not sure what are the implications of this.

Isn’t this possible (for EOAs) with the current 3074 standard as well?

[oren]

Oh okay cool.

Kind of: it’s currently only possible to get an oracle for your own EOA’s nonce, and with this, you can use the oracle for any address.

[ankurdubey521]

Good point, didn’t consider the fact this allows you to verify the nonce of arbitrary contracts on-chain.
Although I’m unsure what the implications of this are.

[MrSilly]

@matt

If the invoker is well implemented, it’s just as safe as a transaction from a smart contract wallet.

Actually a lot of assumptions have to hold. The user also has to understand what it means to sign an EIP 3074 transaction. Wallets either don’t let you authorize any invoker not on their whitelist (e.g., Metamask will only let you use the Metamask invoker) or they open users to scams and poorly written invokers. Incidents are bound to happen so strict whitelists will be the standard and they’ll be justified as a sad but necessary trade off of permissionless innovation in favor of “security”. Developers having full control over the account allows them to do a bunch of interesting things like intents, but in practice only developers that work for a large wallet company like Metamask will be able to access that power.

The root problem is EIP 3074’s all or nothing security model. It’s the old sudo/setuid model, which produced an endless stream of security breaches on Unix. Modern systems have moved to a capability based design. EIP 3074 forces us to choose between restricting innovation to a handful of players and endless scamming.

EIP 3074 is just a bad idea on so many levels. The campaign’s modus operandi was bait and switch. Appeal to developer’s desire for EOA programmability and don’t mention the whitelisting that will be necessary. Appease the security experts by adding nonce and chainID, and then once it passes ACD you start campaigning to remove those “concessions”.

EIP 3074 would never have gotten this far on technical merit. The only reason we seem to be seriously considering it for inclusion now is the some of the people involved seem to be quite adept at using social engineering techniques to play backroom politics.

[matt]

@MrSilly

they’ll [wallet whitelists] be justified as a sad but necessary trade off of permissionless innovation in favor of “security”

I think we have very different definitions of permissionless. Anyone can create a wallet with whatever whitelist they want / no whitelist at all. If a wallet decides to gatekeep a feature, that is their choice. They could already do so today. The protocol has no concept of permissions. That is permissionless.

@MrSilly

The root problem is EIP 3074’s all or nothing security model.

This is an oversimplification of the security model. 3074 allows you develop arbitrary capabilities. When you sign to an invoker, you are signing only to a certain capability implemented by that invoker. The correctness of this can be determined by auditing the contract. This is far more powerful than implementing such features directly in the protocol.

It’s also the same type of security model as a smart contract wallet. When you’re executing in the context of the wallet, it has “sudo” capabilities. It is the implementation of the wallet which enforces the security model. In both cases, you can be certain of the safety by reviewing the code.

This isn’t Linux. There aren’t RCEs in smart contracts. We can formally verify an invoker and be certain it implements only the defined capability.

@MrSilly

EIP 3074 would never have gotten this far on technical merit. The only reason we seem to be seriously considering it for inclusion now is the some of the people involved seem to be quite adept at using social engineering techniques to play backroom politics.

ACD doesn’t accept EIPs w/o merit. And no EIP makes it without a champion. I have spent a lot of time discussing the EIP with many different members of the community, sometimes in non public discussions. Each has had the opportunity to decide the merit of the proposal themselves. Of course, many EOA wallets and their users are excited about the proposal because it finally breaks the monopoly of UX improvements held by smart contract wallets.

This isn’t social engineering. 3074 is extremely beneficial to a lot of Ethereum users and they voiced their support.

[MicahZoltu]

@MrSilly

Appease the security experts by adding nonce and chainID

The security experts are not the ones demanding nonce and chainID.

[MicahZoltu]

@SamWilsn

It might be more productive, @charles-cooper, to come up with something that’s mutually acceptable?

I don’t know if vyper has decorators, but annotating the function in some way to show that it can be called from within an auth might make me happy.

This snippet should compile fine:

@impersonates
def approve_erc20():
    extcall erc20.approve(...)

def sudo(...):
    with authorized(msg.sender, sig):
        approve_erc20()

While functions without the @impersonates decorator would generate an error if used inside an authorized block or function annotated with @impersonates.

This would need to be constrained to within a single EVM call frame. Otherwise you could call some third party contract and change its internal behavior by setting the authorized flag.

Being able to AUTH_STATIC_CALL would definitely be nice, it does feel like it is “missing”, though it could be added later in theory.

[shemnon]

@hritzdorf

For AUTH, why is the commit in the memory and not taken from the stack?

It’s not just the commit, it’s the entire signature to. The stack is limited to 256 bits. Taking the commit and signature from memory preserves design space so that AUTH could use different signature schemes (such as BLS) or more divergent mechanisms such as SNARKS or quantum safe lattice signatures. Given yParity is 1 or 0 the first byte can still easily be used to signal type.

[shemnon]

@MicahZoltu

The security experts are not the ones demanding nonce and chainID.

I didn’t ask for nonce, I demanded single-action-revocation. Nonce was the EIPs authors solution to that request. If you can hand over total control of your account with a single action, you should be able to revoke it with a single action too.

[xinbenlv]

@shemnon

I didn’t ask for nonce, I demanded single-action-revocation. Nonce was the EIPs authors solution to that request. If you can hand over total control of your account with a single action, you should be able to revoke it with a single action too.

Agreed

I also like to second the concern about introducing nonce and chainId. Introducing these values alone doesn’t guarantee protection of replay attack, while makes it hard to handle other situations such as more than one outstanding TX.

Editorial suggestion

Invoker is first introduced in this EIP and was not a common terminology prior. Can we give a definition of invoker at the first time when the word invoker appear? (Especially to clarify relationship with signer)

[matt]

@xinbenlv

Invoker is first introduced in this EIP and was not a common terminology prior. Can we give a definition of invoker at the first time when the word invoker appear? (Especially to clarify relationship with signer)

It’s defined immediately after it appears. Read the third bullet of this section. It’s discussed in even more detail later on.

[MicahZoltu]

@shemnon

If you can hand over total control of your account with a single action, you should be able to revoke it with a single action too.

You can already hand over total control of your account with a single action: Give your private key to someone. An invoker is strictly less bad than giving up your private key because the actions the invoker can take are constrained by its code, while a private key hand-over is truly unlimited.

[shemnon]

@MicahZoltu

You can already hand over total control of your account with a single action: Give your private key to someone.

In the normal course of operations for a wallet a dApp cannot cause the wallet to raise a prompt that will cause you to share your secret phrase. An AUTH request, however, will raise that dialog.

So unless the industry standard is going to be keep dApps from being able to raise these requests, then bury the UI three screens deep below a blurred out section with multiple warnings in bright red saying “don’t do this unless you really know what you are doing” then an only then can we equivocate sharing private keys to an eternal AUTH request. I don’t think that’s what MetaMask is planning, a whitelist is far from this.

[hritzdorf]

Thank you for your feedback. Sorry, What I meant was:

• commit on the stack
• signature in the memory

As I assume that the commit will stay 32 bytes for now and as the keccak output lands on the stack.

So overall:
Stack:

Slot	Value
top - 0	authority
top - 1	commit
top - 2	offset
top - 3	length

Memory:

• memory[offset : offset+1 ] - yParity
• memory[offset+1 : offset+33] - r
• memory[offset+33 : offset+65] - s

[shemnon]

Commit isn’t on the stack. I think it changed because of the concerns you are raising…

EIP-3074: AUTH and AUTHCALL opcodes

[MicahZoltu]

@shemnon

In the normal course of operations for a wallet a dApp cannot cause the wallet to raise a prompt that will cause you to share your secret phrase. An AUTH request, however, will raise that dialog.

This is absolutely not true. Wallets should not expose any RPC that allows an app to prompt a user to add an invoker, just as they should not expose any RPC that prompts a wallet to provide the dapp with the private key. If people believe the same as you, this may explain why there is so much backlash against this proposal.

To be explicitly clear, wallets MUST NOT allow dapps to prompt users to add arbitrary invokers.

Wallets MAY allow dapps to prompt the user to add an invoker that the wallet provider has explicitly whitelisted. Getting an invoker onto such a whitelist should involve massive amounts of independent auditing work, validation, testing, and possibly some amount of lindy.

Adding an invoker is a similar trust model as giving your private key to a new wallet provider. It is a bit safer, but not nearly safe enough that dapps should have any mechanism for prompting users to add arbitrary invokers.

[marc]

An essential aspect that deserves attention, yet doesn’t often get its weight, is the continuing mindset among developers on what constitutes an account on Ethereum. I will repeat a sentiment frequently echoed: “Smart contract wallets are regarded as second-class citizens on Ethereum”. An EVM developer typically perceives an account solely as an EOA, and when they do think of testing their application with more than one wallet, it’s often with another EOA. It’s not their fault; the protocol is designed in a way that still, and and continue to favors this perspective.

I will mention two oversights frequently disregarded by EVM dapp developers:

• Support for ERC-1271 or ERC-6492, which provide standard signature validation methods for contracts. Again, it’s not their fault. We should not expect developers to know every ERC to launch their dapp.

• Multichain dapps (pretty much every EVM dapp) often assume an account’s availability across every network, a presumption that does not hold true for smart contract wallets. The result: a SCW can’t create an initial connection with the dapp. More in details:

  Frequently, this results in dapps requiring a connection to a specific network (typically L1 by default), and then asking for a switch to an L2 after the initial wallet connection. While this issue can partly be attributed to initial design releases of walletconnect modals, it underscores the oversight of accommodating smart contract wallets even by well-intentioned companies such as WalletConnect.

Being incompatible with the dapp ecosystem effectively renders a Smart Contract Wallet obsolete on Ethereum.

The EVM is witnessing the departure of some of its most skilled wallet developers due to this very issue. Numerous teams launched smart contract wallets, only to discover their incompatibility and lack of support across the EVM’s array of dapps. One prominent example is Argent, which ultimately gave up on EVM, and transitioned to Cairo’s Starknet. Their reasoning: on Sarknet, every account is a SCW, aligning with the expectations of EVERY dapp over there.

With ERC-4337 and RIP-7560, SCWs have finally captured some, if not little, attention of dapp developers, who now consider testing their dapps with a wallet that is not an EOA. Just recently, Uniswap removed an unjustified warning that prevented smart wallets from interacting with their interface. Without the highlight that ERC-4337 gave to SCWs, this issue would never have been fixed. If a prominent company like Uniswap had this issue, imagine other dapps, particularly those with limited resources. Will they ever test their dapps with more than one wallet?

If our objective is to cater to future users with full AA, then pursuing EIP-3074 distracts both wallet and dapp developers from this goal. The underlying message conveyed here is that we will continue supporting EOAs enshrinement and development, and the adoption of smart accounts will continue to be optional.

EIP-3074 has garnered favorable responses from both EOA wallets and some SCW tooling providers, despite EIP-3074 only addressing execution abstraction alone. Why? Quite simply, for wallets, it already integrates seamlessly with the present dapp ecosystem, and that’s where the profit lies. For some SCW infra providers, it expands their market to the current userbase of EOA wallets with gas sponsorship relaying.

Achieving full account abstraction on Ethereum relies on our capacity to focus efforts, rather than splitting the already limited attention span within our ecosystem.

[matt]

@shemnon

In the normal course of operations for a wallet a dApp cannot cause the wallet to raise a prompt that will cause you to share your secret phrase. An AUTH request, however, will raise that dialog.

@MicahZoltu

Wallets should not expose any RPC that allows an app to prompt a user to add an invoker, just as they should not expose any RPC that prompts a wallet to provide the dapp with the private key.

This is really the key misunderstanding that people have with 3074. Just because it is permissible to do so doesn’t mean this is how it should be utilized.

It’s like saying we should have protocol nonces for smart accounts because “a dapp might ask you swap the implementation of your smart account for their specially extended one”. Yes, you could imagine a design where this is possible. It just doesn’t make sense though because it’s totally insecure.

[thogard]

To be crystal clear:

• I do not have a problem with metamask, specifically.
• I do have a problem with white lists maintained by large, private companies.
• I understand that the Ethereum codebase is permissionless.
• I understand that anyone can build a wallet and market their wallet to users.

But what I don’t understand is why people think “If you don’t like it, just make your own wallet company!” is a reasonable response to my concern as an app dev about not having feature-parity with the apps made by wallet companies. That approach might be viable for unicorns like Coinbase and Uniswap, but it isn’t for me.

3074 white lists are wallet-specific. The invoker contracts are chain specific. If I want to make a smart contract that uses AUTH or AUTHCALL on ten different chains with the ten largest wallets then I will need to go through one hundred wait lists and audits. Many of those white lists will be managed by wallet companies building their own applications, some of which may be competing with mine.

The debate seems to have missed one critically important fact: a white listed invoker that is generalized enough for the use cases of all apps would be so generalized that maintaining a white list would no longer serve a purpose, as any hostile app could fully drain the user via the generalized invoker.

An example:

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.

An app-specific version of this invoker would:

1. Ensure that AUTHCALL is only used during the liquidation.
2. Ensure that the AUTHCALL is only called explicitly by the lending protocol.
3. Only transfer the specific token that matches the user’s collateral token.
4. Only deposit up to a pre-approved amount set by the user when they opted into the hook.
5. Can continue ‘topping off’ multiple collateralized positions to protect the user from liquidations while keeping the user capital efficient.
6. Can be opted-out at any time.
7. Fully immutable, etc

Now if we set up this hook to access the 3074 op codes through a generalized invoker, this is what it would look like from the perspective of the generalized invoker:
(assume prices are crashing)

1. The invoker would be called by a contract (the invoker is not used as an entrypoint)
2. The contract would then transfer some of one of the user’s tokens to itself
3. It would then transfer some of another one of the user’s tokens to itself
4. And it would keep doing this until the user is fully drained.

The generalized invoker has no sense of the lending protocol. It doesn’t know that the user had deposited multiple different ERC20 tokens into it, it also doesn’t know that each of these transfers is a deposit that is protecting the user.

From its POV, all it sees is some contract transferring all of the users’ tokens to itself. Without apriori knowledge of the lending protocol, this would be indistinguishable from an attack.

If a white listed invoker allows the calling contract to take all of the users’ tokens then there’s no point in maintaining a white list. Importantly, the app-specific version of the invoker would be significantly safer than any invoker that is generalized enough to perform this feature.

Although this design, specifically, isn’t something I’m planning to build, this app-specific invoker design is a genuinely useful feature. It’s a feature that helps users. It’s a feature that provides value to users - both by freeing up a portion of their collateralized capital and by mitigating the losses that a user suffers upon liquidation. This type of app doesn’t even use intents; with intents, the advantages of in-app 3074 are even more pronounced.

I do not want to have to “build my own wallet company” in order to build an app like this. I do not want to have to “build my own wallet company” to have feature parity with the wallet companies building apps like this.

As an app dev, my perspective is:

• I would strongly prefer for the permissioning of smart contract usage of 3074 to be managed by users in a similar way (but more pronounced, perhaps) to how users currently manage token approvals.
• If that isn’t possible, I would prefer for smart contract usage of 3074 to be handled solely by an enshrined invoker contract.
• If that isn’t possible, then I do not believe that 3074 is secure enough for production.

I do not believe that invoker interactions should be heterogenous between wallets. Handling the permissioning offchain doesn’t make a system permissionless, especially when that permissioning is explicitly assumed to be occuring and is factored into the security assumptions of the proposal. If the EIP is too unsafe to function without strict permissioning from offchain actors then, in my opinion, it is too unsafe for production in a permissionless system.

[MicahZoltu]

I think the concern of centralizing apps into wallets because wallets have more capabilities is a legitimate concern. However, wallets already have privileges for doing what any invoker could do today, but they choose (for whatever reason) not to leverage that. Invokers make it so there is a path somewhere between “giving your keys to a new entity” to “only your wallet can do these things”.

My hope is that we see a small number of high profile individuals within the community (ideally not just big name platforms financial platforms, but people building public goods) write some useful general purpose invokers and then all wallets add them. I also hope that this doesn’t just turn into “Uniswap can write invokers and no one else can”.