From f88425749592eb36488223ac8085806f35309934 Mon Sep 17 00:00:00 2001 From: Pete Date: Thu, 20 Feb 2025 08:39:24 -0600 Subject: [PATCH 1/4] faq/glossary updater --- arbitrum-docs/partials/_glossary-partial.mdx | 12 ++++++------ .../_troubleshooting-bridging-partial.mdx | 6 +++--- .../_troubleshooting-building-partial.mdx | 6 +++--- .../_troubleshooting-users-partial.mdx | 18 +++++++++--------- website/static/bridging-faqs.json | 2 +- website/static/building-faqs.json | 2 +- website/static/get-started-faqs.json | 2 +- website/static/glossary.json | 12 ++++++------ 8 files changed, 30 insertions(+), 30 deletions(-) diff --git a/arbitrum-docs/partials/_glossary-partial.mdx b/arbitrum-docs/partials/_glossary-partial.mdx index 18b0ec234a..6fb4d68530 100644 --- a/arbitrum-docs/partials/_glossary-partial.mdx +++ b/arbitrum-docs/partials/_glossary-partial.mdx @@ -92,7 +92,7 @@ Arbitrum's "operating system" that trustlessly handles system-level operations; ### Assertion {#assertion}

-A staked claim by an Arbitrum Validator. An assertion may, e.g., propose a new RBlock, or may be a step in a Challenge. +A staked claim made by an Arbitrum Validator representing a claim about an Arbitrum chain's state. An Assertion may, e.g., propose a new assertion, or may be a step in a Challenge.

### Auction Contract {#auction-contract} @@ -147,12 +147,12 @@ When two Stakers disagree about the correct ### Challenge Period {#challenge-period}

-Window of time (1 week on Arbitrum One) over which an asserted RBlock can be challenged, and after which the RBlock can be confirmed. +Window of time (one week on Arbitrum One) over which an Assertion can be challenged, and after which the assertion can be confirmed.

### Challenge protocol {#challenge-protocol}

-The protocol by which RBlocks are submitted, disputed, and ultimately confirmed. The Challenge Protocol guarantees that only valid RBlocks will be confirmed provided that there is at least one honest Active Validator. +The protocol by which assertions are submitted, disputed, and ultimately confirmed. The Challenge Protocol guarantees that only valid Assertion will be confirmed provided that there is at least one honest Active Validator.

### Child chain {#child-chain} @@ -167,7 +167,7 @@ A program running on a user's machine, often in the user's browser, that interac ### Confirmation {#confirmation}

-The decision by an Arbitrum chain to finalize an RBlock as part of the chain's history. Once an RBlock is confirmed its L2 to L1 Messages (e.g., withdrawals) can be executed. +The decision by an Arbitrum chain to finalize an assertion as part of the chain's history. Once an Assertion is confirmed its L2 to L1 Messages (e.g., withdrawals) can be executed.

### Cross-chain message {#crosschain-message} @@ -354,7 +354,7 @@ A web application maintained by Offchain ### RBlock {#rblock}

-An assertion by an Arbitrum Validator that represents a claim about an Arbitrum chain's state. +Refer to Assertion

### Reorg {#reorg} @@ -414,7 +414,7 @@ Target computation limit for an Arbitrum chain. Validator who deposits a stake (in Ether on Arbitrum One and Arbitrum Nova ) to vouch for a particular RBlock in an Arbitrum Chain. A validator who stakes on a false RBlock can expect to lose their stake. An honest staker can recover their stake once the RBlock they are staked on has been confirmed. +A Validator who deposits a stake (in Ether on Arbitrum One and Arbitrum Nova ) to vouch for a particular Assertion in an Arbitrum Chain. A validator who stakes on a false assertion can expect to lose their stake. An honest staker can recover their stake once the assertion they are staked on has been confirmed.

### Standard Arb-Token {#standard-arbtoken} diff --git a/arbitrum-docs/partials/_troubleshooting-bridging-partial.mdx b/arbitrum-docs/partials/_troubleshooting-bridging-partial.mdx index c7f8281a91..16f06b9dab 100644 --- a/arbitrum-docs/partials/_troubleshooting-bridging-partial.mdx +++ b/arbitrum-docs/partials/_troubleshooting-bridging-partial.mdx @@ -52,13 +52,13 @@ The variability of the dispute window comes from the slight variance of block ti

