# Goal

A scalable and persistent L2 DA network with native BLOB TX support, which aims to serve as:

- **Alt-DA** layer for L2 rollup chains
- **dStorage** chain for fully-on-chain Dapp projects based on BLOBs

# Motivation

In align with danksharding, yet to serve as scale and persistency solution, and can be extended to fit DApp dStorage needs

# What

A L2 rollup chain with [muliple Sequencers](https://stack.optimism.io/docs/understand/landscape/#multiple-sequencer-proposed) that persist BLOBs with similar [DAS+DAC](https://hackmd.io/@vbuterin/sharding_proposal) mechanisms introducted by [Danksharding](https://ethereum.org/en/roadmap/danksharding/).

Currently there is only a single Sequencer in OP Chain *Sequencing Layer*, which is reponsible for:
- Producing L2 Blocks
- Collect and publish L2 Tx bundles (aka L2 Blocks) to L1

OP Stack is planning to extend its *Sequencing Layer* to [muliple Sequencers](https://stack.optimism.io/docs/understand/landscape/#multiple-sequencer-proposed). *Crust DA* brings it one step furture to allow *Sequencers* to permanently persist BLOBs leveraging the same data sharding technologies of L1:
- **Persistency**: use *DAS* for proof of custody of BLOBs
- **Scalability**: use *DAC* for data sharding

Also, some economical incentive mechanisms will be introduced:
- **GPOS**: Sequencers stakes goveranance token like *$CRU*, which will be slashed if they fail to store BLOBs they claim to
- **Storage Fees**: Users pay L2 TX fees using native *$ETH*, which will be splitted to be used as:
- *Gas fees* to rollup *Crust DA* L2 TX to L1
- *Storage fees* to pay to Sequencers for BLOB storage

# Design

The whole Crust DA protocol consists of three levels:
- **Core Protocol**: The optimistic rollup protocol that makes *Crust DA* a canonical rollup chain, plus some additional protocols to permanently store self-produced BLOBs in *Sequencing Layer*.
- **Peripheral Protocol**: BLOB TX support and a Plasma Protocol to guarantee attached BLOB data storage
- **Auxiliary Protocol**: A set of application level infrastructure and toolset to support large sized dStorage based on BLOBs

## Core Protocol

At the core, *Crust DA* is **a canonical L2 rollup chain** (imagine it as an OP Chain built with OP Stack), with some novel designs like:

- *Sequencing Layer* is extended from single Sequencer to multiple Sequencers
- Sequencers are incentived to store BLOBs in a permanant scalable manner
- L2 TXs are rolled up to L1 as BLOBs as other L2 rollup chains do, but in addition to that, BLOBs are also persisted to *Sequencing Layer* for permanant storage
- For *fraud proof*, *Validators* could download state data from L1, or optionally from *Sequencing Layer* especially after rollup BLOBs expire in L1 beacon nodes

## Peripheral Protocol

**A Plasma Protocl for Blob Storage**

**[BLOB TX](https://notes.ethereum.org/@vbuterin/blob_transactions)** was initially introduced by [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) to scall massive L2 chains rolling up to L1, and is intended to be supported in L1 only. *Crust DA* innovates by directly supporting BLOB TX in *Crust DA* network, and designs a *Plasma Protocol* to guarantee BLOB storage.

### Components

- **Plasma Contract**: Deployed on L1 as part of *Plasma Protocol*
- **BLOB Storage Supervisor**: A new role of nodes in *Crust DA* to supervise BLOB storage (posted via BLOB TX) and initialize *BLOB Storage Challenge* if necessary

### Crust Plasma Protocol Overview

- User posts a BLOB TX to *Crust DA*, similar to how user posts a BLOB TX to L1
- A Sequencer is selected from *Sequencing Layer* to produce L2 block, and rollup L2 TX bundles to L1 (also in form of BLOB TX, of course), which includes the BLOB TX posted by user
- The Sequencer detects that a BLOB is attached to one of the bundled TXs. The Sequencer will then store the BLOB to *Sequencing Layer*, and post the BLOB commiment to L1 *Plasma Protocol*
- Supervisor monitors all BLOB TXs posted to *Crust DA*. If no BLOB commitment is detected in *Plasma Protocol*, it starts a *BLOB Storage Challenge*
- Once a *BLOB Storage Challenge* is started, the Sequencer must post the attached BLOB to L1 *Plasma Protocol*, otherwise the BLOB is discarded from *Crust DA*, and that BLOB TX is set to *failed*

## Auxiliary Protocol for dStorage

The idea is to split large sized file or folders to BLOBs and organize them as a **Merkle BLOB Tree**. The Merkle Tree root hash will be used as *storage receipt* of the file.

### Components

- **dStorage Contract**: Deployed on *Crust DA*, tracking all storage orders
- **dStorage.js Toolkit**: A toolkit to faciliate file storage and download
- *Storage*: Split file to BLOBs, store each BLOB to *Crust DA* via BLOB TX, and post *storage receipt* to *dStorage Contract*
- *Download*: Download whole file given a file's *storage receipt*
- **Retrieval Gateway**
- *File Download*
- *Dapp Rendering*
- **Browser Extension**: Similar to *Retrieval Gateway*, but in the form of brwoser extension

# Alt-DA Scenario

Rollup chains could use *Crust DA* as an alternative DA layer in two ways:
- Rollup to *Crust DA* with *calldata*
- Rollup to *Crust DA* with EIP-4844 BLOB TX

## Rollup with calldata

1. *Rollup Chain* deploys rollup contract in *Crust DA*
2. *Rollup Chain* rollup to *Crust DA* by submitting their L2 TXs as *calldata*
3. *Crust DA* further rollup these *rollup transactions* to L1, using EIP-4844 BLOB TXs. In the meanwhile, the BLOBs are persistened in the *Sequencing Layer* complementarily.

In this approach, from the *Rollup Chain* perspective, L1 still contains all state data and is the true DA layer. They could still download all necessary data from L1 for *fraud proof*.

## Rollup with Blob TX

1. *Rollup Chain* deploys rollup contract in *Crust DA*
2. *Rollup Chain* rollup to *Crust DA* by submitting their L2 TXs via BLOB TX
3. BLOB TXs are further rolled up to L1 by *Crust DA*. The attached BLOB is persisted in *Crust DA*, and is guaranted to be stored by a carefully designed Plasma Protocol and storage challenge mechanism.

In this approach, *Rollup Chain* gains the maximal gas reduction and throughout improvement, but their validators may need to download state data from both L1 and *Crust DA* for *fraud proof*.

# Fully-on-Chain Dapp Scenario

- **Smart Contract**: Dapp smart contracts could be deployed in L1, *Crust DA*, other L2 chain, or even sidechains, depending on their need.
- **Static Websites**: Static websites could be deployed to *Crust DA* and loaded with provided infrastructure and toolset
- **UGC (User Generated Content)**: Could also be stored to *Crust DA*

# dStorage Scenario

Straightforward.

# Rationals

**Self-produced BLOBs are already stored in Crust DA, why still submit to L1?**

To make *Crust DA* a canonical rollup chain, and keep same level of security to nowdays rollups

**Why choose Crust DA over L1**

- BLOBs are permantly stored
- Gas fee reduction & Scalability

**Why choose Crust DA over Celestia**

- BLOB TX interface
- Rollup fees could be paid in native $ETH without introducing any additional bridges

**Why choose Crust DA over Arweave**

- EVM compatible
- Could pay storage fees with native $ETH