From 78f5c2c97f8a5a2defc800e828cc278a11f51b65 Mon Sep 17 00:00:00 2001 From: Jason-Wanxt Date: Thu, 13 Mar 2025 18:51:18 +0800 Subject: [PATCH 1/6] add how to run a sequencer docs --- .../how-tos/running-an-orbit-node.mdx | 8 - .../running-an-orbit-sequencer-node.mdx | 178 ++++++++++++++++++ ...orbit-sequencer-compatible-cli-partial.mdx | 45 +++++ 3 files changed, 223 insertions(+), 8 deletions(-) create mode 100644 arbitrum-docs/node-running/how-tos/running-an-orbit-sequencer-node.mdx create mode 100644 arbitrum-docs/partials/_optional-orbit-sequencer-compatible-cli-partial.mdx diff --git a/arbitrum-docs/node-running/how-tos/running-an-orbit-node.mdx b/arbitrum-docs/node-running/how-tos/running-an-orbit-node.mdx index 59d445cc33..d3c30b6291 100644 --- a/arbitrum-docs/node-running/how-tos/running-an-orbit-node.mdx +++ b/arbitrum-docs/node-running/how-tos/running-an-orbit-node.mdx @@ -89,8 +89,6 @@ And, you need to set the following flag to specify the DAS REST endpoints, there Please contact the chain owners to get the URL of the DAS REST endpoints. If you are a chain owner, please refer to the [DAC setup guide](/run-arbitrum-node/data-availability-committees/01-get-started.mdx#if-you-are-a-chain-owner) to set it up. -(Batch posters only) For your batch posters to post data to the DAS, you need to follow [step 3 of config das](/run-arbitrum-node/data-availability-committees/04-configure-dac.mdx#Step-3:-Craft-the-new-configuration-for-the-batch-poster) to your node config. - ### 3.Important ports | Protocol | Port | @@ -151,12 +149,6 @@ Set the following configurations to your fullnode to make it can receive the seq After that, your node can synchronize the latest state from the sequencer feed. -(Chain owners only) In order for a node to read the sequencer feed, the chain's sequencer needs to be configured with the following parameters: - -```shell ---node.feed.output.enable=true --node.feed.output.addr= --node.feed.output.port= -``` - ## Optional parameters We show here a list of the parameters that are most commonly used when running your Orbit node. You can also use the flag `--help` for a full comprehensive list of the available parameters. diff --git a/arbitrum-docs/node-running/how-tos/running-an-orbit-sequencer-node.mdx b/arbitrum-docs/node-running/how-tos/running-an-orbit-sequencer-node.mdx new file mode 100644 index 0000000000..5e070125bd --- /dev/null +++ b/arbitrum-docs/node-running/how-tos/running-an-orbit-sequencer-node.mdx @@ -0,0 +1,178 @@ +--- +title: 'How to run a full node for an Orbit chain' +description: Learn how to run an Arbitrum orbit node on your local machine +author: Jason Wan +sme: Jason Wan +content_type: how-to +--- + +(Note: This is for Arbitrum Orbit chains only) + +This how-to provides step-by-step instructions for running a sequencer node on your local machine. + +## Prerequisites + +Latest Docker Image: @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.1-8f247fd@@ + +| Minimum Hardware Configuration | +| :--------------------------------------------------------------- | +| **RAM**: 16-32 GB | +| **CPU**: 4-8 core CPU (For AWS: t3 2xLarge) | +| **Storage**: Depends on the Orbit chain and its traffic overtime | + +## Required parameters + +### 1. Sequencer node parameters + +The following parameters are required to run a sequencer node: + +#### 1. Enable sequencer + +Enable the sequencer mode: + +```shell +--node.sequencer=true +``` + +#### 2. Make the node acts and posts to l1 as a sequencer + +Enable the sequencer execution: + +```shell +--execution.sequencer.enable=true +--execution.sequencer.max-tx-data-size=85000 +--execution.sequencer.max-block-speed=250ms +``` + +#### 3. Enable delayed sequencer + +Enable your node to read and include transaction from parent chain delayed inbox. + +```shell +--node.delayed-sequencer.enable=true +--node.delayed-sequencer.use-merge-finality=false +--node.delayed-sequencer.finalize-distance=1 +``` + +#### 4. Enable batch poster + +Enable your node to send batches to parent chain: + +```shell +--node.batch-poster.enable=true +--node.batch-poster.max-size=90000 +--node.batch-poster.parent-chain-wallet.private-key= +``` + +#### 4. Disable transaction forwarding + +Disable your sequencer's forwarding transaction as the node will queue the transaction directly: + +```shell +--execution.forwarding-target="" +``` + +#### 5. Enable feed out queued transaction + +Enable your node to feed out transaction so fullnode can receive queued transaction: + +```shell +--node.feed.output.enable=true +--node.feed.output.addr= +--node.feed.output.port= +``` + +#### 5. Connect the node to data availability servers + +(This step only required in Anytrust mode) +Enable your node can send batch to DAS and get DACerts from them. + +```shell +--node.data-availability.enable=true +--node.data-availability.sequencer-inbox-address= +--node.data-availability.parent-chain-node-url= +--node.data-availability.rest-aggregator.enable=true +--node.data-availability.rest-aggregator.urls= +--node.data-availability.rpc-aggregator.enable=true +--node.data-availability.rpc-aggregator.assumed-honest=1 +--node.data-availability.rpc-aggregator.backends= +``` + +### 2. Putting it all together + +- When running a Docker image, an external volume should be mounted to persist the database across restarts. The mount point inside the Docker image should be `/home/user/.arbitrum` + +- Example: + + ```shell wordWrap=true + docker run --rm -it -v /some/local/dir/arbitrum:/home/user/.arbitrum -p 0.0.0.0:8547:8547 -p 0.0.0.0:8548:8548 @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.1-8f247fd@@ --node.sequencer=true --node.delayed-sequencer.enable=true --node.delayed-sequencer.use-merge-finality=false --node.delayed-sequencer.finalize-distance=1 --node.batch-poster.enable=true --node.batch-poster.max-size=90000 --node.batch-poster.parent-chain-wallet.private-key= --node.staker.enable=true --node.staker.strategy=MakeNodes --node.staker.parent-chain-wallet.private-key= --node.data-availability.enable=true --node.data-availability.sequencer-inbox-address= --node.data-availability.parent-chain-node-url= --node.data-availability.rest-aggregator.enable=true --node.data-availability.rest-aggregator.urls= --node.data-availability.rpc-aggregator.enable=true --node.data-availability.rpc-aggregator.assumed-honest=1 --node.data-availability.rpc-aggregator.backends= --execution.sequencer.enable=true --execution.sequencer.max-tx-data-size=85000 --execution.sequencer.max-block-speed=250ms + ``` + + - Ensure that `/some/local/dir/arbitrum` already exists otherwise the directory might be created with `root` as owner, and the Docker container won't be able to write to it + +- Json Example: + ```json + { + "node": { + "sequencer": true, + "delayed-sequencer": { + "enable": true, + "use-merge-finality": false, + "finalize-distance": 1 + }, + "batch-poster": { + "max-size": 90000, + "enable": true, + "parent-chain-wallet": { + "private-key": "4a9a2282b8845b7198840154341b628e14dfe8512543d43a7c0f64f090d970e2" + } + }, + "feed": { + "output": { + "enable": true, + "addr": "", + "port": "" + } + }, + "data-availability": { + "enable": true, + "sequencer-inbox-address": "0x55616A4D88Be0290D43a8AF7228c6700E709FBa6", + "parent-chain-node-url": "https://sepolia-rollup.arbitrum.io/rpc", + "rest-aggregator": { + "enable": true, + "urls": ["http://das-server:9877"] + }, + "rpc-aggregator": { + "enable": true, + "assumed-honest": 1, + "backends": "[{\"url\":\"http://das-server:9876\",\"pubkey\":\"YAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==\",\"signermask\":1}]" + } + } + }, + "execution": { + "forwarding-target": "", + "sequencer": { + "enable": true, + "max-tx-data-size": 85000, + "max-block-speed": "250ms" + } + } + } + ``` + +### Note on permissions + +- The Docker image is configured to run as non-root `UID 1000`. If you are running Linux or macOS and you are getting permission errors when trying to run the Docker image, run this command to allow all users to update the persistent folders: + + ```shell + mkdir /data/arbitrum + chmod -fR 777 /data/arbitrum + ``` + +## Optional parameters + +We show here a list of the parameters that are most commonly used when running your Orbit node. You can also use the flag `--help` for a full comprehensive list of the available parameters. + +import OptionalOrbitSequencerCompatibleCLIFlagsPartial from '../../partials/arbitrum-docs/partials/_optional-orbit-sequencer-compatible-cli-partial.mdx'; + + diff --git a/arbitrum-docs/partials/_optional-orbit-sequencer-compatible-cli-partial.mdx b/arbitrum-docs/partials/_optional-orbit-sequencer-compatible-cli-partial.mdx new file mode 100644 index 0000000000..bd3fc0048e --- /dev/null +++ b/arbitrum-docs/partials/_optional-orbit-sequencer-compatible-cli-partial.mdx @@ -0,0 +1,45 @@ +
+ +| Flag | Description | +| --------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `--execution.rpc.classic-redirect=` | Redirects archive requests for pre-nitro blocks to this RPC of an Arbitrum Classic node with archive database. Only for Arbitrum One. | +| `--http.api` | Offered APIs over the HTTP-RPC interface. Default: `net,web3,eth,arb`. Add `debug` for tracing. | +| `--http.corsdomain` | Accepts cross origin requests from these comma-separated domains (browser enforced). | +| `--http.vhosts` | Accepts requests from these comma-separated virtual hostnames (server enforced). Default: `localhost`. Accepts `*`. | +| `--http.addr` | Address to bind RPC to. May require `0.0.0.0` for Docker networking. | +| `--execution.caching.archive` | Retains past block state. For archive nodes. | +| `--node.feed.input.url=` | Default: `wss://.arbitrum.io/feed`. ⚠️ One feed relay per datacenter is advised. See [feed relay guide](/run-arbitrum-node/sequencer/01-run-feed-relay.mdx). | +| `--execution.rpc.evm-timeout` | Default: `5s`. Timeout for `eth_call`. (0 == no timeout). | +| `--execution.rpc.gas-cap` | Default: `50000000`. Gas cap for `eth_call`/`estimateGas`. (0 = no cap). | +| `--execution.rpc.tx-fee-cap` | Default: `1`. Transaction fee cap (in ether) for RPC APIs. (0 = no cap). | +| `--ipc.path` | Filename for IPC socket/pipe within datadir. 🔉 Not supported on macOS. Note the path is within the Docker container. | +| `--init.prune` | Prunes database before starting the node. Can be "full" or "validator". | +| `--init.url=""` | (Non-Orbit Nitro nodes only) URL to download the genesis database from. Required only for the first startup of an Arbitrum One node. Reference to [snapshots](https://snapshot.arbitrum.foundation/index.html) and [archive node guide](/run-arbitrum-node/more-types/01-run-archive-node.mdx). | +| `--init.download-path="/path/to/dir"` | (Non-Orbit Nitro nodes only) Temporarily saves the downloaded database snapshot. Defaults to `/tmp/`. Used with `--init.url`. | +| `--node.batch-poster.post-4844-blobs` | Boolean. Default: `false`. Used to enable or disable the posting of transaction data using Blobs to L1 Ethereum. If using calldata is more expensive and if the parent chain supports EIP4844 blobs, the batch poster will use blobs when this flag is set to `true`. Can be `true` or `false`. | +| `--node.batch-poster.ignore-blob-price` | Boolean. Default: `false`. If the parent chain supports EIP4844 blobs and `ignore-blob-price` is set to `true`, the batch poster will use EIP4844 blobs even if using calldata is cheaper. Can be `true` or `false`. | +| `--execution.sequencer.enable` | Act and post to L1 as sequencer. | +| `--execution.sequencer.enable-profiling` | Enable CPU profiling and tracing. | +| `--execution.sequencer.expected-surplus-hard-threshold` | If expected surplus is lower than this value, new incoming transactions will be denied (default "default"). | +| `--execution.sequencer.expected-surplus-soft-threshold` | If expected surplus is lower than this value, warnings are posted (default "default"). | +| `--execution.sequencer.forwarder.connection-timeout` | Total time to wait before cancelling connection (default 30s). | +| `--execution.sequencer.forwarder.idle-connection-timeout` | Time until idle connections are closed (default 1m0s). | +| `--execution.sequencer.forwarder.max-idle-connections` | Maximum number of idle connections to keep open (default 100). | +| `--execution.sequencer.forwarder.redis-url` | The Redis URL to recommend target via. | +| `--execution.sequencer.forwarder.retry-interval` | Minimal time between update retries (default 100ms). | +| `--execution.sequencer.forwarder.update-interval` | Forwarding target update interval (default 1s). | +| `--execution.sequencer.max-acceptable-timestamp-delta` | Maximum acceptable time difference between the local time and the latest L1 block's timestamp (default 1h0m0s). | +| `--execution.sequencer.max-block-speed` | Minimum delay between blocks (sets a maximum speed of block production) (default 250ms). | +| `--execution.sequencer.max-revert-gas-reject` | Maximum gas executed in a revert for the sequencer to reject the transaction instead of posting it (anti-DOS). | +| `--execution.sequencer.max-tx-data-size` | Maximum transaction size the sequencer will accept (default 95000). | +| `--execution.sequencer.nonce-cache-size` | Size of the tx sender nonce cache (default 1024). | +| `--execution.sequencer.nonce-failure-cache-expiry` | Maximum amount of time to wait for a predecessor before rejecting a tx with nonce too high (default 1s). | +| `--execution.sequencer.nonce-failure-cache-size` | Number of transactions with too high of a nonce to keep in memory while waiting for their predecessor (default 1024). | +| `--execution.sequencer.queue-size` | Size of the pending tx queue (default 1024). | +| `--execution.sequencer.queue-timeout` | Maximum amount of time transaction can wait in queue (default 12s). | +| `--execution.sequencer.sender-whitelist` | Comma separated whitelist of authorized senders (if empty, everyone is allowed). | +| `--node.delayed-sequencer.finalize-distance` | How many blocks in the past L1 block is considered final (ignored when using Merge finality) (default 20). | +| `--node.delayed-sequencer.require-full-finality` | Whether to wait for full finality before sequencing delayed messages. | +| `--node.delayed-sequencer.use-merge-finality` | Whether to use The Merge's notion of finality before sequencing delayed messages (default true). | + +
From f425746a4654c726bf584e6f7b5001980cf32d78 Mon Sep 17 00:00:00 2001 From: Jason-Wanxt Date: Thu, 13 Mar 2025 18:52:52 +0800 Subject: [PATCH 2/6] fix --- arbitrum-docs/node-running/how-tos/running-an-orbit-node.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arbitrum-docs/node-running/how-tos/running-an-orbit-node.mdx b/arbitrum-docs/node-running/how-tos/running-an-orbit-node.mdx index d3c30b6291..ec815ed198 100644 --- a/arbitrum-docs/node-running/how-tos/running-an-orbit-node.mdx +++ b/arbitrum-docs/node-running/how-tos/running-an-orbit-node.mdx @@ -151,7 +151,7 @@ After that, your node can synchronize the latest state from the sequencer feed. ## Optional parameters -We show here a list of the parameters that are most commonly used when running your Orbit node. You can also use the flag `--help` for a full comprehensive list of the available parameters. +We show here a list of the parameters that are most commonly used when running your Orbit sequencer node. You can also use the flag `--help` for a full comprehensive list of the available parameters. import OptionalOrbitCompatibleCLIFlagsPartial from '../../partials/_optional-orbit-compatible-cli-flags-partial.mdx'; From c6af5f1125d7ee2c4759900738273e20858f578d Mon Sep 17 00:00:00 2001 From: Jason-Wanxt Date: Thu, 13 Mar 2025 18:57:49 +0800 Subject: [PATCH 3/6] fix --- arbitrum-docs/node-running/how-tos/running-an-orbit-node.mdx | 2 +- .../node-running/how-tos/running-an-orbit-sequencer-node.mdx | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arbitrum-docs/node-running/how-tos/running-an-orbit-node.mdx b/arbitrum-docs/node-running/how-tos/running-an-orbit-node.mdx index ec815ed198..d3c30b6291 100644 --- a/arbitrum-docs/node-running/how-tos/running-an-orbit-node.mdx +++ b/arbitrum-docs/node-running/how-tos/running-an-orbit-node.mdx @@ -151,7 +151,7 @@ After that, your node can synchronize the latest state from the sequencer feed. ## Optional parameters -We show here a list of the parameters that are most commonly used when running your Orbit sequencer node. You can also use the flag `--help` for a full comprehensive list of the available parameters. +We show here a list of the parameters that are most commonly used when running your Orbit node. You can also use the flag `--help` for a full comprehensive list of the available parameters. import OptionalOrbitCompatibleCLIFlagsPartial from '../../partials/_optional-orbit-compatible-cli-flags-partial.mdx'; diff --git a/arbitrum-docs/node-running/how-tos/running-an-orbit-sequencer-node.mdx b/arbitrum-docs/node-running/how-tos/running-an-orbit-sequencer-node.mdx index 5e070125bd..d79fac9e28 100644 --- a/arbitrum-docs/node-running/how-tos/running-an-orbit-sequencer-node.mdx +++ b/arbitrum-docs/node-running/how-tos/running-an-orbit-sequencer-node.mdx @@ -171,7 +171,7 @@ Enable your node can send batch to DAS and get DACerts from them. ## Optional parameters -We show here a list of the parameters that are most commonly used when running your Orbit node. You can also use the flag `--help` for a full comprehensive list of the available parameters. +We show here a list of the parameters that are most commonly used when running your Orbit sequencer node. You can also use the flag `--help` for a full comprehensive list of the available parameters. import OptionalOrbitSequencerCompatibleCLIFlagsPartial from '../../partials/arbitrum-docs/partials/_optional-orbit-sequencer-compatible-cli-partial.mdx'; From 4f59d4ce2e36892251db217f0243d0ec51bb1094 Mon Sep 17 00:00:00 2001 From: Jason-Wanxt Date: Thu, 20 Mar 2025 16:13:00 +0800 Subject: [PATCH 4/6] fix path --- .../node-running/how-tos/running-an-orbit-sequencer-node.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arbitrum-docs/node-running/how-tos/running-an-orbit-sequencer-node.mdx b/arbitrum-docs/node-running/how-tos/running-an-orbit-sequencer-node.mdx index d79fac9e28..81c3e8cdfb 100644 --- a/arbitrum-docs/node-running/how-tos/running-an-orbit-sequencer-node.mdx +++ b/arbitrum-docs/node-running/how-tos/running-an-orbit-sequencer-node.mdx @@ -173,6 +173,6 @@ Enable your node can send batch to DAS and get DACerts from them. We show here a list of the parameters that are most commonly used when running your Orbit sequencer node. You can also use the flag `--help` for a full comprehensive list of the available parameters. -import OptionalOrbitSequencerCompatibleCLIFlagsPartial from '../../partials/arbitrum-docs/partials/_optional-orbit-sequencer-compatible-cli-partial.mdx'; +import OptionalOrbitSequencerCompatibleCLIFlagsPartial from '../../partials/_optional-orbit-sequencer-compatible-cli-partial.mdx'; From 92c40a893ea2483dc3643cc793e5f88f58bbaf0e Mon Sep 17 00:00:00 2001 From: Jason-Wanxt Date: Thu, 20 Mar 2025 16:54:54 +0800 Subject: [PATCH 5/6] Revert "add" This reverts commit f5e7de566396b551224ddb1a3b1a3c56d7110c44, reversing changes made to 4f59d4ce2e36892251db217f0243d0ec51bb1094. --- .../assets}/arbitrum-chains-diagram.jpeg | Bin .../02-how-to-estimate-gas.mdx | 2 +- .../precompiles/02-reference.mdx | 28 +- .../precompile-tables/_ArbAddressTable.mdx | 14 +- .../precompile-tables/_ArbAggregator.mdx | 22 +- .../partials/precompile-tables/_ArbDebug.mdx | 20 +- .../precompile-tables/_ArbFunctionTable.mdx | 6 +- .../precompile-tables/_ArbGasInfo.mdx | 88 +-- .../partials/precompile-tables/_ArbInfo.mdx | 4 +- .../partials/precompile-tables/_ArbOwner.mdx | 83 ++- .../precompile-tables/_ArbOwnerPublic.mdx | 20 +- .../precompile-tables/_ArbRetryableTx.mdx | 26 +- .../precompile-tables/_ArbStatistics.mdx | 2 +- .../partials/precompile-tables/_ArbSys.mdx | 30 +- .../partials/precompile-tables/_ArbWasm.mdx | 44 +- .../precompile-tables/_ArbWasmCache.mdx | 14 +- .../partials/precompile-tables/_ArbosTest.mdx | 2 +- .../precompile-tables/_NodeInterface.mdx | 20 +- .../02-transaction-lifecycle.mdx | 2 +- .../how-arbitrum-works/03-sequencer.mdx | 2 +- .../05-separating-execution-from-proving.mdx | 0 .../01-validation-and-proving.mdx | 22 - .../02-rollup-protocol.mdx | 272 ------- .../03-proving-and-challenges.mdx | 444 ----------- .../06-optimistic-rollup.mdx | 0 .../07-interactive-fraud-proofs.mdx | 0 .../11-l2-to-l1-messaging.mdx | 129 +--- .../bold/bold-technical-deep-dive.mdx | 2 +- .../bold/gentle-introduction.mdx | 6 +- .../advanced-configurations/01-layer-leap.mdx | 1 - .../03-calculate-aep-fees.mdx | 2 +- .../03-stake-and-validator-configurations.mdx | 1 - .../04-arbos-configuration.mdx | 1 - .../05-gas-optimization-tools.mdx | 1 - .../07-batch-posting-assertion-control.mdx | 1 - .../08-sequencer-timing-adjustments.mdx | 1 - .../09-per-batch-gas-cost.mdx | 1 - .../10-smart-contract-size-limit.mdx | 1 - .../11-customizing-anytrust.mdx | 1 - .../02-start-your-journey.mdx | 1 - .../07-canonical-factory-contracts.mdx | 1 - .../launch-orbit-chain/03-orbit-license.mdx | 1 - .../04-maintain-your-chain/01-bridging.mdx | 1 - .../04-maintain-your-chain/02-monitoring.mdx | 1 - .../01-decentralization-security.mdx | 1 - .../04-guidance/02-guidance-on-altda.mdx | 1 - .../customize-arbos.mdx | 8 +- .../customize-precompile.mdx | 38 +- .../05-customize-your-chain/customize-stf.mdx | 8 +- .../03-integrations.mdx | 1 - .../orbit-node-providers.mdx | 1 - .../08-ecosystem-support/01-orbit-portal.mdx | 1 - .../03-get-listed-orbit-platforms.mdx | 1 - .../how-tos/how-to-configure-your-chain.mdx | 1 - .../how-tos/orbit-chain-finality.mdx | 2 +- .../orbit-batch-poster-configuration.mdx | 1 - .../orbit-configuration-parameters.mdx | 1 - .../reference/orbit-fast-block-times.mdx | 1 - .../orbit-sequencer-configuration.mdx | 1 - .../orbit-smart-contract-size-limit.mdx | 1 - .../how-tos/running-an-orbit-node.mdx | 158 ++++ .../partials/_gentle-intro-partial.mdx | 10 +- ...al-orbit-compatible-cli-flags-partial.mdx} | 42 +- .../run-arbitrum-node/03-run-full-node.mdx | 161 ++-- .../arbos-releases/arbos20.mdx | 2 +- .../02-deploy-das.mdx | 14 +- .../03-deploy-mirror-das.mdx | 6 +- .../04-configure-dac.mdx | 4 +- .../more-types/01-run-archive-node.mdx | 6 +- .../more-types/02-run-validator-node.mdx | 12 +- .../nitro/01-build-nitro-locally.mdx | 2 +- .../run-full-node/_dao-chains-example.mdx | 3 - .../run-full-node/_dao-chains-parameters.mdx | 33 - .../run-full-node/_orbit-chains-example.mdx | 5 - .../_orbit-chains-parameters.mdx | 92 --- .../sequencer/01-run-feed-relay.mdx | 4 +- .../03-run-sequencer-coordination-manager.mdx | 2 +- arbitrum-docs/stylus/concepts/how-it-works.md | 2 +- arbitrum-docs/welcome/get-started.mdx | 22 +- vercel.json | 28 +- website/docusaurus.config.js | 34 +- website/sidebars.js | 55 +- website/src/resources/globalVars.js | 6 +- .../src/resources/precompilesInformation.js | 102 ++- .../scripts/precompile-reference-generator.ts | 14 +- .../static/img/dapps-withdrawing-ether.svg | 691 +----------------- website/yarn.lock | 2 +- 87 files changed, 698 insertions(+), 2202 deletions(-) rename {website/static/img => arbitrum-docs/assets}/arbitrum-chains-diagram.jpeg (100%) rename {website/archive => arbitrum-docs}/how-arbitrum-works/05-separating-execution-from-proving.mdx (100%) delete mode 100644 arbitrum-docs/how-arbitrum-works/05-validation-and-proving/01-validation-and-proving.mdx delete mode 100644 arbitrum-docs/how-arbitrum-works/05-validation-and-proving/02-rollup-protocol.mdx delete mode 100644 arbitrum-docs/how-arbitrum-works/05-validation-and-proving/03-proving-and-challenges.mdx rename {website/archive => arbitrum-docs}/how-arbitrum-works/06-optimistic-rollup.mdx (100%) rename {website/archive => arbitrum-docs}/how-arbitrum-works/07-interactive-fraud-proofs.mdx (100%) create mode 100644 arbitrum-docs/node-running/how-tos/running-an-orbit-node.mdx rename arbitrum-docs/{run-arbitrum-node/partials/run-full-node/_optional-parameters.mdx => partials/_optional-orbit-compatible-cli-flags-partial.mdx} (58%) delete mode 100644 arbitrum-docs/run-arbitrum-node/partials/run-full-node/_dao-chains-example.mdx delete mode 100644 arbitrum-docs/run-arbitrum-node/partials/run-full-node/_dao-chains-parameters.mdx delete mode 100644 arbitrum-docs/run-arbitrum-node/partials/run-full-node/_orbit-chains-example.mdx delete mode 100644 arbitrum-docs/run-arbitrum-node/partials/run-full-node/_orbit-chains-parameters.mdx mode change 100644 => 100755 website/static/img/dapps-withdrawing-ether.svg diff --git a/website/static/img/arbitrum-chains-diagram.jpeg b/arbitrum-docs/assets/arbitrum-chains-diagram.jpeg similarity index 100% rename from website/static/img/arbitrum-chains-diagram.jpeg rename to arbitrum-docs/assets/arbitrum-chains-diagram.jpeg diff --git a/arbitrum-docs/build-decentralized-apps/02-how-to-estimate-gas.mdx b/arbitrum-docs/build-decentralized-apps/02-how-to-estimate-gas.mdx index 73d48c9309..43e989b9e1 100644 --- a/arbitrum-docs/build-decentralized-apps/02-how-to-estimate-gas.mdx +++ b/arbitrum-docs/build-decentralized-apps/02-how-to-estimate-gas.mdx @@ -21,7 +21,7 @@ Multiplying the value obtained from `eth_estimateGas` by the child chain gas pri Alternatively, to obtain the gas limit for your transaction, you can call `NodeInterface.gasEstimateComponents()` and then use the first result, which is `gasEstimate`. Next, to find the total cost, you need to multiply this amount by the child chain gas price, which is available in the third result, `baseFee`. -Note that when working with parent to child chain messages (also known as [retryable tickets](/how-arbitrum-works/10-l1-to-l2-messaging.mdx)), you can use the function [`L1ToL2MessageGasEstimator.estimateAll()`](https://github.com/OffchainLabs/arbitrum-sdk/blob/main/src/lib/message/L1ToL2MessageGasEstimator.ts#L215) of the Arbitrum SDK or [`NodeInterface.estimateRetryableTicket()`](https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.2@@/nodeInterface/NodeInterface.go#L120) to get all the gas information needed to send a successful transaction. +Note that when working with parent to child chain messages (also known as [retryable tickets](/how-arbitrum-works/10-l1-to-l2-messaging.mdx)), you can use the function [L1ToL2MessageGasEstimator.estimateAll()](https://github.com/OffchainLabs/arbitrum-sdk/blob/main/src/lib/message/L1ToL2MessageGasEstimator.ts#L215) of the Arbitrum SDK or [NodeInterface.estimateRetryableTicket()](https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.1@@/nodeInterface/NodeInterface.go#L120) to get all the gas information needed to send a successful transaction. ## Breaking down the formula diff --git a/arbitrum-docs/build-decentralized-apps/precompiles/02-reference.mdx b/arbitrum-docs/build-decentralized-apps/precompiles/02-reference.mdx index a9a588daa5..cc34c392b1 100644 --- a/arbitrum-docs/build-decentralized-apps/precompiles/02-reference.mdx +++ b/arbitrum-docs/build-decentralized-apps/precompiles/02-reference.mdx @@ -54,20 +54,20 @@ This section is divided into two tables. We first list precompiles we expect use [arbsys_link_interface]: https://github.com/OffchainLabs/@@nitroContractsRepositorySlug=nitro-contracts@@/blob/@@nitroContractsCommit=763bd77906b7677da691eaa31c6e195d455197a4@@/@@nitroContractsPathToPrecompilesInterface=src/precompiles@@/ArbSys.sol [arbwasm_link_interface]: https://github.com/OffchainLabs/@@nitroContractsRepositorySlug=nitro-contracts@@/blob/@@nitroContractsCommit=763bd77906b7677da691eaa31c6e195d455197a4@@/@@nitroContractsPathToPrecompilesInterface=src/precompiles@@/ArbWasm.sol [arbwasmcache_link_interface]: https://github.com/OffchainLabs/@@nitroContractsRepositorySlug=nitro-contracts@@/blob/@@nitroContractsCommit=763bd77906b7677da691eaa31c6e195d455197a4@@/@@nitroContractsPathToPrecompilesInterface=src/precompiles@@/ArbWasmCache.sol -[arbaddresstable_link_implementation]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.2@@/@@nitroPathToPrecompiles=precompiles@@/ArbAddressTable.go -[arbaggregator_link_implementation]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.2@@/@@nitroPathToPrecompiles=precompiles@@/ArbAggregator.go -[arbdebug_link_implementation]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.2@@/@@nitroPathToPrecompiles=precompiles@@/ArbDebug.go -[arbfunctiontable_link_implementation]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.2@@/@@nitroPathToPrecompiles=precompiles@@/ArbFunctionTable.go -[arbgasinfo_link_implementation]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.2@@/@@nitroPathToPrecompiles=precompiles@@/ArbGasInfo.go -[arbinfo_link_implementation]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.2@@/@@nitroPathToPrecompiles=precompiles@@/ArbInfo.go -[arbowner_link_implementation]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.2@@/@@nitroPathToPrecompiles=precompiles@@/ArbOwner.go -[arbownerpublic_link_implementation]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.2@@/@@nitroPathToPrecompiles=precompiles@@/ArbOwnerPublic.go -[arbostest_link_implementation]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.2@@/@@nitroPathToPrecompiles=precompiles@@/ArbosTest.go -[arbretryabletx_link_implementation]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.2@@/@@nitroPathToPrecompiles=precompiles@@/ArbRetryableTx.go -[arbstatistics_link_implementation]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.2@@/@@nitroPathToPrecompiles=precompiles@@/ArbStatistics.go -[arbsys_link_implementation]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.2@@/@@nitroPathToPrecompiles=precompiles@@/ArbSys.go -[arbwasm_link_implementation]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.2@@/@@nitroPathToPrecompiles=precompiles@@/ArbWasm.go -[arbwasmcache_link_implementation]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.2@@/@@nitroPathToPrecompiles=precompiles@@/ArbWasmCache.go +[arbaddresstable_link_implementation]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.1@@/@@nitroPathToPrecompiles=precompiles@@/ArbAddressTable.go +[arbaggregator_link_implementation]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.1@@/@@nitroPathToPrecompiles=precompiles@@/ArbAggregator.go +[arbdebug_link_implementation]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.1@@/@@nitroPathToPrecompiles=precompiles@@/ArbDebug.go +[arbfunctiontable_link_implementation]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.1@@/@@nitroPathToPrecompiles=precompiles@@/ArbFunctionTable.go +[arbgasinfo_link_implementation]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.1@@/@@nitroPathToPrecompiles=precompiles@@/ArbGasInfo.go +[arbinfo_link_implementation]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.1@@/@@nitroPathToPrecompiles=precompiles@@/ArbInfo.go +[arbowner_link_implementation]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.1@@/@@nitroPathToPrecompiles=precompiles@@/ArbOwner.go +[arbownerpublic_link_implementation]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.1@@/@@nitroPathToPrecompiles=precompiles@@/ArbOwnerPublic.go +[arbostest_link_implementation]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.1@@/@@nitroPathToPrecompiles=precompiles@@/ArbosTest.go +[arbretryabletx_link_implementation]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.1@@/@@nitroPathToPrecompiles=precompiles@@/ArbRetryableTx.go +[arbstatistics_link_implementation]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.1@@/@@nitroPathToPrecompiles=precompiles@@/ArbStatistics.go +[arbsys_link_implementation]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.1@@/@@nitroPathToPrecompiles=precompiles@@/ArbSys.go +[arbwasm_link_implementation]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.1@@/@@nitroPathToPrecompiles=precompiles@@/ArbWasm.go +[arbwasmcache_link_implementation]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.1@@/@@nitroPathToPrecompiles=precompiles@@/ArbWasmCache.go ## Precompiles reference diff --git a/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbAddressTable.mdx b/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbAddressTable.mdx index 2b7436d775..0e865be0b6 100644 --- a/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbAddressTable.mdx +++ b/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbAddressTable.mdx @@ -22,7 +22,7 @@ Implementation @@ -44,7 +44,7 @@ Implementation @@ -66,7 +66,7 @@ Implementation @@ -90,7 +90,7 @@ Implementation @@ -112,7 +112,7 @@ Implementation @@ -134,7 +134,7 @@ Implementation @@ -156,7 +156,7 @@ Implementation diff --git a/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbAggregator.mdx b/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbAggregator.mdx index d3c5ea1b22..4cb6352438 100644 --- a/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbAggregator.mdx +++ b/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbAggregator.mdx @@ -22,7 +22,7 @@ Implementation @@ -44,7 +44,7 @@ Implementation @@ -66,7 +66,7 @@ Implementation @@ -88,13 +88,13 @@ Implementation - Adds additional batch poster address + Adds newBatchPoster as a batch poster @@ -110,7 +110,7 @@ Implementation @@ -132,7 +132,7 @@ Implementation @@ -157,13 +157,13 @@ Implementation - Deprecated: always returns zero + Deprecated: returns 0 @@ -179,13 +179,13 @@ Implementation - Deprecated: no-op + Deprecated: does nothing diff --git a/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbDebug.mdx b/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbDebug.mdx index e9d2bba433..206128bb01 100644 --- a/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbDebug.mdx +++ b/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbDebug.mdx @@ -22,7 +22,7 @@ Implementation @@ -44,13 +44,13 @@ Implementation - Emits events with values based on the args provided + Emit events with values based on the args provided @@ -66,7 +66,7 @@ Implementation @@ -88,7 +88,7 @@ Implementation @@ -110,7 +110,7 @@ Implementation @@ -132,7 +132,7 @@ Implementation @@ -166,7 +166,7 @@ Implementation @@ -190,7 +190,7 @@ Implementation @@ -214,7 +214,7 @@ Implementation diff --git a/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbFunctionTable.mdx b/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbFunctionTable.mdx index 6d0eb4093f..8ec99f1a67 100644 --- a/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbFunctionTable.mdx +++ b/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbFunctionTable.mdx @@ -22,7 +22,7 @@ Implementation @@ -44,7 +44,7 @@ Implementation @@ -66,7 +66,7 @@ Implementation diff --git a/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbGasInfo.mdx b/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbGasInfo.mdx index a794760b13..5bcdaa371c 100644 --- a/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbGasInfo.mdx +++ b/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbGasInfo.mdx @@ -22,7 +22,7 @@ Implementation @@ -44,7 +44,7 @@ Implementation @@ -66,7 +66,7 @@ Implementation @@ -90,7 +90,7 @@ Implementation @@ -112,7 +112,7 @@ Implementation @@ -134,7 +134,7 @@ Implementation @@ -156,7 +156,7 @@ Implementation @@ -178,7 +178,7 @@ Implementation @@ -202,7 +202,7 @@ Implementation @@ -224,7 +224,7 @@ Implementation @@ -246,7 +246,7 @@ Implementation @@ -268,15 +268,13 @@ Implementation - - GetCurrentTxL1GasFees gets the fee in wei paid to the batch poster for posting this tx - + GetCurrentTxL1GasFees gets the fee paid to the aggregator for posting this tx @@ -292,7 +290,7 @@ Implementation @@ -314,15 +312,13 @@ Implementation - - GetPricingInertia gets how slowly ArbOS updates the L2 basefee in response to backlogged gas - + Returns how slowly ArbOS updates the L2 basefee in response to backlogged gas @@ -338,7 +334,7 @@ Implementation @@ -363,16 +359,13 @@ Implementation - - GetL1PricingSurplus gets the surplus of funds for L1 batch posting payments (may be - negative) - + Returns the surplus of funds for L1 batch posting payments (may be negative) @@ -388,15 +381,14 @@ Implementation - GetPerBatchGasCharge gets the base charge (in L1 gas) attributed to each data batch in the - calldata pricer + Returns the base charge (in L1 gas) attributed to each data batch in the calldata pricer @@ -413,13 +405,13 @@ Implementation - GetAmortizedCostCapBips gets the cost amortization cap in basis points + Returns the cost amortization cap in basis points @@ -435,13 +427,13 @@ Implementation - GetL1FeesAvailable gets the available funds from L1 fees + Returns the available funds from L1 fees @@ -457,15 +449,15 @@ Implementation - GetL1PricingEquilibrationUnits gets the equilibration units parameter for L1 price - adjustment algorithm (Available since ArbOS 20) + Returns the equilibration units parameter for L1 price adjustment algorithm (Available since + ArbOS 20) @@ -482,16 +474,13 @@ Implementation - - GetLastL1PricingUpdateTime gets the last time the L1 calldata pricer was updated (Available - since ArbOS 20) - + Returns the last time the L1 calldata pricer was updated (Available since ArbOS 20) @@ -507,15 +496,15 @@ Implementation - GetL1PricingFundsDueForRewards gets the amount of L1 calldata payments due for rewards (per - the L1 reward rate) (Available since ArbOS 20) + Returns the amount of L1 calldata payments due for rewards (per the L1 reward rate) + (Available since ArbOS 20) @@ -532,15 +521,14 @@ Implementation - GetL1PricingUnitsSinceUpdate gets the amount of L1 calldata posted since the last update - (Available since ArbOS 20) + Returns the amount of L1 calldata posted since the last update (Available since ArbOS 20) @@ -557,15 +545,15 @@ Implementation - GetLastL1PricingSurplus gets the L1 pricing surplus as of the last update (may be negative) - (Available since ArbOS 20) + Returns the L1 pricing surplus as of the last update (may be negative) (Available since + ArbOS 20) diff --git a/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbInfo.mdx b/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbInfo.mdx index 377596499e..acd7685800 100644 --- a/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbInfo.mdx +++ b/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbInfo.mdx @@ -22,7 +22,7 @@ Implementation @@ -44,7 +44,7 @@ Implementation diff --git a/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbOwner.mdx b/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbOwner.mdx index f2f2466c7f..603c58e7f8 100644 --- a/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbOwner.mdx +++ b/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbOwner.mdx @@ -22,7 +22,7 @@ Implementation @@ -44,7 +44,7 @@ Implementation @@ -66,7 +66,7 @@ Implementation @@ -88,7 +88,7 @@ Implementation @@ -110,7 +110,7 @@ Implementation @@ -134,7 +134,7 @@ Implementation @@ -156,7 +156,7 @@ Implementation @@ -178,7 +178,7 @@ Implementation @@ -200,7 +200,7 @@ Implementation @@ -222,7 +222,7 @@ Implementation @@ -244,7 +244,7 @@ Implementation @@ -266,7 +266,7 @@ Implementation @@ -288,7 +288,7 @@ Implementation @@ -310,7 +310,7 @@ Implementation @@ -332,7 +332,7 @@ Implementation @@ -354,7 +354,7 @@ Implementation @@ -376,7 +376,7 @@ Implementation @@ -398,7 +398,7 @@ Implementation @@ -420,7 +420,7 @@ Implementation @@ -442,7 +442,7 @@ Implementation @@ -464,7 +464,7 @@ Implementation @@ -486,7 +486,7 @@ Implementation @@ -508,13 +508,16 @@ Implementation - Sets the Brotli compression level used for fast compression (default level is 1) + + Sets the Brotli compression level used for fast compression (Available in ArbOS version 12 + with default level as 1) + @@ -530,7 +533,7 @@ Implementation @@ -552,7 +555,7 @@ Implementation @@ -574,7 +577,7 @@ Implementation @@ -596,7 +599,7 @@ Implementation @@ -618,7 +621,7 @@ Implementation @@ -640,7 +643,7 @@ Implementation @@ -662,7 +665,7 @@ Implementation @@ -684,7 +687,7 @@ Implementation @@ -706,7 +709,7 @@ Implementation @@ -728,7 +731,7 @@ Implementation @@ -750,7 +753,7 @@ Implementation @@ -772,7 +775,7 @@ Implementation @@ -794,7 +797,7 @@ Implementation @@ -816,7 +819,7 @@ Implementation @@ -838,7 +841,7 @@ Implementation @@ -872,7 +875,7 @@ Implementation diff --git a/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbOwnerPublic.mdx b/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbOwnerPublic.mdx index 06c0699cae..c7256b8f20 100644 --- a/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbOwnerPublic.mdx +++ b/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbOwnerPublic.mdx @@ -22,7 +22,7 @@ Implementation @@ -44,13 +44,15 @@ Implementation - RectifyChainOwner checks if the account is a chain owner (Available since ArbOS 11) + + RectifyChainOwner checks if the account is a chain owner (Available in ArbOS version 11) + @@ -66,7 +68,7 @@ Implementation @@ -88,7 +90,7 @@ Implementation @@ -110,7 +112,7 @@ Implementation @@ -132,7 +134,7 @@ Implementation @@ -157,7 +159,7 @@ Implementation @@ -191,7 +193,7 @@ Implementation diff --git a/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbRetryableTx.mdx b/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbRetryableTx.mdx index 31af13facc..8217802343 100644 --- a/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbRetryableTx.mdx +++ b/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbRetryableTx.mdx @@ -22,7 +22,7 @@ Implementation @@ -47,7 +47,7 @@ Implementation @@ -69,7 +69,7 @@ Implementation @@ -91,7 +91,7 @@ Implementation @@ -113,7 +113,7 @@ Implementation @@ -135,7 +135,7 @@ Implementation @@ -157,7 +157,7 @@ Implementation @@ -179,7 +179,7 @@ Implementation @@ -216,7 +216,7 @@ Implementation @@ -238,7 +238,7 @@ Implementation @@ -260,7 +260,7 @@ Implementation @@ -282,7 +282,7 @@ Implementation @@ -304,7 +304,7 @@ Implementation diff --git a/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbStatistics.mdx b/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbStatistics.mdx index 015e29a362..a7dadbcaf0 100644 --- a/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbStatistics.mdx +++ b/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbStatistics.mdx @@ -22,7 +22,7 @@ Implementation diff --git a/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbSys.mdx b/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbSys.mdx index 934005bef0..546af69ed9 100644 --- a/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbSys.mdx +++ b/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbSys.mdx @@ -22,7 +22,7 @@ Implementation @@ -44,7 +44,7 @@ Implementation @@ -66,7 +66,7 @@ Implementation @@ -88,7 +88,7 @@ Implementation @@ -110,7 +110,7 @@ Implementation @@ -132,7 +132,7 @@ Implementation @@ -154,7 +154,7 @@ Implementation @@ -176,7 +176,7 @@ Implementation @@ -198,7 +198,7 @@ Implementation @@ -222,7 +222,7 @@ Implementation @@ -244,7 +244,7 @@ Implementation @@ -266,7 +266,7 @@ Implementation @@ -303,7 +303,7 @@ Implementation @@ -325,7 +325,7 @@ Implementation @@ -349,7 +349,7 @@ Implementation diff --git a/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbWasm.mdx b/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbWasm.mdx index e8d18bb4ae..f499e55420 100644 --- a/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbWasm.mdx +++ b/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbWasm.mdx @@ -22,7 +22,7 @@ Implementation @@ -44,7 +44,7 @@ Implementation @@ -66,7 +66,7 @@ Implementation @@ -88,7 +88,7 @@ Implementation @@ -110,7 +110,7 @@ Implementation @@ -132,7 +132,7 @@ Implementation @@ -154,7 +154,7 @@ Implementation @@ -176,7 +176,7 @@ Implementation @@ -198,7 +198,7 @@ Implementation @@ -220,7 +220,7 @@ Implementation @@ -242,7 +242,7 @@ Implementation @@ -264,7 +264,7 @@ Implementation @@ -286,7 +286,7 @@ Implementation @@ -308,7 +308,7 @@ Implementation @@ -330,7 +330,7 @@ Implementation @@ -352,7 +352,7 @@ Implementation @@ -374,7 +374,7 @@ Implementation @@ -396,7 +396,7 @@ Implementation @@ -418,7 +418,7 @@ Implementation @@ -440,7 +440,7 @@ Implementation @@ -474,7 +474,7 @@ Implementation @@ -496,7 +496,7 @@ Implementation diff --git a/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbWasmCache.mdx b/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbWasmCache.mdx index 085a07fd48..73c955ead9 100644 --- a/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbWasmCache.mdx +++ b/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbWasmCache.mdx @@ -22,7 +22,7 @@ Implementation @@ -44,7 +44,7 @@ Implementation @@ -66,7 +66,7 @@ Implementation @@ -88,7 +88,7 @@ Implementation @@ -113,7 +113,7 @@ Implementation @@ -137,7 +137,7 @@ Implementation @@ -171,7 +171,7 @@ Implementation diff --git a/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbosTest.mdx b/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbosTest.mdx index 0682e6abde..fc81c84140 100644 --- a/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbosTest.mdx +++ b/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbosTest.mdx @@ -22,7 +22,7 @@ Implementation diff --git a/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_NodeInterface.mdx b/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_NodeInterface.mdx index 7e138ba054..b6c38c784e 100644 --- a/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_NodeInterface.mdx +++ b/arbitrum-docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_NodeInterface.mdx @@ -25,7 +25,7 @@ Implementation @@ -47,7 +47,7 @@ Implementation @@ -69,7 +69,7 @@ Implementation @@ -91,7 +91,7 @@ Implementation @@ -115,7 +115,7 @@ Implementation @@ -137,7 +137,7 @@ Implementation @@ -159,7 +159,7 @@ Implementation @@ -181,7 +181,7 @@ Implementation @@ -203,7 +203,7 @@ Implementation @@ -225,7 +225,7 @@ Implementation diff --git a/arbitrum-docs/how-arbitrum-works/02-transaction-lifecycle.mdx b/arbitrum-docs/how-arbitrum-works/02-transaction-lifecycle.mdx index fccc82e8f6..2fdbfae0d0 100644 --- a/arbitrum-docs/how-arbitrum-works/02-transaction-lifecycle.mdx +++ b/arbitrum-docs/how-arbitrum-works/02-transaction-lifecycle.mdx @@ -2,7 +2,7 @@ title: Sequencing, Followed by Deterministic Execution description: 'Learn the fundamentals of the Arbitrum Transaction Lifecycle, sequencing, and deterministic execution.' author: pete-vielhaber -sme: Mehdi +sme: gmehta2 user_story: As a current or prospective Arbitrum user, I need to learn more about the transaction lifecycle. content_type: get-started --- diff --git a/arbitrum-docs/how-arbitrum-works/03-sequencer.mdx b/arbitrum-docs/how-arbitrum-works/03-sequencer.mdx index 6b3969fac1..bbcae70d6a 100644 --- a/arbitrum-docs/how-arbitrum-works/03-sequencer.mdx +++ b/arbitrum-docs/how-arbitrum-works/03-sequencer.mdx @@ -2,7 +2,7 @@ title: The Sequencer and Censorship Resistance description: 'Learn the fundamentals of the Arbitrum Sequencer.' author: pete-vielhaber -sme: Mehdi +sme: gmehta2 user_story: As a current or prospective Arbitrum user, I need to learn more about the Sequencer. content_type: get-started --- diff --git a/website/archive/how-arbitrum-works/05-separating-execution-from-proving.mdx b/arbitrum-docs/how-arbitrum-works/05-separating-execution-from-proving.mdx similarity index 100% rename from website/archive/how-arbitrum-works/05-separating-execution-from-proving.mdx rename to arbitrum-docs/how-arbitrum-works/05-separating-execution-from-proving.mdx diff --git a/arbitrum-docs/how-arbitrum-works/05-validation-and-proving/01-validation-and-proving.mdx b/arbitrum-docs/how-arbitrum-works/05-validation-and-proving/01-validation-and-proving.mdx deleted file mode 100644 index bc55188bed..0000000000 --- a/arbitrum-docs/how-arbitrum-works/05-validation-and-proving/01-validation-and-proving.mdx +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Validation and Proving Mechanisms -description: 'Learn the fundamentals of validation and proving mechanisms on Arbitrum.' -author: pete-vielhaber -sme: Mehdi -user_story: As a current or prospective Arbitrum user, I need to learn more about validation and proving mechanisms. -content_type: get-started ---- - -The validation and proving mechanism in Arbitrum ensures the integrity of offchain execution while maintaining Ethereum's security guarantees. As an Optimistic Rollup, Arbitrum assumes that transactions execute correctly unless challenged. Arbitrum employs interactive fraud proofs to resolve conflicts efficiently, if a dispute arises. - -At the core of Arbitrum's validation model is the separation of execution and proving: transactions execute optimistically, while state transitions can be verified onchain if necessary. Arbitrum achieves this through WAVM (WebAssembly for Arbitrum Virtual Machine), a modified WASM format optimized for proving, and the BoLD dispute protocol, which resolves disagreements using an interactive, multi-round challenge system. - -This section will explore two primary topics: - -## [Rollup protocol and validation](/how-arbitrum-works/05-validation-and-proving/02-rollup-protocol.mdx) - -Reviews how Arbitrum records and validates transactions, the role of validators, and the mechanics of state confirmations. - -## [Proving and challenge protocols](/how-arbitrum-works/05-validation-and-proving/03-proving-and-challenges.mdx) - -Discusses how the protocol handles resolving disputes using interactive proofs and narrowing conflicts down to a single execution step. diff --git a/arbitrum-docs/how-arbitrum-works/05-validation-and-proving/02-rollup-protocol.mdx b/arbitrum-docs/how-arbitrum-works/05-validation-and-proving/02-rollup-protocol.mdx deleted file mode 100644 index 11fac9dd7f..0000000000 --- a/arbitrum-docs/how-arbitrum-works/05-validation-and-proving/02-rollup-protocol.mdx +++ /dev/null @@ -1,272 +0,0 @@ ---- -title: Rollup Protocol and Validation -description: 'Learn the fundamentals of the Arbitrum Rollup Protocol and validation.' -author: pete-vielhaber -sme: Mehdi -user_story: As a current or prospective Arbitrum user, I need to learn more about the Rollup protocol and validation. -content_type: get-started ---- - -import ImageZoom from '@site/src/components/ImageZoom'; - -Arbitrum operates as an Optimistic Rollup, which advances the chain's -state based on transaction assertions unless a dispute arises. -This approach enables scalability, lower costs, and high throughput while maintaining security through -Ethereum's trustless validation model. - -Optimistic Rollups work by separating execution from proving to ensure efficient transaction processing without immediate validation. The execution process is covered in detail in the [State Transition Function](/how-arbitrum-works/04-state-transition-function/01-stf-gentle-intro.mdx). This section focuses on validation and proving mechanisms. We will cover how child chain validators confirm the chain's state and how assertions are posted to parent chain for finalization, with the potential for future challenges if an assertion is determined to be incorrect. - -## Execution vs. proving: Separating responsibilities - -A fundamental design choice in Arbitrum is the separation of execution from proving, which allows for: - -#### Efficient execution - -Transactions are processed optimistically without immediate verification. - -#### Deterministic proving - -If challenged, state transitions are replayable and verified onchain. - -To achieve this, Arbitrum compiles the State Transition Function (STF) into different formats: - -#### Execution mode - -Uses Go's native compiler for high-performance execution on validator nodes. - -#### Proving mode - -Compiles to WebAssembly (WASM), which transforms into WebAssembly for Arbitrum Virtual Machine (WAVM) for fraud-proof verification. - -This dual compilation approach ensures that Arbitrum nodes execute transactions efficiently while allowing deterministic trustless verification on parent chain. - -### Stylus execution and proving - -Stylus extends Arbitrum's execution model by enabling WASM-based -smart contracts. While execution occurs natively in WAVM, the proving process follows the same interactive -fraud-proof mechanism as the EVM, ensuring Stylus transactions are challengeable and deterministically -verifiable. Fraud proofs for Stylus transactions involve WAVM opcode evaluation, leveraging Arbitrum's -existing one-step proof (OSP) system. - -## The role of validators and the Rollup chain - -Arbitrum's Rollup Protocol relies on validators––network participants responsible for ensuring state correctness. The protocol enforces security through the following principles: - -#### Permissionless validation - -Anyone can become a validator by running an Arbitrum node. - -#### Trustless verification - -Validators confirm assertions, ensuring transactions adhere to protocol rules. - -#### Fraud-proof system - -If an incorrect assertion is detected, validators can challenge it and trigger an interactive fraud-proof. - -Validators interact with the Rollup chain, a sequence of assertions representing state updates. Each assertion includes: - -#### Predecessor assertion - -The last confirmed valid state. - -#### State transition output - -The result of applying transactions. - -#### Inbox message consumption - -A record of processed messages from the parent chain. - -#### Execution claim - -A cryptographic commitment to the computed state. - -### Assertions progress through different stages: - -#### Proposed - -A validator submits a state assertion. - -#### Challenged (if necessary) - -If another validator disputes the assertion, an interactive fraud-proof initiates. - -#### Confirmed - -It becomes final if no one challenges the assertion within the dispute window (6.4 days). - -This model ensures that as long at least one honest validator participates, the correct execution will always be confirmed. - -## Arbitrum Rollup protocol - -Before diving into the Rollup protocol, it is important to clarify two key points: - -1. End users and developers do not need to interact with the Rollup Protocol. - - Like a train passenger relying on the engine without needing to understand its mechanics, users, and developers can interact with Arbitrum without engaging with the validation process. -2. The protocol does not determine transaction results, it only confirms them. - - The ordered sequence of messages in the chain's inbox dictates the transaction outcomes. The protocol ensures correctness and finality but does not alter execution results. - -Since transaction execution is deterministic, the Rollup Protocol exists to confirm results and prevent fraud. This mechanism serves two key purposes: - -- **Detecting dishonest behavior**: If a validator submits an incorrect state, others can challenge it. -- **Anchoring Rollup state to the parent chain**: The parent chain itself does not execute every child chain transaction but serves as the final arbiter of state correctness. - -## Validators and assertions in the Rollup protocol - -Validators play a central role in maintaining Arbitrum's integrity. Some validators act as proposers, submitting assertions to Ethereum and placing a `WETH` bond as collateral. If their assertion is determined to be incorrect, they lose their bond. - -Since at least one honest validator can always confirm the correct state, Arbitrum remains as trustless as Ethereum. - -### The Rollup chain assertions vs. child chain blocks - -The Rollup chain consists of assertions, which serve as checkpoints summarizing multiple child chain blocks. - -- Child chain blocks contain individual transaction data -- Assertions provide state summaries recorded on Ethereum -- Each assertion may represent multiple child chain blocks, optimizing gas costs and reducing Ethereum storage usage. - -Validators submit assertions by calling `createNewAssertion` in the Rollup contract. Assertions contain structured data known as `AssertionInputs`, which capture the before-state and after-state of execution for future validation. - -### Contents of an assertion - -Each assertion consists of: - -- **Assertion number**: A unique identifier -- **Predecessor assertion**: The last confirmed assertion -- **Number of child chain blocks**: The total child chain blocks included -- **Number of inbox messages**: Messages consumed during execution -- **Output hash**: A cryptographic commitment to the resulting state. - -Arbitrum ensures assertions are automatically confirmed or rejected based on protocol rules: - -1. An assertion is confirmed if: - - Its predecessor is the latest confirmed assertion. - - The dispute window has passed without challenges. -2. An assertion is rejected if: - - Its predecessor assertion is invalid. - - A conflicting assertion has been confirmed. - -For more details on how the Rollup chain works under BoLD, the [gentle introduction](/how-arbitrum-works/bold/gentle-introduction.mdx) provides an overview that touches on the Rollup chain. - -:::note - -Validators and proposers serve different roles. Validators validate transactions by computing the next chain state using the chain's STF, whereas proposers can also assert and challenge the chain state on the parent chain. - -::: - -Except for the assertion number, the contents of the assertion are all just claims by the assertion's proposer. Arbitrum doesn't know at first whether any of these fields are correct. The protocol should eventually confirm the assertion if all of these fields are correct. The protocol should eventually reject the assertion if one or more of these fields are incorrect. - -An assertion implicitly claims that its predecessor assertion is correct, which means that it also claims the correctness of a complete history of the chain: a sequence of ancestor assertions that reaches back to the birth of the chain. - -An assertion also implicitly claims that its older siblings (older assertions with the same predecessor), if there are any, are incorrect. If two assertions are siblings, and the older sibling is correct––then the younger sibling is considered incorrect, even if everything else in the younger sibling is true. - -The assertion is assigned a deadline, which indicates how much time other validators have to respond to it. For an assertion `R` with no older siblings, this will equal the time the assertion was posted, plus an interval of time known as the challenge Period; subsequent younger siblings will have the same deadline as their oldest sibling (`R`). You don't need to do anything if you're a validator and agree that an assertion is correct. If you disagree with an assertion, you can post another assertion with a different result, and you'll probably end up in a challenge against the party who proposed the first assertion (or another party acting in support of that assertion). More on challenges below: - -In the normal case, the Rollup chain will look like this: - - - -On the left, representing an earlier part of the chain's history, we have confirmed assertions. These have been fully accepted and recorded by the parent chain contracts that manage the chain. The newest of the confirmed assertions, assertion 94, is called the "latest confirmed assertion." - -On the right, we see a set of newer proposed assertions. The protocol can't yet confirm or reject them because their deadlines haven't run out yet. The oldest assertion whose fate has yet to be determined, assertion 95, is called the "first unresolved assertion." - -Notice that a proposed assertion can build on an earlier proposed assertion. This process allows validators to continue proposing assertions without waiting for the protocol to confirm the previous one. Normally, all of the proposed assertions will be valid, so they will all eventually be accepted. - -Here's another example of what the chain state might look like if several validators are being malicious. It's a contrived example designed to illustrate a variety of cases that can come up in the protocol, all smashed into a single scenario. - - - -There's a lot going on here, so let's unpack it: - -- Assertion 100 was confirmed. -- Assertion 101 claimed to be a correct successor to assertion 100, but 101 was rejected. -- Assertion 102 eventually receives confirmation as the correct successor to 100. -- Assertion 103 was confirmed and is now the latest confirmed assertion. -- Assertion 104 was proposed as a successor to assertion 103, and 105 was proposed as a successor to 104. 104 was rejected as incorrect, consequently, 105 was rejected because its predecessor was rejected. -- Assertion 106 is unresolved. It claims to be a correct successor to assertion 103 but the protocol hasn't yet decided whether to confirm or reject it. It is the first unresolved assertion. -- Assertions 107 and 108 claim to chain from 106. They are also unresolved. If 106 gets rejected, they will be automatically rejected too. -- Assertion 109 disagrees with assertion 106 because they both claim the same predecessor. At least one of them will eventually be rejected, but the protocol hasn't yet resolved them. -- Assertion 110 claims to follow 109. It is unresolved. If 109 gets rejected, 110 will be automatically rejected too. -- Assertion 111 claims to follow 104. 111 will inevitably get rejected because its predecessor has already been rejected. However, it remains active, because the protocol resolves assertions in assertion number order, so the protocol will have to resolve 106 through 110 in order, before it can resolve 111. After 110 resolves, the protocol will immediately reject 111. - -Again this sort of thing is very unlikely in practice. In this diagram, at least four different bonds are on incorrect assertions, and when the dust settles, at least four bonds will be forfeited. The protocol handles these cases correctly, but they're rare corner cases. This diagram illustrates the possible situations that are possible in principle and how the protocol would deal with them. - -## Delays - -Even if the Assertion Tree has multiple conflicting assertions and multiple disputes are in progress, validators can continue making new assertions. Honest validators will build on one valid assertion (intuitively, an assertion is also an implicit claim of the validity of all of its parent assertions). Likewise, users can continue transacting on the child chain since transactions will continue to post in the chain's inbox. - -The only delay users experience during a dispute is their [Child to parent chain messages](/how-arbitrum-works/11-l2-to-l1-messaging.mdx) (i.e., withdrawals). A key property of BoLD is that we can guarantee that, in the common case, their withdrawals/messages will only get delayed for one challenge period. In the case of an actual dispute, the withdrawals/messages will be delayed by no more than two challenge periods, regardless of the adversaries' behavior during the challenge. - -## Who will be validators? - -Anyone can do it, but most people will choose not to. In practice, we expect people to validate a chain for several reasons. - -- It is possible to pay validators for their work by the party that created the chain or someone else. A chain is configurable, so some of the funds from user transaction fees are paid directly to validators. -- Parties with significant assets at bond on a chain, such as dApp developers, exchanges, power users, and liquidity providers, may choose to validate in order to protect their investment. -- Anyone who wants to validate can do so. Some users may choose to validate to protect their interests or be good citizens. But ordinary users don't need to validate, and we expect most users won't. - -### Staking and validator incentives - -Arbitrum requires validators to stake `ETH` as a security deposit to ensure honest participation and prevent malicious behavior. This mechanism enforces economic accountability: - -- **Proposers** (validators submitting assertions) must bond `ETH` to support their claims. -- **Challenges** against incorrect assertions result in bond forfeiture for dishonest validators. -- **Successful challengers** receive a portion of the dishonest validator's bond as a reward. - -Validators can adopt different roles: - -1. **Active validators**: Regularly propose new assertions. -2. **Defensive validators**: Monitor the network and challenge incorrect assertions. -3. **Watchtower validators**: Passively observe and raise alarms when fraud is detected. - -The protocol design requires only one honest validator to secure the system, making Arbitrum trustless and resistant to Sybil attacks. - -### Staking mechanism - -Some validators will act as bonders (staked participants) at any given time, while others remain passive. Bonders deposit `ETH` bonds into Arbitrum's smart contracts, which are forfeited if they lose a challenge. - -:::note - -Nitro chains exclusively accept `ETH` as collateral for staking. - -::: - -A single bond can secure a sequence of assertions, meaning a validator's stake applies to multiple checkpoints of the chain's history. This checkpoint allows efficient resource use while maintaining security. - -A validator must be bonded to its predecessor to create a new assertion. The bond ensures that validators have economic risk in any assertion they make. - -### Staking rules - -1. **New validators**: If unbonded, a validator can stake on the latest confirmed assertion by depositing the required `ETH` bond. -2. **Extending an existing bond**: The validator can extend its bond to one successor assertion if already bonded. - If a validator submits a new assertion, they automatically extend their existing bond to cover it. -3. **Unbonding**: A validator can only request a refund if they have a bond on the latest confirmed assertion. -4. **Losing a challenge**: If a validator's assertion is challenged successfully (i.e., they are malicious), they lose **all** their bonded `ETH` across any unresolved assertions. - -Since unbonding is not allowed mid-assertion validators must commit until their assertion is confirmed or disproven. - -### Handling disputes and delays - -Multiple disputes may be active simultaneously if conflicting assertions arise in the Assertion Tree. However, Arbitrum's protocol ensures that: - -- **Honest validators can continue asserting**, building on the last correct assertion. -- **Users can keep transacting** on the child chain without disruption. -- **Child-to-parent chain withdrawals** may experience delays - Typically, withdrawals experience a single challenge period (6.4 days) delay. - A key property of BoLD is that we can guarantee that in the common case, withdrawals/messages will only experience delay of one challenge period. In the case of an actual dispute, the withdrawals/messages will be delayed by no more than two challenge periods, regardless of the adversaries' behavior during the challenge. - -Despite these delays, Arbitrum guarantees that honest assertions always succeed, maintaining Ethereum-level security. - -### Who becomes a validator? - -Arbitrum's validation process is permissionless, allowing anyone to participate. However, in practice, most users will not act as validators. - -Common validator motivations include: - -- **Financial incentives**: Some validators receive payment from network fees or the chain's owner. -- **Asset protection**: dApp developers, exchanges, and liquidity providers may validate the chain to protect their holdings. -- **Public interest**: Some participants validate purely for network integrity, ensuring fair execution. - -For most users, validation is unnecessary, as the network relies on economic incentives and fraud-proof mechanisms to maintain security. diff --git a/arbitrum-docs/how-arbitrum-works/05-validation-and-proving/03-proving-and-challenges.mdx b/arbitrum-docs/how-arbitrum-works/05-validation-and-proving/03-proving-and-challenges.mdx deleted file mode 100644 index 799de43d7d..0000000000 --- a/arbitrum-docs/how-arbitrum-works/05-validation-and-proving/03-proving-and-challenges.mdx +++ /dev/null @@ -1,444 +0,0 @@ ---- -title: Proving and Challenge Protocol -description: 'Learn the fundamentals of the Arbitrum proving and challenge protocols' -author: pete-vielhaber -sme: Mehdi -user_story: As a current or prospective Arbitrum user, I need to learn more about the Arbitrum proving and challenge protocols. -content_type: get-started ---- - -import ImageZoom from '@site/src/components/ImageZoom'; - -This document details the mechanisms for proving correct execution and resolving disputes in the Rollup Protocol. It explains how the system separates ordinary execution from proving, transforms WASM into a specialized proving format (WAVM), and employs interactive fraud proofs to resolve disputes efficiently. - -## 1. Separating execution from proving - - - -One of the key challenges in designing a practical Rollup system is balancing fast, ordinary execution with the need for reliable proofs of that execution. Nitro addresses this challenge by using the same source code for both purposes but compiling it to different targets: - -- **Execution compilation**: - - The [Nitro node software](https://github.com/OffchainLabs/nitro) is compiled with the ordinary Go compiler into native code for the target architecture. - - This native binary is distributed as source code and as a Docker image, making it deployable on various nodes. -- **Proving compilation**: - - For proving, only the portion of the code that is the State Transition Function (STF) gets compiled by the Go compiler into WebAssembly (WASM). - - The generated WASM code transforms into a specialized format called WAVM. - - In any dispute regarding the STF, the WAVM code is referenced to resolve the correct result. - -## 2. WAVM: A specialized proving format - -WAVM is a modified version of WASM designed to meet the needs of fraud proofs. The following features describe it: - -- **Portability and Structure**: - - WASM was selected because it is portable, well-specified, and supported by robust tools. -- **Modifications made in WAVM**: - - **Removal of unused features**: - - WAVM removes some WASM features that the Go compiler never generates. The transformation phase ensures these features are absent. - - **Restrictions on certain features**: - - Floating-point instructions: WAVM does not contain floating-point instructions. Instead, any floating-point operations get replaced by calls to the Berkeley SoftFloat library. - - Rationale: Using software floating-point libraries reduces the risk of incompatibilities between different architecture. - - **Nested control flow**: - - WAVM flattens control flow constructs by converting them into jump instructions. - - **Variable-time instructions**: - -Some instructions in WASM may take a variable amount of time to execute. WAVM transforms these into constructs with fixed-cost instructions to simplify proving. - - **Additional opcodes for blockchain interaction**: - - WAVM adds new opcodes to enable the code to interact with the blockchain environment. - - For example, new instructions allow the WAVM code to read and write the chain's global state, retrieve the next message from the chain's inbox, or signal a successful end to the STF execution. - -## 3. `ReadPreImage` and the hash oracle trick - -An interesting instruction in WAVM is `ReadPreImage`, which the "hash oracle trick" uses. This mechanism works as follows: - -- **Functionality of `ReadPreImage`**: - - **Input**: A hash `H` and an offset `I`. - - **Output**: The word of data at offset `I` in the preimage of `H` along with the number of bytes written (zero if `I` is at or beyond the end). -- **Constraints for safety**: - - Generating a preimage for an arbitrary hash is infeasible. Therefore, the instruction is allowed only when: - - The preimage is publicly known - - The preimage's size is known to be less than a fixed upper bound (approximately 110 kbytes). -- **Usage examples in Nitro**: - - **State tree access**: - - Nitro's state tree is stored offchain as a Merkle tree, with nodes indexed by their Merkle hashes. - - The STF only stores the root hash but can retrieve any node's contents using `ReadPreImage`. - - **Block headers**: - - The instruction fetches recent publicly known child chain block headers of bounded size. - -:::info Historical Note - -This "hash oracle trick" originates from the original Arbitrum design, where the Merkle hash of a data structure is stored and full contents are retrievable on demand. - -::: - -## 4. Resolving disputes using interactive fraud proofs - -Disputes resolution in optimistic Rollups is a critical design decision. The protocol must decide which execution version is correct when two parties disagree. - -### 4.1 Overview of dispute resolution - -- **Optimistic Rollups**: - - Assume that assertions about execution are correct unless challenged. -- **Dispute Resolution Options**: - - **Interactive proving**: - - Parties engage in a challenge game to narrow down the dispute executed steps. - - **Re-executing transactions**: - - The parent chain re-executes transactions, checking each state transition. - -:::note - -Zero-knowledge Rollups avoid the dispute situation by directly proving correctness via ZK proofs. - -::: - -### 4.2 Interactive proving - -Arbitrum favors interactive proving due to its efficiency and flexibility. - - - -#### The interactive proving process - -1. **Initial claim and dispute start**: - - Suppose Alice claims that the chain will produce a specific result. Bob disagrees. -2. **Bisection of the dispute**: - - **First round**: - - Alice posts an assertion covering `N` steps. - - Bob challenges the assertion. - - Alice then provides two sub-assertions, each covering `N/2` steps. - - **Subsequent rounds**: - - Bob chooses one half to challenge, and the process repeats––halving the disputed steps until only a single instruction remains. -3. **Final one-step proof**: - - Once the dispute narrows to a single execution step, the parent chain referee verifies that one-step claim. - -#### Simplified bisection protocol - -- **Step-by-step breakdown**: - - Alice provides a commitment to the entire computation history. - - She bisects her claim into two halves. - - Bob selects the half he disputes. - - This iteration of the bisection continues until the dispute reaches a single instruction. - -#### Why bisection correctly identifies a cheater - -1. **If Alice's claim is correct**: - - Every bisection provides truthful intermediate states. - - Bob's challenge eventually leads to a correct one-step proof, allowing Alice to win. -2. **If Alice's claim is incorrect**: - - One of Alice's halves will be false at some bisection. - - Bob can always choose the incorrect half, ultimately forcing an incorrect one-step proof that is not verifiable. - - Thus, an honest party will always be able to challenge a dishonest claim. - -### 4.3 Re-executing transactions (alternative approach) - -- **Mechanism**: - - Each transaction would include a state hash after its execution. - - In case of a dispute, the parent chain would re-execute every transaction to verify the correctness. -- **Drawbacks**: - - Requires a state claim for every transaction, increasing computational load. - - In a dispute, the entire transaction must be re-executed onchain, leading to high gas costs. - -:::info - -Interactive proving is more efficient in optimistic and pessimistic cases, as it minimizes onchain computation and adapts to Ethereum's gas limits. - -::: - -## 5. Interactive fraud proofs and the challenge protocol - -Interactive fraud proofs form the basis for resolving proposer disputes when conflicting assertions are made. - -### 5.1 Dispute scenario - -- **Example setup**: - - Suppose the Rollup chain includes assertions 93 and 95, which are siblings (both following assertion 92). - - Alice is bonded on assertion 93, while Bob is bonded on assertion 95. - - Bob's bonding on 95 implies that assertion 93 must be incorrect. -- **Initiation of the challenge**: - - An interactive challenge is initiated automatically when two proposers place bonds on sibling assertions. - - Multiple assertions may participate in a single challenge. - - The protocol records and referees the challenge and eventually declares a winner, confiscating the bonds of the losing parties and removing them as proposers. - -### 5.2 The two-phase challenge game - -1. **Bisection phase**: - - The goal is to narrow the dispute to a single execution step. - - At each stage, claims are bisected into smaller segments (first over child chain blocks, then over "big steps" of 2²⁶ instructions, and finally to a single instruction). - - The parent chain referee only checks that the moves have "the right shape" (e.g., that the bisection was performed correctly) without evaluating the correctness of execution. -2. **One-step proof phase**: - - Once the dispute reduces to one instruction, any player can initiate the one-step proof. - - The parent chain executes the disputed instruction using the proof data provided. - - If the one-step proof is correct, the disputed edge is confirmed, and the challenges resolves. - -### 5.3 Efficiency considerations - -- **Optimistic case**: - - Interactive proving allows a single assertion to cover all transactions in a block. -- **Pessimistic case**: - - Only one instruction is re-executed onchain during a dispute. -- **Gas limits**: - - The interactive proving model can work with higher per-transaction gas limits since most work is done offchain. -- **Implementation flexibility**: - - The system only requires verification a one-step proof onchain, rather than full transaction re-execution. - -### 5.4 `ChallengeManager`: The arbiter - - - -- **Role**: - - The `ChallengeManager` contract arbitrates the challenge game. - - It tracks assertion histories, timers, and state commitments. -- **State machine**: - - A state machine represents the challenge with several distinct phases: - - **Block challenge**: - - The challenge begins by bisecting over global states (including block hashes) to narrow down the dispute to a single block. - - **Big-step execution challenge**: - - Upon identifying the block, the execution challenge bisects a "chunk" of 2²⁶ instructions. - - **Small-step execution challenge**: - - This phase bisects the chunk until the dispute narrows to a single instruction. - - **One-step proof**: - - A final onchain one-step proof confirms the disputed instruction. -- **Winning the challenge**: - - Winning is not instantaneous; a built-in time delay safeguards against erroneous challenge resolutions. - - This delay allows time for diagnosing and correcting errors via contract upgrades if necessary. - -## 6. One-step proof assumptions - -The one-step proof (OSP) is the final arbiter of a single disputed instruction. Its design accounts for several key assumptions: - -### 6.1 Assumptions for correct execution - -- **Correct cases**: - - In a challenge involving at least one honest party, the honest side will always prove a reachable case. - - An arbitrator generates the WAVM code (from a valid WASM compile) and should not encounter unreachable cases in correct execution. - -### 6.2 Handling unreachable cases - -- **Definition**: - - An unreachable case is a situation that is assumed never to arise during correct execution. -- **Behavior in malicious challenges**: - - In challenges between malicious assertions, unreachable cases may occur and can be handled arbitrarily by the one-step proof. -- **Safety in honest challenges**: - - An honest party never needs to prove an unreachable case. - - If a dishonest party attempts to force an unreachable case, it will be preceded by an invalid reachable case, ensuring that the dishonest party eventually loses the challenge. - -### 6.3 Additional safety assumptions - -- **WAVM code validity**: - - The WAVM code produced by the arbitrator comes from valid WASM compile. It is checked using `wasm-validate` from the WebAssembly Binary Toolkit (WABT). -- **Inbox message size**: - - Inbox messages must be small enough (no larger than 117,964 bytes) to be fully available for proving. -- **Preimage requests**: - - Preimages requested via `ReadPreImage` must be known and within the size limit (117,964 bytes). - - Examples include block headers, state trie nodes, and recent child chain block headers. - -## 7. WASM to WAVM transformation - -Not all WASM instructions are mapped directly 1:1 to WAVM opcodes. The transformation design simplifies execution for proving and enables additional blockchain interactions. - -### 7.1 Transformation process overview - -- **Source**: - - The Go compiler produces WASM code. -- **Transformation**: - - A simple transformation stage converts the WASM code into WAVM code. -- **Purpose**: - - Ensure that the WAVM code is free from unused features, restricted in its functionality where necessary, and augmented with additional opcodes for blockchain interaction. - -### 7.2 Key differences between WASM and WAVM - -- **Removed features**: - - Any WASM features not generated by the Go compiler are removed. -- **Restricted features**: - - Berkeley SoftFloat library calls replace floating-point instructions. - - The nested control flow flattens into jumps. - - Variable-time instructions transform into fixed-cost instructions. -- **Added opcodes**: - - New opcodes additions for interacting with the blockchain (e.g., reading global state, fetching inbox messages, signaling completion). - -### 7.3 Translation of specific WASM constructs - -- **Block and loop**: - - In WASM, blocks contain instructions and branch instructions for exiting blocks. - - In WAVM, since instructions are flat, branch instructions are replaced with jumps to predetermined destinations. -- **If and Else**: - - Translated into a block with an `ArbitraryJumpIf` instructions. - - **Structure example**: - - Begin block with endpoint `end` - - Conditional jump to `else` block - - [if-statement instructions] - - Unconditional branch (to skip else) - - `Else` block: [else-statement instructions] - - `End` block -- **Branch instructions (`br` and `br_if`)**: - - Translated into `ArbitraryJump` and `ArbitraryJumpIf` with jump destinations known at compile time. -- **Branch table (`br_table`)**: - - Translated to a series of conditional checks for each possible branch, with a default branch if no conditions are met. -- **`Local.tee`**: - - Implemented by duplicating the local value (using a `Dup` opcode) followed by a `LocalSet`. -- **Return**: - - The function signature knows the number of return values: - - A `MoveFromStackToInternal` opcode is added for each return value. - - A loop uses `IsStackBoundary` to clean up the stack. - - Finally, `MoveFromInternalToStack` opcodes are added for each return value, followed by a `Return` opcode. -- **Floating-point instructions**: - - `f32` and `f64` values are bitcast to `i32` and `i64`. - - Cross-module calls go to the floating-point library. - - Return values are bitcast back to floating-point types. - -### 7.4 WAVM custom opcodes not in WASM - -WAVM includes several unique opcodes that simplifying proving. They breakdown into several categories: - -#### Invariants and Codegen internal opcodes - -- **General assumptions**: - - Many opcodes assume specific items on the stack (e.g., "pops an `i32" means the top stack item must be an `i32`). - - WASM validation and arbitrator code generation maintain these invariants. -- **Examples of custom opcodes**: - -| Opcode | Name | Description | -| ------ | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| 0x8000 | `EndBlock` | Pops an item from the block stack. | -| 0x8001 | `EndBlockIf` | Peeks the top value (assumed `i32`) and, if non-zero, pops an item from the block stack. | -| 0x8002 | `InitFrame` | Pops a caller module index (`i32`), a caller module internals offset (`i32`), and a return `InternalRef`; creates a stack frame with these details and the locals Merkle root. | -| 0x8003 | `ArbitraryJumpIf` | Pops an `i32`; if non-zero, jumps to the program counter provided in the argument data. | -| 0x8004 | `PushStackBoundary` | Pushes a stack boundary marker onto the stack. | -| 0x8005 | `MoveFromStackToInternal` | Pops an item from the stack and pushes it to an internal stack. | -| 0x8006 | `MoveFromInternalToStack` | Pops an item from the internal stack and pushes it back onto the stack. | -| 0x8007 | `IsStackBoundary` | Pops an item from the stack; if it is a stack boundary, pushes an `i32` with value 1; otherwise, 0. | -| 0x8008 | `Dup` | Peeks at the top stack item and pushes a duplicate. | - -#### Linking opcode - -- **Purpose**: - - Generated for linking modules together: -- **Opcode**: - -| Opcode | Name | Description | -| ------ | ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 0x8009 | `CrossModuleCall` | Pushes current program counter, module number, and module internals offset; splits the argument data into function index and module index; jumps to the beginning of that function. | - -#### Host calls - -- **Used in host call implementations**: - - They enable libraries to perform host calls and access the caller's memory. -- **Examples of host call opcodes**: - -| Opcode | Name | Description | -| ------ | -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 0x800A | `CallerModuleInternalCall` | Pushes the current program counter, module number, and module internals offset; retrieves caller module internals offset; jumps to caller module function if valid, otherwise errors. | -| 0x8010 | `GetGlobalStateBytes32` | Pops a pointer and index; writes the global state bytes32 value (if all alignment and bounds checks pass) to the pointer. | -| 0x8011 | `SetGlobalStateBytes32` | Pops a pointer and index; reads a bytes32 value from memory and writes it into the global state. | -| 0x8012 | `GetGlobalStateU64` | Pops a pointer and index; writes the global state u64 value to memory (with alignment and bounds checking). | -| 0x8013 | SetGlobalStateU64 | Pops a pointer and index; reads a u64 from memory and writes it into the global state. | -| 0x8020 | `ReadPreImage` | Pops an offset and pointer; reads a 32-byte Keccak-256 hash from memory; writes up to 32 bytes of its preimage starting from the offset; pushes the number of bytes written. | -| 0x8021 | `ReadInboxMessage` | Pops an offset, pointer, and i64 message number; attempts to read an inbox message; if out-of-bounds, enters a “too far” state; writes up to 32 bytes and pushes the number of bytes written. | -| 0x8022 | `HaltAndSetFinished` | Sets the machine status to finished, halting execution and marking it as successful. | - -## 8. WAVM floating-point implementation - -Floating-point operations in WAVM are handled differently to ensure determinism and consistency: - -- **Implementation using Berkeley SoftFloat**: - - Instead of implementation IEEE 754-2019 directly in WAVM, floating-point instructions are replaced with calls to the Berkeley SoftFloat-3e library. - - The soft float library is linked, and floating-point operations are implemented via cross-module calls. -- **Known divergences**: - - For example, floating-point to integer truncation will saturate on overflow (instead of erroring), which is safer and more consistent with x86 behavior. - - These divergences follow proposals (e.g., saturating opcodes) that are not yet widely adopted. - -## 9. WAVM modules and linking - -WASM's notion of modules is extended in WAVM to support multi-module programs. This extension allows: - -### 9.1 Entrypoint module - -- **Definition**: - - The entry point module is the starting point of execution. -- **Behavior**: - - It calls any modules' start functions if specified. - - If then calls the main module's `main` function: - - **For Go**: - - Sets `argv` to `["js"]` (to mimic the JS environment) and calls `run`. - - **For Rust**: - - Simply calls `main` with no arguments. - -### 9.2 Library exports - -- **Export naming convention**: - - Libraries export function using the pattern `module__name`. - - This convention allows future libraries or the main module to import these functions. -- **Example**: - - The `wasi-stub` library provides functions that Rust imports, adhering to the WebAssembly System Interface (WASI). - -### 9.3 WAVM guest calls - -- **Mechanism**: - - Libraries can call exports of the main module using the naming scheme `"env"` `"wavm_guest_call__*"`. -- **Usage example**: - - `go-stub` calls Go's resume function when queueing asynchronous events via `wavm_guest_call_resume()`, and retrieves the new stack pointer with `wavm_guest_call_getsp()`. - -### 9.4 Caller module internals call - -- **Purpose**: - - Each stack frame retains information about the caller module and its internals offset. -- **Implementation**: - - WAVM appends four "internal" functions to each module that perform small memory load or store operations. - - Libraries use opcodes such as `wavm_caller_{load,store}{8,32}` to access their caller's memory. - - Only libraries can access their caller's memory; restrictions prevent the main module from doing so. - -## 10. Stylus proving and fraud detection - -Stylus introduces an execution path alongside the EVM, enabling - smart Contract - execution in WebAssembly (WASM). Given that Stylus program are fraud-proven directly rather than -interpreted via Geth's EVM implementation––the proving mechanism required modifications to the standard -Arbitrum proving architecture. - -### 10.1 Proving Stylus programs - -Unlike EVM-based contracts, Stylus programs are dynamically linked into the replay machine when proving fraud. This is achieved through two key opcodes: - -- **`LinkModule`**: Loads the Stylus contract's WASM module into the replay machine. -- **`UnlinkModule`**: Removes the module once execution completes. - -These opcodes ensure that Stylus contracts are treated as part as part of the replay machine, allowing for precise fraud-proof bisection at the WASM level. - -### 10.2 Execution-proving separation - -Stylus leverages Arbitrum's execution-proving separation, where the replay machine runs in WAVM, and disputes over Stylus transactions follow the standard interactive fraud-proof protocol (BoLD), which means: - -1. A challenge initiates if a validator disputes the execution of a Stylus transaction. -2. The dispute narrows to a single WAVM opcode via the bisection protocol. -3. The One-Step Proof (OSP) mechanism extends to handle Stylus-specific operations, proving the correctness of WASM execution at the opcode level. - -### 10.3 Internal function calls in proofs - -Since Stylus programs interact with the blockchain through host I/O's, fraud proofs must ensure correct execution of cross-module calls. The following additional proving opcodes facilitate Stylus program execution: - -- **`CrossModuleInternalCall`**: Allows internal functions within a Stylus module to be proven independently. -- **`CrossModuleForward`**: Ensures host I/O calls are accurately relayed through `forward.wat`, maintaining consistency in fraud proofs. - -### 10.4 Error recovery and chain safety - -Stylus introduces a novel Error Guard mechanism to prevent malicious programs from halting the chain. If an error occurs within a Stylus program during proving: - -1. Execution reverts to the main replay machine context. -2. The replay machine resets the program's execution state using an Error Guard stack. -3. If recovery is not possible, the transaction is flagged as invalid, ensuring Stylus fraud proofs remain deterministic. - -### 10.5 One-Step Proofs for Stylus - -The One-Step Prover extends to validate Stylus-specific opcodes, which include: - -- **Memory operations** (e.g., `MemoryGrow`, `HeapAlloc`) -- **Host I/O's** (e.g., `storage_load_bytes32`, `return_data`) -- **Gas metering** within WASM execution - -By integrating these functionalities, Stylus ensures WASM contract execution can be fraud-proven like EVM transactions, while leveraging Arbitrum's existing BoLD fraud-proof architecture. diff --git a/website/archive/how-arbitrum-works/06-optimistic-rollup.mdx b/arbitrum-docs/how-arbitrum-works/06-optimistic-rollup.mdx similarity index 100% rename from website/archive/how-arbitrum-works/06-optimistic-rollup.mdx rename to arbitrum-docs/how-arbitrum-works/06-optimistic-rollup.mdx diff --git a/website/archive/how-arbitrum-works/07-interactive-fraud-proofs.mdx b/arbitrum-docs/how-arbitrum-works/07-interactive-fraud-proofs.mdx similarity index 100% rename from website/archive/how-arbitrum-works/07-interactive-fraud-proofs.mdx rename to arbitrum-docs/how-arbitrum-works/07-interactive-fraud-proofs.mdx diff --git a/arbitrum-docs/how-arbitrum-works/11-l2-to-l1-messaging.mdx b/arbitrum-docs/how-arbitrum-works/11-l2-to-l1-messaging.mdx index 3bf2a0a010..681c2f8bdf 100644 --- a/arbitrum-docs/how-arbitrum-works/11-l2-to-l1-messaging.mdx +++ b/arbitrum-docs/how-arbitrum-works/11-l2-to-l1-messaging.mdx @@ -4,126 +4,31 @@ description: 'Learn the fundamentals of L2 to L1 messaging on Arbitrum.' author: pete-vielhaber sme: TucksonDev user_story: As a current or prospective Arbitrum user, I need to learn more about messaging between L2 and L1 on Arbitrum. -content_type: concept +content_type: get-started --- -import ImageZoom from '@site/src/components/ImageZoom'; +Arbitrum's Outbox system +allows for arbitrary child chain to parent chain contract calls; i.e., messages initiated from the +child chain which eventually resolve in execution on the parent chain. Child chain-to-parent chain +messages (aka "outgoing" messages) bear many things in common with Arbitrum's [Parent chain-to-child +chain messages](/how-arbitrum-works/10-l1-to-l2-messaging.mdx) (Retryables), "in reverse" though +with a few differences. -Arbitrum's outbox system -allows for arbitrary child chain to - parent chain - contract calls, i.e., messages initiated from the child chain, which eventually resolve in -execution on the parent chain. Child-to-parent chain messages (aka "outgoing" messages) bear some -things in common with Arbitrum's [parent chain to child chain -messages](/how-arbitrum-works/10-l1-to-l2-messaging.mdx), which are "in reverse" though with -differences, which we'll explore in this section. +### Protocol Flow -## Protocol flow +Part of the child chain state of an Arbitrum chain — and consequently, part of every assertion — is a Merkle root of all child chain-to-parent chain messages in the chain's history. Upon an assertion being confirmed (typically ~1 week after its asserted), this Merkle root is posted on parent chain in the `Outbox` contract. The Outbox contract then lets users execute their messages — validating Merkle proofs of inclusion, and tracking which child to parent chain messages have already been spent. -Messages from child to parent are included in Arbitrum's Rollup state and finalized through the Rollup Protocol. The process follows these steps: +### Client Flow -1. **Message creation on child chain**: - - To initiate a child-to-parent chain message, a user or contract calls the `sendTxToL1` method on the `ArbSys` precompile. -2. **Message inclusion in an assertion**: - - The message is batched with other transactions and included in a Rollup assertion. - - Assertions are submitted to the Rollup contract on the parent chain and enter the dispute window (~one week). -3. **Assertion confirmation**: - - If the assertion remains unchallenged after the dispute window, the Rollup contract finalizes the assertion. - - The assertion's Merkle root gets posted to the outbox contract on the parent chain. -4. **Execution on the parent chain**: - - Once the assertion is confirmed, anyone can execute the message on the parent chain by proving its inclusion. - - Execution is possible using `Outbox.executeTransaction`, which takes a Merkle proof proving the message exists in the finalized assertion. +From a Client perspective, a child to parent chain message begins with a call to the child chain [`ArbSys`](/build-decentralized-apps/precompiles/02-reference.mdx#arbsys) precompile contract's `sendTxToL1` method. Once the message is included in an Assertion (typically within ~1 hour) and the assertion is confirmed (typically about ~1 week), any client can execute the message. To do this, the client first retrieves the proof data via a call to the Arbitrum chain's "virtual"/precompile-esque\*\* `NodeInterface` contract's `constructOutboxProof` method. The data returned can then be used in the `Outbox`'s `executeTransaction` method to perform the parent chain execution. -## Client flow (How to send and execute messages) +### Protocol Design Details -### Sending a message from a child to parent chain +An important feature in the design of the Outbox system is that calls to `confirmNode` have constant overhead. Requiring that `confirmNode` only update the constant-sized outgoing message root hash, and that users themselves carry out the final step of execution, achieves this goal; i.e., no matter the number of outgoing messages in the root, or the gas cost of executing them on the parent chain, the cost of confirming nodes remains constant; this ensures that the assertion confirmation processed can't be griefed. -A contract or user sends a message from the child chain by calling: +Unlike Retryables, which have an option to provide Ether for automatic child chain execution, outgoing messages can't provide in-protocol automatic parent chain execution, for the simple reason that Ethereum itself doesn't offer scheduled execution affordances. However, application-layer contracts that interact with the Outbox could in principle be built to provide somewhat-analogous "execution market" functionality for outsourcing the final parent chain execution step. -```solidity -ArbSys(100).sendTxToL1(destAddress, calldata); -``` +Another difference between outgoing messages and Retryables is that Retryables have a limited lifetime before which they must be redeemed (or have their lifetime explicitly extended), whereas child to parent chain messages are stored in parent chain state, and thus persist permanently / have no deadline before which they must be executed. +The week long delay period before outgoing messages can be executed is inherent and fundamental to the nature of Arbitrum rollup, or any optimistic rollup style child chain; the moment a Transaction is published on-chain, any observer can anticipate its result; however, for Ethereum itself to accept its result, the protocol must give time for Arbitrum validators to detect and prove fault if need-be. For a protocol overview, see [How Arbitrum works](/how-arbitrum-works/01-a-gentle-introduction.mdx) -### Executing the message on the parent chain - -After the seven-day Challenge period, if the assertion is confirmed, anyone can execute the message on the parent chain. - -1. **Retrieve proof data**: - - Call the `constructOutboxProof` method from the `NodeInterface` contract to get proof data. - -:::note - -We refer to `NodeInterface` as a "virtual" contract; its methods are accessible via calls `0x00000000000000000000000000000000000000C8`, but it doesn't live onchain. It isn't a precompile but behaves like a precompile that can't receive calls from other contracts. This approach is a cute trick that lets us provide Arbitrum-specific data without implementing a custom RPC. - -::: - -2. **Execute on the parent chain**; - - Call `Outbox.executeTransaction` with the proof data to execute the message on the parent chain. - -## Protocol design details - -### Constant overhead for node confirmation - -- Calling `confirmNode` on the Rollup contract has constant gas overhead, regardless of the number of messages in the assertion. -- This confirmation ensures malicious actors cannot grief the network by submitting assertions with many outgoing messages. - -### Why child to parent chain messages require manual execution - -Unlike [retryable tickets](/how-arbitrum-works/10-l1-to-l2-messaging.mdx), which can execute automatically with pre-funded gas, child-to-parent chain message must undergo manual execution because Ethereum (parent chain) does not support scheduled execution. - -However, applications can implement execution markets that allow third parties to execute messages for a fee. - -### Persistence and expiry - -- **Child-to-parent chain messages**: - Persist indefinitely on the parent chain once included in the outbox. - -## Parent-to-child chain message lifecycle - -Each message progresses through three primary states: -| Stage | Description | -| ------------------------ | ----------- | -| Posted on child chain | The message is sent via `ArbSys.sendTxToL1`. | -| Waiting for finalization | The assertion containing the message is in the challenge period (~6.4 days) | -| Confirmed and executable on the parent chain | If no fraud proof is submitted, the assertion is confirmed, and the message is available for execution in the outbox. | - -## Withdrawing Ether - -Withdrawing Ether can be done using the [ArbSys precompile](/build-decentralized-apps/precompiles/02-reference.mdx#arbsys)'s `withdrawEth` method: - -```solidity -ArbSys(100).withdrawEth{ value: 2300000 }(destAddress) -``` - -Upon withdrawing, the Ether balance is burnt on the child chain side and will later be made available on the parent chain side. - -`ArbSys.withdrawEth` is a convenience function equivalent to calling `ArbSys.sendTxToL1` with empty `calldataForL1`. Like any other `sendTxToL1` call, it will require an additional call to `Outbox.executeTransaction` on the parent chain after the dispute period elapses for the user to finalize claiming their funds on the parent chain. Once the withdraw executes (removed from the outbox), the user's Ether balance will receive credit on the parent chain. - -The following diagram depicts the process that funds follow during a withdrawal operation. - - - -## `ERC-20` token withdrawal - -Arbitrum has a canonical bridge design and architecture, which we explain in detail in the [Token bridging](/how-arbitrum-works/10-l1-to-l2-messaging.mdx#token-bridging) section of Bridging from a parent chain to a child chain article. This section will explain how the Arbitrum canonical bridge works on the child-to-parent chain token bridging. - -1. Initiation of a child-to-parent chain transfer occurs via the `L2GatewayRouter` contract on the child chain. -2. The token's gateway contract (`L2ArbitrumGateway`) on the child chain gets called. -3. `L2ArbitrumGateway` finally communicates to its corresponding gateway contract on the parent chain using the `L1ArbitrumGateway` contract. - - - -For any given gateway pairing, calls have to be initiated through the corresponding router (`L2GatewayRouter`), and the gateways must conform to the `TokenGateway` interfaces; the `TokenGateway` interfaces should be flexible and extensible enough to support any bridging functionality a particular token may require. - -Token withdrawals are the most common usage of child-to-parent chain messaging. The standard withdrawal happens as follows (for standard gateway): - -1. On the child chain, a user calls `L2GatewayRouter.outBoundTransfer`, which calls `outBoundTransfer` on `arbSomeERC20Token`'s gateway (i.e., `L2ERC20Gateway`). -2. This call burns arbSomeERC20Token tokens and calls `ArbSys` with an encoded message to `L1ERC20Gateway.finalizeInboundTransfer`, which will eventually execute on the parent chain. -3. After the dispute window expires and the assertion with the user's transaction receives confirmation, a user can call `Outbox.executeTransaction`, which calls the encoded `L1ERC20Gateway.finalizeInboundTransfer` message, releasing the user's tokens from the `L1ERC20Gateway` contract's escrow. +\*\* We refer to `NodeInterface` as a "virtual" contract; its methods are accessible via calls `0x00000000000000000000000000000000000000C8`, but it doesn't really live on chain. It isn't really a precompile, but behaves a lot like a precompile that can't receive calls from other contracts. This is a cute trick that let's us provide Arbitrum-specific data without having to implement a custom RPC. diff --git a/arbitrum-docs/how-arbitrum-works/bold/bold-technical-deep-dive.mdx b/arbitrum-docs/how-arbitrum-works/bold/bold-technical-deep-dive.mdx index daba1b09b5..b0f539a051 100644 --- a/arbitrum-docs/how-arbitrum-works/bold/bold-technical-deep-dive.mdx +++ b/arbitrum-docs/how-arbitrum-works/bold/bold-technical-deep-dive.mdx @@ -61,7 +61,7 @@ The current implementation of BoLD involves both on-chain and off-chain componen - **Edge:** Edges are a portion of a claim made by a validator about the history of the chain from some end state all the way back to some initial state. Edges are the fundamental unit in a challenge. -- **Fraud proofs:** Proofs that prove or disprove that an invalid state transition has taken place. These proofs are generated by challenge participants and are submitted to a chain's parent chain. For example, Arbitrum Rollups that settle onto Ethereum will have their proofs submitted to Ethereum and verified via a smart contract. In this case, these proofs allow Ethereum to be the final arbiter of disagreements over assertions in the Rollup contracts, which cannot be falsified by any parties as there is only a single, correct result of executing a `WASM` instruction on a pre-state. `WASM` is the assembly language that is used to represent programs whose execution is being disputed. In fact, Arbitrum, before and after BoLD, uses a slightly different language called WAVM when executing challenges. The difference is not important to this discussion, but for details, see the page outlining the differences between [WASM and WAVM](/how-arbitrum-works/05-validation-and-proving/03-proving-and-challenges.mdx#7-wasm-to-wavm-transformation). +- **Fraud proofs:** Proofs that prove or disprove that an invalid state transition has taken place. These proofs are generated by challenge participants and are submitted to a chain's parent chain. For example, Arbitrum Rollups that settle onto Ethereum will have their proofs submitted to Ethereum and verified via a smart contract. In this case, these proofs allow Ethereum to be the final arbiter of disagreements over assertions in the Rollup contracts, which cannot be falsified by any parties as there is only a single, correct result of executing a `WASM` instruction on a pre-state. `WASM` is the assembly language that is used to represent programs whose execution is being disputed. In fact, Arbitrum, before and after BoLD, uses a slightly different language called WAVM when executing challenges. The difference is not important to this discussion, but for details, see the page outlining the differences between [WASM and WAVM](/how-arbitrum-works/07-interactive-fraud-proofs.mdx#wasm-to-wavm). - **Honest validator:** An entity that knows the correct state of the Arbitrum child chain and who may want to participate in creating assertions, confirming assertions, and/or challenging invalid assertions if they exist. More specifically, this entity must run an Arbitrum full node in `MakeNodes`, `Defensive`, `StakeLatest`, or `ResolveNodes` mode as described in the [How to run a validator](https://docs.arbitrum.io/run-arbitrum-node/more-types/run-validator-node). Note that there must always be an active proposer (i.e., a validator who actively submits new assertions) to advance the chain and who will need to run a validator in `MakeNodes` mode. diff --git a/arbitrum-docs/how-arbitrum-works/bold/gentle-introduction.mdx b/arbitrum-docs/how-arbitrum-works/bold/gentle-introduction.mdx index e9b17fa251..6b99f7c552 100644 --- a/arbitrum-docs/how-arbitrum-works/bold/gentle-introduction.mdx +++ b/arbitrum-docs/how-arbitrum-works/bold/gentle-introduction.mdx @@ -19,7 +19,7 @@ BoLD replaces the previous, permissioned fr ## In a nutshell: - Validation for Arbitrum One and Arbitrum Nova is a privileged action currently limited to an [allow-listed set of parties, maintained by the Arbitrum DAO](https://docs.arbitrum.foundation/state-of-progressive-decentralization#allowlisted-validators) to reduce the risks of _[delay attacks](https://medium.com/offchainlabs/solutions-to-delay-attacks-on-rollups-434f9d05a07a)_. _Delay attacks_ are a class of attacks where malicious entities can open as many disputes as they are willing to forfeit bonds during the challenge period to delay confirmations of assertions (equal to the time needed to resolve those disputes one by one). -- BoLD, an acronym for Bounded Liquidity Delay, is a new challenge resolution protocol for Arbitrum chains that enables permissionless validation by mitigating the risks of delay attacks against [Optimistic rollups like Arbitrum](/how-arbitrum-works/05-validation-and-proving/02-rollup-protocol.mdx). This is possible because BoLD's design ensures disputes will be resolved within a fixed time window, currently set to equal one challenge period (~6.4 days) for Arbitrum One and Arbitrum Nova. If there is a dispute, BoLD guarantees the maximum total time to be equal to two challenge periods (one for raising disputes, one for resolving disputes), a two day grace period for the Security Council to intervene if necessary, and a small delta for computing challenges. +- BoLD, an acronym for Bounded Liquidity Delay, is a new challenge resolution protocol for Arbitrum chains that enables permissionless validation by mitigating the risks of delay attacks against [Optimistic rollups like Arbitrum](/how-arbitrum-works/06-optimistic-rollup.mdx). This is possible because BoLD's design ensures disputes will be resolved within a fixed time window, currently set to equal one challenge period (~6.4 days) for Arbitrum One and Arbitrum Nova. If there is a dispute, BoLD guarantees the maximum total time to be equal to two challenge periods (one for raising disputes, one for resolving disputes), a two day grace period for the Security Council to intervene if necessary, and a small delta for computing challenges. - Enabling permissionless validation is key milestone on [Arbitrum’s journey to becoming a Stage 2 Rollup](https://docs.arbitrum.foundation/state-of-progressive-decentralization) - the most advanced and mature rollup technology categorization, according to [L2Beat](https://medium.com/l2beat/introducing-stages-a-framework-to-evaluate-rollups-maturity-d290bb22befe). With BoLD, **any honest party can validate and bond their funds to post a correct L2 state assertions to win disputes against malicious entities.** ## What _exactly_ is BoLD? @@ -84,9 +84,9 @@ The BoLD protocol provides the guardrails and rules for how validators challenge Let’s dive in to an overview of how BoLD actually works. -1. **An assertion is made:** Validators begin by taking the most recent confirmed [assertion](/how-arbitrum-works/05-validation-and-proving/02-rollup-protocol.mdx), called `Block A`, and assert that some number of transactions afterward, using Nitro’s deterministic State Transition Function (STF), will result in an end state, `Block Z`. If a validator claims that the end state represented by `Block Z` is correct, they will bond their funds to `Block Z` and propose that state to it's parent chain. (For more details on how bonding works, see [Bold technical deep dive](/how-arbitrum-works/bold/bold-technical-deep-dive.mdx)). If nobody disagrees after a certain amount of time, known as the challenge period, then the state represented by the assertion `Block Z` is confirmed as the correct state of an Arbitrum chain. However, if someone disagrees with the end state `Block Z`, they can submit a challenge. This is where BoLD comes into play. +1. **An assertion is made:** Validators begin by taking the most recent confirmed [assertion](/how-arbitrum-works/06-optimistic-rollup.mdx#the-rollup-chain), called `Block A`, and assert that some number of transactions afterward, using Nitro’s deterministic State Transition Function (STF), will result in an end state, `Block Z`. If a validator claims that the end state represented by `Block Z` is correct, they will bond their funds to `Block Z` and propose that state to it's parent chain. (For more details on how bonding works, see [Bold technical deep dive](/how-arbitrum-works/bold/bold-technical-deep-dive.mdx)). If nobody disagrees after a certain amount of time, known as the challenge period, then the state represented by the assertion `Block Z` is confirmed as the correct state of an Arbitrum chain. However, if someone disagrees with the end state `Block Z`, they can submit a challenge. This is where BoLD comes into play. 2. **A challenge is opened:** When another validator observes and disagrees with the end state represented by `Block Z`, they can permissionlessly open a challenge by asserting and bonding capital to a claim on a different end state, represented by an assertion `Block Y`. At this point in time, there are now 2 asserted states: `Block A → Block Z` and `Block A → Block Y`. Each of these asserted states, at this point in time now that there's a challenge, are referred to _edges_ while a Merkle tree of asserted states from some start to endpoint (e.g., `Block A → Block Z`) is more formally known as a _history commitment._ It is important to note that Ethereum at this point in time has no notion of which edge(s) is correct or incorrect - edges are simply a portion of a claim made by a validator about the history of the chain from some end state all the way back to some initial state. Also note that because a bond put up by a validator is tied to an assertion rather than the party who put up that bond, there can be any number of honest, anonymous parties that can open challenges against incorrect claims. It is important to note that the bonds put up to open challenges are held in the rollup contract. There is a prescribed procedure for what the Arbitrum Foundation is expected to do with these funds; see Step 5 below for a summary. -3. **Multi-level, interactive dissection begins:** To resolve the dispute, the disagreeing entities will need to come to an agreement on what the _actual, correct_ asserted state should be. [It would be tremendously expensive to re-execute](/how-arbitrum-works/05-validation-and-proving/03-proving-and-challenges.mdx) and compare everything from `Block A → Block Z` and `Block A → Block Y`, especially since there could be potentially millions of transactions in between `A`, `Z`, and `Y`. Instead, entities take turns bisecting their respective _history commitments_ until they arrive at a single step of instruction where an arbiter, like Ethereum, can declare a winner. Note that [this system is very similar to how challenges are resolved on Arbitrum chains today](/how-arbitrum-works/05-validation-and-proving/01-validation-and-proving.mdx) - BoLD only changes some minor, but important, details in the resolution process. Let’s dive into what happens next: +3. **Multi-level, interactive dissection begins:** To resolve the dispute, the disagreeing entities will need to come to an agreement on what the _actual, correct_ asserted state should be. [It would be tremendously expensive to re-execute](/how-arbitrum-works/06-optimistic-rollup.mdx#why-interactive-proving-is-better) and compare everything from `Block A → Block Z` and `Block A → Block Y`, especially since there could be potentially millions of transactions in between `A`, `Z`, and `Y`. Instead, entities take turns bisecting their respective _history commitments_ until they arrive at a single step of instruction where an arbiter, like Ethereum, can declare a winner. Note that [this system is very similar to how challenges are resolved on Arbitrum chains today](/how-arbitrum-works/07-interactive-fraud-proofs.mdx) - BoLD only changes some minor, but important, details in the resolution process. Let’s dive into what happens next: - **Block challenges**: when a challenge is opened, the edges are called _level-zero edges_ since they are at the granularity of Arbitrum blocks. The disputing parties take turns bisecting their history commitments until they identify the specific block that they disagree on. - **Big-step challenge:** Now that the parties have narrowed down their dispute to a single block, the back-and-forth bisection exercise continues within that block. Note that this block is agreed by all parties to be some state after the initial state, but before the final states. This time, however, the parties will narrow down on a specific _range_ of instructions for the State Transition Function within the block - essentially working towards identifying a set of instructions within which their disagreement lies. This range is currently defined as 2^20 steps of `WASM` instructions, which is the assembly of choice for validating Arbitrum chains. - **One-step challenge:** Within that range of 2^20 instructions, the back-and-forth bisecting continues until all parties arrive at a single step of instruction that they disagree on. At this point in time, parties agree on the initial state of Arbitrum before the step but disagree on the end state one step immediately after. Remember that since Arbitrum’s state is entirely deterministic, there is only one correct end state. diff --git a/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/advanced-configurations/01-layer-leap.mdx b/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/advanced-configurations/01-layer-leap.mdx index e10cb087d0..2595ab9ee5 100644 --- a/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/advanced-configurations/01-layer-leap.mdx +++ b/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/advanced-configurations/01-layer-leap.mdx @@ -4,5 +4,4 @@ description: 'Learn how to configure Layer Leap on your Orbit chain' author: sme: content_type: how-to -tags: ['hide-from-search'] --- diff --git a/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/advanced-configurations/03-aep-fee-router/03-calculate-aep-fees.mdx b/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/advanced-configurations/03-aep-fee-router/03-calculate-aep-fees.mdx index 614dede4b2..53fa84a41d 100644 --- a/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/advanced-configurations/03-aep-fee-router/03-calculate-aep-fees.mdx +++ b/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/advanced-configurations/03-aep-fee-router/03-calculate-aep-fees.mdx @@ -25,7 +25,7 @@ Based on the above, we interpret that an Orbit chain’s revenue sources include ### Assertion costs -The above fee system applies to an Orbit chain’s Sequencer and Batch Poster, but there is another important actor that is considered essential to the chain. These are the [validators](/how-arbitrum-works/05-validation-and-proving/03-proving-and-challenges.mdx). +The above fee system applies to an Orbit chain’s Sequencer and Batch Poster, but there is another important actor that is considered essential to the chain. These are the [validators](/how-arbitrum-works/06-optimistic-rollup.mdx#validators). Validators are responsible for posting assertions on the parent chain, which are disputable claims about the new state of the Rollup. Posting an assertion is what progressed chain state on the parent chain. Validators are also responsible for securing the chain by creating disputes on false assertions. diff --git a/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/03-stake-and-validator-configurations.mdx b/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/03-stake-and-validator-configurations.mdx index 1616de70db..11389a9c44 100644 --- a/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/03-stake-and-validator-configurations.mdx +++ b/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/03-stake-and-validator-configurations.mdx @@ -4,7 +4,6 @@ description: 'Learn how to configure your Orbit chain with a custom stake and va author: sme: content_type: how-to -tags: ['hide-from-search'] --- - **Base Stake**: Minimum stake required for validators. diff --git a/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/04-arbos-configuration.mdx b/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/04-arbos-configuration.mdx index b581d1a6bc..69cdd9dbe8 100644 --- a/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/04-arbos-configuration.mdx +++ b/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/04-arbos-configuration.mdx @@ -4,5 +4,4 @@ description: 'Learn how to configure ArbOS on your Orbit chain' author: jose-franco sme: jose-franco content_type: how-to -tags: ['hide-from-search'] --- diff --git a/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/05-gas-optimization-tools.mdx b/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/05-gas-optimization-tools.mdx index 535e86e468..f9c6d4890d 100644 --- a/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/05-gas-optimization-tools.mdx +++ b/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/05-gas-optimization-tools.mdx @@ -4,5 +4,4 @@ description: 'Learn how to configure gas optimization tools for your Orbit chain author: sme: content_type: how-to -tags: ['hide-from-search'] --- diff --git a/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/07-batch-posting-assertion-control.mdx b/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/07-batch-posting-assertion-control.mdx index c8d2451fa9..8cd1005c18 100644 --- a/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/07-batch-posting-assertion-control.mdx +++ b/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/07-batch-posting-assertion-control.mdx @@ -4,5 +4,4 @@ description: 'Learn how to configure batch posting and assertion control for you author: sme: content_type: how-to -tags: ['hide-from-search'] --- diff --git a/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/08-sequencer-timing-adjustments.mdx b/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/08-sequencer-timing-adjustments.mdx index 7d7603967f..93458e9dc4 100644 --- a/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/08-sequencer-timing-adjustments.mdx +++ b/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/08-sequencer-timing-adjustments.mdx @@ -4,5 +4,4 @@ description: 'Learn how to configure sequencer timing adjustments for your Orbit author: sme: content_type: how-to -tags: ['hide-from-search'] --- diff --git a/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/09-per-batch-gas-cost.mdx b/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/09-per-batch-gas-cost.mdx index 4043420291..7913f9d7b2 100644 --- a/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/09-per-batch-gas-cost.mdx +++ b/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/09-per-batch-gas-cost.mdx @@ -4,5 +4,4 @@ description: 'Learn how to configure per batch gas cost for your Orbit chain' author: sme: content_type: how-to -tags: ['hide-from-search'] --- diff --git a/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/10-smart-contract-size-limit.mdx b/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/10-smart-contract-size-limit.mdx index 5e457b9d9e..dd1ef999e9 100644 --- a/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/10-smart-contract-size-limit.mdx +++ b/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/10-smart-contract-size-limit.mdx @@ -4,5 +4,4 @@ description: 'Learn how to configure smart contract size limits on your Orbit ch author: sme: content_type: how-to -tags: ['hide-from-search'] --- diff --git a/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/11-customizing-anytrust.mdx b/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/11-customizing-anytrust.mdx index 16a58aa9c5..4d1522e540 100644 --- a/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/11-customizing-anytrust.mdx +++ b/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/11-customizing-anytrust.mdx @@ -4,5 +4,4 @@ description: 'Learn how to customize AnyTrust on your Orbit chain' author: sme: content_type: how-to -tags: ['hide-from-search'] --- diff --git a/arbitrum-docs/launch-orbit-chain/02-start-your-journey.mdx b/arbitrum-docs/launch-orbit-chain/02-start-your-journey.mdx index 28cfe18f39..0268252031 100644 --- a/arbitrum-docs/launch-orbit-chain/02-start-your-journey.mdx +++ b/arbitrum-docs/launch-orbit-chain/02-start-your-journey.mdx @@ -7,5 +7,4 @@ author: 'anegg0' sme: 'mahsamoosavi' editor: 'anegg0' target_audience: 'Prospective chain owners, and operators' -tags: ['hide-from-search'] --- diff --git a/arbitrum-docs/launch-orbit-chain/03-deploy-an-orbit-chain/07-canonical-factory-contracts.mdx b/arbitrum-docs/launch-orbit-chain/03-deploy-an-orbit-chain/07-canonical-factory-contracts.mdx index 6db2d69c83..eef0a94b3a 100644 --- a/arbitrum-docs/launch-orbit-chain/03-deploy-an-orbit-chain/07-canonical-factory-contracts.mdx +++ b/arbitrum-docs/launch-orbit-chain/03-deploy-an-orbit-chain/07-canonical-factory-contracts.mdx @@ -4,5 +4,4 @@ description: 'Learn how to deploy Canonical factory contracts on your Orbit chai author: sme: content_type: how-to -tags: ['hide-from-search'] --- diff --git a/arbitrum-docs/launch-orbit-chain/03-orbit-license.mdx b/arbitrum-docs/launch-orbit-chain/03-orbit-license.mdx index dacd643a41..4c11294383 100644 --- a/arbitrum-docs/launch-orbit-chain/03-orbit-license.mdx +++ b/arbitrum-docs/launch-orbit-chain/03-orbit-license.mdx @@ -7,5 +7,4 @@ author: sme: editor: anegg0 target_audience: -tags: ['hide-from-search'] --- diff --git a/arbitrum-docs/launch-orbit-chain/04-maintain-your-chain/01-bridging.mdx b/arbitrum-docs/launch-orbit-chain/04-maintain-your-chain/01-bridging.mdx index f25b20da44..2cf2c42211 100644 --- a/arbitrum-docs/launch-orbit-chain/04-maintain-your-chain/01-bridging.mdx +++ b/arbitrum-docs/launch-orbit-chain/04-maintain-your-chain/01-bridging.mdx @@ -4,5 +4,4 @@ description: 'PLACEHOLDER' author: sme: content_type: how-to -tags: ['hide-from-search'] --- diff --git a/arbitrum-docs/launch-orbit-chain/04-maintain-your-chain/02-monitoring.mdx b/arbitrum-docs/launch-orbit-chain/04-maintain-your-chain/02-monitoring.mdx index 1f3fef4201..365652dba8 100644 --- a/arbitrum-docs/launch-orbit-chain/04-maintain-your-chain/02-monitoring.mdx +++ b/arbitrum-docs/launch-orbit-chain/04-maintain-your-chain/02-monitoring.mdx @@ -4,5 +4,4 @@ description: 'Learn how to configure your Orbit chain with a custom stake and va author: sme: content_type: how-to -tags: ['hide-from-search'] --- diff --git a/arbitrum-docs/launch-orbit-chain/04-maintain-your-chain/04-guidance/01-decentralization-security.mdx b/arbitrum-docs/launch-orbit-chain/04-maintain-your-chain/04-guidance/01-decentralization-security.mdx index c7834258af..d2ea509bfd 100644 --- a/arbitrum-docs/launch-orbit-chain/04-maintain-your-chain/04-guidance/01-decentralization-security.mdx +++ b/arbitrum-docs/launch-orbit-chain/04-maintain-your-chain/04-guidance/01-decentralization-security.mdx @@ -4,5 +4,4 @@ description: 'PLACEHOLDER' author: sme: content_type: how-to -tags: ['hide-from-search'] --- diff --git a/arbitrum-docs/launch-orbit-chain/04-maintain-your-chain/04-guidance/02-guidance-on-altda.mdx b/arbitrum-docs/launch-orbit-chain/04-maintain-your-chain/04-guidance/02-guidance-on-altda.mdx index 00e506e493..9173110028 100644 --- a/arbitrum-docs/launch-orbit-chain/04-maintain-your-chain/04-guidance/02-guidance-on-altda.mdx +++ b/arbitrum-docs/launch-orbit-chain/04-maintain-your-chain/04-guidance/02-guidance-on-altda.mdx @@ -4,5 +4,4 @@ description: 'PLACEHOLDER' author: sme: content_type: how-to -tags: ['hide-from-search'] --- diff --git a/arbitrum-docs/launch-orbit-chain/05-customize-your-chain/customize-arbos.mdx b/arbitrum-docs/launch-orbit-chain/05-customize-your-chain/customize-arbos.mdx index c2dfc32675..b4d921ff83 100644 --- a/arbitrum-docs/launch-orbit-chain/05-customize-your-chain/customize-arbos.mdx +++ b/arbitrum-docs/launch-orbit-chain/05-customize-your-chain/customize-arbos.mdx @@ -150,9 +150,9 @@ After you add ArbOS version control to the Nitro code, you can update ArbOS. You It should be noted that if you set a higher ArbOS version as the upgrade target, all the features added between the current and target versions will be activated. For example, if your current version is ArbOS v18 and you set the target version to v25, all the features between v18 and v25 will be loaded. -[precompile_main_file_link]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.2@@/@@nitroPathToPrecompiles=precompiles@@/precompile.go +[precompile_main_file_link]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.1@@/@@nitroPathToPrecompiles=precompiles@@/precompile.go [arbosstate_file_link]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/v3.1.0/@@nitroPathToArbosState=arbos/arbosState@@/arbosstate.go [arbosstate_updatearbosversion_method_link]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/v3.1.0/arbos/@@nitroPathToArbosState=arbos/arbosState@@/arbosstate.go#L253 -[block_processor_file_link]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.2@@/@@nitroPathToArbos=arbos@@/block_processor.go -[internal_tx_file_link]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.2@@/@@nitroPathToArbos=arbos@@/internal_tx.go -[tx_processor_file_link]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.2@@/@@nitroPathToArbos=arbos@@/tx_processor.go +[block_processor_file_link]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.1@@/@@nitroPathToArbos=arbos@@/block_processor.go +[internal_tx_file_link]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.1@@/@@nitroPathToArbos=arbos@@/internal_tx.go +[tx_processor_file_link]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.1@@/@@nitroPathToArbos=arbos@@/tx_processor.go diff --git a/arbitrum-docs/launch-orbit-chain/05-customize-your-chain/customize-precompile.mdx b/arbitrum-docs/launch-orbit-chain/05-customize-your-chain/customize-precompile.mdx index 5787fdeb46..948cfc7b01 100644 --- a/arbitrum-docs/launch-orbit-chain/05-customize-your-chain/customize-precompile.mdx +++ b/arbitrum-docs/launch-orbit-chain/05-customize-your-chain/customize-precompile.mdx @@ -32,7 +32,7 @@ There are five primary ways to customize your chain's precompiles: Clone the Nitro repository before you begin: ```shell -git clone --branch @@nitroVersionTag=v3.5.2@@ +git clone --branch @@nitroVersionTag=v3.5.1@@ cd nitro git submodule update --init --recursive --force ``` @@ -55,6 +55,12 @@ function sayHi() external view returns(string memory); Next, follow the steps in [How to customize your Orbit chain's behavior](./customize-stf.mdx#step-3-run-the-node-without-fraud-proofs) to build a modified Arbitrum Nitro node docker image and run it. +:::info + +Note that the instructions provided in [How to run a full node](/run-arbitrum-node/03-run-full-node.mdx) **will not** work with your Orbit node. See [Optional parameters (Orbit)](/node-running/how-tos/running-an-orbit-node.mdx#optional-parameters) for Orbit-specific CLI flags. + +::: + Once your node is running, you can call `ArbSys.sol` either directly using `curl`, or through Foundry's `cast call`. ### Call your function directly using `curl` @@ -124,6 +130,12 @@ interface ArbHi { Next, follow the steps in [How to customize your Orbit chain's behavior](./customize-stf.mdx#step-3-run-the-node-without-fraud-proofs) to build a modified Arbitrum Nitro node docker image and run it. +:::info + +Note that the instructions provided in [How to run a full node](/run-arbitrum-node/03-run-full-node.mdx) **will not** work with your Orbit node. See [Optional parameters (Orbit)](/node-running/how-tos/running-an-orbit-node.mdx#optional-parameters) for Orbit-specific CLI flags. + +::: + Once your node is running, you can call `ArbHi.sol` either directly using `curl`, or through Foundry's `cast call`. ### Call your function directly using `curl` @@ -212,9 +224,15 @@ Next, build Nitro by following the instructions in [How to build Nitro locally]( Run Nitro with the following command: ```shell -docker run --rm -it -v /some/local/dir/arbitrum:/home/user/.arbitrum -p 0.0.0.0:8547:8547 -p 0.0.0.0:8548:8548 @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.2-33d30c0@@ --parent-chain.connection.url= --chain.id= --http.api=net,web3,eth,debug --http.corsdomain=* --http.addr=0.0.0.0 --http.vhosts=* +docker run --rm -it -v /some/local/dir/arbitrum:/home/user/.arbitrum -p 0.0.0.0:8547:8547 -p 0.0.0.0:8548:8548 @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.1-8f247fd@@ --parent-chain.connection.url= --chain.id= --http.api=net,web3,eth,debug --http.corsdomain=* --http.addr=0.0.0.0 --http.vhosts=* ``` +:::info + +Note that the instructions provided in [How to run a full node](/run-arbitrum-node/03-run-full-node.mdx) **will not** work with your Orbit node. See [Optional parameters (Orbit)](/node-running/how-tos/running-an-orbit-node.mdx#optional-parameters) for Orbit-specific CLI flags. + +::: + ### Send the transaction and get the transaction receipt To send a transaction to `ArbSys`, we need to include a gas cost, because the function is no longer a view/pure function: @@ -290,9 +308,15 @@ Next, build Nitro by following the instructions in [How to build Nitro locally]( Run Nitro with the following command: ```shell -docker run --rm -it -v /some/local/dir/arbitrum:/home/user/.arbitrum -p 0.0.0.0:8547:8547 -p 0.0.0.0:8548:8548 @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.2-33d30c0@@ --parent-chain.connection.url= --chain.id= --http.api=net,web3,eth,debug --http.corsdomain=* --http.addr=0.0.0.0 --http.vhosts=* +docker run --rm -it -v /some/local/dir/arbitrum:/home/user/.arbitrum -p 0.0.0.0:8547:8547 -p 0.0.0.0:8548:8548 @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.1-8f247fd@@ --parent-chain.connection.url= --chain.id= --http.api=net,web3,eth,debug --http.corsdomain=* --http.addr=0.0.0.0 --http.vhosts=* ``` +:::info + +Note that the instructions provided in [How to run a full node](/run-arbitrum-node/03-run-full-node.mdx) **will not** work with your Orbit node. See [Optional parameters (Orbit)](/node-running/how-tos/running-an-orbit-node.mdx#optional-parameters) for Orbit-specific CLI flags. + +::: + ### Send the transaction and get the transaction receipt In order to obtain the gas used, we can use the `eth_sendRawTransaction` RPC method to test execution on the chain. @@ -518,11 +542,11 @@ The same goes for the path to precompiles interface. We can use the @@nitroContractsRepositorySlug=nitro-contracts@@ and @@nitroContractsPathToPrecompilesInterface=src/precompiles@@ variables once we release nitro version 2.1.0 or above. --> -[precompile_impl_dir_link]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.2@@/@@nitroPathToPrecompiles=precompiles@@/ +[precompile_impl_dir_link]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.1@@/@@nitroPathToPrecompiles=precompiles@@/ [precompile_interface_dir_link]: https://github.com/OffchainLabs/@@nitroContractsRepositorySlug=nitro-contracts@@/blob/@@nitroContractsCommit=763bd77906b7677da691eaa31c6e195d455197a4@@/@@nitroContractsPathToPrecompilesInterface=src/precompiles@@/ -[precompile_main_file_link]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.2@@/@@nitroPathToPrecompiles=precompiles@@/precompile.go -[arbosstate_file_link]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.2@@/@@nitroPathToArbosState=arbos/arbosState@@/arbosstate.go +[precompile_main_file_link]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.1@@/@@nitroPathToPrecompiles=precompiles@@/precompile.go +[arbosstate_file_link]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.1@@/@@nitroPathToArbosState=arbos/arbosState@@/arbosstate.go [arbosstate_link]: https://github.com/OffchainLabs/nitro/blob/v2.2.0/arbos/arbosState/arbosstate.go#L38 -[storage_link]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.2@@/@@nitroPathToStorage=arbos/storage@@/storage.go +[storage_link]: https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.5.1@@/@@nitroPathToStorage=arbos/storage@@/storage.go [arbosstate_openstate]: https://github.com/OffchainLabs/nitro/blob/v2.2.0/arbos/arbosState/arbosstate.go#L89 [arbosstate_initializeArbosState]: https://github.com/OffchainLabs/nitro/blob/v2.2.0/arbos/arbosState/arbosstate.go#L212 diff --git a/arbitrum-docs/launch-orbit-chain/05-customize-your-chain/customize-stf.mdx b/arbitrum-docs/launch-orbit-chain/05-customize-your-chain/customize-stf.mdx index 3f3d822242..2122f0e24d 100644 --- a/arbitrum-docs/launch-orbit-chain/05-customize-your-chain/customize-stf.mdx +++ b/arbitrum-docs/launch-orbit-chain/05-customize-your-chain/customize-stf.mdx @@ -74,7 +74,7 @@ This guide covers how to build the node and enable fraud proofs by building a ne Clone the Nitro repository before you begin: ```shell -git clone --branch @@nitroVersionTag=v3.5.2@@ https://github.com/OffchainLabs/nitro.git +git clone --branch @@nitroVersionTag=v3.5.1@@ https://github.com/OffchainLabs/nitro.git cd nitro git submodule update --init --recursive --force ``` @@ -135,6 +135,12 @@ This method will only run the customized Nitro node (i.e., it will not run Block docker run --rm -it -v /path/to/your/node/dir:/home/user/.arbitrum -p 0.0.0.0:8449:8449 custom-nitro-node --conf.file /home/user/.arbitrum/nodeConfig.json ``` +:::info + +Note that the instructions provided in [How to run a full node](/run-arbitrum-node/03-run-full-node.mdx) **will not** work with your Orbit node. See [Optional parameters (Orbit)](/node-running/how-tos/running-an-orbit-node.mdx#optional-parameters) for Orbit-specific CLI flags. + +::: + Once your node is running, you can try out your modifications to the State Transition Function and confirm they work as expected. ### Step 4. Enable fraud proofs diff --git a/arbitrum-docs/launch-orbit-chain/06-third-party-integrations/03-integrations.mdx b/arbitrum-docs/launch-orbit-chain/06-third-party-integrations/03-integrations.mdx index 8b5c37d04e..6cc3387420 100644 --- a/arbitrum-docs/launch-orbit-chain/06-third-party-integrations/03-integrations.mdx +++ b/arbitrum-docs/launch-orbit-chain/06-third-party-integrations/03-integrations.mdx @@ -4,7 +4,6 @@ description: 'PLACEHOLDER' author: sme: content_type: how-to -tags: ['hide-from-search'] --- ## Compatible third-party integrations diff --git a/arbitrum-docs/launch-orbit-chain/07-orbit-node-runners/orbit-node-providers.mdx b/arbitrum-docs/launch-orbit-chain/07-orbit-node-runners/orbit-node-providers.mdx index fac18ccb46..332355f399 100644 --- a/arbitrum-docs/launch-orbit-chain/07-orbit-node-runners/orbit-node-providers.mdx +++ b/arbitrum-docs/launch-orbit-chain/07-orbit-node-runners/orbit-node-providers.mdx @@ -4,5 +4,4 @@ description: 'PLACEHOLDER' author: sme: content_type: how-to -tags: ['hide-from-search'] --- diff --git a/arbitrum-docs/launch-orbit-chain/08-ecosystem-support/01-orbit-portal.mdx b/arbitrum-docs/launch-orbit-chain/08-ecosystem-support/01-orbit-portal.mdx index 7fac89bdf9..d204e3af79 100644 --- a/arbitrum-docs/launch-orbit-chain/08-ecosystem-support/01-orbit-portal.mdx +++ b/arbitrum-docs/launch-orbit-chain/08-ecosystem-support/01-orbit-portal.mdx @@ -4,5 +4,4 @@ description: 'PLACEHOLDER' author: sme: content_type: how-to -tags: ['hide-from-search'] --- diff --git a/arbitrum-docs/launch-orbit-chain/08-ecosystem-support/03-get-listed-orbit-platforms.mdx b/arbitrum-docs/launch-orbit-chain/08-ecosystem-support/03-get-listed-orbit-platforms.mdx index 4283ce18dd..fc78418e36 100644 --- a/arbitrum-docs/launch-orbit-chain/08-ecosystem-support/03-get-listed-orbit-platforms.mdx +++ b/arbitrum-docs/launch-orbit-chain/08-ecosystem-support/03-get-listed-orbit-platforms.mdx @@ -4,5 +4,4 @@ description: 'PLACEHOLDER' author: sme: content_type: how-to -tags: ['hide-from-search'] --- diff --git a/arbitrum-docs/launch-orbit-chain/how-tos/how-to-configure-your-chain.mdx b/arbitrum-docs/launch-orbit-chain/how-tos/how-to-configure-your-chain.mdx index 9b9e0779f0..c36e79389f 100644 --- a/arbitrum-docs/launch-orbit-chain/how-tos/how-to-configure-your-chain.mdx +++ b/arbitrum-docs/launch-orbit-chain/how-tos/how-to-configure-your-chain.mdx @@ -8,5 +8,4 @@ target_audience: 'Developers deploying and maintaining Orbit chains.' sidebar_position: '6' user_story: 'As a current or prospective Orbit chain owner or operator, I need to understand how to configure my chain to satisfy my requirements' content_type: 'how-to' -tags: ['hide-from-search'] --- diff --git a/arbitrum-docs/launch-orbit-chain/how-tos/orbit-chain-finality.mdx b/arbitrum-docs/launch-orbit-chain/how-tos/orbit-chain-finality.mdx index 43f69a9f9d..068d6e54a2 100644 --- a/arbitrum-docs/launch-orbit-chain/how-tos/orbit-chain-finality.mdx +++ b/arbitrum-docs/launch-orbit-chain/how-tos/orbit-chain-finality.mdx @@ -9,7 +9,7 @@ content_type: how-to ## Child chain transactions -Generally, transactions executed through the sequencer on Orbit chains [achieve finality](/how-arbitrum-works/02-transaction-lifecycle.mdx) equivalent to their parent chain once the relevant transaction data has been [posted in a batch](/how-arbitrum-works/05-validation-and-proving/02-rollup-protocol.mdx). This means that transactions on Orbit chains are considered final in minutes. +Generally, transactions executed through the sequencer on Orbit chains [achieve finality](/how-arbitrum-works/02-transaction-lifecycle.mdx) equivalent to their parent chain once the relevant transaction data has been [posted in a batch](/how-arbitrum-works/06-optimistic-rollup.mdx). This means that transactions on Orbit chains are considered final in minutes. ## Parent chain → child chain transactions diff --git a/arbitrum-docs/launch-orbit-chain/reference/orbit-batch-poster-configuration.mdx b/arbitrum-docs/launch-orbit-chain/reference/orbit-batch-poster-configuration.mdx index 1ed90f91ff..2ebcad36ce 100644 --- a/arbitrum-docs/launch-orbit-chain/reference/orbit-batch-poster-configuration.mdx +++ b/arbitrum-docs/launch-orbit-chain/reference/orbit-batch-poster-configuration.mdx @@ -8,5 +8,4 @@ target_audience: 'Prospective chain owners, and operators' sidebar_position: '6' user_story: 'As a current or prospective Orbit chain owner or operator, I need to understand how to configure my batch poster' content_type: 'reference' -tags: ['hide-from-search'] --- diff --git a/arbitrum-docs/launch-orbit-chain/reference/orbit-configuration-parameters.mdx b/arbitrum-docs/launch-orbit-chain/reference/orbit-configuration-parameters.mdx index 218ae039a7..dae6cca158 100644 --- a/arbitrum-docs/launch-orbit-chain/reference/orbit-configuration-parameters.mdx +++ b/arbitrum-docs/launch-orbit-chain/reference/orbit-configuration-parameters.mdx @@ -8,5 +8,4 @@ target_audience: 'Prospective chain owners, and operators' sidebar_position: '6' user_story: 'As a current or prospective Orbit chain owner or operator, I need to understand how to configure my chain' content_type: 'reference' -tags: ['hide-from-search'] --- diff --git a/arbitrum-docs/launch-orbit-chain/reference/orbit-fast-block-times.mdx b/arbitrum-docs/launch-orbit-chain/reference/orbit-fast-block-times.mdx index a73987a378..f54c868a12 100644 --- a/arbitrum-docs/launch-orbit-chain/reference/orbit-fast-block-times.mdx +++ b/arbitrum-docs/launch-orbit-chain/reference/orbit-fast-block-times.mdx @@ -8,5 +8,4 @@ taget_audience: 'Prospective chain owners, and operators' sidebar_position: '6' user_story: 'As a current or prospective Orbit chain owner or operator, I need to understand how to configure my chain for fast block times' content_type: 'reference' -tags: ['hide-from-search'] --- diff --git a/arbitrum-docs/launch-orbit-chain/reference/orbit-sequencer-configuration.mdx b/arbitrum-docs/launch-orbit-chain/reference/orbit-sequencer-configuration.mdx index 9e03b366ba..039828733c 100644 --- a/arbitrum-docs/launch-orbit-chain/reference/orbit-sequencer-configuration.mdx +++ b/arbitrum-docs/launch-orbit-chain/reference/orbit-sequencer-configuration.mdx @@ -8,5 +8,4 @@ target_audience: 'Prospective chain owners, and operators' sidebar_position: '6' user_story: 'As a current or prospective Orbit chain owner or operator, I need to understand how to configure my chains sequencer' content_type: 'reference' -tags: ['hide-from-search'] --- diff --git a/arbitrum-docs/launch-orbit-chain/reference/orbit-smart-contract-size-limit.mdx b/arbitrum-docs/launch-orbit-chain/reference/orbit-smart-contract-size-limit.mdx index f47bb8d10e..76e283a51f 100644 --- a/arbitrum-docs/launch-orbit-chain/reference/orbit-smart-contract-size-limit.mdx +++ b/arbitrum-docs/launch-orbit-chain/reference/orbit-smart-contract-size-limit.mdx @@ -8,5 +8,4 @@ taget_audience: 'Prospective chain owners, and operators' sidebar_position: '2' user_story: 'As a current or prospective Orbit chain owner or operator, I need to understand smart contracts size limits' content_type: 'reference' -tags: ['hide-from-search'] --- diff --git a/arbitrum-docs/node-running/how-tos/running-an-orbit-node.mdx b/arbitrum-docs/node-running/how-tos/running-an-orbit-node.mdx new file mode 100644 index 0000000000..d3c30b6291 --- /dev/null +++ b/arbitrum-docs/node-running/how-tos/running-an-orbit-node.mdx @@ -0,0 +1,158 @@ +--- +title: 'How to run a full node for an Orbit chain' +description: Learn how to run an Arbitrum orbit node on your local machine +author: Mehdi Salehi +sme: Mehdi Salehi +content_type: how-to +--- + +This how-to provides step-by-step instructions for running an Orbit node on your local machine. + +## Prerequisites + +Latest Docker Image: @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.1-8f247fd@@ + +| Minimum Hardware Configuration | +| :--------------------------------------------------------------- | +| **RAM**: 8-16 GB | +| **CPU**: 2-4 core CPU (For AWS: t3 xLarge | +| **Storage**: Depends on the Orbit chain and its traffic overtime | + +## Required parameters + +### 1. Parent chain parameters + +The `parent-chain` argument needs to provide a standard RPC endpoint for an EVM node, whether self-hosted or obtained from a node service provider: + +```shell +--parent-chain.connection.url= +``` + +:::note + +[Public Arbitrum RPC endpoints](/build-decentralized-apps/reference/01-node-providers.mdx#arbitrum-public-rpc-endpoints) rate-limit connections. To avoid hitting a bottleneck, you can run a local node for the parent chain or rely on third-party RPC providers. + +::: + +### 2. Child chain parameters + +In the Arbitrum Orbit context, the child chain is an L2 or an L3 Orbit chain, and the required parameters are `chain.info-json` and `chain.name` + +#### 1. `chain.info-json` + +`--chain.info-json` is a JSON string that contains required information about the Orbit chain. + +```shell +--chain.info-json= +``` + +An example of `chain.info-json` is available in the next section. + +#### 2. `chain.name` + +`--chain.name` is a mandatory flag that needs to match the chain name used in `--chain.info-json`: + +```shell +--chain.name= +``` + +#### 3. `execution.forwarding-target` + +You need to set the --execution.forwarding-target flag if you are running a regular full node (Not sequencer). + +```shell +--execution.forwarding-target= +``` + +#### 4. AnyTrust chains + +For Anytrust chains, you need to to add the following flags to the command or configuration: + +```shell +--node.data-availability.enable +--node.data-availability.rest-aggregator.enable +``` + +And, you need to set the following flag to specify the DAS REST endpoints, there two optional methods: + +1. Set URLs directly: + +```shell +--node.data-availability.rest-aggregator.urls= +``` + +2. Or set an URL that returns a list of the DAS REST endpoints: + +```shell +--node.data-availability.rest-aggregator.online-url-list= +``` + +Please contact the chain owners to get the URL of the DAS REST endpoints. If you are a chain owner, please refer to the [DAC setup guide](/run-arbitrum-node/data-availability-committees/01-get-started.mdx#if-you-are-a-chain-owner) to set it up. + +### 3.Important ports + +| Protocol | Port | +| ----------------- | ------ | +| `RPC`/`http` | `8547` | +| `RPC`/`websocket` | `8548` | +| `Sequencer Feed` | `9642` | + +- Please note: the `RPC`/`websocket` protocol requires some ports to be enabled, you can use the following flags: + - `--ws.port=8548` + - `--ws.addr=0.0.0.0` + - `--ws.origins=\*` + +### 4. Putting it all together + +- When running a Docker image, an external volume should be mounted to persist the database across restarts. The mount point inside the Docker image should be `/home/user/.arbitrum` + +- Example: + + ```shell wordWrap=true + docker run --rm -it -v /some/local/dir/arbitrum:/home/user/.arbitrum -p 0.0.0.0:8547:8547 -p 0.0.0.0:8548:8548 @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.1-8f247fd@@ --parent-chain.connection.url= --chain.id= --chain.name= --http.api=net,web3,eth --http.corsdomain=* --http.addr=0.0.0.0 --http.vhosts=* --chain.info-json= --execution.forwarding-targe= + ``` + + - Ensure that `/some/local/dir/arbitrum` already exists otherwise the directory might be created with `root` as owner, and the Docker container won't be able to write to it + + - When using the flag `--chain.info-json=`, replace `` with the specific `chain info` JSON string of the Orbit chain for which you wish to run the node: + +- Example: + + ```shell wordWrap=true + --chain.info-json="[{\"chain-id\":94692861356,\"parent-chain-id\":421614,\"chain-name\":\"My Arbitrum L3 Chain\",\"chain-config\":{\"chainId\":94692861356,\"homesteadBlock\":0,\"daoForkBlock\":null,\"daoForkSupport\":true,\"eip150Block\":0,\"eip150Hash\":\"0x0000000000000000000000000000000000000000000000000000000000000000\",\"eip155Block\":0,\"eip158Block\":0,\"byzantiumBlock\":0,\"constantinopleBlock\":0,\"petersburgBlock\":0,\"istanbulBlock\":0,\"muirGlacierBlock\":0,\"berlinBlock\":0,\"londonBlock\":0,\"clique\":{\"period\":0,\"epoch\":0},\"arbitrum\":{\"EnableArbOS\":true,\"AllowDebugPrecompiles\":false,\"DataAvailabilityCommittee\":false,\"InitialArbOSVersion\":10,\"InitialChainOwner\":\"0xAde4000C87923244f0e95b41f0e45aa3C02f1Bb2\",\"GenesisBlockNum\":0}},\"rollup\":{\"bridge\":\"0xde835286442c6446E36992c036EFe261AcD87F6d\",\"inbox\":\"0x0592d3861Ea929B5d108d915c36f64EE69418049\",\"sequencer-inbox\":\"0xf9d77199288f00440Ed0f494Adc0005f362c17b1\",\"rollup\":\"0xF5A42aDA664E7c2dFE9DDa4459B927261BF90E09\",\"validator-utils\":\"0xB11EB62DD2B352886A4530A9106fE427844D515f\",\"validator-wallet-creator\":\"0xEb9885B6c0e117D339F47585cC06a2765AaE2E0b\",\"deployed-at\":1764099}}]" + ``` + +- When shutting down the Docker image, it is important to allow a graceful shutdown so that the current state can be saved to disk. Here is an example of how to do a graceful shutdown of all Docker images currently running + + ```shell + docker stop --time=1800 $(docker ps -aq) + ``` + +### Note on permissions + +- The Docker image is configured to run as non-root `UID 1000`. If you are running Linux or macOS and you are getting permission errors when trying to run the Docker image, run this command to allow all users to update the persistent folders: + + ```shell + mkdir /data/arbitrum + chmod -fR 777 /data/arbitrum + ``` + +### Note on Sequencer feed + +Nitro nodes can be configured to receive real time ordered transactions from the sequencer feed. If you don't set the feed input url, your node will listen to the parent chain's inbox contract to get the ordered transactions, which will cause your node to be unable to synchronize the latest state. + +Set the following configurations to your fullnode to make it can receive the sequencer feed: + +```shell +--node.feed.input.url= +``` + +After that, your node can synchronize the latest state from the sequencer feed. + +## Optional parameters + +We show here a list of the parameters that are most commonly used when running your Orbit node. You can also use the flag `--help` for a full comprehensive list of the available parameters. + +import OptionalOrbitCompatibleCLIFlagsPartial from '../../partials/_optional-orbit-compatible-cli-flags-partial.mdx'; + + diff --git a/arbitrum-docs/partials/_gentle-intro-partial.mdx b/arbitrum-docs/partials/_gentle-intro-partial.mdx index c5915502d2..b46ea7d3b9 100644 --- a/arbitrum-docs/partials/_gentle-intro-partial.mdx +++ b/arbitrum-docs/partials/_gentle-intro-partial.mdx @@ -1,5 +1,3 @@ -import ImageZoom from '@site/src/components/ImageZoom'; - #### Q: Hello! What’s Arbitrum? Hi! Arbitrum is a technology suite designed to scale Ethereum. You can use Arbitrum chains to do all things you do on Ethereum — use Web3 apps, deploy smart contracts, etc., but your transactions will be cheaper and faster. Our flagship product — Arbitrum Rollup — is an Optimistic rollup protocol that inherits Ethereum-level security. @@ -39,7 +37,7 @@ Additionally, as long as there’s even just one honest validator, the chain wil #### Q: And how exactly is “fraud” “proven”? Sounds complicated. -Oh, it’s not so bad. In essence, if two validators disagree, only one of them (at most) can be telling the truth. In a dispute, the two validators play an interactive, call-and-response game in which they narrow down their dispute to a single computational step (think of something small and simple, like multiplying two numbers). This one step gets executed on L1 and will necessarily prove that the honest party was telling the truth. For a more detailed rundown, see [here](/how-arbitrum-works/05-validation-and-proving/01-validation-and-proving.mdx). +Oh, it’s not so bad. In essence, if two validators disagree, only one of them (at most) can be telling the truth. In a dispute, the two validators play an interactive, call-and-response game in which they narrow down their dispute to a single computational step (think of something small and simple, like multiplying two numbers). This one step gets executed on L1 and will necessarily prove that the honest party was telling the truth. For a more detailed rundown, see [here](/how-arbitrum-works/07-interactive-fraud-proofs.mdx). #### Q: This dispute game obviously takes some time; does this impose any sort of delay on Arbitrum users' transactions? @@ -86,11 +84,7 @@ Here’s a snapshot of the chains running on Arbitrum: - On other L2s: - Various L2 (Orbit) chain - +![700px-img](../assets/arbitrum-chains-diagram.jpeg) Developers can launch their own Arbitrum chains that run as an L2 chain on top of Ethereum. They can also run Arbitrum chains that run on top of an EVM L2 chain. diff --git a/arbitrum-docs/run-arbitrum-node/partials/run-full-node/_optional-parameters.mdx b/arbitrum-docs/partials/_optional-orbit-compatible-cli-flags-partial.mdx similarity index 58% rename from arbitrum-docs/run-arbitrum-node/partials/run-full-node/_optional-parameters.mdx rename to arbitrum-docs/partials/_optional-orbit-compatible-cli-flags-partial.mdx index e32ad40ee2..797652dd84 100644 --- a/arbitrum-docs/run-arbitrum-node/partials/run-full-node/_optional-parameters.mdx +++ b/arbitrum-docs/partials/_optional-orbit-compatible-cli-flags-partial.mdx @@ -1,24 +1,26 @@
-| Flag | Description | -| ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `--http.api` | Offers APIs over the HTTP-RPC interface. Default: `net,web3,eth,arb`. Add `debug` for tracing. | -| `--http.corsdomain` | Accepts cross-origin requests from these comma-separated domains (browser enforced). | -| `--http.vhosts` | Accepts requests from these comma-separated virtual hostnames (server enforced). Default: `localhost`. Accepts `*`. | -| `--http.addr` | Sets the address to bind RPC to. May require `0.0.0.0` for Docker networking. | -| `--execution.caching.archive` | Retains past block state. For archive nodes. | -| `--node.feed.input.url=` | Sets the sequencer feed address to this URL. Default: `wss://.arbitrum.io/feed`. ⚠️ One feed relay per datacenter is advised. See [feed relay guide](/run-arbitrum-node/sequencer/01-run-feed-relay.mdx). | -| `--execution.forwarding-target=` | Sets the sequencer endpoint to forward requests to. | -| `--execution.rpc.evm-timeout` | Default: `5s`. Timeout for `eth_call`. (0 == no timeout). | -| `--execution.rpc.gas-cap` | Default: `50000000`. Gas cap for `eth_call`/`estimateGas`. (0 = no cap). | -| `--execution.rpc.tx-fee-cap` | Default: `1`. Transaction fee cap (in ether) for RPC APIs. (0 = no cap). | -| `--execution.rpc.classic-redirect=` | (Arbitrum One only) Redirects archive requests for pre-nitro blocks to this RPC of an Arbitrum Classic node with archive database. | -| `--ipc.path` | Filename for IPC socket/pipe within datadir. 🔉 Not supported on macOS. Note the path is within the Docker container. | -| `--init.prune` | Prunes the database before starting the node. Can be "full" or "validator". | -| `--init.url=""` | (Required for Arbitrum One) URL to download the genesis database from. Only required for Arbitrum One nodes, when running them for the first time. See [this guide](/run-arbitrum-node/nitro/03-nitro-database-snapshots.mdx) for more information. | -| `--init.download-path="/path/to/dir"` | Temporarily saves the downloaded database snapshot. Defaults to `/tmp/`. Used with `--init.url`. | -| `--init.latest` | Searches for the latest snapshot of the given kind (accepted values: `archive`, `pruned`, `genesis`) | -| `--init.latest-base` | Base url used when searching for the latest snapshot. Default: "https://snapshot.arbitrum.foundation/". If you are running an Orbit chain, ask the chain owner for this URL. | -| `--init.then-quit` | Allows any `--init.*` parameters to complete, and then the node will automatically quit. It doesn't initiate pruning by itself but works in conjunction with other `--init.*` parameters, making it easier to script tasks like database backups after initialization processes finish. | +| Flag | Description | +| ---------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `--execution.rpc.classic-redirect=` | Redirects archive requests for pre-nitro blocks to this RPC of an Arbitrum Classic node with archive database. Only for Arbitrum One. | +| `--http.api` | Offered APIs over the HTTP-RPC interface. Default: `net,web3,eth,arb`. Add `debug` for tracing. | +| `--http.corsdomain` | Accepts cross origin requests from these comma-separated domains (browser enforced). | +| `--http.vhosts` | Accepts requests from these comma-separated virtual hostnames (server enforced). Default: `localhost`. Accepts `*`. | +| `--http.addr` | Address to bind RPC to. May require `0.0.0.0` for Docker networking. | +| `--execution.caching.archive` | Retains past block state. For archive nodes. | +| `--node.feed.input.url=` | Default: `wss://.arbitrum.io/feed`. ⚠️ One feed relay per datacenter is advised. See [feed relay guide](/run-arbitrum-node/sequencer/01-run-feed-relay.mdx). | +| `--execution.forwarding-target=` | Defaults to the L2 Sequencer RPC based on provided L1 and L2 chain IDs. | +| `--execution.rpc.evm-timeout` | Default: `5s`. Timeout for `eth_call`. (0 == no timeout). | +| `--execution.rpc.gas-cap` | Default: `50000000`. Gas cap for `eth_call`/`estimateGas`. (0 = no cap). | +| `--execution.rpc.tx-fee-cap` | Default: `1`. Transaction fee cap (in ether) for RPC APIs. (0 = no cap). | +| `--ipc.path` | Filename for IPC socket/pipe within datadir. 🔉 Not supported on macOS. Note the path is within the Docker container. | +| `--init.prune` | Prunes database before starting the node. Can be "full" or "validator". | +| `--init.url=""` | (Non-Orbit Nitro nodes only) URL to download the genesis database from. Required only for the first startup of an Arbitrum One node. Reference to [snapshots](https://snapshot.arbitrum.foundation/index.html) and [archive node guide](/run-arbitrum-node/more-types/01-run-archive-node.mdx). | +| `--init.download-path="/path/to/dir"` | (Non-Orbit Nitro nodes only) Temporarily saves the downloaded database snapshot. Defaults to `/tmp/`. Used with `--init.url`. | +| `--node.batch-poster.post-4844-blobs` | Boolean. Default: `false`. Used to enable or disable the posting of transaction data using Blobs to L1 Ethereum. If using calldata is more expensive and if the parent chain supports EIP4844 blobs, the batch poster will use blobs when this flag is set to `true`. Can be `true` or `false`. | +| `--node.batch-poster.ignore-blob-price` | Boolean. Default: `false`. If the parent chain supports EIP4844 blobs and `ignore-blob-price` is set to `true`, the batch poster will use EIP4844 blobs even if using calldata is cheaper. Can be `true` or `false`. | +| `--init.latest` | string. if set, searches for the latest snapshot of the given kind (accepted values: "archive" , "pruned" , "genesis") | +| `--init.latest-base` | string. Default: "https://snapshot.arbitrum.foundation/". Base url used when searching for the latest. (If you are running orbit chains you might need to check with orbit chain team to get the url) | +| `--init.then-quit` | Allows any `--init.*` parameters to complete, and then the node will automatically quit. It doesn't initiate pruning by itself but works in conjunction with other `--init.*` parameters, making it easier to script tasks like database backups after initialization processes finish. |
diff --git a/arbitrum-docs/run-arbitrum-node/03-run-full-node.mdx b/arbitrum-docs/run-arbitrum-node/03-run-full-node.mdx index 26daa6bdd1..1ef9fcb5a3 100644 --- a/arbitrum-docs/run-arbitrum-node/03-run-full-node.mdx +++ b/arbitrum-docs/run-arbitrum-node/03-run-full-node.mdx @@ -1,145 +1,122 @@ --- -title: 'How to run a full node for an Arbitrum or Orbit chain' +title: 'How to run a full node (Nitro)' description: Learn how to run an Arbitrum node on your local machine sidebar_position: 1 content_type: how-to --- -This how-to provides step-by-step instructions for running a full node for an Arbitrum or Orbit chain on your local machine. - :::info -If you’re interested in accessing an Arbitrum chain but don’t want to set up your own node, see our [Node Providers](/build-decentralized-apps/reference/01-node-providers.mdx) to get RPC access to fully managed nodes hosted by a third-party provider. +There is no protocol-level incentive to run an Arbitum full node. If you’re interested in accessing an Arbitrum chain but don’t want to set up your own node, see our [Node Providers](/build-decentralized-apps/reference/01-node-providers.mdx) to get RPC access to fully managed nodes hosted by a third-party provider. ::: -## Minimum hardware configuration - -The following is the minimum hardware configuration required to set up a Nitro full node (not archival): - -| Resource | Recommended | -| :----------- | :-------------------------------------------- | -| RAM | 16 GB | -| CPU | 4 core CPU (for AWS, a `t3 xLarge` instance) | -| Storage type | NVMe SSD drives are recommended | -| Storage size | Depends on the chain and its traffic overtime | +### Minimum hardware configuration -Please note that: +Minimum hardware configuration required to set up a Nitro full node (not archival): -- These minimum requirements for RAM and CPU are recommended for nodes that process a small amount of RPC requests. For nodes that require processing multiple simultaneous requests, both RAM and number of CPU cores will need to be scaled with the amount of traffic being served. -- Single core performance is important. If the node is falling behind and a single core is 100% busy, it is recommended to update to a faster processor -- The minimum storage requirements will change over time as the chain grows. Using more than the minimum requirements to run a robust full node is recommended. +- **RAM**: 16 GB +- **CPU**: 4 core CPU + - Single core performance is important. If the node is falling behind and a single core is 100% busy, it is recommended to update to a faster processor +- **Storage (last updated on April 2024)**: + - Arbitrum One: 560GB for a pruned node, growing at ~200GB per month (NVMe SSD drives are recommended) + - Arbitrum Nova: 400GB for a pruned node, growing at ~1.6TB per month (NVMe SSD drives are recommended) -## Recommended Nitro version - -:::caution +:::info -Even though there are alpha and beta versions of the Arbitrum Nitro software, only release versions should be used when running your node. Running alpha or beta versions is not supported and might lead to unexpected behaviors. +These minimum requirements for RAM and CPU are recommended for nodes that process a small amount of RPC requests. For nodes that require processing multiple simultaneous requests, both RAM and number of CPU cores will need to be scaled with the amount of traffic being served. ::: -Latest Docker image: @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.2-33d30c0@@ - -## Database snapshots - -::::info Snapshots availability - -Database snapshots are available for Arbitrum One, Arbitrum Nova and Arbitrum Sepolia and can be found in the [snapshot explorer](https://snapshot-explorer.arbitrum.io/). Database snapshots for other Orbit chains may be available at the discretion of the team running the chain. Please contact them if you're interested in using a database snapshot for their chains. - -:::: - -Supplying a database snapshot when starting your node for the first time is required for Arbitrum One (to supply the information from the Classic era), but optional for other chains. Supplying a database snapshot on the first run will provide the state and data for that chain up to a certain block, so the node will be able to sync faster to the head of the chain. +:::info -We provide here a summary of the parameters available, but we recommend reading the [full guide](/run-arbitrum-node/nitro/03-nitro-database-snapshots.mdx) if you plan on using snapshots. +The minimum storage requirements will change over time as the Nitro chain grows. Using more than the minimum requirements to run a robust full node is recommended. -- Use the parameter `--init.latest ` (accepted values: `archive`, `pruned`, `genesis`) to instruct your node to download the correspondant snapshot from the configured URL -- Optionally, use the parameter `--init.latest-base` to set the base URL when searching for the latest snapshot -- Note that these parameters are ignored if a database already exists -- When running more than one node, it's easier to manually download the different parts of the snapshot, join them into a single archive, and host it locally for your nodes. Please see [Downloading the snapshot manually](/run-arbitrum-node/nitro/03-nitro-database-snapshots.mdx#downloading-the-snapshot-manually) for instructions on how to do that. +::: -## Required parameters +### Prerequisites -The following list contains all the parameters needed to configure your node. Select the appropriate option depending on the chain you want to run your node for. +:::caution -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; -import DAOChainsParameters from './partials/run-full-node/_dao-chains-parameters.mdx'; -import OrbitChainsParameters from './partials/run-full-node/_orbit-chains-parameters.mdx'; -import DAOChainsExample from './partials/run-full-node/_dao-chains-example.mdx'; -import OrbitChainsExample from './partials/run-full-node/_orbit-chains-example.mdx'; +Even though there are alpha and beta versions of the Arbitrum Nitro software, only release versions should be used when running your node. Running alpha or beta versions is not supported and might lead to unexpected behaviors. -
- - - - - - - - -
+::: -## Putting it all together +- Latest Docker Image: @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.1-8f247fd@@ +- Database snapshot (required for Arbitrum One, optional for other chains) + - Use the parameter `--init.latest `, accepted values: "archive" | "pruned" | "genesis". + - When running more than one node, it's easier to manually download the different parts of the snapshot, join them into a single archive, and host it locally for your nodes. You can then use `--init.url="file:///path/to/snapshot/in/container/snapshot-file.tar"` to use it. (For how to manually download the snapshot parts, please see [Downloading the snapshot manually](/run-arbitrum-node/nitro/03-nitro-database-snapshots.mdx#downloading-the-snapshot-manually)) + - This parameter is **required** when initializing an Arbitrum One node because the chain has _classic_ blocks. For the other chains, this parameter is optional. + - This parameter is ignored if the database already exists. + - Find more info in [Nitro database snapshots](/run-arbitrum-node/nitro/03-nitro-database-snapshots.mdx) + - You can find more snapshots on our [snapshot explorer](https://snapshot-explorer.arbitrum.io/) + +### Required parameters + +- L1 RPC URL + - Use the parameter `--parent-chain.connection.url=` for execution layer. + - If the chain is running [ArbOS 20](/run-arbitrum-node/arbos-releases/arbos20.mdx), additionally use the parameter `--parent-chain.blob-client.beacon-url=` for consensus layer. You can find a list of beacon chain RPC providers [here](/run-arbitrum-node/05-l1-ethereum-beacon-chain-rpc-providers.mdx). + - It must provide a standard layer 1 node RPC endpoint that you run yourself or from a node provider. + - Note: historical blob data is required for chains running [ArbOS 20](/run-arbitrum-node/arbos-releases/arbos20.mdx) to properly sync up if they are new or have been offline for more than 18 days. This means the consensus layer RPC endpoint you use may also need to provide historical blob data. Please see [Special notes on ArbOS 20: Atlas support for EIP-4844](/run-arbitrum-node/arbos-releases/arbos20.mdx#special-notes-on-arbos-20-atlas-support-for-eip-4844) for more details. + - Note: this parameter was called `--l1.url` in versions prior to `v2.1.0` + - Note: 8545 is usually the default port for the execution layer. For the Beacon endpoint port, you should connect to the correct port set on your parent chain's consensus client. +- L2 chain ID or name + - Use the parameter `--chain.id=` to set the child chain (L2) chain from its chain id. See [RPC endpoints and providers](/build-decentralized-apps/reference/01-node-providers.mdx) for a list of Arbitrum chains and their respective child chain chain IDs. + - Alternatively, you can use the parameter `--chain.name=` to set the child chain from its name (options are: `arb1`, `nova` and `sepolia-rollup`) + - Note: this parameter was called --l2.chain-id and only accepted chain IDs in versions before `v2.1.0` +- For Arbitrum One or Arbitrum Nova chains (or any chains that have BoLD enabled), we recommend setting `--node.bold.enable=true` to ensure your node monitors for L1 assertions and alerts properly when an invalid assertion is observed on-chain. Setting this flag is not required as your node will continue to operate properly, validate the Arbitrum One/Nova chain, and serve RPC requests as usual, regardless of this flag. + +### Important ports + +- RPC: `8547` +- Sequencer Feed: `9642` +- WebSocket: `8548` + - WS port `8548` needs extra args to be opened. Please use these flags: + - --ws.port=8548 + - --ws.addr=0.0.0.0 + - --ws.origins=\* + +### Putting it all together - When running the Docker image, an external volume should be mounted to persist the database across restarts. The mount point inside the docker image should be `/home/user/.arbitrum` - Here is an example of how to run nitro-node: -
- - - - - - - - -
- -- Note that it is important that `/some/local/dir/arbitrum` already exists; otherwise, the directory might be created with `root` as owner, and the docker container won't be able to write to it. -- Note that if you are running a node for the parent chain (e.g. Ethereum for Arbitrum One or Nova) on localhost, you may need to add `--network host` right after `docker run` to use docker host-based networking -- When shutting down the Docker image, it is important to allow a graceful shutdown to save the current state to disk. Here is an example of how to do a graceful shutdown of all docker images currently running + - Note that it is important that `/some/local/dir/arbitrum` already exists; otherwise, the directory might be created with `root` as owner, and the docker container won't be able to write to it ```shell - docker stop --time=1800 $(docker ps -aq) + docker run --rm -it -v /some/local/dir/arbitrum:/home/user/.arbitrum -p 0.0.0.0:8547:8547 -p 0.0.0.0:8548:8548 @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.1-8f247fd@@ --parent-chain.connection.url https://l1-node:8545 --chain.id= --http.api=net,web3,eth --http.corsdomain=* --http.addr=0.0.0.0 --http.vhosts=* ``` -## Important ports + - Note that if you are running an L1 node on localhost, you may need to add `--network host` right after `docker run` to use docker host-based networking -| Protocol | Default port | -| :---------------- | :----------- | -| `RPC`/`http` | `8547` | -| `RPC`/`websocket` | `8548` | -| `Sequencer Feed` | `9642` | + - When shutting down the Docker image, it is important to allow a graceful shutdown to save the current state to disk. Here is an example of how to do a graceful shutdown of all docker images currently running -- Please note: the `RPC`/`websocket` protocol requires some ports to be enabled, you can use the following flags: - - `--ws.port=8548` - - `--ws.addr=0.0.0.0` - - `--ws.origins=\*` + ```shell + docker stop --time=1800 $(docker ps -aq) + ``` -## Note on permissions +### Note on permissions - The Docker image is configured to run as non-root UID 1000. This means if you are running in Linux or OSX and you are getting permission errors when trying to run the docker image, run this command to allow all users to update the persistent folders - ```shell mkdir /data/arbitrum chmod -fR 777 /data/arbitrum ``` -## Watchtower mode +### Watchtower mode -- By default, the full node will run in watchtower mode. This means that the node watches the on-chain assertions, and if it disagrees with them, it will log an error containing the string `found incorrect assertion in watchtower mode`. For a BoLD-enabled chain like Arbitrum One or Arbitrum Nova, the `--node.bold.enable=true` flag should be set to ensure your node can monitor for on-chain assertions properly. -- Setting this flag is not required as your node will continue to operate properly, validate the Arbitrum One/Nova chain, and serve RPC requests as usual, regardless of this flag. -- Note that watchtower mode adds a small amount of execution and memory overhead. You can deactivate this mode using the parameter `--node.staker.enable=false`. +- By default, the full node will run in Watchtower mode. This means that the node watches the on-chain assertions, and if it disagrees with them, it will log an error containing the string `found incorrect assertion in watchtower mode`. For a BoLD-enabled chain like Arbitrum One or Arbitrum Nova, the `--node.bold.enable=true` flag must be set to ensure your node can monitor for on-chain assertions properly. +- Watchtower mode adds a small amount of execution and memory overhead. You can deactivate this mode using the parameter `--node.staker.enable=false`. -## Pruning +### Pruning - Pruning a full node refers to removing older, unnecessary data from the local copy of the blockchain that the node maintains to save disk space and slightly improve the node's efficiency. Pruning will remove all states from blocks older than the latest 128. - You can activate pruning by using the parameter `--init.prune` and using "full" or "validator" as the value (depending on the type of node you are running). Remember that this process will happen upon starting the node and will not serve RPC requests while pruning. -## Optional parameters +### Optional parameters Below, we listed the most commonly used parameters when running a node. You can also use the flag `--help` for a comprehensive list of the available parameters. -import OptionalParameters from './partials/run-full-node/_optional-parameters.mdx'; +import OptionalOrbitCompatibleCLIFlagsPartial from '../partials/_optional-orbit-compatible-cli-flags-partial.mdx'; - + diff --git a/arbitrum-docs/run-arbitrum-node/arbos-releases/arbos20.mdx b/arbitrum-docs/run-arbitrum-node/arbos-releases/arbos20.mdx index 9973949c9a..88a6469e3e 100644 --- a/arbitrum-docs/run-arbitrum-node/arbos-releases/arbos20.mdx +++ b/arbitrum-docs/run-arbitrum-node/arbos-releases/arbos20.mdx @@ -58,7 +58,7 @@ To enable the posting of transaction data in Blobs to L1 Ethereum, you must set | `--node.batch-poster.post-4844-blobs` | Boolean. Default: `false`. Used to enable or disable the posting of transaction data using Blobs to L1 Ethereum. If using calldata is more expensive and if the parent chain supports EIP4844 blobs, the batch poster will use blobs when this flag is set to `true`. Can be `true` or `false`. | | `--node.batch-poster.ignore-blob-price` | Boolean. Default: `false`. If the parent chain supports EIP4844 blobs and `ignore-blob-price` is set to `true`, the batch poster will use EIP4844 blobs even if using calldata is cheaper. Can be `true` or `false`. | -The above configurations are also available in the [Nitro command line options reference section](/run-arbitrum-node/03-run-full-node.mdx#optional-parameters) and can be set using the command line or using the JSON node configuration below: +The above configurations are also available in the [Orbit command line options reference section](/node-running/how-tos/running-an-orbit-node.mdx#optional-parameters) and can be set using the command line or using the JSON node configuration below: ```json "node": { diff --git a/arbitrum-docs/run-arbitrum-node/data-availability-committees/02-deploy-das.mdx b/arbitrum-docs/run-arbitrum-node/data-availability-committees/02-deploy-das.mdx index 3878d06b2c..e00a507335 100644 --- a/arbitrum-docs/run-arbitrum-node/data-availability-committees/02-deploy-das.mdx +++ b/arbitrum-docs/run-arbitrum-node/data-availability-committees/02-deploy-das.mdx @@ -87,8 +87,8 @@ DA servers also have an optional REST aggregator which, when a data batch is not Gather the following information: -- The latest Nitro docker image: `@@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.2-33d30c0@@` -- An RPC endpoint for the parent chain. It is recommended to use a [third-party provider RPC](/build-decentralized-apps/reference/01-node-providers.mdx#third-party-rpc-providers) or [run your own node](/run-arbitrum-node/03-run-full-node.mdx) to prevent being rate limited. +- The latest Nitro docker image: `@@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.1-8f247fd@@` +- An RPC endpoint for the parent chain. It is recommended to use a [third-party provider RPC](/build-decentralized-apps/reference/01-node-providers.mdx#third-party-rpc-providers) or [run your own node](/node-running/how-tos/running-an-orbit-node.mdx) to prevent being rate limited. - The SequencerInbox contract address in the parent chain. - If you wish to configure a [REST aggregator for your DAS](#state-synchronization), you'll need the URL where the list of REST endpoints is kept. @@ -113,7 +113,7 @@ Here's an example of how to use the `datool keygen` utility inside Docker and st ```shell docker run -v $(pwd)/bls_keys:/data/keys --entrypoint datool \ -@@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.2-33d30c0@@ keygen --dir /data/keys +@@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.1-8f247fd@@ keygen --dir /data/keys ``` ### Step 2: Deploy the DAS @@ -239,7 +239,7 @@ template: - | mkdir -p /home/user/data/badgerdb /usr/local/bin/daserver --data-availability.parent-chain-node-url "" --data-availability.sequencer-inbox-address "
" --data-availability.key.key-dir /home/user/data/keys --enable-rpc --rpc-addr '0.0.0.0' --log-level 3 --enable-rest --rest-addr '0.0.0.0' --data-availability.local-cache.enable --data-availability.rest-aggregator.enable --data-availability.rest-aggregator.online-url-list "" --data-availability.s3-storage.enable --data-availability.s3-storage.access-key "" --data-availability.s3-storage.bucket "" --data-availability.s3-storage.region "" --data-availability.s3-storage.secret-key "" --data-availability.s3-storage.object-prefix "/" --data-availability.s3-storage.discard-after-timeout false --data-availability.local-file-storage.enable --data-availability.local-file-storage.data-dir /home/user/data/das-data - image: @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.2-33d30c0@@ + image: @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.1-8f247fd@@ imagePullPolicy: Always resources: limits: @@ -326,7 +326,7 @@ datool keygen --dir /some/local/dir/keys --ecdsa You can also use the `docker run` command as follows: ```shell -docker run --rm -it -v /some/local/dir:/home/user/data --entrypoint datool @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.2-33d30c0@@ keygen --dir /home/user/data/keys --ecdsa +docker run --rm -it -v /some/local/dir:/home/user/data --entrypoint datool @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.1-8f247fd@@ keygen --dir /home/user/data/keys --ecdsa ``` #### Step 2: Change the DAS configuration and restart the server @@ -362,7 +362,7 @@ datool client rpc store --url http://localhost:9876 --message "Hello world" --s You can also use the `docker run` command: ```shell -docker run --rm -it -v /some/local/dir:/home/user/data --network="host" --entrypoint datool @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.2-33d30c0@@ client rpc store --url http://localhost:9876 --message "Hello world" --signing-key /home/user/data/keys/ecdsa +docker run --rm -it -v /some/local/dir:/home/user/data --network="host" --entrypoint datool @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.1-8f247fd@@ client rpc store --url http://localhost:9876 --message "Hello world" --signing-key /home/user/data/keys/ecdsa ``` The above command will output the `Hex Encoded Data Hash` which can then be used to retrieve the data in the next step. @@ -378,7 +378,7 @@ datool client rest getbyhash --url http://localhost:9877 --data-hash 0xDataHash You can also use the `docker run` command: ```shell -docker run --rm -it --network="host" --entrypoint datool @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.2-33d30c0@@ client rest getbyhash --url http://localhost:9877 --data-hash 0xDataHash +docker run --rm -it --network="host" --entrypoint datool @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.1-8f247fd@@ client rest getbyhash --url http://localhost:9877 --data-hash 0xDataHash ``` If we set `0xDataHash` to `0x052cca0e379137c975c966bcc69ac8237ac38dc1fcf21ac9a6524c87a2aab423` (from the previous step), then the result should be: `Message: Hello world` diff --git a/arbitrum-docs/run-arbitrum-node/data-availability-committees/03-deploy-mirror-das.mdx b/arbitrum-docs/run-arbitrum-node/data-availability-committees/03-deploy-mirror-das.mdx index c75076803c..67dd565613 100644 --- a/arbitrum-docs/run-arbitrum-node/data-availability-committees/03-deploy-mirror-das.mdx +++ b/arbitrum-docs/run-arbitrum-node/data-availability-committees/03-deploy-mirror-das.mdx @@ -45,8 +45,8 @@ A mirror DAS will use the same tool and, thus, the same configuration options as Gather the following information: -- The latest Nitro docker image: `@@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.2-33d30c0@@` -- An RPC endpoint for the parent chain. It is recommended to use a [third-party provider RPC](/build-decentralized-apps/reference/01-node-providers.mdx#third-party-rpc-providers) or [run your own node](/run-arbitrum-node/03-run-full-node.mdx) to prevent being rate limited. +- The latest Nitro docker image: `@@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.1-8f247fd@@` +- An RPC endpoint for the parent chain. It is recommended to use a [third-party provider RPC](/build-decentralized-apps/reference/01-node-providers.mdx#third-party-rpc-providers) or [run your own node](/node-running/how-tos/running-an-orbit-node.mdx) to prevent being rate limited. - The SequencerInbox contract address in the parent chain. - URL of the list of REST endpoints of other DA servers to configure the REST aggregator. @@ -201,7 +201,7 @@ spec: mkdir -p /home/user/data/badgerdb mkdir -p /home/user/data/syncState /usr/local/bin/daserver --data-availability.parent-chain-node-url "" --data-availability.sequencer-inbox-address "
" --enable-rest --rest-addr '0.0.0.0' --log-level 3 --data-availability.local-cache.enable --data-availability.rest-aggregator.enable --data-availability.rest-aggregator.urls "http://your-main-das.svc.cluster.local:9877" --data-availability.rest-aggregator.online-url-list "" --data-availability.rest-aggregator.sync-to-storage.eager --data-availability.rest-aggregator.sync-to-storage.eager-lower-bound-block "BLOCK NUMBER" --data-availability.rest-aggregator.sync-to-storage.state-dir /home/user/data/syncState --data-availability.s3-storage.enable --data-availability.s3-storage.access-key "" --data-availability.s3-storage.bucket "" --data-availability.s3-storage.region "" --data-availability.s3-storage.secret-key "" --data-availability.s3-storage.object-prefix "/" --data-availability.local-file-storage.enable --data-availability.local-file-storage.data-dir /home/user/data/das-data - image: @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.2-33d30c0@@ + image: @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.1-8f247fd@@ imagePullPolicy: Always resources: limits: diff --git a/arbitrum-docs/run-arbitrum-node/data-availability-committees/04-configure-dac.mdx b/arbitrum-docs/run-arbitrum-node/data-availability-committees/04-configure-dac.mdx index 264e332d61..d7e851833a 100644 --- a/arbitrum-docs/run-arbitrum-node/data-availability-committees/04-configure-dac.mdx +++ b/arbitrum-docs/run-arbitrum-node/data-availability-committees/04-configure-dac.mdx @@ -89,7 +89,7 @@ Once you have the JSON structure, save it into a file, for example, `keyset-info Finally, we'll use Nitro's `datool dumpkeyset` utility inside Docker to generate the keyset and keyset hash. ```shell -docker run -v $(pwd):/data/keyset --entrypoint datool @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.2-33d30c0@@ dumpkeyset --conf.file /data/keyset/keyset-info.json +docker run -v $(pwd):/data/keyset --entrypoint datool @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.1-8f247fd@@ dumpkeyset --conf.file /data/keyset/keyset-info.json ``` This command will output two results: `Keyset` and `KeysetHash`. Save them to use in the next steps. @@ -121,7 +121,7 @@ The JSON file is: And when running the command we obtain: ```shell -$ docker run -v $(pwd):/data/keyset --entrypoint datool @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.2-33d30c0@@ dumpkeyset --conf.file /data/keyset/keyset-info.json +$ docker run -v $(pwd):/data/keyset --entrypoint datool @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.1-8f247fd@@ dumpkeyset --conf.file /data/keyset/keyset-info.json Keyset: 0x0000000000000002000000000000000201216006dcb5e56764bb72e6a45e6deb301ca85d8c4315c1da2efa29927f2ac8fb25571ce31d2d603735fe03196f6d56bcbf9a1999a89a74d5369822c4445d676c15ed52e5008daa775dc9a839c99ff963a19946ac740579874dac4f639907ae1bc69f0c6694955b524d718ca445831c5375393773401f33725a79661379dddabd5fff28619dc070befd9ed73d699e5c236c1a163be58ba81002b6130709bc064af5d7ba947130b72056bf17263800f1a3ab2269c6a510ef8e7412fd56d1ef1b916a1306e3b1d9c82c099371bd9861582acaada3a16e9dfee5d0ebce61096598a82f112d0a935e8cab5c48d82e3104b0c7ba79157dad1a019a3e7f6ad077b8e6308b116fec0f58239622463c3631fa01e2b4272409215b8009422c16715dbede5909060121600835f995f2478f24892d050daa289f8b6b9c1b185bcd28532f88d610c2642a2dc6f3509740236d33c3e2d9136aab17f819c8c671293bba277717762e8d1c1f7bac9e17dd28d2939a959bb38e500f9c11c38cebbc426e2dea97c40175a655d17400ae6c75ff49e884c79469249e70953258854b64fa8445c585ad45dc6dc6975501c6af7cff7074202c687f8a7bf1a3ac192689755f232275b4c8421b1a5669e9b904c29a292cdf961b783a7c0b4ce736900de4d8c63c5f85a65cb44af34bef840acef84ab75f44c4c9137610b68107aff3bbdcc19119c7a927c115b7b9bfb27d85c500ee77d13ec5a97a3ae6bf51d3b70a5502e8416de7b5eb8e9feee376411ca35c8a7f3f597c7606578cf96a4715ce5a35cf48e39c0a1faa2dee22d74e6819 KeysetHash: 0xfdca3e4e2de25f0a56d0ced68fd1cc64f91b20cde67c964c55105477c02f49be ``` diff --git a/arbitrum-docs/run-arbitrum-node/more-types/01-run-archive-node.mdx b/arbitrum-docs/run-arbitrum-node/more-types/01-run-archive-node.mdx index bfa8b19e7a..772b76ceb1 100644 --- a/arbitrum-docs/run-arbitrum-node/more-types/01-run-archive-node.mdx +++ b/arbitrum-docs/run-arbitrum-node/more-types/01-run-archive-node.mdx @@ -48,7 +48,7 @@ The minimum storage requirements will change as the Nitro chains grow (growing r - Arbitrum One: 9.7TB SSD, currently growing at a rate of about 850GB per month - Arbitrum Nova: 4.3TB SSD, currently growing at a rate of about 1.8TB GB per month 4. **Docker images:** We'll specify these in the below commands; you don't need to download them manually. - - Latest Docker image for **Arbitrum One Nitro**: @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.2-33d30c0@@ + - Latest Docker image for **Arbitrum One Nitro**: @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.1-8f247fd@@ - Latest Docker image for **Arbitrum One Classic**: @@latestClassicNodeImage=offchainlabs/arb-node:v1.4.5-e97c1a4@@ 5. **Database snapshots:** - Nitro database snapshot @@ -92,7 +92,7 @@ To run both Arbitrum Nitro and/or Arbitrum Classic in archive mode, follow one o - **Arbitrum One Nitro archive node**: ```shell - docker run --rm -it -v /some/local/dir/arbitrum:/home/user/.arbitrum -p 0.0.0.0:8547:8547 -p 0.0.0.0:8548:8548 @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.2-33d30c0@@ --parent-chain.connection.url https://l1-node:8545 --chain.id=42161 --http.api=net,web3,eth --http.corsdomain=* --http.addr=0.0.0.0 --http.vhosts=* --execution.caching.archive + docker run --rm -it -v /some/local/dir/arbitrum:/home/user/.arbitrum -p 0.0.0.0:8547:8547 -p 0.0.0.0:8548:8548 @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.1-8f247fd@@ --parent-chain.connection.url https://l1-node:8545 --chain.id=42161 --http.api=net,web3,eth --http.corsdomain=* --http.addr=0.0.0.0 --http.vhosts=* --execution.caching.archive ``` - **Arbitrum One Classic archive node**: ```shell @@ -100,7 +100,7 @@ To run both Arbitrum Nitro and/or Arbitrum Classic in archive mode, follow one o ``` - **Arbitrum One Nitro archive node with forwarding classic execution support**: ```shell - docker run --rm -it -v /some/local/dir/arbitrum:/home/user/.arbitrum -p 0.0.0.0:8547:8547 -p 0.0.0.0:8548:8548 @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.2-33d30c0@@ --parent-chain.connection.url https://l1-node:8545 --chain.id=42161 --execution.rpc.classic-redirect= --http.api=net,web3,eth --http.corsdomain=* --http.addr=0.0.0.0 --http.vhosts=* --execution.caching.archive + docker run --rm -it -v /some/local/dir/arbitrum:/home/user/.arbitrum -p 0.0.0.0:8547:8547 -p 0.0.0.0:8548:8548 @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.1-8f247fd@@ --parent-chain.connection.url https://l1-node:8545 --chain.id=42161 --execution.rpc.classic-redirect= --http.api=net,web3,eth --http.corsdomain=* --http.addr=0.0.0.0 --http.vhosts=* --execution.caching.archive ``` Note that the above commands both map to port `8547` on their hosts. To run both on the same host, you should edit those mapping to different ports and specify your Classic node RPC URL as `` in your Nitro start command. To verify the connection health of your node(s), see [Docker network between containers - Docker Networking Example](https://www.middlewareinventory.com/blog/docker-network-example/). diff --git a/arbitrum-docs/run-arbitrum-node/more-types/02-run-validator-node.mdx b/arbitrum-docs/run-arbitrum-node/more-types/02-run-validator-node.mdx index fd811acd51..6cb6fa88d4 100644 --- a/arbitrum-docs/run-arbitrum-node/more-types/02-run-validator-node.mdx +++ b/arbitrum-docs/run-arbitrum-node/more-types/02-run-validator-node.mdx @@ -12,8 +12,8 @@ This page describes the different strategies a validator may follow and provides This how-to assumes that you're familiar with the following: -- How to run a full node (see instructions [here](/run-arbitrum-node/03-run-full-node.mdx)) -- [How the Rollup protocol works](/how-arbitrum-works/05-validation-and-proving/02-rollup-protocol.mdx) +- How to run a full node (see instructions [here](/run-arbitrum-node/03-run-full-node.mdx) for DAO-governed chains, and [here](/node-running/how-tos/running-an-orbit-node.mdx) for Orbit chains) +- [How the Rollup protocol works](/how-arbitrum-works/06-optimistic-rollup.mdx) - [How BoLD works](/how-arbitrum-works/bold/bold-technical-deep-dive.mdx#how-bold-uses-ethereum), if you're running a validator for a chain that has BoLD activated ## Validation strategies @@ -56,7 +56,7 @@ This section explains how to configure your node to act as a validator. ### Step 0: prerequisites -A validator node is a regular full node with validation enabled, so you'll have to know how to configure a full node. You can find instructions [here](/run-arbitrum-node/03-run-full-node.mdx). +A validator node is a regular full node with validation enabled, so you'll have to know how to configure a full node. You can find instructions [here](/run-arbitrum-node/03-run-full-node.mdx) for DAO-governed chains, and [here](/node-running/how-tos/running-an-orbit-node.mdx) for Orbit chains. Additionally, you'll need a wallet with enough funds to perform actions on-chain and enough tokens to stake. Keep in mind that: @@ -80,7 +80,7 @@ On top of the configuration of a regular full node, you'll need to configure the Here's an example of how to run a defensive validator for Arbitrum One: ```shell -docker run --rm -it -v /some/local/dir/arbitrum:/home/user/.arbitrum @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.2-33d30c0@@ --parent-chain.connection.url=https://l1-mainnet-node:8545 --chain.id=42161 --node.staker.enable --node.staker.strategy=Defensive --node.staker.parent-chain-wallet.password="SOME SECURE PASSWORD" --node.bold.enable --node.bold.strategy=Defensive +docker run --rm -it -v /some/local/dir/arbitrum:/home/user/.arbitrum @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.1-8f247fd@@ --parent-chain.connection.url=https://l1-mainnet-node:8545 --chain.id=42161 --node.staker.enable --node.staker.strategy=Defensive --node.staker.parent-chain-wallet.password="SOME SECURE PASSWORD" --node.bold.enable --node.bold.strategy=Defensive ``` ### Step 2: verify that your node is running as a validator @@ -100,7 +100,7 @@ Furthermore, the following logs will indicate that all components are working as ## Run a validator for an Orbit chain -Validation for Orbit chains works the same way as for DAO-governed Arbitrum chains. However, as specified in [How to run a node](/run-arbitrum-node/03-run-full-node.mdx#required-parameters), you need to include the information of the chain when configuring your node by using `--chain.info-json`. +Validation for Orbit chains works the same way as for DAO-governed Arbitrum chains. However, as specified in [How to run a node](/node-running/how-tos/running-an-orbit-node.mdx#2-child-chain-parameters), you need to include the information of the chain when configuring your node by using `--chain.info-json`. ```shell --chain.info-json= @@ -123,7 +123,7 @@ Nitro includes a tool to create a validator wallet for a specific chain automati Here is an example of how to create a validator wallet for Arbitrum One and exit: ```shell -docker run --rm -it -v /some/local/dir/arbitrum:/home/user/.arbitrum @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.2-33d30c0@@ --parent-chain.connection.url=https://l1-mainnet-node:8545 --chain.id=42161 --node.staker.enable --node.staker.parent-chain-wallet.only-create-key --node.staker.parent-chain-wallet.password="SOME SECURE PASSWORD" +docker run --rm -it -v /some/local/dir/arbitrum:/home/user/.arbitrum @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.1-8f247fd@@ --parent-chain.connection.url=https://l1-mainnet-node:8545 --chain.id=42161 --node.staker.enable --node.staker.parent-chain-wallet.only-create-key --node.staker.parent-chain-wallet.password="SOME SECURE PASSWORD" ``` The wallet file will be created under the mounted directory inside the `/wallet/` directory (for example, `arb1/wallet/` for Arbitrum One, or `nova/wallet/` for Arbitrum Nova). Be sure to backup the wallet file, as it will be the only way to withdraw the stake when desired. diff --git a/arbitrum-docs/run-arbitrum-node/nitro/01-build-nitro-locally.mdx b/arbitrum-docs/run-arbitrum-node/nitro/01-build-nitro-locally.mdx index 9242806509..ec773d2c13 100644 --- a/arbitrum-docs/run-arbitrum-node/nitro/01-build-nitro-locally.mdx +++ b/arbitrum-docs/run-arbitrum-node/nitro/01-build-nitro-locally.mdx @@ -60,7 +60,7 @@ For troubleshooting, check Docker's section in [their documentation](https://doc ### Step 2. Download the Nitro source code ```shell -git clone --branch @@nitroVersionTag=v3.5.2@@ https://github.com/OffchainLabs/nitro.git +git clone --branch @@nitroVersionTag=v3.5.1@@ https://github.com/OffchainLabs/nitro.git cd nitro git submodule update --init --recursive --force ``` diff --git a/arbitrum-docs/run-arbitrum-node/partials/run-full-node/_dao-chains-example.mdx b/arbitrum-docs/run-arbitrum-node/partials/run-full-node/_dao-chains-example.mdx deleted file mode 100644 index 755264422e..0000000000 --- a/arbitrum-docs/run-arbitrum-node/partials/run-full-node/_dao-chains-example.mdx +++ /dev/null @@ -1,3 +0,0 @@ -```shell -docker run --rm -it -v /some/local/dir/arbitrum:/home/user/.arbitrum -p 0.0.0.0:8547:8547 -p 0.0.0.0:8548:8548 @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.2-33d30c0@@ --parent-chain.connection.url= --parent-chain.blob-client.beacon-url= --chain.id= --init.latest=pruned --http.api=net,web3,eth --http.corsdomain=* --http.addr=0.0.0.0 --http.vhosts=* -``` diff --git a/arbitrum-docs/run-arbitrum-node/partials/run-full-node/_dao-chains-parameters.mdx b/arbitrum-docs/run-arbitrum-node/partials/run-full-node/_dao-chains-parameters.mdx deleted file mode 100644 index 943b7e94cb..0000000000 --- a/arbitrum-docs/run-arbitrum-node/partials/run-full-node/_dao-chains-parameters.mdx +++ /dev/null @@ -1,33 +0,0 @@ - - -#### 1. Parent chain (Ethereum) parameters - -The `--parent-chain.connection.url` parameter needs to provide a standard RPC endpoint for an Ethereum node, whether self-hosted or obtained from a node service provider: - -```shell ---parent-chain.connection.url= -``` - -Additionally, use the parameter `--parent-chain.blob-client.beacon-url` to provide a beacon chain RPC endpoint: - -```shell ---parent-chain.blob-client.beacon-url= -``` - -You can find a list of Ethereum beacon chain RPC providers [here](/run-arbitrum-node/05-l1-ethereum-beacon-chain-rpc-providers.mdx). Note that historical blob data is required for these chains to properly sync up if they are new or have been offline for more than 18 days. This means that the beacon chain RPC endpoint you use may also need to provide historical blob data. Please see [Special notes on ArbOS 20: Atlas support for EIP-4844](/run-arbitrum-node/arbos-releases/arbos20.mdx#special-notes-on-arbos-20-atlas-support-for-eip-4844) for more details. - -#### 2. Arbitrum chain parameters - -Use the parameter `--chain.id` to specify the chain you're running this node for. See [RPC endpoints and providers](/build-decentralized-apps/reference/01-node-providers.mdx) to find the IDs of these chains. - -```shell ---chain.id= -``` - -Alternatively, you can use the parameter `--chain.name` to specify the chain you're running this node for. Use `arb1` for Arbitrum One, `nova` for Arbitrum Nova or `sepolia-rollup` for Arbitrum Sepolia. - -```shell ---chain.name= -``` diff --git a/arbitrum-docs/run-arbitrum-node/partials/run-full-node/_orbit-chains-example.mdx b/arbitrum-docs/run-arbitrum-node/partials/run-full-node/_orbit-chains-example.mdx deleted file mode 100644 index b636e53dab..0000000000 --- a/arbitrum-docs/run-arbitrum-node/partials/run-full-node/_orbit-chains-example.mdx +++ /dev/null @@ -1,5 +0,0 @@ -```shell -docker run --rm -it -v /some/local/dir/arbitrum:/home/user/.arbitrum -p 0.0.0.0:8547:8547 -p 0.0.0.0:8548:8548 @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.2-33d30c0@@ --parent-chain.connection.url= --chain.info-json= --chain.name= --node.feed.input.url= --execution.forwarding-target= --http.api=net,web3,eth --http.corsdomain=* --http.addr=0.0.0.0 --http.vhosts=* -``` - -- You can see an example of `--chain.info-json` in the section above. diff --git a/arbitrum-docs/run-arbitrum-node/partials/run-full-node/_orbit-chains-parameters.mdx b/arbitrum-docs/run-arbitrum-node/partials/run-full-node/_orbit-chains-parameters.mdx deleted file mode 100644 index 22bfe65b4c..0000000000 --- a/arbitrum-docs/run-arbitrum-node/partials/run-full-node/_orbit-chains-parameters.mdx +++ /dev/null @@ -1,92 +0,0 @@ - - -#### 1. Parent chain parameters - -The `--parent-chain.connection.url` parameter needs to provide a standard RPC endpoint for an EVM node, whether self-hosted or obtained from a node service provider: - -```shell ---parent-chain.connection.url= -``` - -:::info Public Arbitrum RPC endpoints - -[Public Arbitrum RPC endpoints](/build-decentralized-apps/reference/01-node-providers.mdx#arbitrum-public-rpc-endpoints) rate-limit connections. To avoid hitting a bottleneck, you can run a local node for the parent chain or rely on third-party RPC providers. - -::: - -Additionally, if the chain is a Layer-2 (L2) chain on top of Ethereum and uses blobs to post calldata, use the parameter `--parent-chain.blob-client.beacon-url` to provide a beacon chain RPC endpoint: - -```shell ---parent-chain.blob-client.beacon-url= -``` - -You can find a list of Ethereum beacon chain RPC providers [here](/run-arbitrum-node/05-l1-ethereum-beacon-chain-rpc-providers.mdx). Note that historical blob data is required for these chains to properly sync up if they are new or have been offline for more than 18 days. This means that the beacon chain RPC endpoint you use may also need to provide historical blob data. Please see [Special notes on ArbOS 20: Atlas support for EIP-4844](/run-arbitrum-node/arbos-releases/arbos20.mdx#special-notes-on-arbos-20-atlas-support-for-eip-4844) for more details. - -#### 2. Child chain parameters - -The parameter `--chain.info-json` specifies a JSON string that contains the information about the Orbit chain required by the node. - -```shell ---chain.info-json= -``` - -This information should be provided by the chain owner and will look something like the following: - -```shell ---chain.info-json="[{\"chain-id\":94692861356,\"parent-chain-id\":421614,\"chain-name\":\"My Arbitrum L3 Chain\",\"chain-config\":{\"chainId\":94692861356,\"homesteadBlock\":0,\"daoForkBlock\":null,\"daoForkSupport\":true,\"eip150Block\":0,\"eip150Hash\":\"0x0000000000000000000000000000000000000000000000000000000000000000\",\"eip155Block\":0,\"eip158Block\":0,\"byzantiumBlock\":0,\"constantinopleBlock\":0,\"petersburgBlock\":0,\"istanbulBlock\":0,\"muirGlacierBlock\":0,\"berlinBlock\":0,\"londonBlock\":0,\"clique\":{\"period\":0,\"epoch\":0},\"arbitrum\":{\"EnableArbOS\":true,\"AllowDebugPrecompiles\":false,\"DataAvailabilityCommittee\":false,\"InitialArbOSVersion\":10,\"InitialChainOwner\":\"0xAde4000C87923244f0e95b41f0e45aa3C02f1Bb2\",\"GenesisBlockNum\":0}},\"rollup\":{\"bridge\":\"0xde835286442c6446E36992c036EFe261AcD87F6d\",\"inbox\":\"0x0592d3861Ea929B5d108d915c36f64EE69418049\",\"sequencer-inbox\":\"0xf9d77199288f00440Ed0f494Adc0005f362c17b1\",\"rollup\":\"0xF5A42aDA664E7c2dFE9DDa4459B927261BF90E09\",\"validator-utils\":\"0xB11EB62DD2B352886A4530A9106fE427844D515f\",\"validator-wallet-creator\":\"0xEb9885B6c0e117D339F47585cC06a2765AaE2E0b\",\"deployed-at\":1764099}}]" -``` - -Use the parameter `--chain.name` to specify the chain you're running this node for. The name of the chain should match the name used in the JSON string used in `--chain.info-json`: - -```shell ---chain.name= -``` - -#### 3. Parameters to connect to the sequencer - -Use the parameter `--node.feed.input.url` to point at the sequencer feed endpoint, which should be provided by the chain owner. - -```shell ---node.feed.input.url= -``` - -Use the parameter `--execution.forwarding-target` to point at the sequencer node of the orbit chain, which should also be provided by the chain owner. - -```shell ---execution.forwarding-target= -``` - -#### 3. Additional parameters for AnyTrust chains - -If you're running a node for an Anytrust chain, you need to specify information about the Data Availability Committee (DAC) in the configuration of your node. - -First, enable `data-availability` using the following parameters: - -```shell ---node.data-availability.enable ---node.data-availability.rest-aggregator.enable -``` - -Then, choose one of these methods to specify the DAS REST endpoints that your node will read the information from. These endpoints should also be provided by the chain owner. - - 1. Set the DAS REST endpoints directly: - - ```shell - --node.data-availability.rest-aggregator.urls= - ``` - - 2. Set a URL that returns a list of the DAS REST endpoints: - - ```shell - --node.data-availability.rest-aggregator.online-url-list= - ``` - -::::tip Setting a DAS (for chain owners) - -If you are a chain owner, please refer to the [DAC setup guide](/run-arbitrum-node/data-availability-committees/01-get-started.mdx#if-you-are-a-chain-owner) to set it up. - -Additionally, for your batch poster to post data to the DAS, follow [step 3 of How to configure a DAC](/run-arbitrum-node/data-availability-committees/04-configure-dac.mdx#step-3-craft-the-new-configuration-for-the-batch-poster) to configure your batch poster node. - -:::: diff --git a/arbitrum-docs/run-arbitrum-node/sequencer/01-run-feed-relay.mdx b/arbitrum-docs/run-arbitrum-node/sequencer/01-run-feed-relay.mdx index 409320c8b4..43ec1b522b 100644 --- a/arbitrum-docs/run-arbitrum-node/sequencer/01-run-feed-relay.mdx +++ b/arbitrum-docs/run-arbitrum-node/sequencer/01-run-feed-relay.mdx @@ -21,11 +21,11 @@ The feed relay is in the same docker image as the Nitro node. - Here is an example of how to run the feed relay for Arbitrum One: ```shell - docker run --rm -it -p 0.0.0.0:9642:9642 --entrypoint relay @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.2-33d30c0@@ --node.feed.output.addr=0.0.0.0 --node.feed.input.url=wss://arb1.arbitrum.io/feed --chain.id=42161 + docker run --rm -it -p 0.0.0.0:9642:9642 --entrypoint relay @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.1-8f247fd@@ --node.feed.output.addr=0.0.0.0 --node.feed.input.url=wss://arb1.arbitrum.io/feed --chain.id=42161 ``` - Here is an example of how to run nitro-node for Arbitrum One with custom relay: ```shell - docker run --rm -it -v /some/local/dir/arbitrum:/home/user/.arbitrum -p 0.0.0.0:8547:8547 -p 0.0.0.0:8548:8548 @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.2-33d30c0@@ --parent-chain.connection.url=https://l1-mainnet-node:8545 --chain.id=42161 --http.api=net,web3,eth --http.corsdomain=* --http.addr=0.0.0.0 --http.vhosts=* --node.feed.input.url=ws://local-relay-address:9642 + docker run --rm -it -v /some/local/dir/arbitrum:/home/user/.arbitrum -p 0.0.0.0:8547:8547 -p 0.0.0.0:8548:8548 @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.1-8f247fd@@ --parent-chain.connection.url=https://l1-mainnet-node:8545 --chain.id=42161 --http.api=net,web3,eth --http.corsdomain=* --http.addr=0.0.0.0 --http.vhosts=* --node.feed.input.url=ws://local-relay-address:9642 ``` Note that Arbitrum classic does not communicate with Nitro sequencer, so classic relay is no longer used. diff --git a/arbitrum-docs/run-arbitrum-node/sequencer/03-run-sequencer-coordination-manager.mdx b/arbitrum-docs/run-arbitrum-node/sequencer/03-run-sequencer-coordination-manager.mdx index cbb23133af..e97f73ad72 100644 --- a/arbitrum-docs/run-arbitrum-node/sequencer/03-run-sequencer-coordination-manager.mdx +++ b/arbitrum-docs/run-arbitrum-node/sequencer/03-run-sequencer-coordination-manager.mdx @@ -13,7 +13,7 @@ The tool offers keyboard-only support. Any changes you make are stored locally u - Clone and enter nitro repository: ```shell - git clone --branch @@nitroVersionTag=v3.5.2@@ https://github.com/OffchainLabs/nitro.git + git clone --branch @@nitroVersionTag=v3.5.1@@ https://github.com/OffchainLabs/nitro.git cd nitro ``` diff --git a/arbitrum-docs/stylus/concepts/how-it-works.md b/arbitrum-docs/stylus/concepts/how-it-works.md index bc334b36e9..aa036965a0 100644 --- a/arbitrum-docs/stylus/concepts/how-it-works.md +++ b/arbitrum-docs/stylus/concepts/how-it-works.md @@ -41,7 +41,7 @@ EVM contracts continue to execute the same way they were before Stylus. When cal Nitro operates in two modes: a "happy case" where it compiles execution history to native code, and a "sad case" during validator disputes, where it compiles execution history to WASM for interactive fraud proofs on Ethereum. Stylus builds on Nitro's fraud-proving technology, allowing it to verify both execution history and WASM programs deployed by developers. -Stylus is made possible by Nitro’s ability to replay and verify disputes using WASM. Validators bisect disputes until an invalid step is identified and proven on-chain through a [“one-step proof.”](/how-arbitrum-works/05-validation-and-proving/03-proving-and-challenges.mdx#simplified-bisection-protocol). This deterministic fraud-proving capability ensures the correctness of any arbitrary program compiled to WASM. The combination of WASM's and Nitro's properties enables this technological leap we call Stylus. +Stylus is made possible by Nitro’s ability to replay and verify disputes using WASM. Validators bisect disputes until an invalid step is identified and proven on-chain through a [“one-step proof.”](/how-arbitrum-works/07-interactive-fraud-proofs.mdx#bisection-protocol-simplified-version). This deterministic fraud-proving capability ensures the correctness of any arbitrary program compiled to WASM. The combination of WASM's and Nitro's properties enables this technological leap we call Stylus. For more details on Nitro’s architecture, refer to the [documentation](/how-arbitrum-works/01-a-gentle-introduction.mdx) or the [Nitro whitepaper](https://github.com/OffchainLabs/nitro/blob/master/docs/Nitro-whitepaper.pdf). diff --git a/arbitrum-docs/welcome/get-started.mdx b/arbitrum-docs/welcome/get-started.mdx index 7995251d94..7ff71f49e5 100644 --- a/arbitrum-docs/welcome/get-started.mdx +++ b/arbitrum-docs/welcome/get-started.mdx @@ -14,17 +14,17 @@ Arbitrum suite along with onboarding guidance tailored to specific audiences. The Arbitrum suite includes the protocols, chains, services, and SDKs that power the Arbitrum ecosystem: -| Component | Description | -| --------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | -| [Arbitrum Rollup](/how-arbitrum-works/05-validation-and-proving/02-rollup-protocol.mdx) | A **protocol** for scaling Ethereum smart contracts. | -| [Arbitrum AnyTrust](/how-arbitrum-works/08-anytrust-protocol.mdx) | A **protocol** for scaling Ethereum smart contracts even further, with a mild trust assumption. | -| [Arbitrum Nitro](/how-arbitrum-works/01-a-gentle-introduction.mdx) | The node **software** that codifies the Rollup and AnyTrust protocols. | -| [Arbitrum nodes](/run-arbitrum-node/03-run-full-node.mdx) | **Machines** that run Nitro in order to service and/or interact with an Arbitrum chain. | -| [Arbitrum One](https://portal.arbitrum.io/?chains=arbitrum-one) | A public Rollup **chain**. | -| [Arbitrum Nova](https://portal.arbitrum.io/?chains=arbitrum-nova) | A public AnyTrust **chain**. | -| [Arbitrum bridge](https://bridge.arbitrum.io/) | Lets you move ETH and ERC-20 tokens between Ethereum, Arbitrum, and select Orbit chains. | -| [Arbitrum Orbit](https://orbit.arbitrum.io/) | Lets you run your own Rollup and AnyTrust chains. | -| [Arbitrum Stylus](/stylus/gentle-introduction.mdx) | Lets you write EVM-compatible smart contracts in Rust and any other language that compiles to Wasm. | +| Component | Description | +| ------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------- | +| [Arbitrum Rollup](/how-arbitrum-works/06-optimistic-rollup.mdx) | A **protocol** for scaling Ethereum smart contracts. | +| [Arbitrum AnyTrust](/how-arbitrum-works/08-anytrust-protocol.mdx) | A **protocol** for scaling Ethereum smart contracts even further, with a mild trust assumption. | +| [Arbitrum Nitro](/how-arbitrum-works/01-a-gentle-introduction.mdx) | The node **software** that codifies the Rollup and AnyTrust protocols. | +| [Arbitrum nodes](/run-arbitrum-node/03-run-full-node.mdx) | **Machines** that run Nitro in order to service and/or interact with an Arbitrum chain. | +| [Arbitrum One](https://portal.arbitrum.io/?chains=arbitrum-one) | A public Rollup **chain**. | +| [Arbitrum Nova](https://portal.arbitrum.io/?chains=arbitrum-nova) | A public AnyTrust **chain**. | +| [Arbitrum bridge](https://bridge.arbitrum.io/) | Lets you move ETH and ERC-20 tokens between Ethereum, Arbitrum, and select Orbit chains. | +| [Arbitrum Orbit](https://orbit.arbitrum.io/) | Lets you run your own Rollup and AnyTrust chains. | +| [Arbitrum Stylus](/stylus/gentle-introduction.mdx) | Lets you write EVM-compatible smart contracts in Rust and any other language that compiles to Wasm. | ## Arbitrum for users diff --git a/vercel.json b/vercel.json index cb5fa7bd5d..def6b42120 100644 --- a/vercel.json +++ b/vercel.json @@ -17,37 +17,22 @@ }, { "source": "/(proving/challenge-manager/?)", - "destination": "/how-arbitrum-works/validation-and-proving/validation-and-proving", + "destination": "/how-arbitrum-works/interactive-fraud-proofs", "permanent": false }, { "source": "/(how-arbitrum-works/fraud-proofs/challenge-manager/?)", - "destination": "/how-arbitrum-works/validation-and-proving/validation-and-proving", - "permanent": false - }, - { - "source": "/(how-arbitrum-works/optimistic-rollup/?)", - "destination": "/how-arbitrum-works/validation-and-proving/rollup-protocol", - "permanent": false - }, - { - "source": "/(how-arbitrum-works/interactive-fraud-proofs/?)", - "destination": "/how-arbitrum-works/validation-and-proving/validation-and-proving", + "destination": "/how-arbitrum-works/interactive-fraud-proofs", "permanent": false }, { "source": "/(fraud-proofs/challenge-manager/?)", - "destination": "/how-arbitrum-works/validation-and-proving/validation-and-proving", - "permanent": false - }, - { - "source": "/(how-arbitrum-works/separating-execution-from-proving/?)", - "destination": "/how-arbitrum-works/validation-and-proving/validation-and-proving.mdx", + "destination": "/how-arbitrum-works/interactive-fraud-proofs", "permanent": false }, { "source": "/(how-arbitrum-works/geth-at-the-core/?)", - "destination": "/how-arbitrum-works/state-transition-function/stf-gentle-intro", + "destination": "/how-arbitrum-works/state-transition-function/01-stf-gentle-intro", "permanent": false }, { @@ -430,11 +415,6 @@ "destination": "/run-arbitrum-node/overview", "permanent": false }, - { - "source": "/(node-running/how-tos/running-an-orbit-node/?)", - "destination": "/run-arbitrum-node/run-full-node", - "permanent": false - }, { "source": "/(bridge-tokens/concepts/usdc-concept/?)", "destination": "/arbitrum-bridge/usdc-arbitrum-one", diff --git a/website/docusaurus.config.js b/website/docusaurus.config.js index a17f0c02a8..5cdb04827a 100644 --- a/website/docusaurus.config.js +++ b/website/docusaurus.config.js @@ -135,39 +135,7 @@ const config = { }, ], require.resolve('docusaurus-plugin-fathom'), - [ - 'docusaurus-lunr-search', - { - excludeRoutes: [ - 'launch-orbit-chain/02-configure-your-chain/advanced-configurations/01-layer-leap', - 'launch-orbit-chain/02-configure-your-chain/common-configurations/03-stake-and-validator-configurations', - 'launch-orbit-chain/02-configure-your-chain/common-configurations/04-arbos-configuration', - 'launch-orbit-chain/02-configure-your-chain/common-configurations/05-gas-optimization-tools', - 'launch-orbit-chain/02-configure-your-chain/common-configurations/07-batch-posting-assertion-control', - 'launch-orbit-chain/02-configure-your-chain/common-configurations/08-sequencer-timing-adjustments', - 'launch-orbit-chain/02-configure-your-chain/common-configurations/09-per-batch-gas-cost', - 'launch-orbit-chain/02-configure-your-chain/common-configurations/10-smart-contract-size-limit', - 'launch-orbit-chain/02-configure-your-chain/common-configurations/11-customizing-anytrust', - 'launch-orbit-chain/02-start-your-journey', - 'launch-orbit-chain/03-deploy-an-orbit-chain/07-canonical-factory-contracts', - 'launch-orbit-chain/03-orbit-license', - 'launch-orbit-chain/04-maintain-your-chain/01-bridging', - 'launch-orbit-chain/04-maintain-your-chain/02-monitoring', - 'launch-orbit-chain/04-maintain-your-chain/04-guidance/01-decentralization-security', - 'launch-orbit-chain/04-maintain-your-chain/04-guidance/02-guidance-on-altda', - 'launch-orbit-chain/06-third-party-integrations/03-integrations', - 'launch-orbit-chain/07-orbit-node-runners/orbit-node-providers', - 'launch-orbit-chain/08-ecosystem-support/01-orbit-portal', - 'launch-orbit-chain/08-ecosystem-support/03-get-listed-orbit-platforms', - 'launch-orbit-chain/how-tos/how-to-configure-your-chain', - 'launch-orbit-chain/reference/orbit-batch-poster-configuration', - 'launch-orbit-chain/reference/orbit-configuration-parameters', - 'launch-orbit-chain/reference/orbit-fast-block-times', - 'launch-orbit-chain/reference/orbit-sequencer-configuration', - 'launch-orbit-chain/reference/orbit-smart-contract-size-limit', - ], - }, - ], + require.resolve('docusaurus-lunr-search'), require.resolve('docusaurus-plugin-sass'), ], themeConfig: diff --git a/website/sidebars.js b/website/sidebars.js index e90ac7a82d..5a10548121 100644 --- a/website/sidebars.js +++ b/website/sidebars.js @@ -498,11 +498,9 @@ const sidebars = { collapsed: true, items: [ { - type: 'html', - value: - 'Run a full node ↓', - // q: why use an anchor html tag here? - // a: see note at end of file + type: 'doc', + id: 'node-running/how-tos/running-an-orbit-node', + label: 'Run a full node', }, { type: 'html', @@ -743,6 +741,13 @@ const sidebars = { label: 'Use Timeboost', id: 'run-arbitrum-node/how-to-use-timeboost', }, + { + type: 'html', + value: + 'Run a full Orbit node ↑', + // q: why use an anchor html tag here? + // a: see note at end of file + }, { type: 'html', value: @@ -932,41 +937,35 @@ const sidebars = { ], }, { - type: 'category', - label: 'Validation and Proving', - items: [ - { - type: 'doc', - label: 'Validation and proving overview', - id: 'how-arbitrum-works/validation-and-proving/validation-and-proving', - }, - { - type: 'doc', - label: 'Rollup protocol', - id: 'how-arbitrum-works/validation-and-proving/rollup-protocol', - }, - { - type: 'doc', - label: 'Proving and challenges', - id: 'how-arbitrum-works/validation-and-proving/proving-and-challenges', - }, - ], + type: 'doc', + id: 'how-arbitrum-works/separating-execution-from-proving', + label: 'Separating Execution from Proving', }, { type: 'doc', - id: 'how-arbitrum-works/anytrust-protocol', - label: 'AnyTrust protocol', + id: 'how-arbitrum-works/optimistic-rollup', + label: 'Optimistic Rollup', }, { type: 'doc', - id: 'how-arbitrum-works/l2-to-l1-messaging', - label: 'Child to parent chain messaging', + id: 'how-arbitrum-works/interactive-fraud-proofs', + label: 'Challenges: Interactive Fraud Proofs', + }, + { + type: 'doc', + id: 'how-arbitrum-works/anytrust-protocol', + label: 'AnyTrust protocol', }, { type: 'doc', id: 'how-arbitrum-works/gas-fees', label: 'Gas and fees', }, + { + type: 'doc', + id: 'how-arbitrum-works/l2-to-l1-messaging', + label: 'L2 to L1 messaging', + }, { type: 'doc', id: 'how-arbitrum-works/data-availability', diff --git a/website/src/resources/globalVars.js b/website/src/resources/globalVars.js index fe6ecd5825..3d6b8e4d94 100644 --- a/website/src/resources/globalVars.js +++ b/website/src/resources/globalVars.js @@ -21,7 +21,7 @@ const sepoliaForceIncludePeriodBlocks = 5760; const globalVars = { // Node docker images - latestNitroNodeImage: 'offchainlabs/nitro-node:v3.5.2-33d30c0', + latestNitroNodeImage: 'offchainlabs/nitro-node:v3.5.1-8f247fd', latestClassicNodeImage: 'offchainlabs/arb-node:v1.4.5-e97c1a4', // Node snapshots (taken around April 20th, 2013) @@ -38,7 +38,7 @@ const globalVars = { // Nitro Github references nitroRepositorySlug: 'nitro', - nitroVersionTag: 'v3.5.2', + nitroVersionTag: 'v3.5.1', nitroPathToPrecompiles: 'precompiles', nitroContractsRepositorySlug: 'nitro-contracts', @@ -69,7 +69,7 @@ const globalVars = { sepoliaDisputeWindowMinutes: blocksToMinutes(sepoliaDisputeWindowBlocks), // base stake - arbOneBaesStakeEth: 3600, + arbOneBaesStakeEth: 1, novaBaesStakeEth: 1, goerliBaesStakeEth: 1, sepoliaBaesStakeEth: 1, diff --git a/website/src/resources/precompilesInformation.js b/website/src/resources/precompilesInformation.js index 46fdd6552a..89f72836d8 100644 --- a/website/src/resources/precompilesInformation.js +++ b/website/src/resources/precompilesInformation.js @@ -8,15 +8,34 @@ const precompilesInformation = { getdefaultaggregator: { deprecated: true, }, + addbatchposter: { + description: 'Adds newBatchPoster as a batch poster', + }, gettxbasefee: { + description: 'Deprecated: returns 0', deprecated: true, }, settxbasefee: { + description: 'Deprecated: does nothing', deprecated: true, }, }, }, ArbDebug: { + methodOverrides: { + events: { + description: 'Emit events with values based on the args provided', + }, + eventsview: { + description: 'Tries (and fails) to emit logs in a view context', + }, + customrevert: { + description: 'Throws a custom error', + }, + legacyerror: { + description: 'Throws a hardcoded error', + }, + }, eventOverrides: { basic: { description: 'Emitted in Events for testing', @@ -32,40 +51,87 @@ const precompilesInformation = { ArbFunctionTable: {}, ArbGasInfo: { methodOverrides: { - getcurrenttxl1gasfees: { + getl1pricingsurplus: { + description: 'Returns the surplus of funds for L1 batch posting payments (may be negative)', + }, + getpricinginertia: { description: - 'GetCurrentTxL1GasFees gets the fee in wei paid to the batch poster for posting this tx', + 'Returns how slowly ArbOS updates the L2 basefee in response to backlogged gas', }, - GetL1PricingEquilibrationUnits: { - availableSinceArbOS: 20, + getperbatchgascharge: { + description: + 'Returns the base charge (in L1 gas) attributed to each data batch in the calldata pricer', + }, + getamortizedcostcapbips: { + description: 'Returns the cost amortization cap in basis points', }, - GetLastL1PricingUpdateTime: { - availableSinceArbOS: 20, + getl1feesavailable: { + description: 'Returns the available funds from L1 fees', + }, + getl1pricingequilibrationunits: { + description: + 'Returns the equilibration units parameter for L1 price adjustment algorithm (Available since ArbOS 20)', }, - GetL1PricingFundsDueForRewards: { - availableSinceArbOS: 20, + getlastl1pricingupdatetime: { + description: + 'Returns the last time the L1 calldata pricer was updated (Available since ArbOS 20)', + }, + getl1pricingfundsdueforrewards: { + description: + 'Returns the amount of L1 calldata payments due for rewards (per the L1 reward rate) (Available since ArbOS 20)', }, - GetL1PricingUnitsSinceUpdate: { - availableSinceArbOS: 20, + getl1pricingunitssinceupdate: { + description: + 'Returns the amount of L1 calldata posted since the last update (Available since ArbOS 20)', }, - GetLastL1PricingSurplus: { - availableSinceArbOS: 20, + getlastl1pricingsurplus: { + description: + 'Returns the L1 pricing surplus as of the last update (may be negative) (Available since ArbOS 20)', }, }, }, ArbInfo: {}, ArbOwner: { methodOverrides: { - setBrotliCompressionLevel: { + setl1pricingequilibrationunits: { + description: 'Sets equilibration units parameter for L1 price adjustment algorithm', + }, + setl1pricinginertia: { + description: 'Sets inertia parameter for L1 price adjustment algorithm', + }, + setl1pricingrewardrecipient: { + description: 'Sets reward recipient address for L1 price adjustment algorithm', + }, + setl1pricingrewardrate: { + description: 'Sets reward amount for L1 price adjustment algorithm, in wei per unit', + }, + setl1priceperunit: { + description: 'Set how much ArbOS charges per L1 gas spent on transaction data.', + }, + setperbatchgascharge: { description: - 'Sets the Brotli compression level used for fast compression (default level is 1)', + 'Sets the base charge (in L1 gas) attributed to each data batch in the calldata pricer', + }, + setamortizedcostcapbips: { + description: 'Sets the cost amortization cap in basis points', + }, + releasel1pricersurplusfunds: { + description: 'Releases surplus funds from L1PricerFundsPoolAddress for use', + }, + setbrotlicompressionlevel: { + description: + 'Sets the Brotli compression level used for fast compression (Available in ArbOS version 12 with default level as 1)', + }, + setchainconfig: { + description: 'Sets serialized chain config in ArbOS state', }, }, }, ArbOwnerPublic: { methodOverrides: { - RectifyChainOwner: { - availableSinceArbOS: 11, + rectifychainowner: { + description: + 'RectifyChainOwner checks if the account is a chain owner (Available in ArbOS version 11)', }, }, eventOverrides: { @@ -80,6 +146,10 @@ const precompilesInformation = { getcurrentredeemer: { description: 'Gets the redeemer of the current retryable redeem attempt', }, + submitretryable: { + description: + 'Do not call. This method represents a retryable submission to aid explorers. Calling it will always revert.', + }, }, eventOverrides: { ticketcreated: { diff --git a/website/src/scripts/precompile-reference-generator.ts b/website/src/scripts/precompile-reference-generator.ts index 49e57fdf0e..c2188976f2 100644 --- a/website/src/scripts/precompile-reference-generator.ts +++ b/website/src/scripts/precompile-reference-generator.ts @@ -11,7 +11,6 @@ type PrecompileMethodInfo = { implementationLine: number; description: string; deprecated?: boolean; - availableSinceArbOS?: number; }; type PrecompileEventInfo = { @@ -90,17 +89,11 @@ const renderMethodsInTable = ( }); if (methodOverrides) { - // Making all method names lowercase - const lowercasedMethodOverrides = Object.keys(methodOverrides).reduce((acc, key) => { - acc[key.toLowerCase()] = methodOverrides[key]; - return acc; - }, {}); - // Merge potential overrides - Object.keys(lowercasedMethodOverrides).map((methodName: string) => { + Object.keys(methodOverrides).map((methodName: string) => { methodsInformation[methodName] = { ...methodsInformation[methodName], - ...lowercasedMethodOverrides[methodName], + ...methodOverrides[methodName], }; }); } @@ -124,9 +117,6 @@ const renderMethodsInTable = ( if (methodInfo.deprecated) { showDeprecationFlag = true; } - if (methodInfo.availableSinceArbOS) { - methodInfo.description += ` (Available since ArbOS ${methodInfo.availableSinceArbOS})`; - } return ` ${methodInfo.deprecated ? `⚠️` : ''}${methodInfo.signature} diff --git a/website/static/img/dapps-withdrawing-ether.svg b/website/static/img/dapps-withdrawing-ether.svg old mode 100644 new mode 100755 index 784b8e65c3..714799ffcf --- a/website/static/img/dapps-withdrawing-ether.svg +++ b/website/static/img/dapps-withdrawing-ether.svg @@ -1,683 +1,10 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + diff --git a/website/yarn.lock b/website/yarn.lock index 3f32e9b5c8..ed9d58a6a7 100644 --- a/website/yarn.lock +++ b/website/yarn.lock @@ -13270,4 +13270,4 @@ zwitch@^1.0.0: zwitch@^2.0.0: version "2.0.4" resolved "https://registry.yarnpkg.com/zwitch/-/zwitch-2.0.4.tgz#c827d4b0acb76fc3e685a4c6ec2902d51070e9d7" - integrity sha512-bXE4cR/kVZhKZX/RjPEflHaKVhUVl85noU3v6b8apfQEc1x4A+zBxjZ4lN8LqGd6WZ3dl98pY4o717VFmoPp+A== \ No newline at end of file + integrity sha512-bXE4cR/kVZhKZX/RjPEflHaKVhUVl85noU3v6b8apfQEc1x4A+zBxjZ4lN8LqGd6WZ3dl98pY4o717VFmoPp+A== From 8de7e69557ab8323b331d0e82760fbdce7334c1f Mon Sep 17 00:00:00 2001 From: Jason-Wanxt Date: Thu, 20 Mar 2025 16:56:34 +0800 Subject: [PATCH 6/6] remove orbit node --- .../how-tos/running-an-orbit-node.mdx | 158 ------------------ 1 file changed, 158 deletions(-) delete mode 100644 arbitrum-docs/node-running/how-tos/running-an-orbit-node.mdx diff --git a/arbitrum-docs/node-running/how-tos/running-an-orbit-node.mdx b/arbitrum-docs/node-running/how-tos/running-an-orbit-node.mdx deleted file mode 100644 index d3c30b6291..0000000000 --- a/arbitrum-docs/node-running/how-tos/running-an-orbit-node.mdx +++ /dev/null @@ -1,158 +0,0 @@ ---- -title: 'How to run a full node for an Orbit chain' -description: Learn how to run an Arbitrum orbit node on your local machine -author: Mehdi Salehi -sme: Mehdi Salehi -content_type: how-to ---- - -This how-to provides step-by-step instructions for running an Orbit node on your local machine. - -## Prerequisites - -Latest Docker Image: @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.1-8f247fd@@ - -| Minimum Hardware Configuration | -| :--------------------------------------------------------------- | -| **RAM**: 8-16 GB | -| **CPU**: 2-4 core CPU (For AWS: t3 xLarge | -| **Storage**: Depends on the Orbit chain and its traffic overtime | - -## Required parameters - -### 1. Parent chain parameters - -The `parent-chain` argument needs to provide a standard RPC endpoint for an EVM node, whether self-hosted or obtained from a node service provider: - -```shell ---parent-chain.connection.url= -``` - -:::note - -[Public Arbitrum RPC endpoints](/build-decentralized-apps/reference/01-node-providers.mdx#arbitrum-public-rpc-endpoints) rate-limit connections. To avoid hitting a bottleneck, you can run a local node for the parent chain or rely on third-party RPC providers. - -::: - -### 2. Child chain parameters - -In the Arbitrum Orbit context, the child chain is an L2 or an L3 Orbit chain, and the required parameters are `chain.info-json` and `chain.name` - -#### 1. `chain.info-json` - -`--chain.info-json` is a JSON string that contains required information about the Orbit chain. - -```shell ---chain.info-json= -``` - -An example of `chain.info-json` is available in the next section. - -#### 2. `chain.name` - -`--chain.name` is a mandatory flag that needs to match the chain name used in `--chain.info-json`: - -```shell ---chain.name= -``` - -#### 3. `execution.forwarding-target` - -You need to set the --execution.forwarding-target flag if you are running a regular full node (Not sequencer). - -```shell ---execution.forwarding-target= -``` - -#### 4. AnyTrust chains - -For Anytrust chains, you need to to add the following flags to the command or configuration: - -```shell ---node.data-availability.enable ---node.data-availability.rest-aggregator.enable -``` - -And, you need to set the following flag to specify the DAS REST endpoints, there two optional methods: - -1. Set URLs directly: - -```shell ---node.data-availability.rest-aggregator.urls= -``` - -2. Or set an URL that returns a list of the DAS REST endpoints: - -```shell ---node.data-availability.rest-aggregator.online-url-list= -``` - -Please contact the chain owners to get the URL of the DAS REST endpoints. If you are a chain owner, please refer to the [DAC setup guide](/run-arbitrum-node/data-availability-committees/01-get-started.mdx#if-you-are-a-chain-owner) to set it up. - -### 3.Important ports - -| Protocol | Port | -| ----------------- | ------ | -| `RPC`/`http` | `8547` | -| `RPC`/`websocket` | `8548` | -| `Sequencer Feed` | `9642` | - -- Please note: the `RPC`/`websocket` protocol requires some ports to be enabled, you can use the following flags: - - `--ws.port=8548` - - `--ws.addr=0.0.0.0` - - `--ws.origins=\*` - -### 4. Putting it all together - -- When running a Docker image, an external volume should be mounted to persist the database across restarts. The mount point inside the Docker image should be `/home/user/.arbitrum` - -- Example: - - ```shell wordWrap=true - docker run --rm -it -v /some/local/dir/arbitrum:/home/user/.arbitrum -p 0.0.0.0:8547:8547 -p 0.0.0.0:8548:8548 @@latestNitroNodeImage=offchainlabs/nitro-node:v3.5.1-8f247fd@@ --parent-chain.connection.url= --chain.id= --chain.name= --http.api=net,web3,eth --http.corsdomain=* --http.addr=0.0.0.0 --http.vhosts=* --chain.info-json= --execution.forwarding-targe= - ``` - - - Ensure that `/some/local/dir/arbitrum` already exists otherwise the directory might be created with `root` as owner, and the Docker container won't be able to write to it - - - When using the flag `--chain.info-json=`, replace `` with the specific `chain info` JSON string of the Orbit chain for which you wish to run the node: - -- Example: - - ```shell wordWrap=true - --chain.info-json="[{\"chain-id\":94692861356,\"parent-chain-id\":421614,\"chain-name\":\"My Arbitrum L3 Chain\",\"chain-config\":{\"chainId\":94692861356,\"homesteadBlock\":0,\"daoForkBlock\":null,\"daoForkSupport\":true,\"eip150Block\":0,\"eip150Hash\":\"0x0000000000000000000000000000000000000000000000000000000000000000\",\"eip155Block\":0,\"eip158Block\":0,\"byzantiumBlock\":0,\"constantinopleBlock\":0,\"petersburgBlock\":0,\"istanbulBlock\":0,\"muirGlacierBlock\":0,\"berlinBlock\":0,\"londonBlock\":0,\"clique\":{\"period\":0,\"epoch\":0},\"arbitrum\":{\"EnableArbOS\":true,\"AllowDebugPrecompiles\":false,\"DataAvailabilityCommittee\":false,\"InitialArbOSVersion\":10,\"InitialChainOwner\":\"0xAde4000C87923244f0e95b41f0e45aa3C02f1Bb2\",\"GenesisBlockNum\":0}},\"rollup\":{\"bridge\":\"0xde835286442c6446E36992c036EFe261AcD87F6d\",\"inbox\":\"0x0592d3861Ea929B5d108d915c36f64EE69418049\",\"sequencer-inbox\":\"0xf9d77199288f00440Ed0f494Adc0005f362c17b1\",\"rollup\":\"0xF5A42aDA664E7c2dFE9DDa4459B927261BF90E09\",\"validator-utils\":\"0xB11EB62DD2B352886A4530A9106fE427844D515f\",\"validator-wallet-creator\":\"0xEb9885B6c0e117D339F47585cC06a2765AaE2E0b\",\"deployed-at\":1764099}}]" - ``` - -- When shutting down the Docker image, it is important to allow a graceful shutdown so that the current state can be saved to disk. Here is an example of how to do a graceful shutdown of all Docker images currently running - - ```shell - docker stop --time=1800 $(docker ps -aq) - ``` - -### Note on permissions - -- The Docker image is configured to run as non-root `UID 1000`. If you are running Linux or macOS and you are getting permission errors when trying to run the Docker image, run this command to allow all users to update the persistent folders: - - ```shell - mkdir /data/arbitrum - chmod -fR 777 /data/arbitrum - ``` - -### Note on Sequencer feed - -Nitro nodes can be configured to receive real time ordered transactions from the sequencer feed. If you don't set the feed input url, your node will listen to the parent chain's inbox contract to get the ordered transactions, which will cause your node to be unable to synchronize the latest state. - -Set the following configurations to your fullnode to make it can receive the sequencer feed: - -```shell ---node.feed.input.url= -``` - -After that, your node can synchronize the latest state from the sequencer feed. - -## Optional parameters - -We show here a list of the parameters that are most commonly used when running your Orbit node. You can also use the flag `--help` for a full comprehensive list of the available parameters. - -import OptionalOrbitCompatibleCLIFlagsPartial from '../../partials/_optional-orbit-compatible-cli-flags-partial.mdx'; - -