You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/content/docs/en/developers/guides/scroll-messenger-cross-chain-interaction.mdx
+3-3Lines changed: 3 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -79,13 +79,13 @@ contract GreeterOperator {
79
79
We pass the message by executing `executeFunctionCrosschain` and passing the following parameters:
80
80
81
81
-`scrollMessengerAddress`: This will depend on where you deployed the `GreeterOperator` contract.
82
-
- If you deployed it on Sepolia use `0x50c7d3e7f7c656493D1D76aaa1a836CedfCBB16A`. If you deployed on Scroll use `0xBa50f5340FB9F3Bd074bD638c9BE13eCB36E603d`.
82
+
- If you deployed it on Sepolia use `0x50c7d3e7f7c656493D1D76aaa1a836CedfCBB16A`. If you deployed on Scroll Sepolia use `0xBa50f5340FB9F3Bd074bD638c9BE13eCB36E603d`.
83
83
-`targetAddress`: The address of the `Greeter` contract on the opposite chain.
84
84
-`value`: In this case, it is `0` because the `setGreeting`is not payable.
85
85
-`greeting`: This is the parameter that will be sent through the message. Try passing `“This message was cross-chain!”`
86
86
-`gasLimit`:
87
-
- If you are sending the message from L1 to L2, around `1000000` gas limit should be more than enough.
88
-
- 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.
87
+
- 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.
88
+
- 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.
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.
12
+
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.
Copy file name to clipboardExpand all lines: src/content/docs/en/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge.mdx
+5-6Lines changed: 5 additions & 6 deletions
Original file line number
Diff line number
Diff line change
@@ -28,10 +28,9 @@ When bridging ERC20 tokens, you don’t have to worry about selecting the right
28
28
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.
29
29
30
30
<Asidetype="tip"title="">
31
-
Users can also bypass the `L1ScrollMessenger` and send messages directly to the `L1MessageQueue`. If a message is sent
31
+
In future upgrades, users will be able to bypass the `L1ScrollMessenger` and send messages directly to the `L1MessageQueue`. If a message is sent
32
32
via the `L1MessageQueue`, the transaction's sender will be the address of the user sending the transaction, not the
33
-
address of the `L1ScrollMessenger`. Learn more about sending arbitrary messages in the [Scroll
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
54
53
55
54
## Creating an ERC20 token with custom logic on L2
56
55
57
-
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
56
+
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
58
57
59
58
The following interface is the `IScrollStandardERC20` needed for deploying tokens compatible with the `L2CustomERC20Gateway` on L2.
| to | The address of recipient's account on L2. |
107
106
| amount | The amount of token to transfer, in wei. |
108
-
| gasLimit | Gas limit required to complete the deposit on L2. From 4000 to 10000 gas limit should be enough to process the transaction. |
107
+
| gasLimit | Gas limit required to complete the deposit on L2. 170000 should be enough to process the transaction, but unused funds are refunded. |
109
108
110
109
### depositERC20
111
110
@@ -120,7 +119,7 @@ Sends ERC20 tokens from L1 to L2.
120
119
| token | The token address on L1. |
121
120
| to | The address of recipient's account on L2. |
122
121
| amount | The amount of token to transfer, in wei. |
123
-
| gasLimit | Gas limit required to complete the deposit on L2. From 4000 to 10000 gas limit should be enough to process the transaction. |
122
+
| 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. |
Copy file name to clipboardExpand all lines: src/content/docs/en/technology/bridge/cross-domain-messaging.mdx
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -93,7 +93,7 @@ function sendMessage(
93
93
</ToggleElement>
94
94
95
95
96
-
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.
96
+
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.
97
97
98
98
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.
Copy file name to clipboardExpand all lines: src/content/docs/en/technology/sequencer/zktrie.mdx
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -61,9 +61,9 @@ When we insert a new leaf node to a zkTrie, there are two cases illustrated in t
61
61
62
62
The deletion of a leaf node is similar to the insertion. There are two cases illustrated in the Figure 3.
63
63
64
-
1. The sibling node of to-be-deleted leaf node is a
64
+
1. The sibling node of the to-be-deleted leaf node is a
65
65
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.
66
-
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.
66
+
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.
67
67
68
68
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.
0 commit comments