docs: glossary-update-bold

arbitrum-docs/partials/_glossary-partial.mdx

@@ -92,7 +92,7 @@ Arbitrum's "operating system" that trustlessly handles system-level operations;
 
 ### Assertion {#assertion}
 <p>
-A staked claim by an Arbitrum <a href="/intro/glossary#validator">Validator</a>. An assertion may, e.g., propose a new <a href="/intro/glossary#rblock">RBlock</a>, or may be a step in a <a href="/intro/glossary#challenge">Challenge</a>.
+A staked claim made by an Arbitrum <a href="/intro/glossary#validator">Validator</a> representing a claim about an Arbitrum chain's state. An <a href="/intro/glossary#assertion">Assertion</a> may propose a new assertion, or may be a step in a <a href="/intro/glossary#challenge">Challenge</a>.
 </p>
 
 ### Auction Contract {#auction-contract}
@@ -147,12 +147,12 @@ When two <a href="/intro/glossary#staker">Staker</a>s disagree about the correct
 
 ### Challenge Period {#challenge-period}
 <p>
-Window of time (1 week on Arbitrum One) over which an asserted <a href="/intro/glossary#rblock">RBlock</a>  can be challenged, and after which the RBlock can be confirmed.
+Window of time (one week on Arbitrum One) over which an <a href="/intro/glossary#assertion">Assertion</a> can be challenged, and after which the assertion can be confirmed.
 </p>
 
 ### Challenge protocol {#challenge-protocol}
 <p>
-The protocol by which <a href="/intro/glossary#rblock">RBlock</a>s 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 <a href="/intro/glossary#active-validator">Active Validator</a>.
+The protocol by which assertions are submitted, disputed, and ultimately confirmed. The Challenge Protocol guarantees that only valid <a href="/intro/glossary#assertion">Assertions</a> will be confirmed provided that there is at least one honest <a href="/intro/glossary#active-validator">Active Validator</a>.
 </p>
 
 ### 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}
 <p>
-The decision by an <a href="/intro/glossary#arbitrum-chain">Arbitrum chain</a>  to finalize an <a href="/intro/glossary#rblock">RBlock</a>  as part of the chain's history. Once an RBlock is confirmed its <a href="/intro/glossary#l2-to-l1-message">L2 to L1 Message</a>s  (e.g., withdrawals) can be executed.
+The decision by an <a href="/intro/glossary#arbitrum-chain">Arbitrum chain</a>  to finalize an assertion  as part of the chain's history. Once an <a href="/intro/glossary#assertion">Assertion</a> is confirmed its <a href="/intro/glossary#l2-to-l1-message">L2 to L1 Message</a>s  (e.g., withdrawals) can be executed.
 </p>
 
 ### Cross-chain message {#crosschain-message}
@@ -354,7 +354,7 @@ A web application maintained by <a href="/intro/glossary#offchain-labs">Offchain
 
 ### RBlock {#rblock}
 <p>
-An assertion by an Arbitrum <a href="/intro/glossary#validator">Validator</a> that represents a claim about an Arbitrum chain's state.
+Refer to <a href="/intro/glossary#assertion">Assertion</a> 
 </p>
 
 ### Reorg {#reorg}
@@ -414,7 +414,7 @@ Target computation limit for an Arbitrum chain. <a href="/intro/glossary#arbitru
 
 ### Staker {#staker}
 <p>
-A <a href="/intro/glossary#validator">Validator</a> who deposits a stake (in Ether on <a href="/intro/glossary#arbitrum-one">Arbitrum One</a> and <a href="/intro/glossary#arbitrum-nova">Arbitrum Nova</a> ) to vouch for a particular <a href="/intro/glossary#rblock">RBlock</a>  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 <a href="/intro/glossary#validator">Validator</a> who deposits a stake (in Ether on <a href="/intro/glossary#arbitrum-one">Arbitrum One</a> and <a href="/intro/glossary#arbitrum-nova">Arbitrum Nova</a> ) to vouch for a particular <a href="/intro/glossary#assertion">Assertion</a> 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.
 </p>
 
 ### Standard Arb-Token {#standard-arbtoken}

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
 </p>
 
 <p>
-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,
 </p>
 
 <ol>
-<li>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,</li>
+<li>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,</li>
 <li>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</li>
-<li>Somebody (anybody) confirms the assertion on L1 (usually within ~15 minutes).</li>
+<li>Somebody (anybody) confirms the assertion on the parent chain (usually within ~15 minutes).</li>
 </ol>
 <p>
 Additionally, in the rare and unlikely event of a dispute, this delay period will be extended for the dispute to resolve.

