ethereum-optimism · krofax · Jan 17, 2025 · Jan 17, 2025 · Jan 17, 2025 · Jan 17, 2025
@@ -262,46 +262,46 @@ default value is `10`.
   <Tabs.Tab>`OP_BATCHER_NUM_CONFIRMATIONS=10`</Tabs.Tab>
 </Tabs>
 
-### plasma.da-server
+### altda.da-server
 
 HTTP address of a DA Server.
 
 <Tabs items={['Syntax', 'Example', 'Environment Variable']}>
-  <Tabs.Tab>`--plasma.da-server=<value>`</Tabs.Tab>
-  <Tabs.Tab>`--plasma.da-server=`</Tabs.Tab>
-  <Tabs.Tab>`OP_BATCHER_PLASMA_DA_SERVER=`</Tabs.Tab>
+  <Tabs.Tab>`--altda.da-server=<value>`</Tabs.Tab>
+  <Tabs.Tab>`--altda.da-server=`</Tabs.Tab>
+  <Tabs.Tab>`OP_BATCHER_ALTDA_DA_SERVER=`</Tabs.Tab>
 </Tabs>
 
-### plasma.da-service
+### altda.da-service
 
-Use DA service type where commitments are generated by plasma server. The 
+Use DA service type where commitments are generated by altda server. The 
 default value is `false`.
 
 <Tabs items={['Syntax', 'Example', 'Environment Variable']}>
-  <Tabs.Tab>`--plasma.da-service=<value>`</Tabs.Tab>
-  <Tabs.Tab>`--plasma.da-service=false`</Tabs.Tab>
-  <Tabs.Tab>`OP_BATCHER_PLASMA_DA_SERVICE=false`</Tabs.Tab>
+  <Tabs.Tab>`--altda.da-service=<value>`</Tabs.Tab>
+  <Tabs.Tab>`--altda.da-service=false`</Tabs.Tab>
+  <Tabs.Tab>`OP_BATCHER_ALTDA_DA_SERVICE=false`</Tabs.Tab>
 </Tabs>
 
-### plasma.enabled
+### altda.enabled
 
-Enable plasma mode. The default value is `false`.
+Enable altda mode. The default value is `false`.
 
 <Tabs items={['Syntax', 'Example', 'Environment Variable']}>
-  <Tabs.Tab>`--plasma.enabled=<value>`</Tabs.Tab>
-  <Tabs.Tab>`--plasma.enabled=false`</Tabs.Tab>
-  <Tabs.Tab>`OP_BATCHER_PLASMA_ENABLED=false`</Tabs.Tab>
+  <Tabs.Tab>`--altda.enabled=<value>`</Tabs.Tab>
+  <Tabs.Tab>`--altda.enabled=false`</Tabs.Tab>
+  <Tabs.Tab>`OP_BATCHER_ALTDA_ENABLED=false`</Tabs.Tab>
 </Tabs>
 
-### plasma.verify-on-read
+### altda.verify-on-read
 
 Verify input data matches the commitments from the DA storage service. The 
 default value is `true`.
 
 <Tabs items={['Syntax', 'Example', 'Environment Variable']}>
-  <Tabs.Tab>`--plasma.verify-on-read=<value>`</Tabs.Tab>
-  <Tabs.Tab>`--plasma.verify-on-read=true`</Tabs.Tab>
-  <Tabs.Tab>`OP_BATCHER_PLASMA_VERIFY_ON_READ=true`</Tabs.Tab>
+  <Tabs.Tab>`--altda.verify-on-read=<value>`</Tabs.Tab>
+  <Tabs.Tab>`--altda.verify-on-read=true`</Tabs.Tab>
+  <Tabs.Tab>`OP_BATCHER_ALTDA_VERIFY_ON_READ=true`</Tabs.Tab>
 </Tabs>
 
 ### poll-interval

@@ -1007,9 +1007,9 @@ for sustainably low costs. Learn more [here](/stack/beta-features/alt-da-mode).
 
 ***
 
-#### usePlasma
+#### useAltDA
 
-UsePlasma is a flag that indicates if the system is using op-plasma
+UseAltDA is a flag that indicates if the system is using op-alt-da
 
 *   **Type:** bool
 *   **Recommended value:** 
@@ -1040,7 +1040,7 @@ of a data commitment can be challenged.
 *   **Type:** Number
 *   **Default value:** None
 *   **Recommended value:** 
-*   **Notes:** DAChallengeWindow must not be 0 when using plasma mode
+*   **Notes:** DAChallengeWindow must not be 0 when using altda mode
 *   **Standard Config Requirement:** Non-standard feature.
 
 ***
@@ -1053,7 +1053,7 @@ challenge can be resolved.
 *   **Type:** Number
 *   **Default value:** None
 *   **Recommended value:** 
