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.