-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 the Sequencer and their child-to-parent chain message being executable. After getting their receipt,

    -
  1. The sequencer posts their transaction in a batch (usually within a few minutes, though the sequencer will wait a bit longer if the L1 is congested). Then,
    2. +
  2. The sequencer posts their transaction in a batch (usually within a few minutes, though the sequencer will wait a bit longer if the parent chain is congested). Then,
  3. A validator includes their transaction in an assertion (usually within the hour). Then, after the ~week long dispute window passes, the assertion is confirmable, and
    4. -
  4. Somebody (anybody) confirms the assertion on L1 (usually within ~15 minutes).
    5. +
  5. Somebody (anybody) confirms the assertion on the parent chain (usually within ~15 minutes).

Additionally, in the rare and unlikely event of a dispute, this delay period will be extended for the dispute to resolve. diff --git a/arbitrum-docs/partials/_troubleshooting-building-partial.mdx b/arbitrum-docs/partials/_troubleshooting-building-partial.mdx index b876ede498..ac10b29773 100644 --- a/arbitrum-docs/partials/_troubleshooting-building-partial.mdx +++ b/arbitrum-docs/partials/_troubleshooting-building-partial.mdx @@ -381,9 +381,9 @@ Make sure you have enough funds in your wallet, and the gas fields of the reques

-### How can I verify that an L2 block has been processed as part of a specific assertion? +### How can I verify that a child chain block has been processed as part of a specific assertion?

-If you want to verify that the latest confirmed (or created) assertion has processed a specific L2 block, you can follow these steps: +If you want to verify that the latest confirmed (or created) assertion has processed a specific child chain block, you can follow these steps:

    @@ -391,7 +391,7 @@ If you want to verify that the latest confirmed (or created) assertion has proce
  1. Obtain the node information through getNode
  2. Find the NodeCreated event that was emitted when that node was created.
  3. In that NodeCreated event, there's an assertion property that contains the state of the chain before processing the specified blocks, and after processing them. Get the afterState.globalState property
    4. -
  4. That value contains a bytes32Vals array with the latest L2 block hash processed in the first element.
    5. +
  5. That value contains a bytes32Vals array with the latest child chain block hash processed in the first element.

You can find an example script in our arbitrum-tutorials repository. diff --git a/arbitrum-docs/partials/_troubleshooting-users-partial.mdx b/arbitrum-docs/partials/_troubleshooting-users-partial.mdx index cadc8a0b8c..b5d05ee4e3 100644 --- a/arbitrum-docs/partials/_troubleshooting-users-partial.mdx +++ b/arbitrum-docs/partials/_troubleshooting-users-partial.mdx @@ -16,7 +16,7 @@ Since transactions are processed in the order that the Sequencer receives them, ### 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 and OKX Wallet, 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/. +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/.

@@ -46,7 +46,7 @@ The Arbitrum Sequencer orders transactions on a first come, first served basis; ### 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 How Arbitrum works. +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.

@@ -70,7 +70,7 @@ Variants of the AnyTrust model in which the new trust assumption is minimized ar

-For more, see AnyTrust protocol. +For more, see Inside AnyTrust.

@@ -102,7 +102,7 @@ If you cross-chain message was initiated from -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) +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)

@@ -112,7 +112,7 @@ Nope; once an Arbitrum transaction is included on L1, there is no way it can be ### ...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). +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).

@@ -290,17 +290,17 @@ In any case, we could also analyze why would someone use this mechanism having a

-### What is the difference between an L2 block and an assertion? +### What is the difference between an child chain block and an assertion?

-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. +A child chain block is very similar to the concept of an parent chain block. These blocks are generated by validator nodes of Arbitrum by executing the state transition function on sequenced transactions. The structure of a child chain block is similar to that of an Ethereum block, with a few differences that you can see here.

-On the other hand, an assertion 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 assertions can be viewed here. +On the other hand, an assertion is a distinctive block that is transmitted back to the parent chain 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 assertions can be viewed here.

