UX audit of EIP-3074: EOA delegates control to a Contract Account

[depatchedmode]

Allow externally owned accounts to delegate control to a contract.

More Details here: https://ethereum-magicians.org/t/eip-3074-auth-and-authcall-opcodes/4880

EIP-3074 simplifies Ethereum transactions and reduces gas costs by introducing two new opcodes, AUTH and AUTHCALL. Smart contracts can now use a user’s signature to authorize transactions, eliminating the need for users to hold ETH to pay for gas fees. This makes Ethereum more accessible to a wider range of users.

Let's assess the impacts this proposal would have on UX, and help ensure the standard encourages client implementations that would maintain security, safety and agency. Things we'll want to consider:

• threat models
• multi-modal accessibility
• localization
• trust indicators
• role and impact of trusted UIs

We can share notes, sketches and prototypes in this thread.

We have a Figjam going here:
https://www.figma.com/file/R0OrE5ewGUyBWPyvSaIapv/EIP-3074?type=whiteboard&node-id=0%3A1&t=xQbZHafqWZoPH9Cx-1

[depatchedmode]

There will be a breakout session next Wednesday about EOA/AA that will touch upon 3074:
ethereum/pm#962

[depatchedmode]

This is a decent read: https://notes.ethereum.org/@yoav/erc-4337-vs-eip-3074-false-dichotomy

TLDR: 3074 extends the EOA's capabilities onchain, by delegating execution authority to a contract. It does not allow for other desired things like key rotation on the EOA. Sounds like key rotation on an existing public key absolutely requires migration to a Contract Account (CA). In the case of EIP-3074 it would be complimented in this regard by EIP-5003 AUTHUSURP.

That said, EOA -> CA migration does come with known risk, particularly given the fact that rollout of the EIPs across chains the prior EOA had been active on will not occur simultaneously. Yoav gives the following summary of risks:

What could go wrong if the EOA key is compromised after it has been revoked?

1. The key remains valid on other chains (including future chains that do not even exist at the migration time). It can be used to claim the same account on other chains and transfer any assets sent to the account on these chains.
2. Off-chain systems such as the login process of dapp frontends check signatures. Many of them support EIP-1271 for smart contract signatures, but only try it if ecrecover fails. The key could be used to compromise the account on these systems.
3. It can be used on-chain (on the same chain where it has been revoked) to sign permit authorizations. If the account contains ERC-20 tokens that support permit, these tokens may get stolen using the revoked key.
4. Cross-chain bridges often check a signature during withdrawal. If the account sends funds to another chain through such a bridge, the revoked key may be used to withdraw the funds on the other side.

[depatchedmode]

Some UX concerns for EIP-3074 on its own are:

1. Ensure the contract is trusted
2. Understand the scope of the delegated authorization
3. How do I revoke? Or track what's happening?
4. Clarify why this only works on some chains/networks

Some UX concerns in concert with other EIPs/ERCs

Related proposals:

• ERC-4337 (Account Abstraction)
• EIP-5003 (AUTHUSURP) or EIP-6913 (SETCODE)
• RIP-7560 (Native Account Abstraction)

Need to parse this article about the overlap between: https://notes.ethereum.org/@yoav/eip-3074-erc-4337-synergy

Bottom line for interop with future proposals would be to caution that EOA migration to a CA should be a last resort, given the potential risks. A better approach will always be to migrate assets to a fresh account.

[depatchedmode]

This is a fantastic thread on common security concerns wrt 3074: https://warpcast.com/lightclient/0x3a6e8cfa

Text in full:

"One bad signature will be able to drain your account on Ethereum after EIP-3074."

Yes; this is true. 3074 coauthor here! Let me put this concern to rest a bit before it gets more out of hand.

To start: I'm not aware of any wallets that support signing unprefixed data today. This means that currently, no wallets support 3074. Doesn't matter how many control panels you navigate through or advanced features you turn on. It isn't possible to sign a 3074 message today.

The messages you sign to "login" to dapps use a completely different standard based on EIP-191. This prepends the following data to the message you sign:

"""
0x19 <0x45 (E)> <thereum Signed Message:\n" + len(message)>
"""

That's what makes it impossible to trick someone logging into a dapp to actually sign a valid Ethereum transaction.

Transactions are prefixed with single byte values:

0x01 - 2930 tx
0x02 - 1559 tx
0x03 - 4844 tx

more info here:
https://github.com/ethereum/execution-specs/tree/master/lists/signature-types

3074 plans to use the prefix 0x04. This will disambiguate it from all other types of signable data in Ethereum.

Wallets will have to actively opt-in to allowing users to sign these messages.

Depending on how wallets integrate 3074, they could create a situation where their users can more easily be exploited. To understand this, we need to make sure we understand how 3074 signatures work.

The auth msg which the signature is constructed over have the below fields. Importantly, it includes an invoker address. This is the only address under which the signature will be considered valid by AUTH.

For an account to be drained 1) the wallet will need to allow users to sign to any invoker address and 2) the users must not verify the invoker is trustworthy. Do either of those and there is not an issue.

For 1) we hope wallets understand that 3074 invokers are more akin to extensions of their code than they are contracts. Wallets don't give users the freedom to run arbitrary code with access to their pk; similarly, they shouldn't allow users to delegate their account arbitrarily.

So if wallets insecurely integrate 3074 and users do not verify the invoker they're interacting with, it is possible to delegate to a malicious invoker.

However, it is possible to undo by sending a single tx from the EOA. This revokes all "in-flight" AUTH signatures.

At minimum, wallets should make signing a 3074 message a big deal. This is like exporting-your-private-key level of big deal.

Assuming a wallet securely integrates 3074, it is still possible for an account to be swept. This is a fundamental property of batch txs. It as easily allows you to send multiple ops as it allows an attacker to trick you to send a batch of assets to an address they control.

Wallets must clearly display each op you're signing over. This way, it is easy to notice "I was only planning to make a single trade, but this signing request is having me do a dozen transfers also".

It will be impossible to detect this if batching available via blind signing.

Yes, 3074 is putting a lot of trust into wallets. But look, we are already trusting them with securely our private key! There isn't a higher level of trust.

It is possible to integrate and use 3074 safely. If any wallets have questions on how they can do this, please don't hesitate to reach out. As authors of 3074, we're currently figuring how we can best help this standard in its next phase of life.

Over the last several years, we've spent a lot of time developing hypothetical scenarios on how it might be used and abuse. We're excited for these ideas to begin being productionized. But we're also cognizant that this is the hard part.

Our DMs are open! Please reach out if we can help.

[depatchedmode]

This is a nice, short explainer video covering the benefits of 3074:
https://www.youtube.com/watch?v=rEnXN5U1q-E

[depatchedmode]

Another excellent thread with a link to a great overview video by lightclient, one of the co-authors of the EIP:
https://twitter.com/0xcygaar/status/1778522744919044442