fix address aliasing description (OffchainLabs#2425)

* fix address aliasing description * Update docs/L1_L2_Messages.md Co-authored-by: gzeon <[email protected]> Co-authored-by: gzeon <[email protected]>
waleedcj · Aug 11, 2022 · 8f9c388 · 8f9c388
1 parent 0ec9e60
commit 8f9c388
Showing 1 changed file with 2 additions and 2 deletions.
diff --git a/docs/L1_L2_Messages.md b/docs/L1_L2_Messages.md
@@ -109,13 +109,13 @@ Beyond the superfluous ticket creation, this is suboptimal in that the base subm
 
 ### Address Aliasing
 
-When a retryable ticket is executed on L2, the sender's address —i.e., that which is returned by `msg.sender` — will _not_ simply be the address of the contract on L1 that initiated the message; rather it will be the contract's "L2 Alias." A contract address's L2 alias is its value increased by the hex value `0x1111000000000000000000000000000000001111`:
+All messages that are not initiated on L1 by the Sequencer (which includes all retryable tickets) are submitted via the [Delayed Inbox](Censorship_resistance). When unsigned messages in the Delayed Inbox are executed on L2, the sender's address —i.e., that which is returned by `msg.sender` — will _not_ simply be the L1 address that sent the message; rather it will be the address's "L2 Alias." An address's L2 alias is its value increased by the hex value `0x1111000000000000000000000000000000001111`:
 
 ```
 L2_Alias = L1_Contract_ Address + 0x1111000000000000000000000000000000001111
 ```
 
-The Arbitrum protocol's usage of L2 Aliases for L1-to-L2 messages prevents cross-chain exploits that would otherwise be possible if we simply reused L1 contact addresses.
+The Arbitrum protocol's usage of L2 Aliases for L1-to-L2 messages prevents cross-chain exploits that would otherwise be possible if we simply reused the same L1 addresses as the L2 sender.
 
 If for some reason you need to compute the L1 address from an L2 alias on chain, you can use our `AddressAliasHelper` library: