feat: DOCS-766 RaaS AnyTrust and No-code custom gas token

pages/_meta.json

@@ -24,7 +24,7 @@
   "advanced-tutorials": "Advanced Tutorials",
   "-- Scaling with Ankr": {
     "type": "separator",
-    "title": "Scaling with Ankr"
+    "title": "Scaling with Asphere"
   },
   "scaling-services-overview": "Scaling Services Overview",
   "scaling-services-nocode-deployer": "No-Code Deployer",

pages/scaling-services-nocode-deployer.mdx

@@ -17,7 +17,7 @@ A rollup deployment process consists of the following parts:
 
 First things first, sign in to use the platform's functionality:
 
-  1. Go to the [**Scaling Services**](https://stage-rollup.ankr.com/) platform.
+  1. Go to the [**Scaling Services**](https://rollup.asphere.xyz/) platform.
   2. Click **Sign in > Continue with Google**, and then select an account you'd like to use.
 
 Congrats — you've just signed in to the Scaling Services platform!
@@ -30,14 +30,14 @@ For those signing in for the first time, please enter your basic company informa
 
 To deploy a rollup using a Testnet network, follow these steps:
 
-  1. [Sign in](/scaling-services-nocode-deployer/#sign-in) on the [**Scaling Services**](https://stage-rollup.ankr.com/) platform.
+  1. [Sign in](/scaling-services-nocode-deployer/#sign-in) on the [**Scaling Services**](https://rollup.asphere.xyz/) platform.
   2. In **Navigation**, click **Deploy Rollup** to start a rollup configuration process.
   3. On the **Essentials** tab, select the following rollup parameters, and then click **Next**:
       * **Stack**: [Arbitrum Orbit](/scaling-services-overview/#arbitrum-orbit), [Polygon CDK](/scaling-services-overview/#polygon-cdk), [ZK Stack](/scaling-services-overview/#zk-stack), [OP Stack](/scaling-services-overview/#op-stack).
      <img src="/docs/scale/stack.png" class="responsive-pic" width="700" />
       * **Network**: Select **Testnet** — an option to explore the rollup functionality for free (48 hours).
      <img src="/docs/scale/network.png" class="responsive-pic" width="700" />
-      * **Data Availability Layer**: [Ethereum](/scaling-services-overview/#ethereum), [Celestia](/scaling-services-overview/#celestia), [Eigen Layer](/scaling-services-overview/#eigen-layer), [Avail DA](/scaling-services-overview/#avail-da).
+      * **Data Availability Layer**: [Ethereum](/scaling-services-overview/#ethereum), [Arbitrum AnyTrust](/scaling-services-overview/#arbitrum-anytrust), [Celestia](/scaling-services-overview/#celestia), [Eigen Layer](/scaling-services-overview/#eigen-layer), [Avail DA](/scaling-services-overview/#avail-da).
      <img src="/docs/scale/da-layer.png" class="responsive-pic" width="700" />
   4. On the **Configuration** tab, specify the following parameters, and then click **Next**:
       * **Chain ID**
@@ -75,7 +75,7 @@ To deploy a rollup using a Mainnet network, follow these steps:
       * **Infrastructure Package**: Upon selecting Mainnet, you have to select the Infrastructure to be used for your rollup solution:
         * **Starter Package**: Starter RPC Package, Bridge, Block Explorer, Aggregator, Synchronizer.
         * **Advanced Package**: Pro RPC Package, Bridge, Block Explorer, Aggregator, Synchronizer.
-      * **Data Availability Layer**: [Ethereum](/scaling-services-overview/#ethereum), [Celestia](/scaling-services-overview/#celestia), [Eigen Layer](/scaling-services-overview/#eigen-layer), [Avail DA](/scaling-services-overview/#avail-da).
+      * **Data Availability Layer**: [Ethereum](/scaling-services-overview/#ethereum), [Arbitrum AnyTrust](/scaling-services-overview/#arbitrum-anytrust), [Celestia](/scaling-services-overview/#celestia), [Eigen Layer](/scaling-services-overview/#eigen-layer), [Avail DA](/scaling-services-overview/#avail-da).
      <img src="/docs/scale/da-layer.png" class="responsive-pic" width="700" />
   4. On the **Sequencer** tab, select whether you'd like to have an Ankr-managed sequencer or a self-managed sequencer.
 <img src="/docs/scale/sequencer.png" class="responsive-pic" width="700" />
@@ -85,6 +85,8 @@ To deploy a rollup using a Mainnet network, follow these steps:
       * **Rollup Name**
      <img src="/docs/scale/rollup-name.png" class="responsive-pic" width="500" />
       * **Gas Token**
+        * **ETH**: Use ETH to pay your network's gas fees.
+        * **Custom Gas Token** (If DA layer = AnyTrust): For gas fees, use your [custom ERC-20 token](/scaling-services-nocode-deployer/#custom-gas-token) created and deployed on the network.
      <img src="/docs/scale/gas-token.png" class="responsive-pic" width="500" />
   6. On the **Infrastructure** tab, check the components included in your package, and then click **Confirm**.
 <img src="/docs/scale/mainnet-infra-package.png" class="responsive-pic" width="700" />
@@ -96,6 +98,27 @@ Congrats — you've just configured and deployed your Mainnet rollup!
 
 ---
 
+## Custom Gas Token
+
+Deploying your AnyTrust Orbit chain, you have the option of using a custom gas token, other than ETH, for gas payments on the network. When choosing this option, there are certain requirements that the token needs to comply with.
+
+### Requirements
+
+A custom gas token must meet the following requirements:
+
+  * **ERC-20 Compliance**: The token must conform to the ERC-20 standard.
+  * **Native Deployment**: The token must be natively deployed on the parent chain.
+  * **Native Bridging and Proper Configuration**: During chain deployment, the gas token must be "natively bridged" and configured as the native gas token on the Orbit chain.
+
+**Custom gas token restrictions for ERC-20**:
+
+  * The token must be configured with 18 decimals.
+  * The token can't be rebasing or have a transfer fee.
+  * The token must only be transferable via direct calls to the token address.
+  * The token must only be able to set allowances via direct calls to the token address.
+  * The token must not have a callback on transfer.
+  * Users must not be able to make a transfer to themselves that results in a revert.
+
 ## Arbitrum Bridge Setup
 
 You might be interested in how-tos for the following scenarios:

pages/scaling-services-overview.mdx

@@ -123,6 +123,22 @@ Ethereum serves as a data availability layer for Rollups by ensuring that transa
 
 In essence, Ethereum's structure and consensus mechanisms provide a secure and transparent foundation for rollups by ensuring that data needed to validate transactions is available to all participants, which helps prevent fraudulent activities and enhances the overall security of the network. This system enables Ethereum to support various scaling solutions, including both optimistic and ZK-rollups, by providing a reliable layer for data availability and transaction finality.
 
+#### Arbitrum AnyTrust
+
+AnyTrust is an Arbitrum protocol that manages data availability with a permissioned set of parties known as the Data Availability Committee (DAC). AnyTrust settles transactions securely on the parent chain, relying on a DAC to store and verify data, which requires only two honest parties independent of the committee size. Arbitrum chains that implement the AnyTrust protocol are referred to as Arbitrum AnyTrust chains.
+
+**Key features of AnyTrust**:
+
+  * **Data Availability Committee (DAC)**: The AnyTrust model uses a committee-based approach, where a group of validators, known as the Data Availability Committee (DAC), is responsible for storing and providing access to transaction data. The DAC ensures that the data for each rollup batch is available and can be retrieved by any party who needs to verify or interact with the rollup.
+
+  * **Trust Assumptions:**: AnyTrust’s security model relies on the assumption that at least one committee member will behave honestly and make the data available. This is a less stringent requirement compared to other models that assume a majority of participants are honest. This model allows for faster and more efficient data availability without compromising on security.
+
+  * **Efficiency and Cost Reduction**: By offloading the data availability responsibility to the DAC, Arbitrum significantly reduces the amount of data that needs to be stored and processed on the Ethereum mainnet. This reduction in data load translates to lower gas fees for users and increased throughput for the network.
+
+  * **Fallback Mechanism**: In the unlikely event that the DAC fails to make the data available, Arbitrum includes a fallback mechanism that leverages Ethereum’s mainnet for data storage. This ensures that the system remains secure and operational even in cases of DAC malfunction or collusion.
+
+AnyTrust protocol provides a scalable, efficient, and secure solution to the data availability challenge, making it a cornerstone of Arbitrum’s ability to scale Ethereum effectively.
+
 #### Eigen Layer
 
 EigenDA serves Rollups as their data availability layer by storing rollup transactions until they are finalized. It scales linearly with the number of operators, ensuring security and decentralization. EigenDA operates without a separate token, reducing risks and complexity for Ethereum Layer 2 solutions. It integrates with rollups through a process involving operators, a disperser, and retrievers, facilitating efficient data storage and retrieval within the Ethereum ecosystem

pages/scaling-services-rollups/data-availability/_meta.json

@@ -1,4 +1,5 @@
 {
+  "arbitrum-anytrust": "Arbitrum AnyTrust",
   "avail-da": "Avail DA",
   "celestia": "Celestia",
   "eigenda": "EigenDA",

pages/scaling-services-rollups/data-availability/arbitrum-anytrust.mdx

@@ -0,0 +1,15 @@
+# Arbitrum AnyTrust
+
+AnyTrust is an Arbitrum protocol that manages data availability with a permissioned set of parties known as the Data Availability Committee (DAC). AnyTrust settles transactions securely on the parent chain, relying on a DAC to store and verify data, which requires only two honest parties independent of the committee size. Arbitrum chains that implement the AnyTrust protocol are referred to as Arbitrum AnyTrust chains.
+
+## Key features
+
+  * **Data Availability Committee (DAC)**: The AnyTrust model uses a committee-based approach, where a group of validators, known as the Data Availability Committee (DAC), is responsible for storing and providing access to transaction data. The DAC ensures that the data for each rollup batch is available and can be retrieved by any party who needs to verify or interact with the rollup.
+
+  * **Trust Assumptions:**: AnyTrust’s security model relies on the assumption that at least one committee member will behave honestly and make the data available. This is a less stringent requirement compared to other models that assume a majority of participants are honest. This model allows for faster and more efficient data availability without compromising on security.
+
+  * **Efficiency and Cost Reduction**: By offloading the data availability responsibility to the DAC, Arbitrum significantly reduces the amount of data that needs to be stored and processed on the Ethereum mainnet. This reduction in data load translates to lower gas fees for users and increased throughput for the network.
+
+  * **Fallback Mechanism**: In the unlikely event that the DAC fails to make the data available, Arbitrum includes a fallback mechanism that leverages Ethereum’s mainnet for data storage. This ensures that the system remains secure and operational even in cases of DAC malfunction or collusion.
+
+AnyTrust protocol provides a scalable, efficient, and secure solution to the data availability challenge, making it a cornerstone of Arbitrum’s ability to scale Ethereum effectively.