@latestNitroNodeImage@
- Latest Docker image for **Arbitrum One Classic**: @latestClassicNodeImage@
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 83142db299..854aa95edd 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
@@ -8,18 +8,21 @@ 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@
+ Latest Docker Image: @latestNitroNodeImage@
| Minimum Hardware Configuration |
-| :--------------------------------------------------------------- |
-| **RAM**: 8-16 GB |
-| **CPU**: 2-4 core CPU (For AWS: t3 xLarge |
+|:-----------------------------------------------------------------|
+| **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:
@@ -27,20 +30,20 @@ The `parent-chain` argument needs to provide a standard RPC endpoint for an EVM
```shell
--parent-chain.connection.url=- An L1-L2 token bridge can be deployed by using the parameter `--tokenbridge`. The list of - contracts can be found by running: -
-- An L1-L2 token bridge is deployed by default. The list of contracts can be found by running: -
-- The How to run a full node (Nitro){' '} + The{' '} + + How to run a full node (Nitro) + {' '} may address your issue.
- The How to run a full node (Nitro){' '} + The{' '} + + How to run a full node (Nitro) + {' '} may address your issue.
- The How to run a full node (Nitro){' '} + The{' '} + + How to run a full node (Nitro) + {' '} may address your issue.
- The{' '} - How to run a local dev node{' '} + The How to run a local dev node{' '} may address your issue.
Both Arbitrum One and Arbitrum Nova run as layers on top of Ethereum. Thus, you can always move assets between the two chains in two steps by going "through" Ethereum. In other words: withdraw your assets from Arbitrum One to Ethereum and then deposit them onto Nova, or conversely, withdraw your assets from Nova on to Ethereum and then deposit them on to Arbitrum One. These steps can all be done at https://bridge.arbitrum.io/.
-### What fees do I have to pay when bridging funds from L1 to L2? + +### What fees do I have to pay when bridging funds from L1 to L2? {#what-fees-do-i-have-to-pay-when-bridging-funds-from-l1-to-l2}When bridging over tokens from L1 to L2, you will have to sign one or two transactions with their corresponding fees:
Using the official Arbitrum Bridge, the process will take roughly one week. However, some users opt to use third-party fast bridges, which often bypass this delay (remember that these bridges are created and maintained by third parties, so please DYOR!).
+ +### How long does it take before I receive my funds when I initiate withdrawal from Arbitrum chains (One and Nova)? {#how-long-does-it-take-before-i-receive-my-funds-when-i-initiate-withdrawal-from-arbitrum-chains-one-and-nova} +Using the official Arbitrum Bridge, the process will typically take roughly one week. However, some users opt to use third party fast bridges, which often bypass this delay (remember that third party bridges are created by third parties, so please DYOR!).
There's some variability in the exact wall-clock time of the dispute window, plus there's some expected additional "padding" time on both ends (no more than about an hour, typically).
-The variability of the dispute window comes from the slight variance of block times. Arbitrum One's dispute window is 45818 blocks; this converts to about 6.5 days, assuming slightly more than 12 seconds per block, the average block time of Ethereum.
+The variability of the dispute window comes from the slight variance of block times. Arbitrum One's dispute window is 45818 blocks; this converts to ~1 week assuming 13.2 seconds per block, which was the average block time when Ethereum used Proof of Work (with the switch to Proof of Stake, average block times are about 12 seconds).
-The "padding on both ends" involves three events that have to occur between a client receiving their transaction receipt from the sequencer and their L2-to-L1 message being executable. After getting their receipt,
+The "padding on both ends" involves three events that have to occur between a client receiving their transaction receipt from a Sequencer and their L2-to-L1 message being executable. After getting their receipt,
-Additionally, in the rare and unlikely event of a dispute, this delay period will be extended for the dispute to resolve.
-### Is there a way to cancel a withdrawal from Arbitrum? + +### Is there a way to cancel a withdrawal from Arbitrum? {#is-there-a-way-to-cancel-a-withdrawal-from-arbitrum}There is no way to cancel a withdrawal that has been already initiated. However, you can claim your funds on L1 and deposit them again on L2 once the withdrawal period is past.
-### Can I use a smart contract wallet in the bridge? + +### Can I use a smart contract wallet in the bridge? {#can-i-use-a-smart-contract-wallet-in-the-bridge}Support for Smart Contract Wallets is currently limited to token depositing and withdrawal. Keep in mind that when withdrawing funds, you won't be able to claim them on L1 using the bridge (unless you also control that address on L1). In that case, you can use the cross-chain dashboard to claim your funds on L1.
ETH deposits and withdrawals using a Smart Contract Wallet are currently not supported, but will soon be available.
@@ -51,8 +55,11 @@ -### How can I claim withdrawn funds if I don't control on L1 the address that initiated the transaction on L2? + +### How can I claim withdrawn funds if I don't control on L1 the address that initiated the transaction on L2? {#how-can-i-claim-withdrawn-funds-if-i-dont-control-on-l1-the-address-that-initiated-the-transaction-on-l2}Once the withdrawal period is past, you can use the cross-chain dashboard to execute the message on L1. Paste the transaction hash that initiated the withdrawal on L2, and follow the process described in the dashboard.
+ + diff --git a/arbitrum-docs/partials/_troubleshooting-building-partial.md b/arbitrum-docs/partials/_troubleshooting-building-partial.md index c4a4a4ac50..cd6732ec2e 100644 --- a/arbitrum-docs/partials/_troubleshooting-building-partial.md +++ b/arbitrum-docs/partials/_troubleshooting-building-partial.md @@ -1,4 +1,4 @@ -### How does gas work on Arbitrum? +### How does gas work on Arbitrum? {#how-does-gas-work-on-arbitrum}Fees on Arbitrum chains are collected on L2 in the chains' native currency (ETH on both Arbitrum One and Nova).
A transaction fee is comprised of both an L1 and an L2 component:
@@ -12,10 +12,11 @@ -### I tried to create a retryable ticket but the transaction reverted on L1. How can I debug the issue? + +### I tried to create a retryable ticket but the transaction reverted on L1. How can I debug the issue? {#i-tried-to-create-a-retryable-ticket-but-the-transaction-reverted-on-l1--how-can-i-debug-the-issue}Creation of retryable tickets can revert with one of these custom errors:
-msg.value < (maxSubmissionCost + l2CallValue + gasLimit * maxFeePerGas). Note that your L1 transaction's callvalue must cover this full cost. See Retryable Tickets Lifecycle for more information.msg.value < (maxSubmissionCost + l2CallValue + gasLimit * maxFeePerGas). Note that as of the Nitro upgrade, your L1 transaction's callvalue must cover this full cost (previously an L2 message's execution could be paid for with funds on L2: see dapp migration and "retryable ticket creation".To figure out which error caused your transaction to revert, we recommend using etherscan's Parity VM trace support (Tenderly is generally a very useful debugging tool; however, it can be buggy when it comes to custom Geth errors).
-Use the following link to view the Parity VM trace of your failed transaction (replacing the tx-hash with your own, and using the appropriate etherscan root url):
- - +Use the following link to view the Parity VM trace of your failed transaction (replacing the tx-hash with your own, and using the appropriate etherscan root url):
+
+https://goerli.etherscan.io/vmtrace?txhash=0x382bfef03a7f1185a91582b49837740473591fb8715ce7f15e389f1ade630b09&type=parity#raw
To find out the reversion error signature, go to the "Raw Traces" tab, and scroll down to find the last "subtrace" in which your transaction is reverted. Then find "output" field of that subtrace.
+
+To find out the reversion error signature, go to the "Raw Traces" tab, and scroll down to find the last "subtrace" in which your transaction is reverted. Then find "output" field of that subtrace.
(In the above example the desirable "output" is:
-{'0xfadf238a0000000000000000000000000000000000000000000000000000c4df7e2903b00000000000000000000000000000000000000000000000000000a39a1d002808'})
{'0x7040b58c0000000000000000000000000000000000000000000000000001476b081e80000000000000000000000000000000000000000000000000000000000000000000'} )
-The first four bytes of the output is the custom error signature; in our example it's 0xfadf238a .
The first four bytes of the output is the custom error signature; in our example it's 0x7040b58c .
To let's find out which is custom error this signature represents, we can use this handy tool by Samzcsun: https://sig.eth.samczsun.com/
Checking 0xfadf238a gives us InsufficientSubmissionCost(uint256,uint256).
+
Checking 0x7040b58c gives us InsufficientValue(uint256,uint256).
The L1 fee that a transaction is required to pay is determined by compressing its data with brotli and multiplying the size of the result (in bytes) by ArbOS's current calldata price; the latter value can be queried via the getPricesInWeimethod of the ArbGasInfoprecompile. You can find more information about gas calculations in Understanding Arbitrum: 2-Dimensional Fees and How to estimate gas in Arbitrum.
A retryable's submission fee is a special fee a user must pay to create a retryable ticket. The fee is directly proportional to the size of the L1 calldata the retryable ticket uses. The fee can be queried using the Inbox.calculateRetryableSubmissionFeemethod. If insufficient fee is provided, the transaction will revert on L1, and the ticket won't get created.
The method you should (almost certainly) use is Inbox.createRetryableTicket. There is an alternative method, Inbox.unsafeCreateRetryableTicket, which, as the name suggests, should only be used by those who fully understand its implications.
There are two differences between createRetryableTicket and unsafeCreateRetryableTicket:
createRetryableTicket will check that provided L1 callvalue is sufficient to cover the costs of creating and executing the retryable ticket (at the specified parameters) and otherwise revert directly at L1. unsafeCreateRetryableTicket, in contrast, will allow a retryable ticket to be created that is guaranteed to revert on L2.createRetryableTicket will check if either the provided excessFeeRefundAddress or the callValueRefundAddress are contracts on L1; if they are, to prevent the situation where refunds are guaranteed to be irrecoverable on L2, it will convert them to their address alias, providing a potential path for fund recovery. unsafeCreateRetryableTicket will allow the creation of a retryable ticket with refund addresses that are L1 contracts; since no L1 contract can alias to an address that is also itself an L1 contract, refunds to these addresses on L2 will be irrecoverable.{'createRetryableTicket'} will check that provided L1 callvalue is sufficient to cover the costs of creating and executing the retryable ticket (at the specified parameters) and otherwise revert directly at L1 [TODO: link to "retryable reverts at L1" faq]. unsafeCreateRetryableTicket, in contrast, will allow a retryable ticket to be created that is guaranteed to revert on L2.{'createRetryableTicket'} will check if either the provided excessFeeRefundAddress or the callValueRefundAddress are contracts on L1; if they are, to prevent the situation where refunds are guaranteed to be irrecoverable on L2, it will convert them to their address alias, providing a potential path for fund recovery. unsafeCreateRetryableTicket will allow the creation of a retryable ticket with refund addresses that are L1 contracts; since no L1 contract can alias to an address that is also itself an L1 contract, refunds to these addresses on L2 will be irrecoverable.(Astute observers may note a third ticket creation method, createRetryableTicketNoRefundAliasRewrite; this is included only for backwards compatibility, but should be considered deprecated in favor of unsafeCreateRetryableTicket)
In Arbitrum, we use a number of non-standard EIP-2718 typed transactions. See here for the full list and the rationale.
-Note that if you're using Hardhat, v2.12.2 added support for forking networks like Arbitrum with custom transaction types (find more information here).
+Hardhat v2.12.2 added supports for forking networks like Arbitrum with custom transaction types, so if you're using hardhat, upgrade to 2.12.2!
+References
-### Why does it look like two identical transactions consume a different amount of gas? + + + + + +### Why does it look like two identical transactions consume a different amount of gas? {#why-does-it-look-like-two-identical-transactions-consume-a-different-amount-of-gas}Calling an Arbitrum node's eth_estimateGas RPC returns a value sufficient to cover both the L1 and L2 components of the fee for the current gas price; this is the value that, e.g., will appear in users' wallets in the "gas limit" field.
Offchain Labs offers public RPCs for free, but limits requests to prevent DOSing. Hitting the rate limit could come from your request frequency and/or the resources required to process the requests. If you are hitting our rate limit, we recommend running your own node or using a third party node provider.
-### How do block.number and block.timestamp work on Arbitrum? + +### How do block.number and block.timestamp work on Arbitrum? {#how-do-blocknumber-and-blocktimestamp-work-on-arbitrum}Solidity calls to block.number on Arbitrum will return the block number/ timestamp of the underlying L1 on a slight delay; i.e., updated every few minutes. Note that L2 block numbers (i.e., as seen in block explorers / returned by RPCs) are different, and are typically updated roughly every second.
Solidity calls to block.timestamp on Arbitrum are not linked to the timestamp of the L1 block. It is updated every L2 block based on the sequencer's clock. Furthermore, for transactions that are force-included from L1 (bypassing the Sequencer) block.timestamp will be equal to the L1 timestamp when the transaction was put in the delayed inbox on L1 (not force-included), or the L2 timestamp of the previous L2 block (whichever is greater of the two timestamps).
Nope, web3.js, ethers.js and viem will work out of the box just like they do on L1 Ethereum.
-Once upon a time, Arbitrum developers were required to download supplemental packages with names like "arb-provider-ethers" and "arb-ethers-web3-bridge", but these packages are deprecated and no longer required! Any guide that directs devs to use them should be considered outdated.
+### Do I need to download any special npm libraries in order to use web3.js or ethers-js on Arbitrum? {#do-i-need-to-download-any-special-npm-libraries-in-order-to-use-web3js-or-ethersjs-on-arbitrum-} +Nope; web3.js and ethers.js will work out of the box just like they do on L1 Ethereum.
+
+Once upon a time, Arbitrum developers were required to download supplemental packages with names like "arb-provider-ethers" and "arb-ethers-web3-bridge", but these packages are deprecated and no longer required! Any guide that directs devs to use them should be considered outdated.
Arbitrum's block intervals fluctuate with throughput, so relying on block numbers for finality isn't recommended. However, Arbitrum nodes support Ethereum's JSON RPC, enabling the use of eth_getBlockByNumber() to determine block finality. Here, we provide additional details on how to achieve this.
latest: Provides you with the most recent Arbitrum block number that the node has observed on the L1 and indicates that the Sequencer's batch has been just published as an L1 block on the Ethereum network. It's important to note that this block has the potential to be re-orged but you can consider and trust this block as final, if you trust the sequencer.safe: Provides you with the most recent Arbitrum block number that has achieved attestations from a two-thirds majority of Ethereum's validator set. This occurs when the Sequencer's batch is posted as an L1 block on Ethereum and then the batch transactions achieve safe finality there. While safe blocks are typically resistant to re-orgs, they can still be re-orged in the event of a significant L1 re-org.finalized: Provides you with the most recent Arbitrum block number that is finalized on Ethereum. This means that the Sequencer's batch has been published as an L1 block on the Ethereum network and has reached a substantial depth, making it eligible for hard finality. Unlike safe blocks, finalized blocks are highly improbable to undergo re-orgs. {'latest'}: Provides you with the most recent Arbitrum block number that the node has observed on the L1 and indicates that the Sequencer's batch has been just published as an L1 block on the Ethereum network. It's important to note that this block has the potential to be re-orged but you can consider and trust this block as final, if you trust the sequencer.{'safe'}: Provides you with the most recent Arbitrum block number that has achieved attestations from a two-thirds majority of Ethereum's validator set. This occurs when the Sequencer's batch is posted as an L1 block on Ethereum and then the batch transactions achieve safe finality there. While safe blocks are typically resistant to re-orgs, they can still be re-orged in the event of a significant L1 re-org.{'finalized'}: Provides you with the most recent Arbitrum block number that is finalized on Ethereum. This means that the Sequencer's batch has been published as an L1 block on the Ethereum network and has reached a substantial depth, making it eligible for hard finality. Unlike safe blocks, finalized blocks are highly improbable to undergo re-orgs. The L2 token list used in the Arbitrum bridge is generated from the L1 tokens that are part of the token list of Uniswap, Gemini , Coinmarketcap or Coingecko. This is valid for L1-native tokens that have been bridged over to L2, and for L2-native tokens that have been bridged over to L1 as long as they are part of any of those lists.
+ +### How can I list my token on the Arbitrum Bridge? {#how-can-i-list-my-token-on-the-arbitrum-bridge} +The L2 token list used in the Arbitrum bridge is generated from the L1 tokens that are part of the token list of Uniswap, Gemini or Coinmarketcap. This is valid for L1-native tokens that have been bridged over to L2, and for L2-native tokens that have been bridged over to L1 as long as they are part of any of those lists.
Currently, there isn't any L2-only token list.
@@ -147,41 +165,45 @@ To let's find out which is custom error this signature represents, we can use th -### What is a testnet or a devnet? + +### What is a testnet or a devnet? {#what-is-a-testnet-or-a-devnet}Testnets (or devnets) primarily serve developers who want to test out the applications they're building without having to use any real mainnet funds.
-Arbitrum Sepolia is a testnet that has the same full feature-set as the mainnet network. It is also a "true" L2 that runs on top of the Sepolia testnet (L1), using it for security and settlement.
+Arbitrum Goerli and Arbitrum Sepolia are both testnets that have the same full feature-set as the mainnet networks. They are also a "true" L2 that run on top of the Goerli testnet (L1) and the Sepolia testnet (L1) respectively, using them for security and settlement.
-Users can bridge any asset from the Sepolia testnet (L1) into the Arbitrum Sepolia testnet (and back!), using the official bridge.
+Users can bridge any asset from the Goerli testnet (L1) into the Arbitrum Goerli testnet, and from the Sepolia testnet (L1) into the Arbitrum Sepolia testnet (and back!), using the official bridge.
-### Is there any testnet available on Arbitrum? -Yes, there's an Arbitrum Sepolia testnet (421614) that uses the Nitro tech stack and runs on top of Ethereum Sepolia. You can find more information here.
+ +### Is there any testnet available on Arbitrum? {#is-there-any-testnet-available-on-arbitrum} +Yes, there's an Arbitrum Goerli testnet (421613) that uses the Nitro tech stack, running on top of Ethereum Goerli, and an Arbitrum Sepolia testnet (421614) that also uses the Nitro tech stack and runs on top of Ethereum Sepolia. You can find more information here.
-### When was Arbitrum One upgraded from Classic to Nitro? -Arbitrum One was upgraded on August 31st, 2022 (block 22207818), from the Classic stack to the improved Nitro tech stack, maintaining the same state.
- +### When was Arbitrum One upgraded from Classic to Nitro? {#when-was-arbitrum-one-upgraded-from-classic-to-nitro} +Arbitrum One was upgraded on August 31st, 2022, from the Classic stack to the improved Nitro tech stack, maintaining the same state.
+ -### Do Arbitrum chains support precompiles that are present on Ethereum? +### Do Arbitrum chains support precompiles that are present on Ethereum? {#do-arbitrum-chains-support-precompiles-that-are-present-on-ethereum}Yes, all Arbitrum chains support all precompiles that Ethereum supports, as well as others that are not present on Ethereum. Check the precompiles reference page for more information about Arbitrum specific precompiles.
-### What's the contract code size limit in Arbitrum chains? + +### What's the contract code size limit in Arbitrum chains? {#whats-the-contract-code-size-limit-in-arbitrum-chains}As specified in EIP-170, contracts of up to 24KB are deployable on Arbitrum chains.
-### How can I find the L2 block(s) that corresponds to a given L1 block? + +### How can I find the L2 block(s) that corresponds to a given L1 block? {#how-can-i-find-the-l2-blocks-that-corresponds-to-a-given-l1-block}First of all, you should be familiar with how block numbers behave on Arbitrum. You can find information about it in Block numbers and time.
When you query an RPC node for a transaction receipt or a block information, you obtain as part of the result the property l1BlockNumber, which is the L1 block number that the sequencer viewed when it processed the transaction.
If you want a more specific result, you can perform the same operation with the timestamp from the L1 block, instead of the actual block number.
-### Why do some old transactions have extremely high gas prices when querying them? + +### Why do some old transactions have extremely high gas prices when querying them? {#why-do-some-old-transactions-have-extremely-high-gas-prices-when-querying-them}When Arbitrum One was running under the Arbitrum Classic stack (before Nitro), the gas price was an unbounded bid, so when requesting those transactions via RPC, you may obtain a very high amount in the gasPrice property.
Instead of that, it is recommended to look at the effectiveGasPrice property from the transaction receipt.
The WASM module root is a 32 byte hash, which is a merkelization of the Go replay binary and its dependencies.
The replay binary is much too large to post on-chain, so this hash is set in the L1 rollup contract to determine the correct replay binary during fraud proofs.
@@ -209,13 +233,15 @@ To let's find out which is custom error this signature represents, we can use th -### Why do I get a "gas required exceeds allowance" when trying to estimate the gas costs of a request? + +### Why do I get a "gas required exceeds allowance" when trying to estimate the gas costs of a request? {#why-do-i-get-a-gas-required-exceeds-allowance-when-trying-to-estimate-the-gas-costs-of-a-request}During an eth_estimateGas call the actual request will be simulated on the node, so if the transaction reverts or if there aren't enough funds in the wallet that's making the call (usually the from parameter), the eth_estimateGas request will return the error gas required exceeds allowance.
Make sure you have enough funds in your wallet, and the gas fields of the request (if you're using them) are correctly set.
-### How can I verify that an L2 block has been processed as part of a specific RBlock? + +### How can I verify that an L2 block has been processed as part of a specific RBlock? {#how-can-i-verify-that-an-l2-block-has-been-processed-as-part-of-a-specific-rblock}If you want to verify that the latest confirmed (or created) assertion has processed a specific L2 block, you can follow these steps:
latestConfirmed (or latestNodeCreated). In this context, we refer to RBlocks as "nodes".You can find an example script in our arbitrum-tutorials repository.
-### Why is the fee of some Classic transactions slightly different than the multiplication of gasLimit and effectiveGasPrice? -Gas prices in Classic transactions worked a bit differently than in Nitro transactions. Classic transactions handled four different prices: L1 fixed, L1 calldata, L2 computation and L2 storage. You can see all those prices in the Advanced TxInfo of Arbiscan (here's an example).
- -When querying the receipt of a Classic transaction on a Nitro node, there's some calculation done to get an effectiveGasPrice that is close to (but not exactly) what those four prices represent. That's why if you multiply the gasLimit by the effectiveGasPrice you might end up with a transaction fee that is slightly different than the actual fee paid.
- -To get the exact fees paid, you can query a Classic node, which will return all the exact information.
- - - - -### How can I update the information of my bridged token on Arbiscan? -If you have a native-L1 token that was bridged to L2 via the standard gateway, you might find that you can't claim ownership of the L2 contract of your token as it was generated by another contract.
- -To update its information on Arbiscan (logo, socials, etc.), you can open a ticket through Arbiscan support system and request them to replicate the information of your token on L1 to L2.
- - - - -### Why does my transaction revert with InvalidFEOpcode when using Foundry? -Foundry and other similar development tools that enable chain forking, do not support Arbitrum precompiles. If your transaction is calling a precompile, it is likely that it will revert with InvalidFEOpcode.
To rule out that possibility, it is recommended to send the transaction with a different tool.
- - - - -### Why do I receive an "intrinsic gas too low" error when sending a transaction even with a high gas price? -The error intrinsic gas too low usually refers to not providing enough gas to pay for the L1 component of the transaction fees. This is usually a problem related to not setting a high enough gas limit (instead of gas price), due to how Arbitrum handles gas. You can find more information in the article Understanding Arbitrum: 2-dimensional fees and the page How to estimate gas.
In Arbitrum, every block contains a system transaction of type ArbitrumInternalTxType, which is created by the ArbOS itself for specific state updates, such as the L1 base fee and the block number. These transactions are distinct from typical Ethereum transactions and are exclusively generated by the ArbOS state transition function, not by external entities like externally owned accounts (EOAs) or smart contracts. Despite having an INVALID opcode, these transactions are represented in the trace API to signify their presence in the block, even though they're not triggered by an opcode within EVM execution.
One of the key functionalities of ArbitrumInternalTxType involves managing value transfers related to acknowledging batch postings. When batches of transactions are submitted to Layer 1, a special cross-chain message is produced as a receipt, confirming the successful posting of the batch. The function ApplyInternalTxUpdate is responsible for processing and updating the system's state based on these cross-chain messages, ensuring consistency and integrity across the Arbitrum network.
Another functionality of ArbitrumInternalTxType transactions is handling the value held in retryables when they are discarded. Retryable transactions are essentially transactions that can be retried if they fail to execute on the destination chain. However, in certain scenarios, these retryable transactions might get discarded, for instance, due to expiration or other conditions.
In such cases, the escrowed call value, which is the value associated with the retryable transaction, will be paid out to a specified callValueRefundAddress account. This address is designated during the initial submission of the transaction on the parent chain. The purpose of this mechanism is to ensure that funds associated with retryable transactions are not lost in case they cannot be successfully executed, thereby maintaining the integrity and reliability of the Arbitrum network.
To accurately reflect value transfers associated with these transactions, we employ a unique callType parameter: invalid. Unlike conventional EVM calls (such as delegatecall, call, etc.), this designation signifies a different system transaction. Essentially, it denotes a straightforward value transfer from one account to another, with no inherent invocation of smart contract logic. While technically feasible to conduct this transfer within a conventional call type, our deliberate choice of invalid aims to enhance the clarity and distinctiveness of this transaction type within the EVM ecosystem.
Notably, the sender account remains consistent across all instances of this transaction type for the batch posting receipt version. However, it's important to note that for retryable transactions, the sender account differs as each retryable transaction escrows its value in a unique vault specific to that transaction. This ensures that funds associated with each retryable transaction are securely held until either successful execution or eventual refund.
- - - - diff --git a/arbitrum-docs/partials/_troubleshooting-nodes-partial.md b/arbitrum-docs/partials/_troubleshooting-nodes-partial.md index 40861f9e61..9693d0932b 100644 --- a/arbitrum-docs/partials/_troubleshooting-nodes-partial.md +++ b/arbitrum-docs/partials/_troubleshooting-nodes-partial.md @@ -1,24 +1,27 @@ -### How do I run a node? +### How do I run a node? {#how-do-i-run-a-node}See instructions here!
-### How to verify the integrity of the Nitro database I currently have? + +### How to verify the integrity of the Nitro database I currently have? {#how--to-verify-the-integrity-of-the-nitro-database-i-currently-have}We have an accumulator hash on all messages, which means that a message can't be added to the database without the previous message being correct.
-To confirm that everything's working properly, you could just make sure that it's syncing and that the latest block is consistent with other Arbitrum nodes; e.g., you could check it against Arbiscan (note that Arbiscan's search field doesn't support searching by block hash).
+To confirm that everything's working properly, you could just make sure that it's syncing and that the latest block is consistent with other Arbitrum nodes; e.g., you could check it against Arbiscan (note that Arbiscan's search field doesn't support searching by block hash).
-### How can I check if the node is running properly and diagnose the issue if it is not? + +### How can I check if the node is running properly and diagnose the issue if it is not? {#how-can-i-check-if-the-node-is-running-properly-and-diagnose-the-issue-if-it-is-not}We have trace-level logging RPC request implemented on our node. You could use it to log all requests and responses at the trace level. (The performance impact of this should be negligible compared to the network overhead of an RPC request in the first place, especially considering that the request/response will only be serialized for logging if that log level is enabled.)
-### Why do I need an L1 node to run an Arbitrum node? + +### Why do I need an L1 node to run an Arbitrum node? {#why-do-i-need-an-l1-node-to-run-an-arbitrum-node}On the node syncing stage, Arbitrum nodes read transactions from batches that were previously posted on L1 and have been executed. They then connect to the Sequencer feed to receive new incoming batched transactions that have not yet been posted on L1.
When fully synced, the Arbitrum node uses the State Transition Function (STF) to consume transactions coming from the Sequencer feed and creates a new state. It also waits for the L1 batch to be posted. If the L1 batch that is finalized on L1 is different from what the Sequencer published, the node will change the state based on the L1 batched transactions.
@@ -26,20 +29,23 @@ -### Can I run an Arbitrum node in p2p mode? + +### Can I run an Arbitrum node in p2p mode? {#can-i-run-an-arbitrum-node-in-p2p-mode}Arbitrum doesn't have a consensus mechanism, so "p2p mode" doesn't apply. For nodes to sync to the latest chain state, they connect to an L1 node to sync the chain's history that's been posted in calldata and connect to the Sequencer feed for the transactions that have yet to be posted in batches. In no case do nodes need to peer up and sync with each other.
-### How do I read messages from the Sequencer feed? -Running an Arbitrum relay locally as a Feed Relay lets you subscribe to the Sequencer feed for real-time data as the Sequencer accepts and orders transactions off-chain. Visit How to read the sequencer feed for a detailed how-to.
+ +### How do I read messages from the Sequencer feed? {#how-do-i-read-messages-from-the-sequencer-feed} +Running an Arbitrum relay locally as a Feed Relay lets you subscribe to the Sequencer feed for real-time data as the Sequencer accepts and orders transactions off-chain. Visit How to read the sequencer feed for a detailed how-to.
-### How do I run a node locally for development? + +### How do I run a node locally for development? {#how-do-i-run-a-node-locally-for-development}See instructions here.
-We recommend running nitro nodes via docker; to compile directly / run without docker, you can follow the steps in How to build Nitro locally.
+We recommend running nitro nodes via docker; to compile directly / run without docker, you can follow the steps in this file then run the executable directly.
@@ -48,23 +54,24 @@ -### Is there any way to retrieve pre-Nitro archive data from a Nitro node? -The pre-nitro stack is also referred to as the "classic" stack. Full nitro nodes start with a database that contains the information from the "classic" era.
-However, it is not possible for a nitro node to query archive information contained in "classic" blocks right away. To do that, you need to also run a classic node (instructions here) and set the parameter —node.rpc.classic-redirect=your-classic-node-RPC.
The pre-nitro stack is also referred to as a "classic" stack. Full nitro nodes start with a database that contains the information from the "classic" era. However, it is not possible for a nitro node to query archive information contained in "classic" blocks right away. To do that, you need to also run a classic node (instructions here) and set the parameter —node.rpc.classic-redirect=your-classic-node-RPC.
Keep in mind that this information only applies to Arbitrum One nodes. Arbitrum Nova and Arbitrum Sepolia nodes started with a Nitro stack from the beginning, so they don't have "classic" data.
+Keep in mind that this information only applies to Arbitrum One nodes. Arbitrum Nova, Arbitrum Goerli and Arbitrum Sepolia nodes started with a Nitro stack from the beginning, so they don't have "classic" data.
-### How can I verify that my node is syncing at a desirable speed? -Syncing speed can vary depending on multiple factors. You can find the minimum hardware requirements to run your node in this page. You should also verify your network and disk speed, and make sure that the L1 node is running correctly.
+ +### How can I verify that my node is syncing at a desirable speed? {#how-can-i-verify-that-my-node-is-syncing-at-a-desirable-speed} +Syncing speed can vary depending on multiple factors. You can find the minimum hardware requirements to run your node in this page. You should also verify your network and disk speed.
-### How can I verify that my node is fully synced? + +### How can I verify that my node is fully synced? {#how-can-i-verify-that-my-node-is-fully-synced}You can make an eth_syncing RPC call to your node. When a nitro node is fully synced, eth_syncing returns the value false (just like a normal Geth node).
When a nitro node is still syncing, eth_syncing returns a map of values to help understand why the node is not synced. Nitro execution and bottleneck are different from a normal Geth node, so eth_syncing output is unique to nitro.
We recommend running Nitro nodes via Docker, using the guides provided within our documentation. However, you can try to compile the code directly by following the steps described in this guide.
+ +### **Is there an alternative to docker when running a node?** {#is-there-an-alternative-to-docker-when-running-a-node} +We recommend running nitro nodes via docker, using the guides provided within our documentation. However, you can try to compile the code directly by following the steps described in the Dockerfile, or following this guide for Debian.
-### What are the minimum hardware requirements to run a full node? + +### **What are the minimum hardware requirements to run a full node?** {#what-are-the-minimum-hardware-requirements-to-run-a-full-node}You can see the minimum hardware configuration in this section.
-### How can I migrate the date of one synced node to a new one? + +### How can I migrate the date of one synced node to a new one? {#how-can-i-migrate-the-date-of-one-synced-node-to-a-new-one}From a fully synced node, you can copy its database (the .arbitrum directory in a default setup) to the same database folder of the new node, and it will start from the same state.
Keep in mind that this must be done after a clean shutdown, while the node is not running.
@@ -94,8 +104,4 @@ -### When querying Classic transactions from a Nitro node, I sometimes get incorrect data, like the zero address as the sender. Why is that? -Some old Nitro genesis database snapshots didn't properly set the retry sender for Classic blocks and contain said error. If you need to access that information, you can either resync your nitro node with one of the current snapshots, or run a Classic node along with your nitro node and configure a redirection for requests to Classic blocks. Please note that this only happens on Arbitrum One.
- - diff --git a/arbitrum-docs/partials/_troubleshooting-orbit-partial.md b/arbitrum-docs/partials/_troubleshooting-orbit-partial.md deleted file mode 100644 index 5aee1e2a71..0000000000 --- a/arbitrum-docs/partials/_troubleshooting-orbit-partial.md +++ /dev/null @@ -1,198 +0,0 @@ -### Can I use Orbit to deploy a mainnet chain? - -- Yes! Arbitrum Orbit's core technology has undergone a comprehensive audit and is now able to - support deployments to mainnet. You can read more about it{' '} - - here - - . -
- - - -### How can I deploy an Orbit-based Layer 3 (L3) chain? - -- Check our Quickstart to - learn how to launch your own Orbit chain today. -
- - - -### Do I need permission/license to launch an Orbit chain? - -- You can permissionlessly launch an L3 Orbit chain that settles to one of Arbitrum's Layer 2 (L2) - chains. There is an emerging licensing structure will soon make it possible to permissionlessly - launch an L2 Orbit chain that settles directly to Ethereum. Please get in touch with the Arbitrum - Foundation or Offchain Labs for more information. -
- -Note that launching a testnet doesn't require any license.
- - - -### Does Arbitrum officially deploy and/or maintain L3s for external teams? - -- No. Teams are required to deploy and maintain their Orbit chains. There are, however, several RaaS - (Rollup as a Service) providers that can deploy and maintain the Orbit chain for you. -
- - - -### Can I modify Orbit's underlying technology to customize my chain? - -Yes, you can make any changes you require to the underlying Nitro code base.
- - - -### What Data Availability (DA) solutions are currently available for Orbit chains? - -Arbitrum Orbit currently supports 3 different DA solutions:
- -Note that using AnyTrust gives the chain owner the most flexibility and cheapest fees.
- - - -### What token is used to pay gas fees on Orbit chains? - -- By default, Orbit chains pay gas in ETH. However, Orbit chains using AnyTrust can be configured to - use any ERC-20 token as the gas fee token of the chain. -
- - - -### Can I use Ethereum toolkits to develop on my Orbit chain? - -- Orbit chains are fully EVM-compatible. Most tools that support Ethereum should be able to support - an Orbit chain. There are, however, certain differences that developers need to keep in mind when - building on an Orbit chain. You can find them{' '} - - here - - . -
- - - -### Do Orbit chains have any built-in AA solution? - -Not by default, but they can be customized to have native AA.
- -### Is there any cross-chain bridging solution between two Orbit chains? - -- There is currently no Orbit-to-Orbit native bridging solution, other than going through the parent - chain (if they share the same parent chain). However, there are many third-party bridges that have - expressed interest in supporting Orbit chains. -
- - - -### Is there an official block explorer for Orbit chains? - -- Orbit chains deployments usually come with an open-source blockscout explorer by default, but - there are many third-party solutions that have expressed interest in supporting Orbit chains. -
- - - -### Is there any indexing solution that supports Orbit chains? - -- Similar to bridges and block explorers, there are many third-party indexing solutions that have - expressed interest in supporting Orbit chains. -
- - - -### Can I increase the maximum contract size for my Orbit chain? - -- Yes, but only on testnets for now. You can use our{' '} - Orbit SDK (available for - deployments on testnet), and configure the parameters{' '} - - MaxCodeSize and MaxInitCodeSize - {' '} - when calling{' '} - - prepareNodeConfig - - . -
- - - -### How can I modify Nitro to force posting an invalid assertion and test the fraud proof mechanism? - -- Forcing an invalid assertion in the chain is not supported at the moment. However, if you're - building Nitro locally, you can run the following test that goes through the whole - rollup/challenge mechanism: -
- -```shell -go test ./system_tests/ -tags=challengetest -run=TestChallenge - -``` - - - -### What fee collectors can be configured on my chain? - -There are 4 fee types that can be configured on an Orbit chain:
- -ArbOwner.setInfraFeeAccount().
- ArbOwner.setNetworkFeeAccount().
- SequencerInbox.setIsBatchPoster() on the parent chain. And a different fee
- collector for that batch poster can be specified by calling{' '}
- ArbAggregator.setFeeCollector().
- ArbOwner.setL1PricingRewardRecipient()
- - More detailed information about fees can be found in the{' '} - L1 fees and{' '} - L2 fees pages. -
- -- Information about the precompiles methods can be found in the{' '} - - Precompiles reference page - - . -
diff --git a/arbitrum-docs/partials/_troubleshooting-stylus-partial.md b/arbitrum-docs/partials/_troubleshooting-stylus-partial.md deleted file mode 100644 index 942130f88f..0000000000 --- a/arbitrum-docs/partials/_troubleshooting-stylus-partial.md +++ /dev/null @@ -1,131 +0,0 @@ -### How does Stylus manage security issues in smart contracts when interacting with so many different languages? - -- All languages are compiled to WASM for them to be able to work with Stylus. So it just needs to - verify that the produced WASM programs behave as they should inside the new virtual machine. -
- - - -### Is there any analogue of the fallback function from Solidity in the Rust Stylus SDK? - -- Currently there isn't any analogue. However, you can use a minimal entrypoint and perform raw - delegate calls, forwarding your calldata. You can find more information in{' '} - - Bytes-in, bytes-out programming - {' '} - and{' '} - - call, static_call and delegate_call - - . -
- - - -### Why are constructors not yet supported for Stylus contracts? - -- Constructors use EVM bytecode to initialize state. While one could add EVM bytecode manually to - their Stylus deployment, we don't allow WASM execution in the constructor so there's no way to - express this in the SDK. -
- -- We're working on models that will make init easier, so there might be better solutions available - in the future. For now, we suggest calling an init method after deploying. -
- - - -### Is it possible to verify Stylus contracts on the block explorer? - -- Currently it is not possible to verify contracts compiled to WASM on the block explorer, but we - are actively working with providers to have the verification process ready for when Stylus reaches - mainnet-ready status. -
- - - -### Do Stylus contracts compile down to EVM bytecode like prior other attempts? - -- No. Stylus contracts are compiled down to WASM. The user writes a program in Rust / C / C++ which - is then compiled down to WebAssembly. -
- - - -### How is a Stylus contract deployed? - -
- Stylus contracts are deployed on chain as a blob of bytes, just like EVM ones. The only difference
- is that when the contract is executed, instead of invoking the EVM, we invoke a separate WASM
- runtime. Note that a special EOF-inspired prefix distinguishes Stylus contracts from traditional
- EVM contracts: when a contract's bytecode starts with the magic 0xEF000000 prefix,
- it's a Stylus WASM contract.
-
- You deploy a Stylus contract the same way that Solidity contracts are deployed. There are no
- special transaction types. As a UX note: a WASM will revert until a special instrumentation
- operation is performed by a call to the new ArbWasm precompile, which readies the
- program for calls on-chain.
-
- You can find instructions for deploying a Stylus contract in our{' '} - - Quickstart - - . -
- -### Do Stylus contracts use a different type of ABI? - -- Stylus contracts use solidity ABIs. Methods, signatures, logs, calls, etc. work exactly as in the - EVM. From a user's / explorer's perspective, it all just looks and behaves like solidity. -
- - - -### Does the Stylus SDK for Rust support custom data structures? - -- For in-memory usage, you should be able to use any implementation of custom data structures - without problems. -
- -- For storage usage, it might be a bit more complicated. Stylus uses the EVM storage system, so - you'll need to define the data structure on top of it. However, in the SDK there's a storage trait - that custom types can implement to back their collections with the EVM state trie. The SDK macros - are compatible with them too, although fundamentally it's still a global key-value system. -
- -- You can read more about it in the{' '} - - Stylus Rust SDK page - - . -
- -- As an alternative solution, you can use{' '} - - entrypoint-style contracts - {' '} - for your custom data structures. -
- - - - diff --git a/arbitrum-docs/partials/_troubleshooting-users-partial.md b/arbitrum-docs/partials/_troubleshooting-users-partial.md index 155e032ff1..fe4f973ed7 100644 --- a/arbitrum-docs/partials/_troubleshooting-users-partial.md +++ b/arbitrum-docs/partials/_troubleshooting-users-partial.md @@ -1,35 +1,42 @@ -### Why do I need ETH to use the Arbitrum network? -ETH is the currency used to pay gas fees on Arbitrum, and all Arbitrum transactions are powered by ETH. You can bridge ETH (and other tokens) from Ethereum to Arbitrum through Arbitrum's bridge.
+### Why do I need ETH to use the Arbitrum network? {#why-do-i-need-eth-to-use-the-arbitrum-network} +When moving funds (ETH and non-ETH) from Ethereum (L1) to Arbitrum (L2), you'll need to have ETH in your wallet on the corresponding Arbitrum chain. This is because ETH is the currency used for gas fees on Arbitrum and all Arbitrum transactions are powered by ETH.
+ + + -### Do I need to pay a tip or priority fee for my Arbitrum transactions? +### Do I need to pay a tip / Priority fee for my Arbitrum transactions? {#do-i-need-to-pay-a-tip--priority-fee-for-my-arbitrum-transactions}Since transactions are processed in the order that the Sequencer receives them, no priority fee is necessary for Arbitrum transactions; if a transaction does include a priority fee, it will be refunded to the transaction's origin address at the end of the execution.
-### How can I see the balance of ETH and other tokens in my wallet on Arbitrum? -Most wallets are "connected" to one given network at a time. To view your ETH or token balances, ensure that you are connected to the appropriate Arbitrum chain. In MetaMask, you can switch networks via the "networks" dropdown. In this dropdown, select your desired network (either Arbitrum One or Arbitrum Nova for our mainnet networks). If your desired network hasn't been added to your wallet yet, you can add it at https://bridge.arbitrum.io/.
+ +### How can I see the balance of my ETH / Tokens on Arbitrum in my wallet? {#how-can-i-see-the-balance-of-my-eth--tokens-on-arbitrum-in-my-wallet} +Most wallets are "connected" to one given network at a time. To view your Ether / Token balances, ensure that you are connected to the appropriate Arbitrum chain. In MetaMask, you can switch networks via the "networks" dropdown. In this dropdown, select your desired network (either Arbitrum One or Arbitrum Nova for our mainnet networks). If your desired network hasn't been added to your wallet yet, you can add it at https://bridge.arbitrum.io/.
-### What happens if I send my funds to an exchange that doesn't support Arbitrum? -If you send the funds and the receiving wallet/exchange doesn't support the Arbitrum network you are sending funds through, there is unfortunately nothing that we can do to recover your funds. You would need to contact the wallet/exchange support and see if they can do anything to help you retrieve the funds.
+ +### What happens if I send my funds to an exchange that does not support Arbitrum? {#what-happens-if-i-send-my-funds-to-an-exchange-that-does-not-support-arbitrum} +If you send the funds and the receiving wallet/exchange does not support the Arbitrum network you are sending funds through, there is unfortunately nothing that we can do to recover your funds. You would need to contact the wallet/exchange support and see if they can do anything to help you retrieve the funds.
-### Does Arbitrum have a mempool? + +### Does Arbitrum have a mempool? {#does-arbitrum-have-a-mempool}The Arbitrum Sequencer orders transactions on a first come, first served basis; the Sequencer inserts transactions into a queue based on the order they are received and executes them accordingly. This queue thus exists in lieu of a mempool. The Sequencer's queue has no space limit; transactions on the queue will eventually timeout and be discarded if not executed in time. Under normal conditions, the queue is empty, since transactions are executed near-instantaneously.
-### What's the difference between Arbitrum Rollup and Arbitrum AnyTrust? -Arbitrum Rollup is an Optimistic Rollup protocol; it is trustless and permissionless. Part of how these properties are achieved is by requiring all chain data to be posted on layer 1. This means the availability of this data follows directly from the security properties of Ethereum itself, and, in turn, that any party can participate in validating the chain and ensuring its safety. For more information, see Inside Arbitrum Nitro.
-By contrast, Arbitrum AnyTrust introduces a trust assumption in exchange for lower fees; data availability is managed by a Data Availability Committee (DAC), a fixed, permissioned set of entities. We introduce some threshold, K, with the assumption that at least K members of the committee are honest. For simplicity, we'll hereby assume a committee of size 20 and a K value of 2:
Arbitrum Rollup is an Optimistic Rollup protocol; it is trustless and permissionless. Part of how these properties are achieved is by requiring all chain data to be posted on layer 1. This means the availability of this data follows directly from the security properties of Ethereum itself, and, in turn, that any party can participate in validating the chain and ensuring its safety.
+ +By contrast, Arbitrum AnyTrust introduces a trust assumption in exchange for lower fees; data availability is managed by a Data Availability Committee (DAC), a fixed, permissioned set of entities. We introduce some threshold, K, with the assumption that at least K members of the committee are honest. For simplicity, we'll hereby assume a committee of size 20 and a K value of 2:
If 19 out of the 20 committee members and the Sequencer are malicious and colluding together, they can break the chain's safety (and, e.g., steal users' funds); this is the new trust assumption.
@@ -44,7 +51,8 @@ -### How can I check the status of my cross chain message? + +### How can I check the status of my cross chain message? {#how-can-i-check-the-status-of-my-cross-chain-message}You can check the status of any Arbitrum cross chain message at https://retryable-dashboard.arbitrum.io/ (you will also be able to execute the cross chain message there, if applicable).
You'll need the transaction hash of the "initiating transaction": the L1 transaction hash for an L1-to-L2 message (e.g., a deposit), or the L2 transaction hash for an L2-to-L1 message (e.g., a withdrawal).
@@ -56,19 +64,19 @@ -### If there is a dispute, can my L2 transaction get reorged / thrown out / "yeeted"? -Nope; once an Arbitrum transaction is included on L1, there is no way it can be reorged (unless the L1 itself reorgs, of course). A "dispute" involves Validators disagreeing over execution, i.e., the outputted state of a chain. The inputs, however, can't be disputed; they are determined by the Inbox on L1. (See Transaction Lifecycle)
- +### If there is a dispute, can my L2 transaction get reorged / thrown out / "yeeted"? {#if-there-is-a-dispute-can-my-l2-transaction-get-reorged--thrown-out--yeeted} +Nope; once an Arbitrum transaction is included on L1, there is no way it can be reorged (unless the L1 itself reorgs, of course). A "dispute" involves Validators disagreeing over execution, i.e., the outputted state of a chain. The inputs, however, can't be disputed; they are determined by the Inbox on L1. (See Transaction Lifecycle)
-### ...okay but if there's a dispute, will my transaction get delayed? +### ...okay but if there's a dispute, will my transaction get delayed?The only thing that a dispute can add delay to is the confirmation of L2-to-L1 messages. All other transactions continue to be processed, even while a dispute is still undergoing. (Additionally: in practice, most L2-to-L1 messages represent withdrawals of fungible assets; these can be trustlessly completed even during a dispute via trustless fast "liquidity exit" applications. See L2-to-L1 Messages).
- +## -### Are "Sequencers" the same entities as "Validators"? Can a centralized Sequencer act maliciously (e.g., steal all my money)? + +### Are "Sequencers" the same entities as "Validators"? Can a centralized Sequencer act maliciously (e.g., steal all my money)? {#are-sequencers-the-same-entities-as-validators-can-a-centralized-sequencer-act-maliciously-eg-steal-all-my-money}No and no!
An Arbitrum Chain's Sequencer(s) and Validators and completely distinct entities, with their own distinct roles.
@@ -90,27 +98,31 @@ -### Why was "one week" chosen for Arbitrum One's dispute window? -Generally, some amount of time is necessary for the Arbitrum validators to dispute an invalid assertion.
-A week is expected to be more than enough time for validators to carry out an interactive dispute, assuming they don't encounter difficulty in getting their transactions included on L1. One week was chosen following the general consensus among the Ethereum research community — as well as other layer 2 projects — to provide enough time for the community to socially coordinate in the case of a coordinated Ethereum-staker censorship attack.
+### Why was "one week" chosen for Arbitrum One's dispute window? {#why-was-one-week-chosen-for-arbitrum-ones-dispute-window} +Generally, some amount of time is necessary for the Arbitrum validators to dispute an invalid assertion.
+
+A week is expected to be more than enough time for validators to carry out an interactive dispute, assuming they don't encounter difficulty in getting their transactions included on L1. One week was chosen following the general consensus among the Ethereum research community — as well as other layer 2 projects — to provide enough time for the community to socially coordinate in the case of a coordinated Ethereum-staker censorship attack.
See "State of Progressive Decentralization", or check out the work of our friends at L2BEAT.
-### Are there any Fiat on-ramps that support Arbitrum? + +### Are there any Fiat on-ramps that support Arbitrum? {#are-there-any-fiat-onramps-that-support-arbitrum}Yes, you can find a list of Fiat on-ramps that support Arbitrum on our portal.
-### How many blocks are needed for a transaction to be confirmed/finalized in Arbitrum? + +### How many blocks are needed for a transaction to be confirmed/finalized in Arbitrum? {#how-many-blocks-are-needed-for-a-transaction-to-be-confirmedfinalized-in-arbitrum}There are two levels of finality in a transaction lifecycle:
Although we currently don't maintain any stats dashboard for Arbitrum, you can find many community created dashboards in Dune.
-### Will transactions with a higher "gas price bid" be confirmed first? + +### Will transactions with a higher "gas price bid" be confirmed first? {#will-transactions-with-a-higher-gas-price-bid-be-confirmed-first}There is no notion of mempool on Arbitrum, transactions are processed on a first come first served basis by the Sequencer. Thus, the gas price bid parameter does not influence the order in which a transaction is processed.
-### Where can I find a list of the current validators of the Arbitrum chains? + +### Where can I find a list of the current validators of the Arbitrum chains? {#where-can-i-find-a-list-of-the-current-validators-of-the-arbitrum-chains}Validation on both Arbitrum One and Arbitrum Nova is currently allow-listed to a committee of public entities. You can see the list of validators here. Governance currently has the power to change this status.
-### Where can I find the current Data Availability Committee members? + +### Where can I find the current Data Availability Committee members? {#where-can-i-find-the-current-data-availability-committee-members}The Arbitrum Nova chain has a 7-party DAC, whose members can be seen here. Governance has the ability to remove or add members to the committee.
-### Can I withdraw my funds from Arbitrum back to Ethereum without going through the Sequencer? What about funds that are in a contract? -Yes, it is possible to permissionlessly send a message from Ethereum to be executed on Arbitrum, while bypassing the Sequencer. You can do this by using the DelayedInbox contract and force-including the message after a certain amount of time has passed (currently ~24 hours). You can find more information about this behavior here.
- -Keep in mind that you can execute any message in this way, be it a withdrawal of funds back to Ethereum, or a call to a contract.
-You can also find an example of force-inclusion in this tutorial.
- - - - -### Are there any plans to reduce the time a transaction needs to wait before being able to be force-included from Ethereum into the Arbitrum chain, bypassing the sequencer? (Currently 24 hours) +### Are there any plans to reduce the time a transaction needs to wait before being able to be force-included from Ethereum into the Arbitrum chain, bypassing the sequencer? (Currently 24 hours) {#are-there-any-plans-to-reduce-the-time-a-transaction-needs-to-wait-before-being-able-to-be-forceincluded-from-ethereum-into-the-arbitrum-chain-bypassing-the-sequencer-currently-24-hours}The mechanism that allows force-including transactions from Ethereum (bypassing the sequencer) is intended to be used in very rare cases, especially when it is expected that the sequencer will not be operational again, so that users have a way of interacting with Arbitrum in a trustless way.
When using this mechanism, if the sequencer is down for longer than the time window for force-including transactions from Ethereum, the moment it is online again, it can lead to a reorganization of blocks in Arbitrum (it would have received transactions timestamped before the force-included one).
@@ -165,7 +172,15 @@ -### What is the difference between an L2 block and a RBlock? + +### Why do Arbitrum chains enforce a speed limit? Isn't it better that the speed grows without limits? {#why-do-arbitrum-chains-enforce-a-speed-limit-isnt-it-better-that-the-speed-grows-without-limits} +The transaction lifecycle sets a limit that we have to take into account: validators have to execute each transaction, get the status of the chain, and post an assertion to Ethereum every certain amount of time. If the speed of the chain increases too much, there is a risk that validators won't have enough computation power to process all transactions in a timely manner, and will fall behind on validating them, which would cause the chain to delay confirmations of its state.
+ + + + + +### What is the difference between an L2 block and a RBlock? {#what-is-the-difference-between-an-l2-block-and-a-rblock}An L2 block is very similar to the concept of an L1 block. These blocks are generated by validator nodes of Arbitrum by executing the state transition function on sequenced transactions. The structure of an L2 block is similar to that of an Ethereum block, with a few differences that you can see here.
On the other hand, an RBlock is a distinctive block that is transmitted back to L1 to serve as a fingerprint of the most recent state of the Arbitrum chain. It comprises an assertion of the present state root of the Arbitrum chain and other essential information pertaining to withdrawals and challenges. The structure of RBlocks can be viewed here.
@@ -175,8 +190,4 @@ -### Why do Arbitrum chains enforce a speed limit? Isn't it better that the speed grows without limits? -The transaction lifecycle sets a limit that we have to take into account: validators have to execute each transaction, get the status of the chain, and post an assertion to Ethereum every certain amount of time. If the speed of the chain increases too much, there is a risk that validators won't have enough computation power to process all transactions in a timely manner, and will fall behind on validating them, which would cause the chain to delay confirmations of its state.
- - diff --git a/arbitrum-docs/stylus/reference/rust-sdk-guide.md b/arbitrum-docs/stylus/reference/rust-sdk-guide.md index a4f73e1045..992a5f4ffc 100644 --- a/arbitrum-docs/stylus/reference/rust-sdk-guide.md +++ b/arbitrum-docs/stylus/reference/rust-sdk-guide.md @@ -103,15 +103,16 @@ You can access storage types via getters and setters. For example, the `Contract ```rust impl Contract { /// Gets the owner from storage. - pub fn owner(&self) -> Address { - self.owner.get() + pub fn owner(&self) -> Result