-These assertions are also generated by validators, but they are appended to the L1 chain. Other validators can challenge them during a specific time frame of approximately one week if they discover that the current state hash of the chain varies from the one that was initially claimed. Once the challenge period elapses, the assertion is confirmed on L1. +These assertions are also generated by validators, but they are appended to the parent chain. Other validators can challenge them during a specific time frame of approximately one week if they discover that the current state hash of the chain varies from the one that was initially claimed. Once the challenge period elapses, the assertion is confirmed on the parent chain.

diff --git a/website/static/bridging-faqs.json b/website/static/bridging-faqs.json index bdf2e18e86..6f19978ad6 100644 --- a/website/static/bridging-faqs.json +++ b/website/static/bridging-faqs.json @@ -1,7 +1,7 @@ [ {"question": "How do I move assets between One and Nova?","answer": "

\nBoth 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/.\n

\n\n

\n\n

\n\n","key": "how-do-i-move-assets-between-one-and-nova"}, {"question": "What fees do I have to pay when bridging funds from L1 to L2?","answer": "

\nWhen bridging over tokens from L1 to L2, you will have to sign one or two transactions with their corresponding fees:\n

\n\n
    \n
  1. If you are bridging a token for the first time, you'll sign one approval transaction.
    2. \n
  2. In all cases, you'll sign a deposit transaction that will send your tokens to the Bridge.
    3. \n
\n

\n\n

\n\n

\nKeep in mind that the approval transaction needs to be executed at least once per token and wallet. This means that if you bridge the same token from the same wallet again, you probably won't have to pay for that transaction. However, if you bridge the same token from a different wallet, you will have to pay for that transaction again.\n

\n\n

\n\n

\n\n

\nIn any case, the bridge and your wallet will guide you through the process, showing the transaction(s) that you need to sign in order to have your tokens bridged to Arbitrum.\n

\n\n

\n\n

\n\n","key": "what-fees-do-i-have-to-pay-when-bridging-funds-from-l1-to-l2"}, -{"question": "How long does it take before I receive my funds when I initiate a withdrawal from Arbitrum chains (One and Nova)?","answer": "

\nUsing 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!).\n

\n\n

\nThere'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).\n

\n\n

\nThe 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.\n

\n\n

\nThe \"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,\n

\n\n
    \n
  1. The sequencer posts their transaction in a batch (usually within a few minutes, though the sequencer will wait a bit longer if the L1 is congested). Then,
    2. \n
  2. A validator includes their transaction in an RBlock (usually within the hour). Then, after the ~week long dispute window passes, the RBlock is confirmable, and
    3. \n
  3. Somebody (anybody) confirms the RBlock on L1 (usually within ~15 minutes).
    4. \n
\n

\nAdditionally, in the rare and unlikely event of a dispute, this delay period will be extended for the dispute to resolve.\n

\n\n","key": "how-long-does-it-take-before-i-receive-my-funds-when-i-initiate-a-withdrawal-from-arbitrum-chains-one-and-nova"}, +{"question": "How long does it take before I receive my funds when I initiate a withdrawal from Arbitrum chains (One and Nova)?","answer": "

\nUsing 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!).\n

\n\n

\nThere'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).\n

\n\n

\nThe 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.\n

\n\n

\nThe \"padding on both ends\" involves three events that have to occur between a client receiving their transaction receipt from the Sequencer and their child-to-parent chain message being executable. After getting their receipt,\n

\n\n
    \n
  1. The sequencer posts their transaction in a batch (usually within a few minutes, though the sequencer will wait a bit longer if the parent chain is congested). Then,
    2. \n
  2. A validator includes their transaction in an assertion (usually within the hour). Then, after the ~week long dispute window passes, the assertion is confirmable, and
    3. \n
  3. Somebody (anybody) confirms the assertion on the parent chain (usually within ~15 minutes).
    4. \n
\n

\nAdditionally, in the rare and unlikely event of a dispute, this delay period will be extended for the dispute to resolve.\n

\n\n","key": "how-long-does-it-take-before-i-receive-my-funds-when-i-initiate-a-withdrawal-from-arbitrum-chains-one-and-nova"}, {"question": "Is there a way to cancel a withdrawal from Arbitrum?","answer": "

\nThere 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.\n

\n\n

