diff --git a/.gitignore b/.gitignore index d5c300a76..83be1e7d7 100644 --- a/.gitignore +++ b/.gitignore @@ -2,3 +2,4 @@ arbitrum-docs/sdk arbitrum-docs/stylus-by-example .vercel +.DS_Store diff --git a/arbitrum-docs/how-arbitrum-works/arbos/geth.mdx b/arbitrum-docs/how-arbitrum-works/arbos/geth.mdx index 0abe01222..0868c3f13 100644 --- a/arbitrum-docs/how-arbitrum-works/arbos/geth.mdx +++ b/arbitrum-docs/how-arbitrum-works/arbos/geth.mdx @@ -21,7 +21,7 @@ Please note any links on this page may be referencing old releases of Nitro or o Arbitrum uses various hooks to modify Geth's behavior when processing transactions. Each provides an opportunity for ArbOS to update its state and make decisions about the transaction during its lifetime. Transactions are applied using Geth's [`ApplyTransaction`][applytransaction_link] function. -Below is [`ApplyTransaction`][applytransaction_link]'s callgraph, with additional info on where the various Arbitrum-specific hooks are inserted. Click on any to go to their section. By default, these hooks do nothing so as to leave Geth's default behavior unchanged, but for chains configured with [`EnableArbOS`](#EnableArbOS) set to true, [`ReadyEVMForL2`](#ReadyEVMForL2) installs the alternative L2 hooks. +Below is [`ApplyTransaction`][applytransaction_link]'s callgraph, with additional info on where the various Arbitrum-specific hooks are inserted. Click on any to go to their section. By default, these hooks do nothing so as to leave Geth's default behavior unchanged, but for chains configured with [`EnableArbOS`](/how-arbitrum-works/arbos/geth#EnableArbOS) set to true, [`ReadyEVMForL2`](#ReadyEVMForL2) installs the alternative L2 hooks. - `core.ApplyTransaction` ⮕ `core.applyTransaction` ⮕ `core.ApplyMessage` - `core.NewStateTransition` @@ -34,7 +34,7 @@ Below is [`ApplyTransaction`][applytransaction_link]'s callgraph, with additiona - `evm.Call` - `core.vm.EVMInterpreter.Run` - [`PushCaller`](#PushCaller) - - [`PopCaller`](#PopCaller) + - [`PopCaller`](/how-arbitrum-works/arbos/geth#PopCaller) - `core.StateTransition.refundGas` - [`ForceRefundGas`](#ForceRefundGas) - [`NonrefundableGas`](#NonrefundableGas) @@ -176,7 +176,7 @@ Represents a user deposit from L1 to L2. This increases the user's balance by th ### [`ArbitrumSubmitRetryableTx`][arbitrumsubmitretryabletx_link]{#ArbitrumSubmitRetryableTx} -Represents a retryable submission and may schedule an [`ArbitrumRetryTx`](#ArbitrumRetryTx) if provided enough gas. Please see the [retryables documentation](/how-arbitrum-works/arbos/introduction.mdx#Retryables) for more info. +Represents a retryable submission and may schedule an [`ArbitrumRetryTx`](#ArbitrumRetryTx) if provided enough gas. Please see the [retryables documentation](/how-arbitrum-works/arbos/introduction.mdx#retryables) for more info. ### [`ArbitrumRetryTx`][arbitrumretrytx_link]{#ArbitrumRetryTx} diff --git a/arbitrum-docs/how-arbitrum-works/arbos/introduction.mdx b/arbitrum-docs/how-arbitrum-works/arbos/introduction.mdx index d9083022c..dbd7944e5 100644 --- a/arbitrum-docs/how-arbitrum-works/arbos/introduction.mdx +++ b/arbitrum-docs/how-arbitrum-works/arbos/introduction.mdx @@ -81,7 +81,7 @@ Based on this information, ArbOS maintains an L1 data fee, also tracked as part The L2 pricing state tracks L2 resource usage to determine a reasonable L2 gas price. This process considers a variety of factors, including user demand, the state of Geth, and the computational speed limit. The primary mechanism for doing so consists of a pair of pools, one larger than the other, that drain as L2-specific resources are consumed and filled as time passes. L1-specific resources like L1 `calldata` are not tracked by the pools, as they have little bearing on the actual work done by the network actors that the speed limit is meant to keep stable and synced. -While much of this state is accessible through the [`ArbGasInfo`](/build-decentralized-apps/precompiles/02-reference.mdx#arbgasinfo) and [`ArbOwner`](/build-decentralized-apps/precompiles/02-reference.mdx#arbowner) precompiles, most changes are automatic and happen during [block production][block_production_link] and [the transaction hooks](geth#Hooks). Each of an incoming message's transactions removes from the pool the L2 component of the gas it uses, and afterward the message's timestamp [informs the pricing mechanism][notify_pricer_link] of the time that's passed as ArbOS [finalizes the block][finalizeblock_link]. +While much of this state is accessible through the [`ArbGasInfo`](/build-decentralized-apps/precompiles/02-reference.mdx#arbgasinfo) and [`ArbOwner`](/build-decentralized-apps/precompiles/02-reference.mdx#arbowner) precompiles, most changes are automatic and happen during [block production][block_production_link] and [the transaction hooks](/how-arbitrum-works/arbos/geth#Hooks). Each of an incoming message's transactions removes from the pool the L2 component of the gas it uses, and afterward the message's timestamp [informs the pricing mechanism][notify_pricer_link] of the time that's passed as ArbOS [finalizes the block][finalizeblock_link]. ArbOS's larger gas pool [determines][maintain_limit_link] the per-block gas limit, setting a dynamic [upper limit][per_block_limit_link] on the amount of compute gas an L2 block may have. This limit is always enforced, though for the [first transaction][first_transaction_link] it's done in the [GasChargingHook](geth#GasChargingHook) to avoid sharp decreases in the L1 gas price from over-inflating the compute component purchased to above the gas limit. This improves UX by allowing the first transaction to succeed rather than requiring a resubmission. Because the first transaction lowers the amount of space left in the block, subsequent transactions do not employ this strategy and may fail from such compute-component inflation. This is acceptable because such transactions are only present in cases where the system is under heavy load and the result is that the user's transaction is dropped without charges since the state transition fails early. Those trusting the sequencer can rely on the transaction being automatically resubmitted in such a scenario. diff --git a/arbitrum-docs/how-arbitrum-works/assertion-tree.mdx b/arbitrum-docs/how-arbitrum-works/assertion-tree.mdx index a9ce366d5..1669c1944 100644 --- a/arbitrum-docs/how-arbitrum-works/assertion-tree.mdx +++ b/arbitrum-docs/how-arbitrum-works/assertion-tree.mdx @@ -30,4 +30,4 @@ The only delay that users experience during a dispute is of their [L2 to L1 mess ### Detailed Spec -For a more detailed breakdown / specification of the assertion tree protocol, see [Inside Arbitrum](/how-arbitrum-works/inside-arbitrum-nitro.mdx#arbitrum#rollup#protocol). +For a more detailed breakdown / specification of the assertion tree protocol, see [Inside Arbitrum](/how-arbitrum-works/inside-arbitrum-nitro.mdx#arbitrum-rollup-protocol). diff --git a/arbitrum-docs/launch-orbit-chain/how-tos/orbit-sdk-deploying-rollup-chain.md b/arbitrum-docs/launch-orbit-chain/how-tos/orbit-sdk-deploying-rollup-chain.md index acdcf4aa2..75cd3a563 100644 --- a/arbitrum-docs/launch-orbit-chain/how-tos/orbit-sdk-deploying-rollup-chain.md +++ b/arbitrum-docs/launch-orbit-chain/how-tos/orbit-sdk-deploying-rollup-chain.md @@ -194,7 +194,7 @@ The Orbit SDK provides two APIs, `createRollupPrepareDeploymentParamsConfig` and This API is designed to take parameters defined in the Config struct and fill in the rest with default values. It outputs a complete Config struct that is ready for use. -For example, to create a Config struct with a specific chain ID (`chainId`), an owner address (`deployer_address`), and a `chainConfig` as described in the [previous section](#chain-config-parameter), you would use the Orbit SDK as follows: +For example, to create a Config struct with a specific chain ID (`chainId`), an owner address (`deployer_address`), and a `chainConfig` as described in the [previous section](/launch-orbit-chain/how-tos/orbit-sdk-deploying-rollup-chain#chain-config-parameter), you would use the Orbit SDK as follows: ```js import { createPublicClient, http } from 'viem'; diff --git a/arbitrum-docs/launch-orbit-chain/how-tos/orbit-sdk-deploying-token-bridge.md b/arbitrum-docs/launch-orbit-chain/how-tos/orbit-sdk-deploying-token-bridge.md index c41aca345..41be9bd26 100644 --- a/arbitrum-docs/launch-orbit-chain/how-tos/orbit-sdk-deploying-token-bridge.md +++ b/arbitrum-docs/launch-orbit-chain/how-tos/orbit-sdk-deploying-token-bridge.md @@ -44,8 +44,8 @@ Once an Orbit chain has been deployed and initialized, the bridge contracts need The token bridge deployment process is the same for all Orbit chains types except for the following: -- **Custom fee token Orbit chains** which require [token approval](#step-1). -- **`ETH`-based Orbit chains**, for which you need to [set up a WETH gateway](#step-5). +- **Custom fee token Orbit chains** which require [token approval](/launch-orbit-chain/how-tos/orbit-sdk-deploying-token-bridge#step-1). +- **`ETH`-based Orbit chains**, for which you need to [set up a WETH gateway](/launch-orbit-chain/how-tos/orbit-sdk-deploying-token-bridge#step-5). ::: 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 99e747f5d..20e0cd852 100644 --- a/arbitrum-docs/run-arbitrum-node/03-run-full-node.mdx +++ b/arbitrum-docs/run-arbitrum-node/03-run-full-node.mdx @@ -61,7 +61,7 @@ Even though there are alpha and beta versions of the ` to set the L2 chain from its chain id. See [RPC endpoints and providers](/build-decentralized-apps/reference/01-node-providers.mdx#rpc-endpoints) for a list of Arbitrum chains and their respective L2 chain IDs. + - Use the parameter `--chain.id=` to set the 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 L2 chain IDs. - Alternatively, you can use the parameter `--chain.name=` to set the L2 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` diff --git a/arbitrum-docs/stylus/stylus-quickstart.mdx b/arbitrum-docs/stylus/stylus-quickstart.mdx index 253a0d58a..46757859c 100644 --- a/arbitrum-docs/stylus/stylus-quickstart.mdx +++ b/arbitrum-docs/stylus/stylus-quickstart.mdx @@ -14,7 +14,7 @@ This guide will get you started with Stylus' 2. [Creating a Stylus project with cargo stylus](./stylus-quickstart#creating-a-stylus-project-with-cargo-stylus) 3. [Checking the validity of your contract](./stylus-quickstart#checking-if-your-stylus-project-is-valid) 4. [Deploying your contract](./stylus-quickstart#deploying-your-contract) -5. [Exporting your contract's ABIs](./stylus-quickstart#exporting-solidity-abis) +5. [Exporting your contract's ABIs](/stylus/stylus-quickstart#exporting-solidity-abis) 6. [Calling your contract](./stylus-quickstart#calling-your-contract) 7. [Sending a transaction to your contract](./stylus-quickstart#sending-a-transaction-to-your-contract)