-*   **Notes:** DAChallengeWindow must not be 0 when using plasma mode
+*   **Notes:** DAChallengeWindow must not be 0 when using altda mode
 *   **Standard Config Requirement:** Non-standard feature.
 
 ***
@@ -1092,7 +1092,7 @@ contract.
 *   **Type:** Address
 *   **Default value:** None
 *   **Recommended value:** 
-*   **Notes:** Must not be address(0) when using plasma mode
+*   **Notes:** Must not be address(0) when using altda mode
 *   **Standard Config Requirement:** Non-standard feature. 
 
 ***

@@ -249,7 +249,7 @@ the modular, open source, MIT-licensed development stack that powers the OP Main
 
 Layer 2 blockchain that has been built using the MIT-licensed OP Stack, but is not governed by Optimism's governance or contributing sequencer revenue back to the Collective (and therefore is not on track to become part of the Superchain). This means OP Stack Forks won't necessarily share security or interoperability with OP Chains in the Superchain.
 
-### Plasma Chain
+### Alt-DA Chain
 
 A chain where transaction data is committed to on L1 but not supplied to L1 directly, with a data availability challenge fallback.
 

@@ -31,7 +31,7 @@ Although the Data Availability Challenge (DA Challenge) will be disabled at laun
 Just like with the Rollup configuration of the OP Stack, core contributors are continuously improving the decentralization, security, and cost-effectiveness of Alt-DA Mode. Some of the future features that core contributors are looking to build are:
 
 *   Integration with Fault Proofs
-*   Plasma Data Availability Challenges support for more DA Layers (currently only supports DA Layers with a `keccak256` commitment type)
+*   Alt-DA Challenges support for more DA Layers (currently only supports DA Layers with a `keccak256` commitment type)
 *   DA Bridge integrations (like Celestia Blobstream and Eigen DA Cert Verification)
 *   Increasing the amount of data that can be committed to in a single commitment (potentially with merklization)
 

@@ -50,7 +50,7 @@ Chain operators get the following benefits by using custom gas tokens:
 
 *   can use an L1 ERC-20 token as the custom gas token for L2 OP Stack chain deployment
 *   can use an ERC-20 token on an existing L2 OP Stack chain as the custom gas token for an L3 OP Stack chain deployment
-*   can use custom gas tokens with other configurations of the OP Stack, including Plasma Mode.
+*   can use custom gas tokens with other configurations of the OP Stack, including Alt-DA Mode.
 
 ## Considerations
 

@@ -27,7 +27,7 @@ Withdrawal transactions are how the state of the L2 rollup can be proven to the
 | Opcode       | Solidity Equivalent | Behavior                                                                                                                                                                                                                                                |
 | ------------ | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `COINBASE`   | `block.coinbase`    | Returns the address of the current Sequencer's fee wallet. Effectively the same as Ethereum with the caveat that the value typically does not change from block to block.                                                                               |