\n\n

\n\n","key": "is-there-a-way-to-cancel-a-withdrawal-from-arbitrum"}, {"question": "Can I use a smart contract wallet in the bridge?","answer": "

\nSupport 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.\n

\n\n

\nETH deposits and withdrawals using a Smart Contract Wallet are currently not supported, but will soon be available.\n

\n\n

\n\n

\n\n","key": "can-i-use-a-smart-contract-wallet-in-the-bridge"}, {"question": "How can I claim withdrawn funds if I don't control on L1 the address that initiated the transaction on L2?","answer": "

\nOnce 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.\n

\n\n

\n\n

\n\n","key": "how-can-i-claim-withdrawn-funds-if-i-dont-control-on-l1-the-address-that-initiated-the-transaction-on-l2"} diff --git a/website/static/building-faqs.json b/website/static/building-faqs.json index a90563868c..ae1446ae8f 100644 --- a/website/static/building-faqs.json +++ b/website/static/building-faqs.json @@ -20,7 +20,7 @@ {"question": "Why do some old transactions have extremely high gas prices when querying them?","answer": "

\nWhen 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.\n

\n\n

\nInstead of that, it is recommended to look at the effectiveGasPrice property from the transaction receipt.\n

\n\n

\n\n

\n\n","key": "why-do-some-old-transactions-have-extremely-high-gas-prices-when-querying-them"}, {"question": "What is the WASM module root?","answer": "

\nThe WASM module root is a 32 byte hash, which is a merkelization of the Go replay binary and its dependencies.\n

\n\n

\nThe 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.\n

\n\n

\nYou can find more information in How to customize your Orbit chain's behavior.\n

\n\n

\n\n

\n\n","key": "what-is-the-wasm-module-root"}, {"question": "Why do I get a \"gas required exceeds allowance\" when trying to estimate the gas costs of a request?","answer": "

\nDuring 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.\n

\n\n

\nMake sure you have enough funds in your wallet, and the gas fields of the request (if you're using them) are correctly set.\n

\n\n","key": "why-do-i-get-a-gas-required-exceeds-allowance-when-trying-to-estimate-the-gas-costs-of-a-request"}, -{"question": "How can I verify that an L2 block has been processed as part of a specific RBlock?","answer": "

\nIf you want to verify that the latest confirmed (or created) assertion has processed a specific L2 block, you can follow these steps:\n

\n\n
    \n
  1. From the rollup contract, obtain the latest confirmed (or created) Rblock through the function latestConfirmed (or latestNodeCreated). In this context, we refer to RBlocks as \"nodes\".
    2. \n
  2. Obtain the node information through getNode
    3. \n
  3. Find the NodeCreated event that was emitted when that node was created.
    4. \n
  4. In that NodeCreated event, there's an assertion property that contains the state of the chain before processing the specified blocks, and after processing them. Get the afterState.globalState property
    5. \n
  5. That value contains a bytes32Vals array with the latest L2 block hash processed in the first element.
    6. \n
\n

\nYou can find an example script in our arbitrum-tutorials repository.\n

\n\n","key": "how-can-i-verify-that-an-l2-block-has-been-processed-as-part-of-a-specific-rblock"}, +{"question": "How can I verify that a child chain block has been processed as part of a specific assertion?","answer": "

\nIf you want to verify that the latest confirmed (or created) assertion has processed a specific child chain block, you can follow these steps:\n

\n\n
    \n
  1. From the rollup contract, obtain the latest confirmed (or created) assertion through the function latestConfirmed (or latestNodeCreated). In this context, we refer to assertions as \"nodes\".
    2. \n
  2. Obtain the node information through getNode
    3. \n
  3. Find the NodeCreated event that was emitted when that node was created.
    4. \n
  4. In that NodeCreated event, there's an assertion property that contains the state of the chain before processing the specified blocks, and after processing them. Get the afterState.globalState property
    5. \n
  5. That value contains a bytes32Vals array with the latest child chain block hash processed in the first element.
    6. \n
\n

\nYou can find an example script in our arbitrum-tutorials repository.\n

\n\n","key": "how-can-i-verify-that-a-child-chain-block-has-been-processed-as-part-of-a-specific-assertion"}, {"question": "Why is the fee of some Classic transactions slightly different than the multiplication of gasLimit and effectiveGasPrice?","answer": "

\nGas 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).\n

