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:
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.
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
This invalidates the censorship resistance properties we get from force inclusion.
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.
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?
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.
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.
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
I with my company(Aarc), working on solving the problem of migration of assets from EOA to smart accounts. With the current infra, we are using the ERC-20 Permit function and Uniswap’s Permit2 contract to migrate assets. We use the permit function to give allowance to the Permit2 contract and then use Permit2’s batching function to make the migration transaction. The solution works but doesn’t improve the UX as the user still needs to give n+1 signatures in most cases. This EIP seems to be very relevant for the adoption of AA. We would love to see it going forward.
I am also personally very excited to come up with an implementation for it, so if anyone is already working on it or might want to work on it. I would love to join forces with them.
We need this EIP for many use cases especially for supporting infra use cases like support migration of assets from EOAs to smart accounts. Would like to see this go forward!
Given the challenges around EIP at this point, what you mentioned seems like a pretty viable solution. There may be a room for innovation as an ERC and currently looking at it differently. For example uniswap x does gasless transactions approve and swaps without AA on this date!
It is viable but not the best solution for the users and tbh with very limited adoption of Permit2 in the real world. The solution is close to no good. None of the big dapps have integrated Permit2 into their contract. U gave the example of Uniswap but we need to consider that Uniswap team authored it so they obv will be using it. It’s an amazing contract but adoption is very less due to no standardization from the protocol level. The idea of AA is to bring a new standard of wallet, this EIP makes it super easy to adopt the new standard.
Hey all! Sounds like this EIP has definitely stalled. We were interested at the Secure Design WG in helping to explore UX implications of it. We did an initial audit of this thread to try and summarize UX problems. Definitely don’t have any solutions in mind for them yet, but if anybody picks this back up or proposes a similar migration standard, please hit us up for support:
In the meantime, we will explore other EIPs and also invite requests for secure UX audits from the community.