Merge pull request #2863 from OffchainLabs/glossary-new-terms

Glossary new terms

Author: anegg0

docs/partials/_glossary-partial.mdx

@@ -154,6 +154,10 @@ An Arbitrum Chain that settles to a [Parent chain](/intro/glossary#parent-chain)
 
 A program running on a user's machine, often in the user's browser, that interacts with contracts on an [Arbitrum chain](/intro/glossary#arbitrum-chain) and provides a user interface.
 
+### Commitment {#commitment}
+
+In the context of Arbitrum, commitments represents a part of a chain's history. Commitments are used during the fraud proof dispute resolution process, where validators create a Merkle commitment to the history between two assertions. This allows them to efficiently narrow down disagreements about the chain state by using Merkle proofs to specific blocks or states within that range[(1)](https://docs.arbitrum.io/how-arbitrum-works/bold/bold-technical-deep-dive).
+
 ### Confirmation {#confirmation}
 
 The decision by an [Arbitrum chain](/intro/glossary#arbitrum-chain) to finalize an assertion as part of the chain's history. Once an [assertion](/intro/glossary#assertion) is confirmed its [Child to parent chain Messages](/intro/glossary#l2-to-l1-message) (e.g., withdrawals) can be executed.
@@ -210,10 +214,6 @@ A step in the [Challenge protocol](/intro/glossary#challenge-protocol) in which
 
 A software application used for transacting with the Ethereum [Blockchain](/intro/glossary#blockchain).
 
-### EVM+ {#evm}
-
-The paradigm introduced by [Stylus](/intro/glossary#stylus) in which Arbitrum's EVM compatibility is preserved while new features and improvements are introduced.
-
 ### Execution claim {#execution-claim}
 
 A cryptographic commitment to the computed state.
@@ -266,6 +266,14 @@ An execution-layer client that defines the Ethereum state transition function an
 
 The equivalent of gas in the [Stylus](/intro/glossary#stylus) vm. Ink is introduced for finer granularity than gas offers since Stylus's operations are considerably cheaper than their EVM analogs.
 
+### L1 {#L1}
+
+L1, or Layer 1, refers to the underlying blockchain responsible for maintaining the integrity of the distributed ledger. In the context of Arbitrum One and Nova, L1 is the main Ethereum blockchain (Mainnet), and Arbitrum operates as a Layer 2 scaling solution built on top of this base layer. However, any EVM-compatible blockchain can be an L1 to an Arbitrum chain.
+
+### L2 {#L2}
+
+An L2, or Layer 2, is a trustless scaling solution built on top of Ethereum's Layer 1 (L1) base protocol. Arbitrum is a Layer 2 protocol that increases scalability and reduces the cost of transactions on Ethereum's Layer 1 without introducing additional trust assumptions. It does that by executing some computation offchain and batch-posting transactions on the underlying Layer 1.
+
 ### L2 Block {#l2-block}
 
 Data structure that represents a group of L2 transactions (analogous to L1 blocks).
@@ -286,6 +294,10 @@ Trustless scaling solutions built on top of Ethereum's [Layer 1 (L1)](/intro/glo
 
 An Arbitrum chain whose core contract reside on an Arbitrum [Layer 2 (L2)](/intro/glossary#layer-2-l2) chain.
 
+### MultiVM {#multivm}
+
+MultiVM refers Arbitrum's ability to support multiple virtual machines (VMs). Specifically, Arbitrum Stylus introduces a WebAssembly (WASM)-based virtual machine alongside the traditional Ethereum Virtual Machine (EVM). This means developers can write smart contracts in languages like Rust, C, or C++ (compiled to WASM) or continue using Solidity for the EVM, and both types of contracts can interact seamlessly on the same chain. This approach preserves EVM compatibility while enabling more efficient execution and access to a broader set of programming languages and libraries[(1)](https://docs.arbitrum.io/stylus/concepts/how-it-works)[(2)](https://docs.arbitrum.io/launch-arbitrum-chain/partials/config-other-language-support).
+
 ### Native Fee Token {#native-fee-token}
 
 An `ERC-20` token used as the native currency for gas fees on an [Arbitrum chain](/intro/glossary#arbitrum-chain) (i.e., as opposed to using Ether). [Arbitrum chains](/intro/glossary#arbitrum-chains) introduced the option for chains to use native fee tokens.
@@ -298,6 +310,10 @@ The initial builders Arbitrum; current contributors to the Arbitrum ecosystem an
 
 Final step in a challenge; a single operation of the Arbitrum VM ([WASM](/intro/glossary#wasm) ) is executed on the underlying chain, and the validity of its state transition is verified.
 
+### Oracle {#oracle}
+
+Oracles are third-party services that provide smart contracts with external information. They act as a bridge between blockchains and the outside world, which expands their functionality by enabling smart contracts to access data beyond their native networks.
+
 ### Outbox {#outbox}
 
 A parent chain contract responsible for tracking [Child to parent chain Message](/intro/glossary#l2-to-l1-message)s, including withdrawals, which can be executed once they are confirmed. The outbox stores a Merkle Root of all outgoing messages.
@@ -314,6 +330,10 @@ Anyone can become a validator by running an Arbitrum node, without permission.
 
 A web application maintained by [Offchain Labs](/intro/glossary#offchain-labs) showcasing the Arbitrum ecosystem; visit it [here](https://portal.arbitrum.io/).
 
+### Precompile {#precompile}
+
+A precompile is a predefined smart contract with a special address that provides specific functionality executed natively by the Arbitrum client, rather than at the EVM bytecode level. Precompiles are used to introduce functions that would be computationally expensive if run in EVM bytecode, or to facilitate interactions between the parent and child chains. Arbitrum supports all Ethereum precompiles and also provides additional precompiles specific to Arbitrum chains, which can be called from smart contracts like regular Solidity functions[(1)](https://docs.arbitrum.io/build-decentralized-apps/precompiles/overview).
+
 ### Predecessor Assertion {#predecessor-assertion}
 
 The last confirmed valid state of the chain.

docs/partials/glossary/_commitment.mdx

@@ -0,0 +1,7 @@
+---
+title: Commitment
+key: commitment
+titleforSort: Commitment
+---
+
+In the context of Arbitrum, commitments represents a part of a chain's history. Commitments are used during the fraud proof dispute resolution process, where validators create a Merkle commitment to the history between two assertions. This allows them to efficiently narrow down disagreements about the chain state by using Merkle proofs to specific blocks or states within that range[(1)](https://docs.arbitrum.io/how-arbitrum-works/bold/bold-technical-deep-dive).

docs/partials/glossary/_evm.mdx

@@ -0,0 +1,7 @@
+---
+title: L1
+key: L1
+titleforSort: L1
+---
+
+L1, or Layer 1, refers to the underlying blockchain responsible for maintaining the integrity of the distributed ledger. In the context of Arbitrum One and Nova, L1 is the main Ethereum blockchain (Mainnet), and Arbitrum operates as a Layer 2 scaling solution built on top of this base layer. However, any EVM-compatible blockchain can be an L1 to an Arbitrum chain.

docs/partials/glossary/_l1.mdx

@@ -0,0 +1,7 @@
+---
+title: L2
+key: L2
+titleforSort: L2
+---
+
+An L2, or Layer 2, is a trustless scaling solution built on top of Ethereum's Layer 1 (L1) base protocol. Arbitrum is a Layer 2 protocol that increases scalability and reduces the cost of transactions on Ethereum's Layer 1 without introducing additional trust assumptions. It does that by executing some computation offchain and batch-posting transactions on the underlying Layer 1.

docs/partials/glossary/_l2.mdx

@@ -0,0 +1,7 @@
+---
+title: MultiVM
+key: multivm
+titleforSort: MultiVM
+---
+
+MultiVM refers Arbitrum's ability to support multiple virtual machines (VMs). Specifically, Arbitrum Stylus introduces a WebAssembly (WASM)-based virtual machine alongside the traditional Ethereum Virtual Machine (EVM). This means developers can write smart contracts in languages like Rust, C, or C++ (compiled to WASM) or continue using Solidity for the EVM, and both types of contracts can interact seamlessly on the same chain. This approach preserves EVM compatibility while enabling more efficient execution and access to a broader set of programming languages and libraries[(1)](https://docs.arbitrum.io/stylus/concepts/how-it-works)[(2)](https://docs.arbitrum.io/launch-arbitrum-chain/partials/config-other-language-support).

docs/partials/glossary/_multivm.mdx

@@ -0,0 +1,7 @@
+---
+title: Oracle
+key: oracle
+titleforSort: Oracle
+---
+
+Oracles are third-party services that provide smart contracts with external information. They act as a bridge between blockchains and the outside world, which expands their functionality by enabling smart contracts to access data beyond their native networks.

docs/partials/glossary/_oracle.mdx

@@ -0,0 +1,7 @@
+---
+title: Precompile
+key: precompile
+titleforSort: Precompile
+---
+
+A precompile is a predefined smart contract with a special address that provides specific functionality executed natively by the Arbitrum client, rather than at the EVM bytecode level. Precompiles are used to introduce functions that would be computationally expensive if run in EVM bytecode, or to facilitate interactions between the parent and child chains. Arbitrum supports all Ethereum precompiles and also provides additional precompiles specific to Arbitrum chains, which can be called from smart contracts like regular Solidity functions[(1)](https://docs.arbitrum.io/build-decentralized-apps/precompiles/overview).

docs/partials/glossary/_precompile.mdx

@@ -139,6 +139,10 @@
     "title": "Client",
     "text": "<p>A program running on a user&#39;s machine, often in the user&#39;s browser, that interacts with contracts on an <a href=\"/intro/glossary#arbitrum-chain\">Arbitrum chain</a> and provides a user interface.</p>\n"
   },
+  "commitment": {
+    "title": "Commitment",
+    "text": "<p>In the context of Arbitrum, commitments represents a part of a chain&#39;s history. Commitments are used during the fraud proof dispute resolution process, where validators create a Merkle commitment to the history between two assertions. This allows them to efficiently narrow down disagreements about the chain state by using Merkle proofs to specific blocks or states within that range<a href=\"https://docs.arbitrum.io/how-arbitrum-works/bold/bold-technical-deep-dive\">(1)</a>.</p>\n"
+  },
   "confirmation": {
     "title": "Confirmation",
     "text": "<p>The decision by an <a href=\"/intro/glossary#arbitrum-chain\">Arbitrum chain</a> to finalize an assertion as part of the chain&#39;s history. Once an <a href=\"/intro/glossary#assertion\">assertion</a> is confirmed its <a href=\"/intro/glossary#l2-to-l1-message\">Child to parent chain Messages</a> (e.g., withdrawals) can be executed.</p>\n"
@@ -187,10 +191,6 @@
     "title": "Ethereum Wallet",
     "text": "<p>A software application used for transacting with the Ethereum <a href=\"/intro/glossary#blockchain\">Blockchain</a>.</p>\n"
   },
-  "evm": {
-    "title": "EVM+",
-    "text": "<p>The paradigm introduced by <a href=\"/intro/glossary#stylus\">Stylus</a> in which Arbitrum&#39;s EVM compatibility is preserved while new features and improvements are introduced.</p>\n"
-  },
   "execution-claim": {
     "title": "Execution claim",
     "text": "<p>A cryptographic commitment to the computed state.</p>\n"
@@ -243,6 +243,14 @@
     "title": "Ink",
     "text": "<p>The equivalent of gas in the <a href=\"/intro/glossary#stylus\">Stylus</a> vm. Ink is introduced for finer granularity than gas offers since Stylus&#39;s operations are considerably cheaper than their EVM analogs.</p>\n"
   },
+  "L1": {
+    "title": "L1",
+    "text": "<p>L1, or Layer 1, refers to the underlying blockchain responsible for maintaining the integrity of the distributed ledger. In the context of Arbitrum One and Nova, L1 is the main Ethereum blockchain (Mainnet), and Arbitrum operates as a Layer 2 scaling solution built on top of this base layer. However, any EVM-compatible blockchain can be an L1 to an Arbitrum chain.</p>\n"
+  },
+  "L2": {
+    "title": "L2",
+    "text": "<p>An L2, or Layer 2, is a trustless scaling solution built on top of Ethereum&#39;s Layer 1 (L1) base protocol. Arbitrum is a Layer 2 protocol that increases scalability and reduces the cost of transactions on Ethereum&#39;s Layer 1 without introducing additional trust assumptions. It does that by executing some computation offchain and batch-posting transactions on the underlying Layer 1.</p>\n"
+  },
   "l2-block": {
     "title": "L2 Block",
     "text": "<p>Data structure that represents a group of L2 transactions (analogous to L1 blocks).</p>\n"
@@ -263,6 +271,10 @@
     "title": "Layer 3 (L3)",
     "text": "<p>An Arbitrum chain whose core contract reside on an Arbitrum <a href=\"/intro/glossary#layer-2-l2\">Layer 2 (L2)</a> chain.</p>\n"
   },
+  "multivm": {
+    "title": "MultiVM",
+    "text": "<p>MultiVM refers Arbitrum&#39;s ability to support multiple virtual machines (VMs). Specifically, Arbitrum Stylus introduces a WebAssembly (WASM)-based virtual machine alongside the traditional Ethereum Virtual Machine (EVM). This means developers can write smart contracts in languages like Rust, C, or C++ (compiled to WASM) or continue using Solidity for the EVM, and both types of contracts can interact seamlessly on the same chain. This approach preserves EVM compatibility while enabling more efficient execution and access to a broader set of programming languages and libraries<a href=\"https://docs.arbitrum.io/stylus/concepts/how-it-works\">(1)</a><a href=\"https://docs.arbitrum.io/launch-arbitrum-chain/partials/config-other-language-support\">(2)</a>.</p>\n"
+  },
   "native-fee-token": {
     "title": "Native Fee Token",
     "text": "<p>An <code>ERC-20</code> token used as the native currency for gas fees on an <a href=\"/intro/glossary#arbitrum-chain\">Arbitrum chain</a> (i.e., as opposed to using Ether). <a href=\"/intro/glossary#arbitrum-chains\">Arbitrum chains</a> introduced the option for chains to use native fee tokens.</p>\n"
@@ -275,6 +287,10 @@
     "title": "One Step Proof",
     "text": "<p>Final step in a challenge; a single operation of the Arbitrum VM (<a href=\"/intro/glossary#wasm\">WASM</a> ) is executed on the underlying chain, and the validity of its state transition is verified.</p>\n"
   },
+  "oracle": {
+    "title": "Oracle",
+    "text": "<p>Oracles are third-party services that provide smart contracts with external information. They act as a bridge between blockchains and the outside world, which expands their functionality by enabling smart contracts to access data beyond their native networks.</p>\n"
+  },
   "outbox": {
     "title": "Outbox",
     "text": "<p>A parent chain contract responsible for tracking <a href=\"/intro/glossary#l2-to-l1-message\">Child to parent chain Message</a>s, including withdrawals, which can be executed once they are confirmed. The outbox stores a Merkle Root of all outgoing messages.</p>\n"
@@ -291,6 +307,10 @@
     "title": "Portal",
     "text": "<p>A web application maintained by <a href=\"/intro/glossary#offchain-labs\">Offchain Labs</a> showcasing the Arbitrum ecosystem; visit it <a href=\"https://portal.arbitrum.io/\">here</a>.</p>\n"
   },
+  "precompile": {
+    "title": "Precompile",
+    "text": "<p>A precompile is a predefined smart contract with a special address that provides specific functionality executed natively by the Arbitrum client, rather than at the EVM bytecode level. Precompiles are used to introduce functions that would be computationally expensive if run in EVM bytecode, or to facilitate interactions between the parent and child chains. Arbitrum supports all Ethereum precompiles and also provides additional precompiles specific to Arbitrum chains, which can be called from smart contracts like regular Solidity functions<a href=\"https://docs.arbitrum.io/build-decentralized-apps/precompiles/overview\">(1)</a>.</p>\n"
+  },
   "predecessor-assertion": {
     "title": "Predecessor Assertion",
     "text": "<p>The last confirmed valid state of the chain.</p>\n"