\n\n

\nWhen 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.\n

\n\n

\nTo get the exact fees paid, you can query a Classic node, which will return all the accurate information in an object called feeStats. That object will contain all the information split into the four different gas fields: prices, unitsUsed and paid (which is price * unitsUsed).\n

\n\n

\n\n

\n\n","key": "why-is-the-fee-of-some-classic-transactions-slightly-different-than-the-multiplication-of-gaslimit-and-effectivegasprice"}, {"question": "How can I update the information of my bridged token on Arbiscan?","answer": "

\nIf 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.\n

\n\n

\nTo 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.\n

\n\n

\n\n

\n\n","key": "how-can-i-update-the-information-of-my-bridged-token-on-arbiscan"}, {"question": "Why does my transaction revert with InvalidFEOpcode when using Foundry?","answer": "

\nFoundry 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.\n

\n\n

\nTo rule out that possibility, it is recommended to send the transaction with a different tool.\n

\n\n

\n\n

\n\n","key": "why-does-my-transaction-revert-with-invalidfeopcode-when-using-foundry"}, diff --git a/website/static/get-started-faqs.json b/website/static/get-started-faqs.json index 80bf34f180..2a94558a8b 100644 --- a/website/static/get-started-faqs.json +++ b/website/static/get-started-faqs.json @@ -19,6 +19,6 @@ {"question": "Where can I find the current Data Availability Committee members?","answer": "

\nThe 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.\n

\n\n

\n\n

\n\n","key": "where-can-i-find-the-current-data-availability-committee-members"}, {"question": "Can I withdraw my funds from Arbitrum back to Ethereum without going through the Sequencer? What about funds that are in a contract?","answer": "

\nYes, 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.\n

\n\n

\nKeep 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.\n

\n\n

\nYou can also find an example of force-inclusion in this tutorial. \n

\n\n

\n\n

\n\n","key": "can-i-withdraw-my-funds-from-arbitrum-back-to-ethereum-without-going-through-the-sequencer-what-about-funds-that-are-in-a-contract"}, {"question": "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)","answer": "

\nThe 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.\n

\n\n

\nWhen 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).\n

\n\n

\n24 hours was chosen because it provides a comfortable period of time for the team running the sequencer infrastructure to fix any bugs that may cause the sequencer to not work. While there aren't any active initiatives to lower that time, the decision ultimately falls in the hands of the Arbitrum DAO, who has discussed the topic in their governance forum (see here for more information).\n

\n\n

\nIn any case, we could also analyze why would someone use this mechanism having an honest and functional sequencer. For instance, if the reason is a distrust of the sequencer, a centralised agent as of now, one potential solution could be to decentralize the sequencer instead of reducing the force-inclusion delay time.\n

\n\n

\n\n

\n\n","key": "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"}, -{"question": "What is the difference between an L2 block and a RBlock?","answer": "

\nAn 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.\n

\n\n

\nOn 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.\n

\n\n

\nThese RBlocks are also generated by validators, but they are appended to the L1 chain. Other validators can challenge them during a specific time frame of approximately one week if they discover that the current state hash of the chain varies from the one that was initially claimed. Once the challenge period elapses, the RBlock is confirmed on L1.\n

\n\n

\n\n

\n\n","key": "what-is-the-difference-between-an-l2-block-and-a-rblock"}, +{"question": "What is the difference between an child chain block and an assertion?","answer": "

\nA child chain block is very similar to the concept of an parent chain block. These blocks are generated by validator nodes of Arbitrum by executing the state transition function on sequenced transactions. The structure of a child chain block is similar to that of an Ethereum block, with a few differences that you can see here.\n

\n\n

\nOn the other hand, an assertion is a distinctive block that is transmitted back to the parent chain 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 assertions can be viewed here.\n

\n\n

\nThese assertions are also generated by validators, but they are appended to the parent chain. Other validators can challenge them during a specific time frame of approximately one week if they discover that the current state hash of the chain varies from the one that was initially claimed. Once the challenge period elapses, the assertion is confirmed on the parent chain.\n

