Merge pull request #121 from scroll-tech/fix/enforced-txs-and-gas

fix: Clarity and copy changes on enforced txs and gas limit and zktrie

src/content/docs/en/developers/guides/scroll-messenger-cross-chain-interaction.mdx

@@ -79,13 +79,13 @@ contract GreeterOperator {
 We pass the message by executing `executeFunctionCrosschain` and passing the following parameters:
 
 - `scrollMessengerAddress`: This will depend on where you deployed the `GreeterOperator` contract.
-  - If you deployed it on Sepolia use `0x50c7d3e7f7c656493D1D76aaa1a836CedfCBB16A`. If you deployed on Scroll use `0xBa50f5340FB9F3Bd074bD638c9BE13eCB36E603d`.
+  - If you deployed it on Sepolia use `0x50c7d3e7f7c656493D1D76aaa1a836CedfCBB16A`. If you deployed on Scroll Sepolia use `0xBa50f5340FB9F3Bd074bD638c9BE13eCB36E603d`.
 - `targetAddress`: The address of the `Greeter` contract on the opposite chain.
 - `value`: In this case, it is `0` because the `setGreeting`is not payable.
 - `greeting`: This is the parameter that will be sent through the message. Try passing `“This message was cross-chain!”`
 - `gasLimit`:
-  - If you are sending the message from L1 to L2, around `1000000` gas limit should be more than enough.
-  - If you are sending the message from L2 to L1, pass `0`, as the transaction to be completed by executing an additional transaction on L1.
+  - If you are sending the message from L1 to L2, around `1000000` gas limit should be more than enough. That said, if you set this too high, and `msg.value` doesn't cover `gasLimit` * `baseFee`, the transaction will revert. If `msg.value` is greater than the gas fee, the unused portion will be refunded.
+  - If you are sending the message from L2 to L1, pass `0`, as the transaction will be completed by executing an additional transaction on L1.
 
 ### Relay the Message when sending from L2 to L1
 

src/content/docs/en/developers/l1-and-l2-bridging/enforced-transactions.mdx

@@ -9,7 +9,7 @@ excerpt: "The Enforced Transaction contract enables sending transactions between
 
 import Aside from "../../../../../components/Aside.astro"
 
-The Enforced Transaction contract enables sending transactions between L1 and L2 the **`sendTransaction`** function. This contract shares similarities with the Scroll Messenger contract as it allows sending arbitrary data from one layer to the other. However, it distinguishes itself by enabling the relaying of signed transactions and the ability to set the sender (CALLER or msg.sender) on the receiving transaction on Scroll.
+In future upgrades to Scroll, the Enforced Transaction contract will enable sending transactions between L1 and L2 with the **`sendTransaction`** function. This contract shares similarities with the Scroll Messenger contract as it allows sending arbitrary data from one layer to the other. However, it distinguishes itself by enabling the relaying of signed transactions and the ability to set the sender (CALLER or msg.sender) on the receiving transaction on Scroll.
 
 ## Enforced Transactions API
 

src/content/docs/en/developers/l1-and-l2-bridging/erc1155-token-bridge.mdx

@@ -115,7 +115,7 @@ Deposit an ERC1155 token from L1 to a recipient's account on L2.
 | to        | The address of recipient's account on L2.         |
 | tokenId   | The NFT id to deposit.                            |
 | amount    | The amount of tokens to deposit.                  |
-| gasLimit  | Gas limit required to complete the deposit on L2. |
+| gasLimit  | Gas limit required to complete the deposit on L2.  Unused portion of fee will be refunded.|
 
 ### updateTokenMapping
 

src/content/docs/en/developers/l1-and-l2-bridging/erc721-nft-bridge.mdx

@@ -86,7 +86,7 @@ Deposit an ERC721 NFT from L1 to a recipient's account on L2.
 | token     | The address of ERC721 NFT contract on L1.         |
 | to        | The address of recipient's account on L2.         |
 | tokenId   | The NFT id to deposit.                            |
-| gasLimit  | Gas limit required to complete the deposit on L2. |
+| gasLimit  | Gas limit required to complete the deposit on L2. Unused portion of fee will be refunded. |
 
 ### updateTokenMapping
 

src/content/docs/en/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge.mdx

@@ -28,10 +28,9 @@ When bridging ERC20 tokens, you don’t have to worry about selecting the right
 All Gateway contracts will form the message and send it to the `L1ScrollMessenger` which can send arbitrary messages to L2. The `L1ScrollMessenger` passes the message to the `L1MessageQueue`. Any user can send messages directly to the Messenger to execute arbitrary data on L2. This means they can execute any function on L2 from a transaction made on L1 via the bridge. Although an application could directly pass messages to existing token contracts, the Gateway abstracts the specifics and simplifies making transfers and calls.
 
 <Aside type="tip" title="">
-  Users can also bypass the `L1ScrollMessenger` and send messages directly to the `L1MessageQueue`. If a message is sent
+  In future upgrades, users will be able to bypass the `L1ScrollMessenger` and send messages directly to the `L1MessageQueue`. If a message is sent
   via the `L1MessageQueue`, the transaction's sender will be the address of the user sending the transaction, not the
-  address of the `L1ScrollMessenger`. Learn more about sending arbitrary messages in the [Scroll
-  Messenger](/developers/l1-and-l2-bridging/the-scroll-messenger) article.
+  address of the `L1ScrollMessenger`. 
 </Aside>
 
 When a new block gets created on L1, the Watcher will detect the message on the `L1MessageQueue` and will pass it to the Relayer service, which will submit the transaction to the L2 via the l2geth node. Finally, the l2geth node will pass the transaction to the `L2ScrollMessagner` contract for execution on L2.
@@ -54,7 +53,7 @@ The L2 Gateway is very similar to the L1 Gateway. We can withdraw ETH and ERC20
 
 ## Creating an ERC20 token with custom logic on L2
 
-If a token needs custom logic on L2, it will need to be bridged through a `L1CustomERC20Gateway` and `L2CustomERC20Gateway` respectively. The custom token on L2 will need to give permission to the Gateway to mint new tokens when a deposit occurs and to burn when tokens are withdrawn
+If a token needs custom logic on L2, it will need to be bridged through an `L1CustomERC20Gateway` and `L2CustomERC20Gateway` respectively. The custom token on L2 will need to give permission to the Gateway to mint new tokens when a deposit occurs and to burn when tokens are withdrawn
 
 The following interface is the `IScrollStandardERC20` needed for deploying tokens compatible with the `L2CustomERC20Gateway` on L2.
 
@@ -105,7 +104,7 @@ Sends ETH from L1 to L2.
 | --------- | --------------------------------------------------------------------------------------------------------------------------- |
 | to        | The address of recipient's account on L2.                                                                                   |
 | amount    | The amount of token to transfer, in wei.                                                                                    |
-| gasLimit  | Gas limit required to complete the deposit on L2. From 4000 to 10000 gas limit should be enough to process the transaction. |
+| gasLimit  | Gas limit required to complete the deposit on L2. 170000 should be enough to process the transaction, but unused funds are refunded. |
 
 ### depositERC20
 
@@ -120,7 +119,7 @@ Sends ERC20 tokens from L1 to L2.
 | token     | The token address on L1.                                                                                                    |
 | to        | The address of recipient's account on L2.                                                                                   |
 | amount    | The amount of token to transfer, in wei.                                                                                    |
-| gasLimit  | Gas limit required to complete the deposit on L2. From 4000 to 10000 gas limit should be enough to process the transaction. |
+| gasLimit  | Gas limit required to complete the deposit on L2. 20000 should be enough to process the transaction, depending on the Gateway, but unused funds are refunded. |
 
 ### getL2ERC20Address
 

src/content/docs/en/technology/bridge/cross-domain-messaging.mdx

@@ -93,7 +93,7 @@ function sendMessage(
 </ToggleElement>
 
 
-Both functions require users to provide a gas limit for the corresponding `L1MessageTx` transaction on L2 and prepay the [message relay fee](#message-relay-fee) on L1, which is calculated based on the gas limit amount. The fee is collected to a `feeVault` contract on L1. In case the transaction fails on L2 because the user did not set the correct gas limit for their message on L1, the user can replay the same message with a higher gas limit. You can find more details in the [Retrying failed messages](#retrying-failed-messages) section.
+Both functions require users to provide a gas limit for the corresponding `L1MessageTx` transaction on L2 and prepay the [message relay fee](#message-relay-fee) on L1, which is calculated based on the gas limit amount. The fee is collected to a `feeVault` contract on L1. In case the transaction fails on L2 because the user did not set the correct gas limit for their message on L1, the user can replay the same message with a higher gas limit. You can find more details in the [Retrying failed messages](#retrying-failed-messages) section, but since any unused portion of these fees is refunded to the user, there is no penalty for overestimating the gas limit.
 
 The `sendMessage` functions encode the arguments into a cross-domain message (see the code snippet below), where the message nonce is the next queue index of the L1 message queue. The encoded data is then used as calldata in the `L1MessageTx` transaction executed on L2. Note that such cross-domain messages always call the `relayMessage` function of the `L2ScrollMessenger` contract on L2.
 

src/content/docs/en/technology/sequencer/zktrie.mdx

@@ -61,9 +61,9 @@ When we insert a new leaf node to a zkTrie, there are two cases illustrated in t
 
 The deletion of a leaf node is similar to the insertion. There are two cases illustrated in the Figure 3.
 
-1. The sibling node of to-be-deleted leaf node is a
+1. The sibling node of the to-be-deleted leaf node is a
 branch node (Figure 3a). In this case, we can simply replace the node `a` by an empty node and update the node hash of its ancestors till the root node.
-2. The node of to-be-deleted leaf node is a leaf node (Figure 3b). Similarly to case 1, we first replace the leaf node by an empty node and start to contract its sibling node upwards until its sibling node is not an empty node. For example, in Figure 3b, we replace the leaf node `b` by an empty node. Because the sibling of node `c` now becomes an empty node, we need to move node `c` one level upward and replace its parent. The new sibling of node `c`, node `e`, is still an empty node. So again we move node `c` upward. Now that the sibling of node `c` is node `a`, a leaf node, the deletion process is finished.
+2. The sibling node of the to-be-deleted leaf node is a leaf node (Figure 3b). Similarly to case 1, we first replace the leaf node by an empty node and start to contract its sibling node upwards until its sibling node is not an empty node. For example, in Figure 3b, we replace the leaf node `b` by an empty node. Because the sibling of node `c` now becomes an empty node, we need to move node `c` one level upward and replace its parent. The new sibling of node `c`, node `e`, is still an empty node. So again we move node `c` upward. Now that the sibling of node `c` is node `a`, a leaf node, the deletion process is finished.
 
 Note that the sibling of a leaf node in a valid zkTrie cannot be an empty node. Otherwise, we should always prune the subtree and move the leaf node upwards.