docs: rblock-to-assertion-language-changes

arbitrum-docs/how-arbitrum-works/07-interactive-fraud-proofs.mdx

@@ -13,25 +13,25 @@ Suppose the Rollup chain looks like this:
 
 ![600px-img](../assets/interactive-fraud-proof.svg)
 
-RBlocks 93 and 95 are siblings (they both have 92 as predecessor). Alice is bonded on 93 and Bob is bonded on 95.
+Assertions 93 and 95 are siblings (they both have 92 as predecessor). Alice is bonded on 93 and Bob is bonded on 95.
 
-At this point we know that Alice and Bob disagree about the correctness of <a data-quicklook-from="rblock">RBlock</a> 93, with Alice committed to 93 being correct and Bob committed to 93 being incorrect. (Bob is bonded on 95, and 95 implicitly claims that 92 is the last correct RBlock before it, which implies that 93 must be incorrect.)
+At this point we know that Alice and Bob disagree about the correctness of assertion 93, with Alice committed to 93 being correct and Bob committed to 93 being incorrect. (Bob is bonded on 95, and 95 implicitly claims that 92 is the last correct assertion before it, which implies that 93 must be incorrect.)
 
-Whenever two (or more) proposers are bonded on sibling RBlocks, a challenge begins between all of them. (There can only be one bonder per RBlock, but multiple RBlocks may participate in a challenge.) The Rollup protocol will record and referee the challenge, eventually declaring a winner and confiscating the losers' bonds. This will cause the losers to be removed as proposers.
+Whenever two (or more) proposers are bonded on sibling assertions, a challenge begins between all of them. (There can only be one bonder per assertion, but multiple assertions may participate in a challenge.) The Rollup protocol will record and referee the challenge, eventually declaring a winner and confiscating the losers' bonds. This will cause the losers to be removed as proposers.
 