\n\n

\n\n

\n\n","key": "what-is-the-difference-between-an-child-chain-block-and-an-assertion"}, {"question": "Why do Arbitrum chains enforce a speed limit? Isn't it better that the speed grows without limits?","answer": "

\nThe 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.\n

\n\n

\n\n

\n\n","key": "why-do-arbitrum-chains-enforce-a-speed-limit-isnt-it-better-that-the-speed-grows-without-limits"} ] \ No newline at end of file diff --git a/website/static/glossary.json b/website/static/glossary.json index 3ae3cd4e20..49bfb4dda6 100644 --- a/website/static/glossary.json +++ b/website/static/glossary.json @@ -17,7 +17,7 @@ "arbitrum-rollup-chain":{"title":"Arbitrum Rollup Chain","text":"

\nAn Arbitrum chain that implements the Arbitrum Rollup Protocol.\n

"}, "arbitrum-rollup-protocol":{"title":"Arbitrum Rollup Protocol","text":"

\nA trustless, permissionless Arbitrum protocol that uses its underlying base layer for data availability and inherits its security. This protocol is implemented by our Arbitrum One chain. \n

"}, "arbos":{"title":"ArbOS","text":"

\nArbitrum's \"operating system\" that trustlessly handles system-level operations; includes the ability to emulate the EVM.\n

"}, -"assertion":{"title":"Assertion","text":"

\nA staked claim by an Arbitrum Validator. An assertion may, e.g., propose a new RBlock, or may be a step in a Challenge.\n

"}, +"assertion":{"title":"Assertion","text":"

\nA staked claim made by an Arbitrum Validator representing a claim about an Arbitrum chain's state. An Assertion may, e.g., propose a new assertion, or may be a step in a Challenge.\n

"}, "auction-contract":{"title":"Auction Contract","text":"

\nA smart contract that handles the state, accounting of funds for bids, and various operations of the Timeboost auction. The contract is deployed on the target chain for which Timeboost is enabled.\n

"}, "autonomous-auctioneer":{"title":"Autonomous Auctioneer","text":"

\nOff chain software that receives bids from Timeboost participants, processes and validates bids, and then posts the top valid bid (or top two valid bids in the case of a tie) to the Auction Contract to resolve the on-going Timeboost auction. The autonomous auctioneer, for a given chain, is provisioned & deployed by an entity designated by the chain's owner.\n

"}, "batch":{"title":"Batch","text":"

\nA group of Arbitrum transactions posted in a single transaction on the Underlying Chain into the Fast Inbox by the Sequencer.\n

"}, @@ -28,11 +28,11 @@ "chain-owner":{"title":"Chain Owner","text":"

\nAn entity (i.e., a smart contract) with affordance to carry out critical upgrades to an Arbitrum chain's core protocol; this includes upgrading protocol contracts, setting core system parameters, and adding and removing other chain owners.\n

"}, "chain-state":{"title":"Chain state","text":"

\nA particular point in the history of an Arbitrum chain. A chain's state is determined by applying Arbitrum state-transition function to sequence of transactions (i.e., the chain's history).\n

"}, "challenge":{"title":"Challenge","text":"

\nWhen two Stakers disagree about the correct verdict on an Assertion, those stakers can be put in a challenge. The challenge is refereed by the contracts on the underlying chain. Eventually one staker wins the challenge. The protocol guarantees that an honest party will always win a challenge; the loser forfeits their stake. \n

"}, -"challenge-period":{"title":"Challenge Period","text":"

\nWindow of time (1 week on Arbitrum One) over which an asserted RBlock can be challenged, and after which the RBlock can be confirmed.\n

"}, -"challenge-protocol":{"title":"Challenge protocol","text":"

\nThe protocol by which RBlocks are submitted, disputed, and ultimately confirmed. The Challenge Protocol guarantees that only valid RBlocks will be confirmed provided that there is at least one honest Active Validator.\n

"}, +"challenge-period":{"title":"Challenge Period","text":"

\nWindow of time (one week on Arbitrum One) over which an Assertion can be challenged, and after which the assertion can be confirmed.\n

"}, +"challenge-protocol":{"title":"Challenge protocol","text":"