-| `PREVRANDAO` | `block.prevrandao`  | Returns the PREVRENDAO (the most recent [RANDAO](https://eips.ethereum.org/EIPS/eip-4399)) value of L1 at the current L1 origin block.                                                                                                                  |
+| `PREVRANDAO` | `block.prevrandao`  | Returns the PREVRANDAO (the most recent [RANDAO](https://eips.ethereum.org/EIPS/eip-4399)) value of L1 at the current L1 origin block.                                                                                                                  |
 | `ORIGIN`     | `tx.origin`         | If the transaction is an L1 ⇒ L2 transaction triggered by a smart contract on L1, then `tx.origin` is set to the [aliased address](#address-aliasing) of the address that triggered the L1 ⇒ L2 transaction. Otherwise, this opcode behaves normally.   |
 | `CALLER`     | `msg.sender`        | If the transaction is an L1 ⇒ L2 transaction triggered by a smart contract on L1, and this is the first call frame (rather than an internal transaction from one contract to another), the same [address aliasing](#address-aliasing) behavior applies. |
 

@@ -87,7 +87,7 @@ sequenceDiagram
 ### Safe initiating messages
 
 Alternatively, a sequencer can be configured to only accept executing messages once the initiating message is in a cross safe block.
-A cross safe block is one that is written to L1, and whose  (direct or indirect, including dependencies of previous blocks in the same chain) are all written to L1.
+A cross safe block is one that is written to L1, and whose dependencies (direct or indirect, including dependencies of previous blocks in the same chain) are all written to L1.
 
 When a block is cross safe, the source sequencer cannot equivocate, and the state will only need to be recalculated if there's an [L1 reorg](https://www.alchemy.com/overviews/what-is-a-reorg#what-happens-to-reorgs-after-the-merge).
 The cost of this enhanced security that it would take longer for a message to pass from one blockchain to the other.

@@ -264,35 +264,35 @@ It is possible to introduce synchronous cross-chain messaging and enable atomic
 
 With the combination of low-latency L2 to L2 message passing as well as shared sequencing, it is possible to perform complex transactions such as cross-chain flash loans. It is even possible to go further and create an EVM abstraction where individual smart contracts (or even individual storage slots) exist on different chains.
 
-### Alt-Data availability layer — Plasma Protocol
+### Alt-Data availability layer — Alt-DA Protocol
 
 #### Pain point:
 
 4.  Posting transactions to the Superchain is not-scalable because the transaction data must be submitted to L1 which has limited capacity.
 
 #### Proposed solution:
 
-Today L1 data availability (DA) does not scale nearly enough to be able to support internet-level scale. However, it is possible to extend the amount of data availability accessible to OP Chains by using a Plasma protocol which enables alternative DA providers to supplement the more limited L1 DA.
+Today L1 data availability (DA) does not scale nearly enough to be able to support internet-level scale. However, it is possible to extend the amount of data availability accessible to OP Chains by using a Alt-DA protocol which enables alternative DA providers to supplement the more limited L1 DA.
 
 <Callout type="info">
-  Plasma chain
+  Alt-DA chain
 
   A chain where transaction data is committed to on L1 but not supplied to L1 directly, with a data availability challenge fallback.
 </Callout>
 
-A generic Plasma protocol is able to scale beyond what is possible on L1 because only the users who are interested in the transaction data will download the Plasma data, whereas on L1 every Ethereum node downloads all of the transaction data on L1. This means that Plasma data is extremely cheap. However, Plasma has a worse security model than L1 — it is possible for Plasma chain data to temporarily become unavailable, meaning users must withdraw from the chain. Note, this security model still guarantees safety of the Plasma chains, just not liveness.
+A generic Alt-DA protocol is able to scale beyond what is possible on L1 because only the users who are interested in the transaction data will download the Alt-DA data, whereas on L1 every Ethereum node downloads all of the transaction data on L1. This means that Alt-DA data is extremely cheap. However, Alt-DA has a worse security model than L1 — it is possible for Alt-DA chain data to temporarily become unavailable, meaning users must withdraw from the chain. Note, this security model still guarantees safety of the Alt-DA chains, just not liveness.
 
-**Plasma protocol overview:**
+**Alt-DA protocol overview:**
 
 *   Data Availability (DA) Providers receive transaction data from users.
-*   DA Providers then hash the transaction data and submit the hash to the Plasma Contract.
+*   DA Providers then hash the transaction data and submit the hash to the Alt-DA Contract.
 *   Once the hash has been submitted, the DA Provider sends a proof to the user which proves inclusion of their transaction data in the hash. The DA Provider can misbehave by withholding the proof, i.e., not sending it to the user.
-*   If the DA Provider does not send the proof to the user, the user may submit a DA challenge. This forces the DA Provider to post the transaction data onchain. If the DA Provider does not submit the proof onchain, the hash is deleted. This ensures the user can always (after the challenge period) sync the Plasma chain.
+*   If the DA Provider does not send the proof to the user, the user may submit a DA challenge. This forces the DA Provider to post the transaction data onchain. If the DA Provider does not submit the proof onchain, the hash is deleted. This ensures the user can always (after the challenge period) sync the Alt-DA chain.
     *   DA challenge periods may be extended in case of heavy L1 congestion.
-*   The user may also submit an L1 transaction to withdraw from the Plasma chain in order to switch their DA Provider.
-*   Settlement of Plasma chains use a near identical Fault Proof System to Rollup chains with the only difference being that additional data is derived from the chain using the hashes that are finalized in the Plasma Contract.
+*   The user may also submit an L1 transaction to withdraw from the Alt-DA chain in order to switch their DA Provider.
+*   Settlement of Alt-DA chains use a near identical Fault Proof System to Rollup chains with the only difference being that additional data is derived from the chain using the hashes that are finalized in the Alt-DA Contract.
 
-Because of the ability for hashes to reduce arbitrary size data into a constant size commitment, and the ability to parallelize transaction data hashing, it is possible to achieve near-perfect horizontal scalability of data commitments using Plasma DA. This means that it is possible to put massively scalable applications such as games or social media on Plasma chains.
+Because of the ability for hashes to reduce arbitrary size data into a constant size commitment, and the ability to parallelize transaction data hashing, it is possible to achieve near-perfect horizontal scalability of data commitments using Alt-DA DA. This means that it is possible to put massively scalable applications such as games or social media on Alt-DA chains.
 
 ### Multi-chain app frameworks
 

@@ -9,6 +9,7 @@ airgap
 Allnodes
 Allocs
 allocs
+altda
 ANDI
 Ankr
 Apeworx
@@ -280,7 +281,7 @@ preinstalls
 Prestate
 prestate
 prestates
-PREVRENDAO
+PREVRANDAO
 PRICEBUMP
 pricebump
 PRICELIMIT