What should the value of tx.origin and msg.sender be for L1 to L2 transactions?

[smartcontracts]

We're doing some rethinking of the value of tx.origin and msg.sender (at the top-level call) for L1 to L2 transactions. While designing OVMv2, we originally planned to make the value of both variables address(0) for L1 to L2 transactions. However, this introduces several critical issues that must be properly addressed:

1. msg.sender absolutely cannot be address(0) at the top level because contracts generally make the assumption that transactions cannot be "sent" by address(0). Many contracts use address(0) as a way to burn tokens. Check out the address on Etherscan: it's got $1.5b worth of tokens!
2. We also should NOT use the address that triggered the transaction on L1 as msg.sender because this leads to all sorts of security issues in which a contract on L1 can have the same address as a contract on L2 but might have different code. However, we should consider using the address as msg.sender IFF msg.sender == tx.origin (aka the L1 transaction was triggered by an EOA) because it means we don't need to allow users to submit signed transactions to the chain and we can get away with doing everything through L1 => L2 messages.
3. Although it really shouldn't be used, tx.origin will have the exact same problems if a contract ever uses it for authentication. So generally speaking I think we should handle tx.origin and msg.sender in the same way.

So what do you think the value of these variables should be?

[krzkaczor]

What's wrong with the current solution using xchainmessager? I liked it because it's symmetrical between L1->L2 and L2->L1. I don't think that (1) applies as messages always call to xchainmessager first, and no one uses msg.origin? 😆

FWIW: in Arbitrum during L1->L2 calls, a call is originating from the original address sub some constant to avoid security issues. https://developer.offchainlabs.com/docs/l1_l2_messages#address-aliasing

[smartcontracts]

What's wrong with the current solution using xchainmessager? I liked it because it's symmetrical between L1->L2 and L2->L1. I don't think that (1) applies as messages always call to xchainmessager first, and no one uses msg.origin?

It's possible to bypass the xchainmessenger by directly using enqueue so we can't use address(0). Currently my vote is for setting msg.sender and tx.origin to some pseudo-random address.

[qbzzt]

How about we use an address that cannot be faked, but is easy to change to the correct source address? Maybe <L1 origin> ^ 2^255 ?

[smartcontracts]

Ok so @maurelian @qbzzt @ben-chain @karlfloersch and I got on a call about this a few minutes ago. TL;DR is that Arbitrum already has a reasonable approach to this problem and we're just going to use their approach so that we can start getting standardization around these L2 quirks. We could come up with our own way of handling this but there's really no point if it would only introduce a diff between L2 designs.

@maurelian is going to reach out to the Arbitrum team to get a detailed spec of how they set msg.sender and tx.origin and we're going to follow it as closely as possible.

[romanovskaia21]

look at your decision, think about it. Your value matters

[smartcontracts]

We've made a final decision here, we're standardizing with Arbitrum and using the same address aliasing scheme that they use for message passing! Specifically, we use the following aliasing function:

    uint160 constant offset = uint160(0x1111000000000000000000000000000000001111);

    function applyL1ToL2Alias(address l1Address) internal pure returns (address l2Address) {
        unchecked {
            l2Address = address(uint160(l1Address) + offset);
        }
    }

This aliasing ONLY applies for contracts sending messages to L2. If an EOA sends a message to L2 then the address is NOT aliased. Here's the relevant code from the CTC:

        address sender;
        if (msg.sender == tx.origin) {
            sender = msg.sender;
        } else {
            sender = AddressAliasHelper.applyL1ToL2Alias(msg.sender);
        }

[smartcontracts]

Note that the requirement that EOAs not be aliased is so that EOAs can access any msg.sender-gated contracts on L2 even if the Sequencer is censoring.

[fredlacs]

In Arbitrum, EOAs are also aliased if a tx is created directly in the delayed inbox (but you can post a signed L2 tx which will retain unaliased sender).