Merge branch 'master' into Orbit-V3

Author: pete-vielhaber

arbitrum-docs/bold/concepts/bold-technical-deep-dive.mdx

@@ -85,8 +85,8 @@ We'll address any remaining dependencies as we go.
   - People who run Ethereum validator nodes[^3] can earn `$ETH` for processing and validating transactions on behalf of users and dApps.
   - These transactions can be expensive when the network is under heavy load.
 - **Arbitrum**
-  - Arbitrum is a suite of L2 scaling solutions for dApp developers.
-  - <a data-quicklook-from="arbitrum-one">Arbitrum One</a> is an L2 chain that implements the
+  - Arbitrum is a suite of child chain scaling solutions for dApp developers.
+  - <a data-quicklook-from="arbitrum-one">Arbitrum One</a> is a child chain that implements the
     <a data-quicklook-from="arbitrum-rollup-protocol">Arbitrum Rollup protocol</a>.
   - You can use Arbitrum One to build user-friendly dApps with high throughput, low latency, and low transaction costs while inheriting Ethereum's high-security standards[^4].
 
@@ -401,16 +401,16 @@ Click Metamask's network selector dropdown, and then click the `Add Network` but
 
 As we interact with the cupcake vending machine, we'll use Metamask's network selector dropdown to determine which network our cupcake transactions are sent to.
 
-Next, let's deposit some `$ETH` into the wallet corresponding to the private key we added to Remix. At the time of this quickstart's writing, the easiest way to acquire `$ETH` is to bridge Sepolia `$ETH` from Ethereum's L1 Sepolia network to Arbitrum's L2 Sepolia network:
+Next, let's deposit some `$ETH` into the wallet corresponding to the private key we added to Remix. At the time of this quickstart's writing, the easiest way to acquire `$ETH` is to bridge Sepolia `$ETH` from Ethereum's parent chain Sepolia network to Arbitrum's child chain Sepolia network:
 