\nThe protocol by which assertions are submitted, disputed, and ultimately confirmed. The Challenge Protocol guarantees that only valid Assertion will be confirmed provided that there is at least one honest Active Validator.\n

"}, "child-chain":{"title":"Child chain","text":"

\nAn Arbitrum Chain that settles to an underlying Parent chain . For example, Arbitrum One and Arbitrum Nova are child chains of Ethereum.\n

"}, "client":{"title":"Client","text":"

\nA program running on a user's machine, often in the user's browser, that interacts with contracts on an Arbitrum chain and provides a user interface.\n

"}, -"confirmation":{"title":"Confirmation","text":"

\nThe decision by an Arbitrum chain to finalize an RBlock as part of the chain's history. Once an RBlock is confirmed its L2 to L1 Messages (e.g., withdrawals) can be executed.\n

"}, +"confirmation":{"title":"Confirmation","text":"

\nThe decision by an Arbitrum chain to finalize an assertion as part of the chain's history. Once an Assertion is confirmed its L2 to L1 Messages (e.g., withdrawals) can be executed.\n

"}, "crosschain-message":{"title":"Cross-chain message","text":"

\nAn action taken on some chain A which asynchronously initiates an additional action on chain B. \n

"}, "custom-arbtoken":{"title":"Custom Arb-Token","text":"

\nAny L2 token contract registered to the Arb Token Bridge that isn't a standard arb-token (i.e., a token that uses any gateway other than the StandardERC20 gateway ).\n

"}, "custom-gateway":{"title":"Custom gateway","text":"

\nAny Token Gateway that isn't the StandardERC20 gateway.\n

"}, @@ -69,7 +69,7 @@ "outbox":{"title":"Outbox","text":"

\nAn L1 contract responsible for tracking L2 to L1 Messages, including withdrawals, which can be executed once they are confirmed. The outbox stores a Merkle Root of all outgoing messages.\n

"}, "parent-chain":{"title":"Parent chain","text":"

\nEVM compatible chain that acts as the settlement layer for one or more Arbitrum Chains (aka Child chain ). E.g., Ethereum is the parent chain of both Arbitrum One and Arbitrum Nova. Parent chain is synonymous with \"underlying chain.\" \n

"}, "portal":{"title":"Portal","text":"

\nA web application maintained by Offchain Labs showcasing the Arbitrum ecosystem; visit it here.\n

"}, -"rblock":{"title":"RBlock","text":"

\nAn assertion by an Arbitrum Validator that represents a claim about an Arbitrum chain's state.\n

"}, +"rblock":{"title":"RBlock","text":"

\nRefer to Assertion \n

"}, "reorg":{"title":"Reorg","text":"

\nA situation in which transactions on a chain that were at some point considered accepted then get rejected. In the context of an Arbitrum chain, once transactions are posted in the chain's Fast Inbox, the only way the chain can experience a reorg is if its Underlying Chain itself reorgs. Of note, Fraud proofs do not cause reorgs. \n

"}, "retryable-autoredeem":{"title":"Retryable Autoredeem","text":"

\nThe \"automatic\" (i.e., requiring no additional user action) execution of a Retryable Ticket on an Arbitrum chain.\n

"}, "retryable-redeem":{"title":"Retryable Redeem","text":"

\nThe execution of a Retryable Ticket on L2; can be automatic (see Retryable Autoredeem) or manual via a user-initiated L2 transaction.\n

"}, @@ -81,7 +81,7 @@ "smart-contract":{"title":"Smart Contract","text":"

\nA computer program whose operations are defined and executed within a blockchain consensus protocol.\n

"}, "soft-confirmation":{"title":"Soft Confirmation","text":"

\nA semi-trusted promise from the Sequencer to post a user's transaction in the near future; soft-confirmations happen prior to posting on the Parent chain, and thus can be given near-instantaneously (i.e., faster than the parent chain's block times)\n

"}, "speed-limit":{"title":"Speed Limit","text":"

\nTarget computation limit for an Arbitrum chain. Arbitrum One and Arbitrum Nova currently target 7,000,000 gas / second. When computation exceeds this limit, fees rise, ala EIP-1559.\n

"}, -"staker":{"title":"Staker","text":"