-The challenge is a game in which two or more parties make moves in an attempt to defend the correctness of RBlocks they (or their allies) have staked on, with an Ethereum contract as the referee. The goal of the system is to determine which RBlock corresponds to the correct execution.
+The challenge is a game in which two or more parties make moves in an attempt to defend the correctness of assertions they (or their allies) have staked on, with an Ethereum contract as the referee. The goal of the system is to determine which assertion corresponds to the correct execution.
 
 The game will operate in two phases: Bisection, followed by one-step proof. Bisection will narrow down the size of the dispute until it is a dispute about just one instruction of execution. Then the one-step proof will determine who is right about that one instruction.
 
 We’ll describe the bisection part of the protocol twice. First, we’ll give a simplified version which is easier to understand. Then we’ll describe some ways in which the real version differs from the simplified one. For an even more thorough explanation, please see the [BoLD research whitepaper](https://arxiv.org/abs/2404.10491).
 
 ## Bisection Protocol: Simplified Version
 
-Alice (or one of her allies - for the sake of brevity we'll refer to this party as Alice) is defending the claim that starting with the state in the predecessor RBlock, the state of the Virtual Machine can advance to the state specified in RBlock A. Once a challenge starts, Alice has to provide a commitment to the entire history of the computation: that is, to the state after each step of execution.
+Alice (or one of her allies - for the sake of brevity we'll refer to this party as Alice) is defending the claim that starting with the state in the predecessor assertion, the state of the Virtual Machine can advance to the state specified in assertion A. Once a challenge starts, Alice has to provide a commitment to the entire history of the computation: that is, to the state after each step of execution.
 
 Alice’s first move requires her to bisect her claims about intermediate states between the beginning (0 instructions executed) and the end (`N` instructions executed). So we require Alice to divide her claim in half, and post the state at the half-way point, after `N/2` instructions have been executed.
 
-Now Alice has effectively bisected her `N`-step <a data-quicklook-from="assertion">Assertion</a> into two (`N/2`)-step assertions. Bob (or one of his allies; for brevity, Bob) needs to do the same for his assertion, also deriving two new (`N/2`)-step assertions. At most one of these will be a "rival" of one of Alice's assertions. Two assertions are "rivals" if they agree on a prefix of the state history to which they commit but disagree on the rest; this is very similar to the concept of "siblings" for RBlocks. Whichever of the two of Alice's assertions now has a rival, Alice will proceed to defend it.
+Now Alice has effectively bisected her `N`-step <a data-quicklook-from="assertion">Assertion</a> into two (`N/2`)-step assertions. Bob (or one of his allies; for brevity, Bob) needs to do the same for his assertion, also deriving two new (`N/2`)-step assertions. At most one of these will be a "rival" of one of Alice's assertions. Two assertions are "rivals" if they agree on a prefix of the state history to which they commit but disagree on the rest; this is very similar to the concept of "siblings" for assertions. Whichever of the two of Alice's assertions now has a rival, Alice will proceed to defend it.
 
 At this point we’re effectively back in the original situation: Alice having made an assertion that Bob disagrees with. But we have cut the size of the assertion in half, from `N` to `N/2`. We can apply the same method again, with Alice bisecting and Bob choosing one of the halves, to reduce the size to `N/4`. And we can continue bisecting, so that after a logarithmic number of rounds Alice and Bob will be disagreeing about a single step of execution. That’s where the bisection phase of the protocol ends, and Alice must make a one-step proof which will be checked by the EthBridge.
 
@@ -53,7 +53,7 @@ If you’re a stickler for mathematical precision, we invite you to read the [Bo
 
 The real bisection protocol is conceptually similar to the simplified one described above, but with several changes that improve efficiency or deal with necessary corner cases. Here is a list of the differences.
 
-**Bisection over L2 blocks, then over "big steps" of many instructions, then over single instructions: **Alice's assertion is over an RBlock, which asserts the result of creating some number of Layer 2 Nitro blocks. Bisection first occurs over these Layer 2 blocks, to narrow the dispute down to a dispute about a single Layer 2 Nitro block. Next, the dispute transforms into a dispute about executing a "big step" of 2^26 instructions (this intermediate level is needed to reduce the workload on the validator). At this point, the dispute transforms into a dispute about a single execution of the <a data-quicklook-from="state-transition-function">State Transition Function</a> or in other words about the execution of a sequence of WAVM instructions. The protocol then executes the recursive bisection sub-protocol again, this time over WAVM instructions, to narrow the dispute to a single instruction. For details about how these "subchallenges" work, see [BoLD: Technical deep dive](/bold/concepts/bold-technical-deep-dive.mdx)
+**Bisection over L2 blocks, then over "big steps" of many instructions, then over single instructions: **Alice's assertion is over an assertion, which asserts the result of creating some number of Layer 2 Nitro blocks. Bisection first occurs over these Layer 2 blocks, to narrow the dispute down to a dispute about a single Layer 2 Nitro block. Next, the dispute transforms into a dispute about executing a "big step" of 2^26 instructions (this intermediate level is needed to reduce the workload on the validator). At this point, the dispute transforms into a dispute about a single execution of the <a data-quicklook-from="state-transition-function">State Transition Function</a> or in other words about the execution of a sequence of WAVM instructions. The protocol then executes the recursive bisection sub-protocol again, this time over WAVM instructions, to narrow the dispute to a single instruction. For details about how these "subchallenges" work, see [BoLD: Technical deep dive](/bold/concepts/bold-technical-deep-dive.mdx)
 **Time Limits:** The protocol can be seen as tracking a timer for each assertion, counting (essentially) how much time has passed while that assertion could be seen as the presumptive winner of the game (that is, the amount of time during which the onus is on parties opposing the assertion to act.) Think of the time allowance as being about a week. Once an assertion's timer reaches this time allowance, it can be confirmed. The time allowance is designed to give the honest parties in the protocol enough time to act, including the time needed to calculate, submit, and process moves, as well as to account for possible censorship on L1.
 
 It should be clear that these changes don’t affect the basic correctness of the challenge protocol. They do, however, improve its efficiency and enable it to handle all of the cases that can come up in practice.

arbitrum-docs/how-arbitrum-works/09-gas-fees.mdx

@@ -97,11 +97,11 @@ Gas estimation for Retryable submissions is possible via the [NodeInterface](/bu
 
 ### The Speed Limit
 
-The security of Nitro chains depends on the assumption that when one <a data-quicklook-from="validator">Validator</a> creates an <a data-quicklook-from="rblock">RBlock</a>, other validators will check it, and respond with a correct RBlock and a <a data-quicklook-from="challenge">Challenge</a> if it is wrong. This requires that the other validators have the time and resources to check each RBlock quickly enough to issue a timely challenge. The Arbitrum protocol takes this into account in setting deadlines for RBlocks.
+The security of Nitro chains depends on the assumption that when one <a data-quicklook-from="validator">Validator</a> creates an assertion, other validators will check it, and respond with a correct assertion and a <a data-quicklook-from="challenge">Challenge</a> if it is wrong. This requires that the other validators have the time and resources to check each assertion quickly enough to issue a timely challenge. The Arbitrum protocol takes this into account in setting deadlines for assertions.
 
-This sets an effective speed limit on execution of a Nitro chain: in the long run the chain cannot make progress faster than a validator can emulate its execution. If RBlocks are published at a rate faster than the speed limit, their deadlines will get farther and farther in the future. Due to the limit, enforced by the Rollup protocol contracts, on how far in the future a deadline can be, this will eventually cause new RBlocks to be slowed down, thereby enforcing the effective speed limit.
+This sets an effective speed limit on execution of a Nitro chain: in the long run the chain cannot make progress faster than a validator can emulate its execution. If assertions are published at a rate faster than the speed limit, their deadlines will get farther and farther in the future. Due to the limit, enforced by the Rollup protocol contracts, on how far in the future a deadline can be, this will eventually cause new assertions to be slowed down, thereby enforcing the effective speed limit.
 
-Being able to set the speed limit accurately depends on being able to estimate the time required to validate an RBlock, with some accuracy. Any uncertainty in estimating validation time will force us to set the speed limit lower, to be safe. And we do not want to set the speed limit lower, so we try to enable accurate estimation.
+Being able to set the speed limit accurately depends on being able to estimate the time required to validate an assertion, with some accuracy. Any uncertainty in estimating validation time will force us to set the speed limit lower, to be safe. And we do not want to set the speed limit lower, so we try to enable accurate estimation.
 
 ## Total fee and gas estimation
 

arbitrum-docs/how-arbitrum-works/11-l2-to-l1-messaging.mdx

@@ -16,15 +16,15 @@ with a few differences.
 
 ### Protocol Flow
 
-Part of the child chain state of an <a data-quicklook-from="arbitrum-chain">Arbitrum chain</a> — and consequently, part of what's asserted in every <a data-quicklook-from="rblock">RBlock</a> — is a Merkle root of all child chain-to-parent chain messages in the chain's history. Upon an asserted RBlock being confirmed (typically ~1 week after its asserted), this Merkle root is posted on parent chain in the `Outbox` contract. The Outbox contract then lets users execute their messages — validating Merkle proofs of inclusion, and tracking which child to parent chain messages have already been spent.
+Part of the child chain state of an <a data-quicklook-from="arbitrum-chain">Arbitrum chain</a> — and consequently, part of every assertion — is a Merkle root of all child chain-to-parent chain messages in the chain's history. Upon an assertion being confirmed (typically ~1 week after its asserted), this Merkle root is posted on parent chain in the `Outbox` contract. The Outbox contract then lets users execute their messages — validating Merkle proofs of inclusion, and tracking which child to parent chain messages have already been spent.
 
 ### Client Flow
 
 From a <a data-quicklook-from="client">Client</a> perspective, a child to parent chain message begins with a call to the child chain [`ArbSys`](/build-decentralized-apps/precompiles/02-reference.mdx#arbsys) precompile contract's `sendTxToL1` method. Once the message is included in an <a data-quicklook-from="assertion">Assertion</a> (typically within ~1 hour) and the assertion is confirmed (typically about ~1 week), any client can execute the message. To do this, the client first retrieves the proof data via a call to the Arbitrum chain's "virtual"/precompile-esque\*\* `NodeInterface` contract's `constructOutboxProof` method. The data returned can then be used in the `Outbox`'s `executeTransaction` method to perform the parent chain execution.
 
 ### Protocol Design Details
 
-An important feature in the design of the Outbox system is that calls to `confirmNode` have constant overhead. Requiring that `confirmNode` only update the constant-sized outgoing message root hash, and that users themselves carry out the final step of execution, achieves this goal; i.e., no matter the number of outgoing messages in the root, or the gas cost of executing them on the parent chain, the cost of confirming nodes remains constant; this ensures that the RBlock <a data-quicklook-from="confirmation">Confirmation</a> processed can't be griefed.
+An important feature in the design of the Outbox system is that calls to `confirmNode` have constant overhead. Requiring that `confirmNode` only update the constant-sized outgoing message root hash, and that users themselves carry out the final step of execution, achieves this goal; i.e., no matter the number of outgoing messages in the root, or the gas cost of executing them on the parent chain, the cost of confirming nodes remains constant; this ensures that the assertion <a data-quicklook-from="confirmation">confirmation</a> processed can't be griefed.
 
 Unlike Retryables, which have an option to provide Ether for automatic child chain execution, outgoing messages can't provide in-protocol automatic parent chain execution, for the simple reason that Ethereum itself doesn't offer scheduled execution affordances. However, application-layer contracts that interact with the Outbox could in principle be built to provide somewhat-analogous "execution market" functionality for outsourcing the final parent chain execution step.
 

arbitrum-docs/launch-orbit-chain/03-deploy-an-orbit-chain/02-deploying-rollup-chain.md

@@ -170,7 +170,7 @@ In this section, we'll provide detailed explanations of the various chain config
 | :-------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `batchPosters`        | Array of batch poster addresses. Batch posters batch and compress transactions on the Orbit chain and transmit them back to the parent chain.                                                                                                                                                                         |
 | `batchPosterManager`  | Account address responsible for managing currently active batch posters. Not mandatory, as these actions can also be taken by the chain owner.                                                                                                                                                                        |
-| `validators`          | Array of <a data-quicklook-from="validator">validator</a> addresses. Validators are responsible for validating the chain state and posting Rollup Blocks (`RBlocks`) back to the parent chain. They also monitor the chain and initiate challenges against potentially faulty RBlocks submitted by other validators.  |
+| `validators`          | Array of <a data-quicklook-from="validator">validator</a> addresses. Validators are responsible for validating the chain state and posting assertions (`RBlocks`) back to the parent chain. They also monitor the chain and initiate challenges against potentially faulty assertions submitted by other validators.  |
 | `nativeToken`         | Determines the token used for paying gas fees on the Orbit chain. It can be set to `ETH` for regular chains or to any `ERC-20` token for **gas fee token network** Orbit chains.                                                                                                                                      |
 | `confirmPeriodBlocks` | Sets the challenge period in terms of blocks, which is the time allowed for validators to dispute or challenge state assertions. On Arbitrum One and Arbitrum Nova, this is currently set to approximately seven days in block count. `confirmPeriodBlocks` is measured in L1 blocks, we recommend a value of `45818` |
 | `baseStake`           | Orbit chain validator nodes must stake a certain amount to incentivize honest participation. The `basestake` parameter specifies this amount.                                                                                                                                                                         |

arbitrum-docs/launch-orbit-chain/how-tos/customize-deployment-configuration.mdx

@@ -61,7 +61,7 @@ The `Base stake` parameter specifies the amount of the stake token (ETH or an ER
 
 If your `Base stake` is low, the barrier to participation will be low, but your chain will be more vulnerable to certain types of attacks.
 
-For example, an Orbit chain with a base stake of 0.01 ETH could be halted by an adversary who can afford to deploy sacrificial validators that maliciously challenge every RBlock submitted to your Orbit chain's base chain.
+For example, an Orbit chain with a base stake of 0.01 ETH could be halted by an adversary who can afford to deploy sacrificial validators that maliciously challenge every assertion submitted to your Orbit chain's base chain.
 
 The malicious challenges would result in slashed Orbit chain validators (one slashed validator per malicious challenge), but from the adversary's perspective, periodic slashing is just the price they have to pay to keep your chain offline.