Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Remove deprecated Bridge API and add recommended RPC flag #378

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from
Open

Remove deprecated Bridge API and add recommended RPC flag #378

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
863dcd9
add recommended RPC flag
isabellewei Oct 25, 2024
23974a6
remove deprecated bridge API
isabellewei Oct 25, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions src/content/docs/en/developers/guides/running-a-scroll-node.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -68,7 +68,8 @@ Please consider opening port `30303`(UDP & TCP) and enabling discovery so that o
--datadir "./l2geth-datadir" \
--gcmode archive --cache.noprefetch \
--http --http.addr "0.0.0.0" --http.port 8545 --http.api "eth,net,web3,debug,scroll" \
--l1.endpoint "$L2GETH_L1_ENDPOINT" --rollup.verify
--l1.endpoint "$L2GETH_L1_ENDPOINT" --rollup.verify \
--gpo.congestionthreshold=500
Copy link
Member

@icemelon icemelon Oct 25, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new suggested congestionthreshold should be 200 as discussed at https://scrollco.slack.com/archives/C02PKAQ2430/p1729319394735449?thread_ts=1729291990.648509&cid=C02PKAQ2430
cc @Thegaram

```
For Scroll Sepolia, use `--scroll-sepolia` instead of `--scroll`

Expand Down Expand Up @@ -117,7 +118,8 @@ Running the node in Docker might have a significant impact on node performance.
--datadir "/volume/l2geth-datadir" \
--gcmode archive --cache.noprefetch \
--http --http.addr "0.0.0.0" --http.port 8545 --http.api "eth,net,web3,debug,scroll" \
--l1.endpoint "$L2GETH_L1_ENDPOINT" --rollup.verify
--l1.endpoint "$L2GETH_L1_ENDPOINT" --rollup.verify \
--gpo.congestionthreshold=500
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here

```
For Scroll Sepolia, set the chain ID to 534351 and use `--scroll-sepolia` instead of `--scroll`.

Expand Down
70 changes: 3 additions & 67 deletions src/content/docs/en/developers/l1-and-l2-bridging/the-scroll-messenger.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -23,77 +23,13 @@ the messenger smart contract deployed on L1, `L1ScrollMessenger`. To send a mess

## Finalizing transactions on L1

Any upcoming transactions from L2 need to be finalized using the `relayMessageWithProof` function on the Scroll Messenger
contract. We call this process "submitting an Execute Withdrawal transaction," and it is required for both sending arbitrary messages and transferring assets through a gateway or the router. When you use `relayMessageWithProof`, you'll have to provide a Merkle inclusion proof showing your transaction is included in the trie of "withdrawal" messages, along with other parameters. Producing this proof and these values can be done locally and permissionlessly, but at the moment, the easiest way to retrieve these parameters is through our backend APIs:
Any upcoming transactions from L2 need to be finalized using the `relayMessageWithProof` function on the Scroll Messenger contract. We call this process "submitting an Execute Withdrawal transaction," and it is required for both sending arbitrary messages and transferring assets through a gateway or the router. When you use `relayMessageWithProof`, you'll have to provide a Merkle inclusion proof showing your transaction is included in the trie of "withdrawal" messages, along with other parameters.

- Scroll Sepolia API: https://sepolia-api-bridge-v2.scroll.io/api/
- Scroll API: https://mainnet-api-bridge-v2.scroll.io/api/

<Aside type="danger" title="Experimental API">
This API was made for our Bridge UI. It is not yet finalized and may change in the future. We will update this guide
when the API is finalized. Additionally, all examples below use the Sepolia API service -- the calls should be easily
adapted to work on mainnet.
</Aside>

Supply the address of the EOA or contract responsible for initiating the original transaction on L2 to the `/claimable`
endpoint. The API backend will provide you with all the necessary information to successfully conclude the transaction on L1.
Take a look at the following example:

```bash
https://sepolia-api-bridge.scroll.io/api/claimable?address=0x031407eaaffFB4f1EC2c999bE4477E52C81de3c5&page_size=10&page=1
```

The API should return your transaction data in the following format:

```json
{
"errcode": 0,
"errmsg": "",
"data": {
"result": [
{
"hash": "0xa476850306d6ee52b127628ded34dcf2343570873cce9c5383bd497db48d4f9b",
"amount": "",
"to": "",
"isL1": false,
"l1Token": "",
"l2Token": "",
"blockNumber": 748,
"blockTimestamp": null,
"finalizeTx": {
"hash": "",
"amount": "",
"to": "",
"isL1": false,
"blockNumber": 0,
"blockTimestamp": null
},
"claimInfo": {
"from": "0x031407eaaffFB4f1EC2c999bE4477E52C81de3c5",
"to": "0x1039057185CFe192d16c03F5656225821A193FD5",
"value": "0",
"nonce": "9",
"batch_hash": "0x49a18d72dbceeb957f918947b532db452c031f528e7e6bf329007066638c5e50",
"message": "0xa413686200000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000005686f6c6973000000000000000000000000000000000000000000000000000000",
"proof": "0x69b4ee6cf9a38bed79668ddd347fef2bdff44c3760c9309fa41decfd60202d22ad3228b676f7d3cd4284a5443f17f1962b36e491b30a40b2405849e597ba5fb5b4c11951957c6f8f642c4af61cd6b24640fec6dc7fc607ee8206a99e92410d3079f53171df5c0661d2afe86c4d97b6f34278daf6a0ea9baff5b4fc979d5629a5",
"batch_index": "93"
},
"createdTime": null
}
],
"total": 1
}
}
```

The `claimInfo` object under the `result` json returned has all the information needed to execute your transaction on L1. The
parameters needed by the `relayMessageWithProof` are: `from`, `to`, `value`, `nonce`, `message` and `proof`. Supply these to
the `relayMessageWithProof` function on L1 to execute and finalize your transaction on L1.
To produce this proof and these values, a batch indexing service has to be run locally: [Scroll Bridge SDK](https://github.com/scroll-tech/scroll-bridge-sdk). Further details on how to use this service are in the [docs](https://github.com/scroll-tech/scroll-bridge-sdk/blob/main/docs/document.md).

<Aside type="tip" title="">
All L2 transactions are bundled into batches – you have to wait for the batch that includes your transaction to
finalize before calling `relayMessageWithProof`. Your transaction batch index is returned in the `batch_index` value
on the `/claimable` endpoint, and you can follow the progress on the [Scroll Rollup
finalize before calling `relayMessageWithProof`. You can follow the progress of your batch on the [Scroll Rollup
Explorer](https://scroll.io/rollupscan?page=1&per_page=10).
</Aside>

Expand Down