Protocol Simplifications

[saleel]

Protocol simplifications (based on discussions)

1. Remove pointer

• Account Key is enough practically.
• Pointer allows multiple account being created by same user, but this would require user to send emails with CODE {AccountKey} multiple times, which can be assumed to not happen.
• Even if this happens, a "honest" relayer will not create a new account, as there will be an existing mapping in their DB
• Tradeoff: If user signup twice, and Relayer didn't check the DB for existing account, user can endup having multiple account leading to undesirable behaviour. However, they can move one account key to another relayer and recover.

2. Remove relayerRand from account key commitment

• AccountKey commitment doesn't have to be tied to a relayer.
• This way, during account transport, new relayer doesn't have to create a separate account for the user. Users can more seamlessly use any relayer they want.
• Tradeoff: If the account key of a user gets leaked AND the user sends an email to X (not a relayer) with subject that matches our subject templates, then that X can register as a relayer and execute that email. Likelihood of this happening is low.

3. Do account creation + initialization in one step

• There is no need of separate transactions for create, and then initialize. We can create+initialize using the email from a user with account key in header.
• Since we are using UnclaimedFunds now, there is no need of "create" without initialize at any stage.
• Tradeoff: None?

4. Remove transport mechanism

• Allow user to use any Relayer without a pre-registration on contract level
• User still need to send the email with Account Key to the new relayer - new relayer just doesn't have to register an account with commitment
• This is possible if we do 2.
• Tradeoff - We are removing the check on "are you authorized to create EmailOp for emails from a user". So we have like in 2 if a user send email with subject that matches our template, then the recipient can execute it as an EmailOp even if they are not a relayer.
• Question: What are the odds of someone sending "Send 1 USDC to recipient@gmail.com" for other than using email wallet?

[saleel]

@SoraSuegami Please review.

[SoraSuegami]

I totally agree with your simplifications.

If user signup twice, and Relayer didn't check the DB for existing account, user can endup having multiple account leading to undesirable behaviour. However, they can move one account key to another relayer and recover.

I think we can accept this risk for better UX at the account creation and the simpler protocol.

Tradeoff: If the account key of a user gets leaked AND the user sends an email to X (not a relayer) with subject that matches our subject templates, then that X can register as a relayer and execute that email. Likelihood of this happening is low.

Even if the account key is leaked, I think the risk is low that the user sends an email matching our subject templates to X (a malicious party).

What are the odds of someone sending "Send 1 USDC to recipient@gmail.com" for other than using email wallet?

I think the odds of sending emails with the Send (and any well-used) subject template are low. However, if there are multiple email wallet contracts on different L1/L2 networks or forked blockchains, the same email can be used to execute the same transaction on multiple contracts. It has no effect in most cases, but we cannot say that in general. (As a different issue, if Ethereum is forked, the email wallet user will also hold ETH on the forked Ethereum, and a malicious relayer can send ETH both on the original and forked Ethereum using the same email.)