EIP-3074: AUTH and AUTHCALL opcodes

[ankurdubey521]

@derek

In fact, I’d imagine that the nonceManagerAddress being a smart contract would be more useful, since then the EOA can just “own” the smart contract as opposed to having to guard a separate key.

Agreed, owning a Smart Contract to manage this would be much easier.

[oren]

One significant tradeoff of having nonceManagerAddress be a smart contract is it makes the implementation of this opcode more complicated.

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?

More thoughts:

1. It 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.
2. It will change the gas pricing of the opcode because it will be accessing another address which might be cold.

[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.