UX Audit of EIP-7377

[depatchedmode]

Discussion for the Migration Transaction EIP. This EIP proposes a new transaction type that allows EOAs to submit a one-time upgrade to a smart contract.

More Details here: https://ethereum-magicians.org/t/eip-7377-migration-transaction

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. Next sync will be on January 17th.

[depatchedmode]

Summary

This EIP proposes a new transaction type that allows EOAs to submit a one-time upgrade to a smart contract.

Moving forward, the previous private key would no longer control that address, on the network the migration tx was successfully executed on.

Problems to address

1. Malicious Migration: People need to trust the party constructing the migration tx for them. A malicious party might migrate the EOA to a contract that is compromised. Also sounds like a "timing attack" may be possible, where the contents of another transaction in the same block are repurposed to execute a migration transaction.
2. Multiple chains: These transactions will be done one chain at a time. This EOA will need to be migrated once per chain. Not all chains sharing that address space exist at this point in time, meaning the private key should continue to be held in case the same address is desired on other chains in the future.

   • As on chains where this eip is not available or the migration was not executed the ownership is fundamentally different (in the context of the Safe contracts we generally call this “state drift”) — rmeissner

3. Open Permits: Need to close out permits before migrating: https://ethereum-magicians.org/t/eip-7377-migration-transaction/15144/23
4. Signature Validation: Checks for signature validity in contracts should prioritize EIP-1271 signatures before ecrecover: https://ethereum-magicians.org/t/eip-7377-migration-transaction/15144/40
5. L2 Address Aliasing: In the OP stack, an L1 contract can initiate a deposit transaction on L1 that is executed on L2. But, it's possible for different contracts with the same address to exist on L1 and L2. Because of this, L1 addresses are referenced on L2 via an alias. If someone migrated their address on L1 to be controlled by a contract, these deposit transactions would no longer work. https://ethereum-magicians.org/t/eip-7377-migration-transaction/15144/44

Questions about terminology

1. What is EOF? An acronym I've never seen before.

Ways we could help

1. Mock up "ideal client" experiences for the transaction
2. Help to define auditing tools that help folks determine if their contract is ready to migrate
3. PR to identify and highlight mental model problems
4. PR the proposal to include UX-focused language

[depatchedmode]

Updated the Eth Magicians thread to point folks here: https://ethereum-magicians.org/t/eip-7377-migration-transaction/15144/52?u=depatchedmode

[depatchedmode]

It sounds like this proposal has stalled. As far as I can tell, this is because of the L2 Address Aliasing Problem described above. Not clearly documented in the Eth Magicians thread, so might be worth following up there for clarity.

EIP-3074, however, which lets an EOA delegate control to a contract, is currently being considered for the prague update:
https://twitter.com/TimBeiko/status/1747340408030691781

And EIP-7212 is also being strongly advocated for, which would greatly expand secure design opportunities: "Many hardware and software solutions use this elliptic curve as signing algorithms, such as TLS, DNSSEC, Apple’s Secure Enclave, Passkeys, Android Keystore, and Yubikey, which can be used in the EVM"