EIP-7377: Migration Transaction

EIPs Core EIPs
41

I wrote a lil’ internal doc at OP Labs which I’ve lightly edited to share here:

Context

When a contract makes a deposit to an OP Stack L2, we apply a mask to alias it.
So if a multisig on L1 with the address 0xabcd0000abcd makes a deposit to L2, the ORIGIN and initial CALLER will appear as `0xbcde0000bcde```.

Why do we need Aliasing?

We need aliasing because...

We need aliasing because it is possible for there to be a smart contract at the same address on L1 and L2, but for those contracts to have totally different behaviour.
For example they might both be a multisig, but have a different signer set.
Therefore we need a mechanism to allow a contract on L2 to distinguish between these accounts, which in practice requires that msg.sender is different if a call is coming from a contract on L1 (during a deposit Tx) vs. a contract on L2.

For this reason we apply an alias to contracts which are making deposits, using the following code:

// Transform the from-address to its alias if the caller is a contract.
address from = msg.sender;
if (msg.sender != tx.origin) {
    from = AddressAliasHelper.applyL1ToL2Alias(msg.sender);
}

Why is there an exemption for EOAs?

EOAs are exempt because...

EOAs are exempt from this aliasing process because:

  1. It is safe to assume that an EOA is controlled by the same entity no matter the chain, so the same risk that applies to contracts does not apply here.
  2. Aliasing EOAs on deposits would mean that the same account has a different address depending if the call is made via deposit or is being sent on L2 using ECDSA based signature validation.

7377 Impact Scenario

An EOA might be unaliased during a deposit transaction today, and then aliased in the future after a migration.

Imagine Alice deploys a 1 of 1 multisig on Optimism, which she controls with her EOA.

As is, she can call her multisig either via a deposit transaction, or directly via a sequencer transaction.

After 7377, Alice might choose to migrate her EOA to a smart contract wallet on Mainnet. But then she would lose the deposit transaction option for calling her multisig on Optimism.

Problems

  1. This invalidates the censorship resistance properties we get from force inclusion.
  2. There’s also a new footgun where Alice might try interacting with another L2 contract from L1 without realizing that the msg.sender would now be aliased. I won’t bother to contrive a scenario, but undoubtedly someone will find a way to lose a lot of money.
1 Like
42

then she would lose the deposit transaction option for calling her multisig on Optimism

Can’t they just add the aliased address as authorized on their account?

There’s also a new footgun where Alice might try interacting with another L2 contract from L1 without realizing that the msg.sender would now be aliased. I won’t bother to contrive a scenario, but undoubtedly someone will find a way to lose a lot of money.

I’m not very familiar with how L1 → L2 calls are typically being utilized on OP, but I am not sure why the aliasing here would cause a loss of funds? I would expect whatever transfer is happening, the assets would now simply be associated with the aliased address on the L2 and the user would need to possibly send another deposit tx to call as the aliased address?

43

What are the potential solutions?

Is it possible that leaning into addressing tx.origin first as a standalone EIP might make AA easier to adopt afterwards?

I do think it’s very possible an EVM-like chain that prioritizes AA could see rapid adoption due to ease-of-onboarding (business-incentivized participation), which could threaten Ethereum’s dominance (if that’s the sort of thing we even care about). I’d rather see Ethereum tackle it first vs wait for external pressure.

44

In the 1 of 1 multisig case, yes, she can easily add the alias and make it a 1 of 2.
However she would have to be sure to do this in advance of the migration on L1, so the error case remains.

A better example would be that of a token balance belonging to the unaliased EOA. After migrating the account on L1 the option to make a call to send that balance via deposit transaction would be lost.

You might suggest that Alice transfer all of her balances to the aliased address first, however this would mean that the balances no longer belong to the original address on L2, so she would then be forced to interact via L1 → L2 transactions.

45

Interesting idea.
I have a question though, After migration, can user use their account in ERC-4337 system ?. If they can, we will have an account abstraction system without moving any assets and use can still using their wallet address in ERC-4337

46

Yes of course, the main goal of this EIP is to make it easy for EOAs to migrate to ERC-4337.