Merge pull request #1828 from prestwich/patch-4

Update sender address modification details for L1 to L2

Author: sbvegan

concepts/stack/differences.mdx

@@ -39,18 +39,24 @@ Because of the behavior of the `CREATE` opcode, it is possible to create a contr
 Even though these contracts share the same address, they are fundamentally two different smart contracts and cannot be treated as the same contract.
 As a result, the sender of a transaction sent from L1 to L2 by a smart contract cannot be the address of the smart contract on L1 or the smart contract on L1 could act as if it were the smart contract on L2 (because the two contracts share the same address).
 
-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.
+To prevent this sort of impersonation, the sender of a transaction is slightly modified by the `OptimismPortal` when a smart contract calls `depositTransaction` to send a transaction from L1 to L2.
+This alias is applied when the caller has code, and that code is not a valid EIP-7702 delegation.
+When the address has no code, or the code present at the address is a valid EIP-7702 delegation, the sender is not modified.
+Note that ephemeral contracts (those that are created and self-destructed in the same transaction) WILL be aliased, despite having no code at the start or end of transaction execution.
 
-This change in sender address is only applied to L2 transactions sent by L1 smart contracts.
+Instead of appearing to be sent from the actual L1 contract address, the L2 transaction is sent from an "aliased" version of the L1 contract address.
+This aliased address is produced by treating the address as a 160-bit integer, adding a constant offset with overflows allowed, and then truncating the result to a 20-byte address.
+The address hashing function ensures that aliased address will never conflict with any other address on L2. 
+The simple offset original L1 address can easily be recovered from the aliased address.
+
+The `OptimismPortal` applies this change only to L2 transactions sent by L1 smart contracts.
 In all other cases, the transaction sender address is set according to the same rules used by Ethereum.
 
-| Transaction Source                                      | Sender Address                                                     |
-| ------------------------------------------------------- | ------------------------------------------------------------------ |
-| L2 user (Externally Owned Account)                      | The user's address (same as in Ethereum)                           |
-| L1 user (Externally Owned Account)                      | The user's address (same as in Ethereum)                           |
-| L1 contract (using `OptimismPortal.depositTransaction`) | `L1_contract_address + 0x1111000000000000000000000000000000001111` |
+| Transaction Source                                        | Sender Address                                                              |
+| --------------------------------------------------------- | --------------------------------------------------------------------------- |
+| L2 user (Externally Owned, or EIP-7702 Delegated Account) | The user's address (same as in Ethereum)                                    |
+| L1 user (Externally Owned, or EIP-7702 Delegated Account) | The user's address (same as in Ethereum)                                    |
+| L1 contract (using `OptimismPortal.depositTransaction`)   | `uint160(L1_contract_address) + 0x1111000000000000000000000000000000001111` |
 
 ## Transactions