# Cysic Network Whitepaper

## TL;DR
Cysic Network is a ZK proof layer that delivers high-performance and cost-effective proof generation and verification services to the entire ZK ecosystem. In this article, we present the design of the Cysic Network. Please note that this whitepaper is subject to change without notice.

## Introduction
A Zero-Knowledge Proof (ZKP) is a cryptographic concept that allows one party (the prover) to prove the truth of a statement to another party (the verifier) without revealing any information beyond the validity of the statement itself. This concept was first introduced by Shafi Goldwasser, Silvio Micali, and Charles Rackoff in 1985.

The core idea behind ZKPs is to enable succinct and private verification of claims while protecting the sensitive information of the prover. ZKPs have various applications in the crypto space, such as building private blockchains, improving the throughput of layer-1 blockchains, and enabling communication between separate blockchains. However, ZKPs are not without limitations, as generating proofs can be extremely resource-intensive in terms of both time and energy. Proof generation is often slowed down by the need for numerous complex mathematical operations, such as exponentiation, inversion, polynomial multiplication, and significant data movement. To address these challenges in all proposed ZKP constructions, it is crucial to develop hardware acceleration methods using Graphical Processing Units (GPUs) and Application-Specific Integrated Circuits (ASICs). This high computational demand is reminiscent of Bitcoin (and other altcoin) mining, which has drawn criticism for being centralized and energy-intensive.

Cysic Network aims to provide proof generation and verification services for the entire ZK ecosystem. The goal of the network is to cultivate a sustainable environment for ZK proof generation and verification by addressing the following two major challenges:

Prover Decentralization: The concept of decentralized provers provides a robust solution to prevent single points of failure in ZK projects, while simultaneously improving the efficiency and cost-effectiveness of proof generation. This design principle is inherently incorporated into all Layer 1 and Layer 2 ZK projects, reflecting the decentralized ethos of the blockchain community. Hardware acceleration, including the use of GPUs and ASICs, is likely inevitable if we aim to maintain performance without compromising decentralization.

Latency and Cost in ZK Proof Verification: Ethereum has high costs and latency for settling ZK proofs. The current solution is to aggregate multiple proofs and then settle the aggregated proof on Ethereum. This approach reduces the gas fees required for verification but increases the waiting time. ZK proof verification is essentially a nearly stateless process, which means it can be verified off-chain and later aggregated and settled on Ethereum, should the users choose to do so. This two-stage settlement process strikes a balance between the latency and cost of ZK proof verification.

Cysic Network offers an effective solution to both challenges. In the following sections, we present the design details of the Cysic Network.

## Terminology
The Cysic token is the native and transferable asset of the network, and it is subdivisible into 100,000,000 microtokens. A microtoken is the base unit of this native asset. Cysic tokens can be used to pay for gas fees and execute programs on the network. Additionally, the native token can be converted into ve-tokens, which are eligible for participation in consensus and governance to protect the integrity and security of the Cysic Network.

A **prover** is a node that computes ZK proofs on the network. A prover provides its computational power to the Cysic Network in exchange for Cysic tokens as a reward. There are two types of proof tasks that a prover commonly generates:

- Normal Proof Task: This type of proof task is assigned by ZK projects. Depending on the specific ZK project, the proof backend for each task may vary.
- Aggregated Proof Task: The purpose of this task is to aggregate multiple proofs and then settle the aggregated proof on Ethereum. The proof backend for this type of task remains the same.

A **verifier** is a lightweight node that verifies the normal proof tasks generated by provers. Due to the succinctness of ZK proofs, the computing resources required for verification are minimal. After a normal proof is generated, a large number of verifiers are selected to verify the proof.

A **validator** is a node that holds a certain number of ve-tokens as their stake. A delegator is a ve-token holder who can delegate their holdings to a validator. Additionally, a prover or verifier can also delegate their quantified computational power to a validator to participate in block production and governance.