arbitrum-docs/partials/_troubleshooting-building-partial.mdx

@@ -381,17 +381,17 @@ Make sure you have enough funds in your wallet, and the gas fields of the reques
 </p>
 
 
-### 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?
 <p>
-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:
 </p>
 
 <ol>
 <li>From the rollup contract, obtain the latest confirmed (or created) assertion through the function <code>latestConfirmed</code> (or <code>latestNodeCreated</code>). In this context, we refer to assertions as "nodes".</li>
 <li>Obtain the node information through <code>getNode</code></li>
 <li>Find the <code>NodeCreated</code> event that was emitted when that node was created.</li>
 <li>In that NodeCreated event, there's an <code>assertion</code> property that contains the state of the chain before processing the specified blocks, and after processing them. Get the <code>afterState.globalState</code> property</li>
-<li>That value contains a bytes32Vals array with the latest L2 block hash processed in the first element.</li>
+<li>That value contains a bytes32Vals array with the latest child chain block hash processed in the first element.</li>
 </ol>
 <p>
 You can find an example script in our <a href="https://github.com/OffchainLabs/arbitrum-tutorials/tree/master/packages/l2-block-verification-in-assertion">arbitrum-tutorials</a> repository.

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?
 <p>
-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 <a href="https://bridge.arbitrum.io/">https://bridge.arbitrum.io/</a>.
+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 <a href="https://bridge.arbitrum.io/">https://bridge.arbitrum.io/</a>.
 </p>
 
 <p>
@@ -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?
 <p>
-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 <a href="https://docs.arbitrum.io/how-arbitrum-works/a-gentle-introduction">How Arbitrum works</a>.
+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 <a href="https://docs.arbitrum.io/inside-arbitrum-nitro/">Inside Arbitrum Nitro</a>.
 </p>
 
 <p>
@@ -70,7 +70,7 @@ Variants of the AnyTrust model in which the new trust assumption is minimized ar
 </p>
 
 <p>
-For more, see <a href="https://docs.arbitrum.io/how-arbitrum-works/anytrust-protocol">AnyTrust protocol</a>.
+For more, see <a href="https://developer.arbitrum.io/inside-anytrust">Inside AnyTrust</a>.
 </p>
 
 <p>
@@ -102,7 +102,7 @@ If you cross-chain message was initiated from <a href="https://bridge.arbitrum.i
 
 ### If there is a dispute, can my L2 transaction get reorged / thrown out / "yeeted"?
 <p>
-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 <a href="https://docs.arbitrum.io/how-arbitrum-works/transaction-lifecycle">Transaction Lifecycle</a>)
+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 <a href="https://developer.arbitrum.io/tx-lifecycle">Transaction Lifecycle</a>)
 </p>
 
 <p>
@@ -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?
 <p>
-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 <em>even during a dispute</em> via trustless fast "liquidity exit" applications. See <a href="https://docs.arbitrum.io/how-arbitrum-works/l2-to-l1-messaging">L2-to-L1 Messages</a>).
+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 <em>even during a dispute</em> via trustless fast "liquidity exit" applications. See <a href="https://developer.arbitrum.io/arbos/l2-to-l1-messaging">L2-to-L1 Messages</a>).
 </p>
 
 <p>
@@ -290,17 +290,17 @@ In any case, we could also analyze why would someone use this mechanism having a
 </p>
 
 
-### What is the difference between an L2 block and an assertion?
+### What is the difference between an child chain block and an assertion?
 <p>
-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 <a href="https://docs.arbitrum.io/for-devs/concepts/differences-between-arbitrum-ethereum/rpc-methods#blocks">see here</a>.
+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 <a href="https://docs.arbitrum.io/for-devs/concepts/differences-between-arbitrum-ethereum/rpc-methods#blocks">see here</a>.
 </p>
 
 <p>
-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 <a href="https://github.com/OffchainLabs/nitro/blob/2436da3fbf339ce72b02f761254aff5b86efafac/contracts/src/rollup/Node.sol#L7">here</a>.
+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 <a href="https://github.com/OffchainLabs/nitro/blob/2436da3fbf339ce72b02f761254aff5b86efafac/contracts/src/rollup/Node.sol#L7">here</a>.
 </p>
 
 <p>
-These assertions are also generated by validators, but they are appended to the L1 chain. Other validators can <a href="https://docs.arbitrum.io/how-arbitrum-works/interactive-fraud-proofs">challenge them</a> 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 <a href="https://docs.arbitrum.io/inside-arbitrum-nitro/#resolving-disputes-using-interactive-fraud-proofs">challenge them</a> 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.
 </p>
 
 <p>