## Background

In the realm of blockchain technology, modular design represent significant advancements, it decouples the various components of traditional blockchains—such as consensus, data availability, and execution—allowing for more specialized and efficient processing. Modular approach is also a paradigm shift from monolithic structures, allowing for a more flexible and efficient system where various components can operate independently yet cohesively. zkRollup, on the other hand, leverage zero-knowledge proofs to roll up multiple transactions into a single proof, which can be verified on the main blockchain, thus enhancing throughput while maintaining data integrity. Despite these innovations, the ecosystem faces challenges, particularly in the lack of modular implementations that can seamlessly connect different components together to boost the go-to-marketing process for developers.

## Introducing ZKCross rollup development kit
To address the challenge of adopting modular zkRollup, ZKCross's has been working on a full function SDK, the SDK includes functions like RPC interfaces, sequencer, executor, services adptor layer. Everyone can easily build a zkRollup by configurate the SDK to boot up a zkc-node.

graph TD
    subgraph ZKCnode [ZKC node]
        Sequencer
        WASMexecutor[Wasm ]
        subgraph AdaptorLayer [Adaptor layer]
            proverAdaptor[prover adaptor]
            daAdaptor[DA adaptor]
            stateAdaptor[State adaptor]
            blockchainAdaptor[blockchain adaptor]
        end
    end
    Sequencer <--> AdaptorLayer
    WASMexecutor <--> AdaptorLayer
    proverAdaptor --> zkWasmProverNetwork[zkWasm prover network]
    daAdaptor --> DataAvailability[Data Availability]
    stateAdaptor --> zkKvDB[zk kvDB]
    blockchainAdaptor --> onchainSettlement[On-chain settlement]
    

The typical interaction between an end user and zkc-node would follow the sequence:
"connect -> play -> prove -> on-chain verify and settlement".

In specific, it is as follows:

* Firstly, the user connects to zkc-node using wallets like MetaMask, OKX Wallet, etc., and optionally deposits assets.
* Then the user can interact with any dApps built and depolyed at zkc-node.
* zkProof will be generated manually triggered by the user or automatically by the zkc-node and posted on-chain for verification.
* After on-chain verification, the user can receive rewards(native assets) from L1 chains directly.

## The desing of ZKC node
### why do we choose to have our own node?

### The challenge we have

## Core components of zkc-node
### ZKC sequencer

The Sequencer is responsible for ordering user requests. It retrieves requests from a mempool, sorts them based on specific policies before get processed, and adds them to the Data Availability (DA) layer in batch.

### WASM exectuor

The WASM Executor can be either the browser or the ZKCross node. It is responsible for loading the Wasm binary, parsing requests from the Data Availability (DA) layer, and invoking Wasm functions to perform dApp core logic, generate input and output. It may also need to provide an environment (ENV) for Wasm to access external services, such as the state service.

### Service Adaptor layer

* Prover adaptor
The Prover adaptor is responsible for connecting proving network to generate proofs for the Wasm execution trace and posting them on-chain for verification. These proofs provide cryptographic assurances of the correctness of the execution process, enhancing trust and security. Only verified executions can be marked as finalized.

* DA Adaptor
The Data Availability (DA) layer ensures that all request and proof raw data are available when needed. In zkcross modular solution, there is a DA Adaptor provide adoption for different DA implementations e.g ethereum calldata or third-party DA providers such as Polygon avail.

* State sercice Adaptor

There are other common services exist outside of zkc-node and are passed to WASM modules through host functions as imports. zkc-node provides a standard interface for Wasm dApps to utilize common servers, such as state services for accessing/storing merkle trees and VRF services for generating provably random numbers. This adaptor design makes it easy to plug in new services

* Settlement adaptor

Settlement adaptor is a standard interface to smart contracts depolyed on L1/L2 blockchains. Which make it's eaiser to chose which chain to be used as the settlement layer.
The Settlement contracts will first verify the zkProof posted, ensuring that the hash of the current rule set matches the commitment, and then behave accordingly. Subsequently, callbacks for certain events are generated during the execution, such as rewarding the user with token assets.

## How does each components works towards modularity

As showed in above picture, a request sent by user will first go through the sequencer for ordering before execution. This ensures that requests are processed in the correct sequence, maintaining the integrity of the system. Request information and parameters will be saved in a Data Availability (DA) provider, ensuring that data related to the request is securely stored.

During execution, the system may need to interact with various services to fulfill the request. For example, it may connect with services like the State service to retrieve or store dApp state, and it may utilize a Verifiable Random Function (VRF) service to generate random numbers.

The Prover component will collect the input and output of the execution and then sends these informations to a proving provider, such as the Delphison cloud proving service, which is responsible for generating zero-knowledge proofs (zk proofs). These proofs are cryptographic constructs that allow the system to prove the validity of computations without revealing sensitive data. Once generated, the zk proofs are saved also in DA and posted to the on-chain settlement smart contract for verification.

The on-chain smart contract verifies the zk proofs to ensure the correctness of the computations. If the verification is successful, the smart contract updates the on-chain state accordingly. For example, if there is a settlement involved, such as distributing token rewards to users, the smart contract will execute this action on-chain. This may involve transferring token assets from one account to another, ensuring that rewards are distributed fairly and securely.

## Total cost of using ZKCross
To know the exact cost, lets break down into different parts. Because we are modular design, which means dapp developers can always choose the biggest ecosystem and most cost efficient components to use. With this analysis, it will give you some insights into the total cost could be.
* Sequencing
* WASM contract execution (这块如何计费? wasm还没evm这种不同指令收费的设计,指令数也太多)
* Services
* Data storage
* Proof generation
* On-chain verification

## Advantages
(应该放在前面?)
Turn any web2 app/server provable/web3 for mass adoption. e.g multiplayer game.

## Concluson