## Overview
Cysic Network is a ZK proof layer that powers the entire ZK ecosystem. It is built on the Cosmos SDK and is EVM-compatible. The network allows participants to use their hardware—both powerful and less powerful—to contribute to the protocol and, in return, earn rewards from various ZK projects. The workflow for a proof task is shown in the following figure:
Once the Cysic Network reaches a stable state, any ZK project can deploy proving tasks via smart contracts through the following process:
<ol>
<li>A ZK project first deposits the necessary tokens into the task smart contract. When it needs to generate a proof, it sends a notification to an automated agent smart contract, which then initiates the proof task on the blockchain. </li>
<li>A certain number of provers are then selected to compete for the task. The selection method is decentralized and is spontaneously executed by interested provers. More specifically, each interested prover runs a verifiable random function to determine if it is eligible to participate in the task. The probability of selection depends on the amount of ve-tokens held and the token system for proof task completion. Once a prover completes the proof generation, it posts a transaction on the blockchain to update the task status. Only the fastest three provers are allowed to update the task status. </li>
<li>After the proof generation for a task is completed, a larger number of verifiers is selected in a manner similar to prover selection to verify the generated proof. AVS services can also be included to enhance confidence in the proof verification. For a proof to be considered valid, at least six verifiers must approve the proof. Once six validity votes are cast for the same proof, the task is marked as successful on the blockchain. </li>
<li> When a task reaches a successful status on the chain, it triggers the task smart contract to send the agreed-upon amount of funds to the agent contract. This completes the proof task process. </li>
</ol>

This is the process of a normal proof task. An aggregated proof task follows similarly. There are several states that a proof task can become: **Wait for proof**, **Wait for verification** and **Success**.

As shown in the figure, various hardware owners—including GPU servers, laptops, cell phones, and ASIC machines (designed and manufactured by Cysic, ready for deployment in 2025)—can join as computing providers. Cysic facilitates this process by providing the network infrastructure and necessary hardware acceleration techniques to attract more ZK projects to deploy proof generation tasks on the Cysic Network.

## Consensus Mechanism
The consensus mechanism of the Cysic Network is based on the CometBFT algorithm. CometBFT follows the Byzantine Fault Tolerance (BFT) consensus model, meaning it is designed to handle situations where some nodes in the network behave maliciously or fail to follow the protocol correctly. It tolerates up to one-third of the nodes failing or behaving maliciously without compromising the system’s integrity. The consensus algorithm consists of three main stages:
- **Propose**: One validator is chosen as the proposer in each round to propose a new block of transactions.
- **Pre-vote**: After a block is proposed, validators broadcast their pre-vote messages for the proposed block.
- **Pre-commit**: Validators then send their pre-commit messages for the block if they receive enough pre-votes (typically two-thirds or more).

If enough pre-commit votes are received, the block is committed, and the transactions within it are finalized. The consensus algorithm uses voting rounds and timeouts to ensure progress is made in the event of network delays or failures. Validators vote on blocks, and if a round fails (due to network partitions or Byzantine behavior), the process continues with a new round and a different proposer. Once a block is committed, it is final and cannot be reverted. This differs from traditional Proof of Work (PoW) systems, where finality is probabilistic, and there is always a chance of chain reorganization. CometBFT is highly secure and guarantees consensus as long as more than two-thirds of the validators are honest.

The consensus process relies on a set of validators responsible for proposing and validating new blocks. Validators are selected based on a staking mechanism, where nodes with more stake (tokens) have a higher probability of being chosen as proposers. In the Cysic Network, this staking mechanism is modified to incentivize provers and verifiers to contribute to the network.

The new consensus mechanism, Proof-of-Compute (PoC), draws inspiration from both Proof of Work (PoW) and Proof of Stake (PoS). Intuitively, it quantifies the computational contributions of provers and verifiers in the network. Provers and verifiers are compensated through the following two methods:
- **Cysic tokens**: A fixed amount of Cysic tokens will be rewarded to provers and verifiers who successfully complete a proof task.
- **Computing Governance (CG) credit**: As mentioned above, the Cysic Network receives a certain amount of ZK project tokens for its computing services. These external tokens are converted into CG credits to quantify the computing contribution of each participant. Any party can delegate its CG credits to validators to participate in the consensus of an epoch. After delegation, the CG credit balance of the delegatee is reset to zero.

At the end of each epoch, any CG credit holder can delegate their CG credits to any validator of their choice. This delegation can be based on several factors, such as validator fees and latency. Each validator then calculates its weight as
$$\mathsf{weight(validator)} = \frac{1}{3}\mathsf{stake(validator)} + \frac{2}{3} \mathsf{CG(validator)},$$
where the value of staked Cysic tokens and CG credits is calculated based on the quoted proposal from the current epoch committee. As long as a validator's **weight** exceeds a dynamically adjusted **threshold**, the validator can participate in the next **epoch committee**. Once the epoch committee is formed, its members engage in the CometBFT algorithm to produce blocks for the duration of the epoch, as described above.

## Dual Token Model
The goal of the Cysic Network is to establish a decentralized and reliable proving and verification service that fosters community growth and self-sustainability. The token will be used to incentivize provers, verifiers, and validators within the protocol, establishing an effective governance and reward distribution mechanism. Cysic Network uses a dual-token model, consisting of the network token and governance token. Each token plays a specific role in the network, working together to build the Cysic Network ecosystem:

- **$CYS**: The $CYS token is the native token of the Cysic Network and is used to pay transaction fees, block rewards, and other network-related activities. $CYS ensures the liveness and vitality of the network through its transaction fee mechanism and serves as one of the incentives for users to participate in network activities.
- **$CGT**: $CGT is the governance token and is non-transferable. It can be obtained by staking $CYS and completing computation tasks. The un-staking process takes longer than the staking process, as implemented in the Cosmos SDK.

The dual-token model is illustrated in the following:

Provers and verifiers contribute their computational power to the pool, which in turn provides services to various ZK projects. In addition to receiving block rewards from the Cysic Network, users can also buy $CYS and stake them to gain voting power to govern the computation pool. The distribution of computational power can be dynamically adjusted based on several key factors, with the external token rewards from ZK projects being one of the main factors.

The Cysic Network requires provers and verifiers to stake a certain amount of $CGT initially to defend against malicious behavior. All eligible computing providers can connect to the Cysic Network by staking $CYS as collateral to maintain the reliability and sustainability of the network service. The staked $CYS can also be delegated to validators to participate in the consensus process.

## Cysic Network Basics
Each transaction includes a fee, which consists of a base fee and a priority fee. The base fee is calculated based on specific criteria for the task or transaction type, while the priority fee is optional and can be added to achieve faster on-chain execution. For example, in a normal proof task, the base fee primarily covers the storage cost for storing the proof. In contrast, for an aggregated proof task, the base fee mainly covers the Ethereum gas cost for settling the aggregated proof on Ethereum.

A block is produced based on the following consensus mechanism. An epoch consists of approximately 200 blocks, during which the validator set remains unchanged. Simply put, a block is structured as follows:
- **Header**: Metadata, block links, Merkle root hashes.
- **Data (transactions)**: Actual transactions to be processed.
- **Last commit**: Signatures from validators committing the previous block.
- **Evidence**: Proof of misbehavior, if any, by validators.
- **Validators**: Information on the current set of validators.

Where the block header contains some metadata about this block, such as
- **Epoch number** -- Identify which epoch the block belongs to.
- **Height** -- The block's position in the blockchain.
- **Last block ID and commit hash** -- The hash of the last commit signatures from validators.
- **Validator hash** -- The Merkle root of the current validator set, showing the validators responsible for creating and verifying this block.
- **Consensus Hash** -- Hash of the consensus parameters, ensuring that the consensus rules used to create this block are known and unchanged.
- **Proposer Address** -- The address of the validator that proposed the block.

### Supply Curve
Cysic network starts at genesis $\mathsf{block}_0$ with a $\mathsf{supply}_{\sf starting}$ in tokens that is distributed amongst stakeholders, which include provers, verifiers, developer grantees, investors, community members and the foundation. The starting supply $\mathsf{supply}_{\sf starting}$ is 150,000,000 $CYS. The token release follow a schedule of an estimated halving sechedule of every 3 years, initially every block will reward 50 $CYS, then 25 $CYS and 12.5 after each havling, and so on. The current estimated block epoch time is 10 seconds, with possible slight adjustment based on network difficulty and activities. The generated tokens will be distributed with roughly 1/3 towards staking and 2/3 towards to computing providers. The network is designed to encourage the gradual increase of proving capacity over the first decade.

Thus, it follows that the supply curve is not fixed; rather it is target-based, depending on how well the network scales proving capacity for developers and users of ZK technology. Over the first decade, the compensation is expected to change towards a more balanced split between the staking and computing parties. The exact rate of pro-rata is based on a mechansim of weight constituent of a validator con but roughly 1:2 ratios among the two groups. Basically based on the 10 seconds per block and 3 years of time, so it will be rougly $365*24*3600 / 10 *3 = 9,460,800$ blocks before the first halving.

Prover and verifiers are compensated using the the block reward, minus a fixed commission fee paid to the validators for their block producing service. The exact reward is calculated based on the CC value accumulated in the whole network during that block time.

### Token Allocation
Among the initial token releases:
- Community allocation will be - 10\%: These tokens will be released through airdrops, supporting early adopters, testnet incentives, and various community-related activities, particularly for early participants.
- Investor and core team - 33\%: 1-year cliff, followed by 3 years of linear monthly vesting.
- Treasury reserve - 30\%: This portion of tokens will be used to reward provers and verifiers who contribute to the protocol. The treasury will maintain, receive, and manage the initial tokens, along with revenue collected from activity rewards that Cysic contributes to other networks.
- Foundation - 27\%: This allocation can be used for governance, growth, improvement proposals, market making, and more.