Why is only the first call frame aliased?

[PaulRBerg]

Did you check the documentation?

• Yes

Did you read the specs?

• Yes
• No

Did you check for duplicate questions?

• Yes

Issue Description

Because addresses can be impersonated cross-chain, rollups have to alias addresses when L1 to L2 transactions are performed.

From the docs:

CALLER
msg.sender
If the transaction is an L1 ⇒ L2 transaction triggered by a smart contract on L1, and this is the first call frame (rather than an internal transaction from one contract to another), the same address aliasing behavior applies.

Why is the address aliased only within first call frames and not internal txs, too?

[hash1go]

Hello!

The document explains the behavior of the OP Stack's opcode. Internal txs occur entirely within L2, so aliasing is not necessary in these cases.
Aliasing is applied only to the first call frame to prevent address impersonation across L1 and L2 boundaries.

[hash1go]

Sorry, I didn't read it carefully.

[opfocus]

Hey! I've linked to that document in the original post.

Internal txs occur entirely within L2

Can you expound on this? With this example setup, why doesn't A's address have to be aliased, too?

flowchart LR
    Z[Alice EOA] -- "Tx" --> A
    A[Contract A] -- "Internal Tx" --> B[Contract B]
    B --> C[L1StandardBridge]

Loading

Where does this example come from, it doesn't seem to be an example of L2

[PaulRBerg]

I created the diagram myself.

What I was trying to get to is this: why is only Alice EOA and Contract B aliased on L2, but not Contract A?

I think I am now able to answer myself - the reason is that Contract A is nowhere to be found in the transaction. It's just an intermediary. Whereas Alice is tx.origin and Contract B is msg.sender, which do have to be aliased because they are part of the execution context.

[opfocus]

I'm a bit confused. I think that when a contract internally calls another contract, the msg.sender in the called contract is always the address of the previous contract. Except for the first one which used an alias, the others did not use aliases.

[PaulRBerg]

I think seeing an example of a contract tx on L1 and how it is interpreted in L2 would clarify this.

[sbvegan]

I believe this security measure was meant to protect from spoofing the msg.sender value and not the internal contract calls:

To prevent this sort of impersonation, the sender of a transaction is slightly modified when a transaction is sent from L1 to L2 by a smart contract. Instead of appearing to be sent from the actual L1 contract address, the L2 transaction appears to be sent from an "aliased" version of the L1 contract address. This aliased address is a constant offset from the actual L1 contract address such that the aliased address will never conflict with any other address on L2 and the original L1 address can easily be recovered from the aliased address.

[PaulRBerg]

I still don't understand - when contracts call each other, the msg.sender changes.

[Chomtana]

It's easier to say that tx.origin get aliased, not msg.sender

And on the first call frame, msg.sender == tx.origin

But on subsequent call (internal transactions), msg.sender is equal to the contract that call another contract which may not equal to the aliases tx.origin

You can think of that aliased address as an EOA calling the contract on L2, it will behave exactly same like this.