-1. Use an L1 Sepolia `$ETH` faucet like [sepoliafaucet.com](https://sepoliafaucet.com/) to acquire some testnet `$ETH` on L1 Sepolia.
-2. Bridge your L1 Sepolia `$ETH` into Arbitrum L2 using [the Arbitrum bridge](https://bridge.arbitrum.io/).
+1. Use a parent chain Sepolia `$ETH` faucet like [sepoliafaucet.com](https://sepoliafaucet.com/) to acquire some testnet `$ETH` on parent chain Sepolia.
+2. Bridge your parent chain Sepolia `$ETH` into Arbitrum child chain using [the Arbitrum bridge](https://bridge.arbitrum.io/).
 
 Once you've acquired some `$ETH`, you'll be able to deploy your smart contract to Arbitrum's Sepolia testnet by issuing the following command:
 
 This tells remix to deploy the compiled smart contract through the RPC endpoint corresponding to `Arbitrum Sepolia` in MetaMask (MetaMask uses [INFURA](https://www.infura.io)'s nodes as endpoints)
 
-Congratulations! You've just deployed **business logic and data** to Arbitrum Sepolia. This logic and data will be hashed and submitted within a transaction to Ethereum's L1 Sepolia network, and then it will be mirrored across all nodes in the Sepolia network[^6].
+Congratulations! You've just deployed **business logic and data** to Arbitrum Sepolia. This logic and data will be hashed and submitted within a transaction to Ethereum's parent chian Sepolia network, and then it will be mirrored across all nodes in the Sepolia network[^6].
 
 To view your smart contract in a blockchain explorer, visit `https://sepolia.arbiscan.io/address/0x...B3`, but replace the `0x...B3` part of the URL with the full address of your deployed smart contract.
 
@@ -421,7 +421,7 @@ Select `Arbitrum Sepolia` from Metamask's dropdown, paste your contract address
 The final step is deploying our Cupcake machine to a production network, such as Ethereum, Arbitrum One, or Arbitrum Nitro.
 The good news is: deploying a smart contract in production is exactly the same as for Sepolia Testnet.
 The harder news: it will cost real money, this time. If you deploy on Ethereum, the fees can be significant and the transaction confirmation time 12 seconds on average.
-Arbitrum, a Layer2, reduces these costs about 10X and a confirmation time in the same order while maintaining a similar level of security and decentralization.
+Arbitrum, a child chain, reduces these costs about 10X and a confirmation time in the same order while maintaining a similar level of security and decentralization.
 
 ### Summary
 
@@ -453,8 +453,8 @@ If you have any questions or feedback, reach out to us on [Discord](https://disc
 | [Alchemy University](https://www.alchemy.com/university)      | Online education platform for blockchain and web3 development courses                          |
 
 [^1]: The vending machine example was inspired by [Ethereum.org's "Introduction to Smart Contracts"](https://ethereum.org/en/developers/docs/smart-contracts/), which was inspired by [Nick Szabo's "From vending machines to smart contracts"](http://unenumerated.blogspot.com/2006/12/from-vending-machines-to-smart.html).
-[^2]: Although application front-ends are usually hosted by centralized services, smart contracts allow the underlying logic and data to be partially or fully decentralized. These smart contracts are hosted and executed by Ethereum's public, decentralized network of nodes. Arbitrum has its own network of nodes that use advanced cryptography techniques to "batch process" Ethereum transactions and then submit them to Ethereum L1, which significantly reduces the cost of using Ethereum. All without requiring developers to compromise on security or decentralization.
+[^2]: Although application front-ends are usually hosted by centralized services, smart contracts allow the underlying logic and data to be partially or fully decentralized. These smart contracts are hosted and executed by Ethereum's public, decentralized network of nodes. Arbitrum has its own network of nodes that use advanced cryptography techniques to "batch process" Ethereum transactions and then submit them to the Ethereum parent chain, which significantly reduces the cost of using Ethereum. All without requiring developers to compromise on security or decentralization.
 [^3]: There are multiple types of Ethereum nodes. The ones that earn `$ETH` for processing and validating transactions are called _validators_. See [Nodes and Networks](https://docs.prylabs.network/docs/concepts/nodes-networks) for a beginner-friendly introduction to Ethereum's node types.
 [^4]: When our `VendingMachine` contract is deployed to Ethereum, it'll be hosted by Ethereum's decentralized network of nodes. Generally speaking, we won't be able to modify the contract's code after it's deployed.
 [^5]: To learn more about how Ethereum wallets work, see [Ethereum.org's introduction to Ethereum wallets](https://ethereum.org/en/wallets/).
-[^6]: Visit the [Gentle Introduction to Arbitrum](../intro/intro.mdx) for a beginner-friendly introduction to Arbitrum's rollup protocol.
+[^6]: Visit the [Gentle Introduction to Arbitrum](../intro/intro.mdx) for a beginner-friendly introduction to Arbitrum's Rollup protocol.

arbitrum-docs/build-decentralized-apps/01-quickstart-solidity-remix.mdx

@@ -15,13 +15,13 @@ This how-to is intended for users and developers interested in understanding how
 
 ## Skip the formula, focus on practical know-how
 
-Before diving into the specifics and the formula, if you're looking for a practical way to estimate gas for your transaction, you can rely on the standard gas estimation process. This can be achieved by calling an Arbitrum node's `eth_estimateGas`, which provides a value (gas limit) that should sufficiently cover the entire transaction fee at the specified L2 gas price.
+Before diving into the specifics and the formula, if you're looking for a practical way to estimate gas for your transaction, you can rely on the standard gas estimation process. This can be achieved by calling an Arbitrum node's `eth_estimateGas`, which provides a value (gas limit) that should sufficiently cover the entire transaction fee at the specified child chain gas price.
 
-Multiplying the value obtained from `eth_estimateGas` by the L2 gas price will give you the total amount of Ether required for the transaction to be successful. It's important to note that, for a specific operation, the result of `eth_estimateGas` value may vary over time due to fluctuations in the L1 calldata price, see below to learn why!
+Multiplying the value obtained from `eth_estimateGas` by the child chain gas price will give you the total amount of Ether required for the transaction to be successful. It's important to note that, for a specific operation, the result of `eth_estimateGas` value may vary over time due to fluctuations in the parent chain calldata price, see below to learn why!
 
-Alternatively, to obtain the gas limit for your transaction, you can call `NodeInterface.gasEstimateComponents()` and then use the first result, which is `gasEstimate`. Next, to find the total cost, you need to multiply this amount by the L2 gas price, which is available in the third result, `baseFee`.
+Alternatively, to obtain the gas limit for your transaction, you can call `NodeInterface.gasEstimateComponents()` and then use the first result, which is `gasEstimate`. Next, to find the total cost, you need to multiply this amount by the child chain gas price, which is available in the third result, `baseFee`.
 
-Note that when working with L1 to L2 messages (also known as [retryable tickets](/how-arbitrum-works/10-l1-to-l2-messaging.mdx)), you can use the function [L1ToL2MessageGasEstimator.estimateAll()](https://github.com/OffchainLabs/arbitrum-sdk/blob/main/src/lib/message/L1ToL2MessageGasEstimator.ts#L215) of the Arbitrum SDK or [NodeInterface.estimateRetryableTicket()](https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.4.0@@/nodeInterface/NodeInterface.go#L120) to get all the gas information needed to send a successful transaction.
+Note that when working with parent to child chain messages (also known as [retryable tickets](/how-arbitrum-works/10-l1-to-l2-messaging.mdx)), you can use the function [L1ToL2MessageGasEstimator.estimateAll()](https://github.com/OffchainLabs/arbitrum-sdk/blob/main/src/lib/message/L1ToL2MessageGasEstimator.ts#L215) of the Arbitrum SDK or [NodeInterface.estimateRetryableTicket()](https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.4.0@@/nodeInterface/NodeInterface.go#L120) to get all the gas information needed to send a successful transaction.
 
 ## Breaking down the formula
 
@@ -35,24 +35,24 @@ As explained in the Medium article, the transaction fees to pay at any given mom
 Transaction fees (TXFEES) = L2 Gas Price (P) * Gas Limit (G)
 ```
 
-This Gas Limit includes the gas of the L2 computation and an additional buffer to cover the L1 gas to be paid by the Sequencer when [posting the batch including this transaction on L1](/how-arbitrum-works/03-sequencer.mdx).
+This Gas Limit includes the gas of the child chain computation and an additional buffer to cover the parent chain gas to be paid by the Sequencer when [posting the batch including this transaction on the parent chain](/how-arbitrum-works/03-sequencer.mdx).
 
 ```
 Gas Limit (G) = Gas used on L2 (L2G) + Extra Buffer for L1 cost (B)
 ```
 
-This buffer takes into account the cost of posting the transaction, batched and compressed, on L1. The L1 estimated posting cost is calculated by multiplying these two values:
+This buffer takes into account the cost of posting the transaction, batched and compressed, on the parent chain. The parent chain estimated posting cost is calculated by multiplying these two values:
 
 - L1S, which estimates the amount of data the transaction will take up in the batch by compressing the transaction with Brotli.
-- L1P, which is the L2's estimated view of the current L1's price of data (per byte), which the L2 dynamically adjusts over time.
+- L1P, which is the L2's estimated view of the current parent chain's price of data (per byte), which the child chain dynamically adjusts over time.
 
 More information is available [in this page](/how-arbitrum-works/09-gas-fees.mdx).
 
 ```
 L1 Estimated Cost (L1C) = L1 price per byte of data (L1P) * Size of data to be posted in bytes (L1S)
 ```
 
-To calculate the buffer, that estimated cost is divided by the L2 Gas Price.
+To calculate the buffer, that estimated cost is divided by the child chain Gas Price.
 
 ```
 Extra Buffer (B) = L1 Estimated Cost (L1C) / L2 Gas Price (P)
@@ -70,20 +70,22 @@ We'll use one resource available in Arbitrum: the [NodeInterface](/build-decentr
 
 - P (L2 Gas Price) ⇒ Price to pay for each gas unit. It starts at @@arbOneGasFloorGwei=0.01@@ gwei on Arbitrum One (@@novaGasFloorGwei=0.01@@ gwei on Arbitrum Nova) and can increase depending on the demand for network resources.
   - Call `NodeInterface.GasEstimateComponents()` and get the third element, `baseFee`.
-- L2G (Gas used on L2) ⇒ Gas used to compute the transaction on L2. This does not include the _“posting on L1”_ part of the calculations. The value of L2G will depend on the transaction itself, but having the data of the transaction, we can calculate it as follows:
-  - Call `NodeInterface.GasEstimateComponents()` with the transaction data and subtract the second element (`gasEstimateForL1`, which estimates the L1 part of the fees) from the first (`gasEstimate`, which includes both the L1 and the L2 parts).
-- L1P (L1 estimated price per byte of data) ⇒ Estimated cost of posting 1 byte of data on L1:
+- L2G (Gas used on L2) ⇒ Gas used to compute the transaction on the child chain. This does not include the _“posting on L1”_ part of the calculations. The value of L2G will depend on the transaction itself, but having the data of the transaction, we can calculate it as follows:
+  - Call `NodeInterface.GasEstimateComponents()` with the transaction data and subtract the second element (`gasEstimateForL1`, which estimates the parent chain part of the fees) from the first (`gasEstimate`, which includes both the parent and the child chain parts).
+- L1P (L1 estimated price per byte of data) ⇒ Estimated cost of posting 1 byte of data on the parent chain:
   - Call `NodeInterface.GasEstimateComponents()`, get the fourth element `l1BaseFeeEstimate` and multiply it by 16.
-- L1S (Size of data to be posted on L1, in bytes) ⇒ This will depend on the data of the transaction. Keep in mind that Arbitrum adds a fixed amount to this number to make up for the static part of the transaction, which is also posted on L1 (140 bytes). We can do a small calculation to obtain this value: call `NodeInterface.GasEstimateComponents()` take the second element, `gasEstimateForL1` (this is equivalent to `B` in our formula), multiply it by P and divide it by L1P.
-  - For Arbitrum Nova (AnyTrust), the size of the data is also a fixed value, as only the Data Availability Certificate is posted on L1, [as explained here](/how-arbitrum-works/08-anytrust-protocol.mdx#data-availability-certificates).
+- L1S (Size of data to be posted on L1, in bytes) ⇒ This will depend on the data of the transaction. Keep in mind that Arbitrum adds a fixed amount to this number to make up for the static part of the transaction, which is also posted on the parent chain (140 bytes). We can do a small calculation to obtain this value: call `NodeInterface.GasEstimateComponents()` take the second element, `gasEstimateForL1` (this is equivalent to `B` in our formula), multiply it by P and divide it by L1P.
+  - For Arbitrum Nova (AnyTrust), the size of the data is also a fixed value, as only the Data Availability Certificate is posted on the parent chain, [as explained here](/how-arbitrum-works/08-anytrust-protocol.mdx#data-availability-certificates).
 
-(Note: for L1P and L1S, you can also call `NodeInterface.gasEstimateL1Component()` to get `l1BaseFeeEstimate` and `gasEstimateForL1`)
+:::note
+For L1P and L1S, you can also call `NodeInterface.gasEstimateL1Component()` to get `l1BaseFeeEstimate` and `gasEstimateForL1`
+:::
 
 ## An example of how to apply this formula in your code
 
 Finally, we show an example of how to get the values we just described and how to estimate the gas usage of a transaction in Javascript. We'll use our [SDK](https://github.com/OffchainLabs/arbitrum-sdk) to connect to the `NodeInterface`.
 
-We first instantiate a factory object for the NodeInterface, using two methods from the SDK. `l2Provider` is a regular JSON RPC provider for the L2 network we are using, and `NODE_INTERFACE_ADDRESS` is the addresses that we need to call to access NodeInterface methods in said network.
+We first instantiate a factory object for the NodeInterface, using two methods from the SDK. `l2Provider` is a regular JSON RPC provider for the child chain network we are using, and `NODE_INTERFACE_ADDRESS` is the addresses that we need to call to access NodeInterface methods in said network.
 
 ```ts
 const { NodeInterface__factory } = require("@arbitrum/sdk/dist/lib/abi/factories/NodeInterface__factory");
@@ -115,7 +117,7 @@ const gasEstimateComponents = await nodeInterface.callStatic.gasEstimateComponen
 );
 ```
 
-With this, we can now get the values of the 4 variables we'll use in our formula:
+With this, we can now get the values of the four variables we'll use in our formula:
 
 ```ts
 // Getting useful values for calculating the formula
@@ -138,7 +140,7 @@ const L1P = l1EstimatedPrice;
 const L1S = l1Size;
 ```
 
-And finally, we estimate the transaction fees applying the formula described in the beginning.
+And finally, we estimate the transaction fees applying the formula described in the beginning:
 
 ```ts
 // L1C (L1 Cost) = L1P * L1S