\nA Validator who deposits a stake (in Ether on Arbitrum One and Arbitrum Nova ) to vouch for a particular RBlock in an Arbitrum Chain. A validator who stakes on a false RBlock can expect to lose their stake. An honest staker can recover their stake once the RBlock they are staked on has been confirmed.\n

"}, +"staker":{"title":"Staker","text":"

\nA Validator who deposits a stake (in Ether on Arbitrum One and Arbitrum Nova ) to vouch for a particular Assertion in an Arbitrum Chain. A validator who stakes on a false assertion can expect to lose their stake. An honest staker can recover their stake once the assertion they are staked on has been confirmed.\n

"}, "standard-arbtoken":{"title":"Standard Arb-Token","text":"

\nAn token contract on an Arbitrum chain deployed via the StandardERC20 gateway; offers basic ERC20 functionality in addition to deposit / withdrawal affordances.\n

"}, "standarderc20-gateway":{"title":"StandardERC20 gateway","text":"

\nToken Gateway via which any underlying chain's ERC20 token can permissionlessly bridge; the StandardERC20 gateway contracts deploy a Standard Arb-Token on the Child chain for each bridged token.\n

"}, "state-transition-function":{"title":"State Transition Function","text":"

\nThe STF (State Transition Function) defines how new blocks are produced from input messages (i.e. transactions) in an Arbitrum chain.\n

"}, From ec0b1f55430613ea5b70092de6050c85dd6f9650 Mon Sep 17 00:00:00 2001 From: Pete Date: Thu, 20 Feb 2025 08:39:36 -0600 Subject: [PATCH 2/4] yarn format --- website/src/theme/Layout.tsx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/src/theme/Layout.tsx b/website/src/theme/Layout.tsx index 03e8c3d7b9..80742811c9 100644 --- a/website/src/theme/Layout.tsx +++ b/website/src/theme/Layout.tsx @@ -29,7 +29,7 @@ export default function Layout(props) { {/* */} - + {/* */} ); From f5ba7c732d32edc4c279c1b6f396b0ab693bfa15 Mon Sep 17 00:00:00 2001 From: Pete Date: Fri, 21 Feb 2025 13:11:49 -0600 Subject: [PATCH 3/4] Update arbitrum-docs/partials/_glossary-partial.mdx MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Gaël Blanchemain --- arbitrum-docs/partials/_glossary-partial.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arbitrum-docs/partials/_glossary-partial.mdx b/arbitrum-docs/partials/_glossary-partial.mdx index 6fb4d68530..de095c5e27 100644 --- a/arbitrum-docs/partials/_glossary-partial.mdx +++ b/arbitrum-docs/partials/_glossary-partial.mdx @@ -92,7 +92,7 @@ Arbitrum's "operating system" that trustlessly handles system-level operations; ### Assertion {#assertion}

-A staked claim made by an Arbitrum Validator representing a claim about an Arbitrum chain's state. An Assertion may, e.g., propose a new assertion, or may be a step in a Challenge. +A staked claim made by an Arbitrum Validator representing a claim about an Arbitrum chain's state. An Assertion may propose a new assertion, or may be a step in a Challenge.

### Auction Contract {#auction-contract} From 763578921c77e6e1b0946472355ce51a1095952d Mon Sep 17 00:00:00 2001 From: Pete Date: Fri, 21 Feb 2025 13:11:57 -0600 Subject: [PATCH 4/4] Update arbitrum-docs/partials/_glossary-partial.mdx MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Gaël Blanchemain --- arbitrum-docs/partials/_glossary-partial.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arbitrum-docs/partials/_glossary-partial.mdx b/arbitrum-docs/partials/_glossary-partial.mdx index de095c5e27..1cb8601b8e 100644 --- a/arbitrum-docs/partials/_glossary-partial.mdx +++ b/arbitrum-docs/partials/_glossary-partial.mdx @@ -152,7 +152,7 @@ Window of time (one week on Arbitrum One) over which an Assertion will be confirmed provided that there is at least one honest Active Validator. +The protocol by which assertions are submitted, disputed, and ultimately confirmed. The Challenge Protocol guarantees that only valid Assertions will be confirmed provided that there is at least one honest Active Validator.

### Child chain {#child-chain}