Merge pull request #21 from aoraki-labs/Galactic-Network

Feat: Add Galactic Network doc

docs/ZKPool-1.0/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "ZKPool-1.0",
+  "position": 3,
+  "link": {
+    "type": "generated-index",
+    "description": "Introduction about the ZKPool-1.0"
+  }
+}

docs/ZKPool-2.0/Galactic-Network-introduction.md

@@ -0,0 +1,46 @@
+---
+sidebar_label: 'Galactic Network Introduction'
+sidebar_position: 1
+slug: /ZKPool-2.0/
+---
+# Galactic Network Introduction
+We refer to ZKPool-2.0 as the [Galactic Network](https://en.wikipedia.org/wiki/Intergalactic_Computer_Network) in tribute to J.C.R. Licklider, who first proposed the Galactic Network concept, an early vision of the open internet.
+
+## Background
+
+- Verifiable computation, specifically Zero-knowledge proof (ZKPs) technology, serves as a cornerstone in the crypto world. However, designing and operating a reliable, low-cost, decentralized, and economically healthy proving network can be very challenging.
+- As Vitalik mentioned[1][2], the zkEVM might have bugs. For better security, a multi-provers framework has been proposed, and increasingly more projects, like Taiko, Scroll etc. are adopting this solution. Such a design will make the network more complex.
+- ZKP requires a significant amount of computational power. However, it's crucial to understand that, unlike the POW project, these requirements are dynamic, not constant. For instance, the total number of transactions in a rollup may fluctuate, and some ZKP projects operate in optimism mode, requiring ZKP only at specific times. Therefore, in each independent ZKP network, the use of ZKP accelerators may vary, increasing the overall cost. Sharing the proving network is essential for fully utilizing the vital computational power.
+
+## Galactic Network
+
+The Galactic network aims to create a modular Verifiable Computation Layer (MVCL) that is affordable, decentralized, and easily accessible. This network will significantly reduce the development cost for ZKP (Zero-Knowledge Proof) projects' developers. 
+
+Ethereum also plans to use ZKP to verify Layer 1. Vitalik proposed the "Enshrined ZKEVM" to allow L1 and L2 to share the ZKEVM prover[3]. A modular verifiable computation layer will be aligned with Ethereum's long-term vision.
+
+Additionally, it supports not only the Ethereum ZKP proving network but also other types of verifiable computation, including the Bitcoin ecosystem, web2 verifiable computation scenarios, and so on.
+
+![Galactic Network Ecosystem](./images/modular%20ecosystem.png)
+*Modular Galactic Network Ecosystem*
+
+The Galactic network comprises the following components:
+
+- Ethereum L3 based Appchain: A decentralized, permissionless network constructed to support protocols for provers, verifiers, and more to schedule the proving/verification tasks and distribute rewards.
+- Galactic prover node: Nodes responsible for generating proofs.
+- Galactic verification node: Nodes that handle verifications.
+- Galactic relayer node: Nodes to relay proving tasks from ZKP projects to the Galactic network.
+- Galactic oracle node: Nodes to split and schedule proving and verification tasks, and aggregate multi-provers.
+
+This network offers several unique features:
+
+- Low-cost and high-performance
+- Support for multiple ZKP provers.
+- Support for a PoS-Based verifier.
+
+ZKP accelerators can participate in ZKP-proving tasks, which effectively boosts the utilization rate of their accelerators. Meanwhile, the verifier can aid in the validation of these proofs.
+
+## References
+
+1. [Rollup Day 2022 - Multi-Provers for Rollup Security w/ Vitalik Buterin](https://www.youtube.com/watch?v=6hfVzCWT6YI)
+2. [Taiko’s Approach to Multi-Proofs](https://taiko.mirror.xyz/j_zUGgLDwb1FY18fzh7bJQz2Qt5xbUlqov4n-vm6IC0)
+3. [What might an “enshrined ZK-EVM” look like?](https://notes.ethereum.org/@vbuterin/enshrined_zk_evm)

docs/ZKPool-2.0/Guide/Introduction.md

@@ -0,0 +1,9 @@
+---
+sidebar_label: 'Introduction'
+sidebar_position: 1
+slug: /ZKPool-2.0/Guide
+---
+
+Here is the guide to run provers, verifiers and integrate with Galactic Network for developers.
+
+*Coming Soon!*

docs/ZKPool-2.0/Guide/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "Guide",
+  "position": 3,
+  "link": {
+    "type": "generated-index",
+    "description": "Guide to run provers, verifiers and integrate with ZKPool-2.0. (Coming soon)"
+  }
+}

docs/ZKPool-2.0/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "ZKPool-2.0",
+  "position": 2,
+  "link": {
+    "type": "generated-index",
+    "description": "Introduction about the ZKPool-2.0"
+  }
+}

docs/ZKPool-2.0/technology/PoS-based-verifiers.md

@@ -0,0 +1,37 @@
+---
+sidebar_label: 'PoS-Based Verifiers'
+sidebar_position: 3
+---
+
+# PoS-Based Verifiers
+
+Proofs need to be verified within the network before being sent back or retrieved by the requester for the following reasons:
+
+1. If a proof is invalid, the network can reassign the task to another prover.
+2. Rewards are only distributed to provers who produce valid proofs.
+3. Verifying proofs enhances the network's trustworthiness.
+
+A decentralized network of verifier nodes will be established to reach a consensus on proof settlement. A node offers greater flexibility than a verifier contract because not all projects have a Solidity version of verification code. Verifying the batched proof can further reduce the cost. The mechanism will resemble Ethereum's proof of stake but likely in a simpler form. The process is as follows:
+
+![PoS-Based Verifiers](./images/PoS-verifier-flow.png)*PoS-Based Verifiers Flow*
+
+1. ZK projects supply the verifier code, which can be in different languages.
+2. Either the ZK project or the community operates one or more verifier nodes.
+3. To ensure the verifier's good intentions, a minimal deposit is required as staking asset.
+4. Galactic contract or Oracle node aggregates proofs and produce an batchedProof
+5. The Galactic contract or Oracle node uses a VRF to select a committee of verifier nodes for the batchedProof.
+6. The verifier nodes carry out the proof verification and submit their results to the Galactic contract or Oracle node within a specified timeframe.
+7. If a majority of the committee (for example, 2/3) reach a consensus, and if correct, all proofs in the batched proof are considered verified as either valid, if not then iterate to verify each proof.
+8. Honest verifier nodes are equally rewarded, while dishonest ones are penalized.
+9. The verifier's reputation is updated based on their actions.
+
+We choose a verifier network over a DAO which handles challenges in an optimistic manner for the following reasons:
+
+1. ZK verification is quick and cost-effective.
+2. Verification consensus can be achieved rapidly because it depends on the L3 block proposing speed, which can be significantly fast.
+3. It takes longer for a DAO to settle a proof if a challenge arises.
+4. In both scenarios, verification codes from various ZK projects are required.
+
+However, if there's a conflict between the PoS-Based verification results and the requestors' verification results, we'll need the governance DAO to handle such an issue.
+
+Additionally, using an existing platform like EigenLayer is an option for us.

docs/ZKPool-2.0/technology/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "Technology",
+  "position": 2,
+  "link": {
+    "type": "generated-index",
+    "description": "Technology of ZKPool-2.0"
+  }
+}

docs/ZKPool-2.0/technology/graph-based-computation-tasks-scheduling.md

@@ -0,0 +1,115 @@
+---
+sidebar_label: 'Graph-Based Computation  Tasks Scheduling'
+sidebar_position: 2
+---
+# Graph-Based Computation Tasks Scheduling
+## ZKP Proving Task Description
+
+In AI, like TensorFlow, we will use graphs to describe the computation. In the graph, there are many operations, such as conv, pooling, and so on. 
+
+In ZKP, we also have similar requirements, because:
+
+1. For ZKVM, the continuation technology will split the big proving tasks into smaller ones. 
+2. The recursion/composition/aggregation technology is widely used.
+
+![Proof Composition](./images/proof%20composition.png)*Proof Composition (Source: Figment Capital)*
+
+For each zkp proving task, we can define it as a kind of operation of a computation graph. Each device works as a computation node to finish the part of the proving tasks.
+
+Thus, we can use a graph to describe the overall proving tasks. 
+![Graph-Based Computation](./images/graph-based%20computation.png)
+*Graph-Based Computation*
+
+For each operation, we can define these properties:
+
+- input operation (null, one input or multiple inputs)
+- name: (support customization)
+    - “zkp-singleton"
+    - “zkp-continuation”
+    - “zkp-recursion-A”
+    - “zkp-recursion-B”
+    - “zkp-aggregation”
+    - ……
+- device requirements
+    - OS type
+    - CPU requirements
+    - GPU requirements
+    - Memory requirements
+- devices id (null when it’s not assigned)
+- output operation
+
+## Power of Computation
+
+The platform's incentives are determined by the Power of Computation. Without an accurate measurement of computation power, we can't effectively incentivize devices.
+
+For Zero-Knowledge Proof (ZKP) algorithms, most computations are operations such as Multi-Scalar Multiplication (MSM), Number Theoretic Transform (NTT), and Hash, which are similar to operations in Artificial Intelligence (AI) like encoders, decoders, or Convolutional Neural Networks (CNN).
+
+We can create a table defining the computation amount for each operation based on the add/multiply function and its bitwidth. This is referred to as the 'Gas' of the ZKP/AI. An offline benchmark tool can then be used to calculate the total Gas for an algorithm.
+
+This method won't be 100% accurate, so our final computation can be measured using a formula like:
+
+$P = P_{gas} * Gas$
+
+Here, $P$ represents the total computation amount for an algorithm, and $P_{gas}$ is a dynamic price that can be retrieved from the Galactic network to reflect the supply and demand relationship.
+
+## Galactic Universal Modular Prover
+
+The UMP means each ZKP accelerator can support different kinds of ZKP proving tasks.
+
+![UMP](./images/UMP.png)
+*Universal Modular Prover*
+
+The Oracle node features a plug-in service. This allows provers to connect and determine the types of tasks the prover can manage. The corresponding proving binary Docker is then downloaded, enabling the node to handle such tasks.
+
+In this manner, a single accelerator can support multiple ZKP proving binaries.
+
+The Galactic SDK client connects to the proving binary plugin via RPC call.
+
+The protocol includes:
+
+1. Init 
+2. Start
+3. Stop
+
+There is a mechanism to trigger different kinds of computation. 
+
+- high-efficient mode (default mode): The computation service is restarted each time.  It can easily switch among different tasks.
+- high-performance mode: The computation service stays in the memory, and when a new task comes, it doesn’t need to restart the service. It’s used for high throughput tasks.
+
+Each kind of requester project can define its expected mode.
+
+## Scheduler
+
+We will use Oracle Node to take the role of scheduling.
+
+Oracle node will receive the status of all the connected provers and record its liveness and busy/idle status. Once a new task is published, the scheduler will start to work.
+
+Here, we define a task-node matching mechanism.
+
+Firstly, after analyzing a computation graph, a 
+
+- Descriptor of tasks (optimized binary related)
+    - Graph
+    - Task mode:
+        - Performance priority: Redundancy of provers
+        - Cost priority: Only one prover for each operation.
+- Descriptor of device
+    - OS type
+    - CPU type
+    - GPU type
+    - Memory
+
+Then we we find a candidate device list for each operation. 
+
+Here we can adopt a relatively simple and effective strategy rather than a complex reputation system.
+
+1. The proposed rules include:
+- If a prover fails to generate proof in time, a filter window will be used to exclude this prover.
+- If the prover fails to generate proof for the second time, the length of the prohibition window will be doubled.
+- If there are more than 3 consecutive failures, then the prover will be permanently banned. The only way to regain access is to rename the prover and reconnect to the scheduler.
+2. The scheduler in the Oracle node can reschedule the prover if they fail to generate proof in time. 
+3. For tasks with high penalty amounts, the scheduler could assign more than one prover.
+
+When we need more than one device, and then we will exclude the assigned device and use the above method to choose the other devices.
+
+Finally, we will fill in the device ID for each operation of the computation graph.

docs/ZKPool-2.0/technology/moludar-Galactic-Network-overview.md

@@ -0,0 +1,96 @@
+---
+sidebar_label: 'Modular Galactic Network Overview'
+sidebar_position: 1
+---
+# Modular Galactic Network Overview
+## Ethereum L3-Based Appchain
+
+We expect the network to have high-performance requirements due to the frequent chain interactions and token transactions associated with the lifecycle of proof tasks. As such, cost is a significant consideration.
+
+To reduce the overall cost, we will deploy our protocol layer on an Ethereum L3 Appchain which is L2 of another L2 rollup, which offers the following advantages:
+
+1. Compatibility with the Ethereum ecosystem
+2. Low transaction fees, essential for the numerous interactions with smart contracts
+3. Customizable block proposing speed, for instance, every 1 second, and block finalization frequency, like every 1 minute, to further reduce cost
+4. Its own ecosystem including bridge, DEX, etc. which could potentially expand in the future
+5. Decentralization
+
+We will start with the Taiko chain, and consider other chains as a backup.
+
+Taiko allows for setting the ratio between optimistic proofs (no ZK computation) and ZK proofs (requires ZK computation) of blocks, significantly reducing the cost. We will also batch  blocks to decrease the transaction fee of settling block data into L2. Furthermore, we will consider using a Data Availability Layer to lessen the cost of writing data to L2.
+
+However, we will not compromise on security. The protocol's main contract and token contract will be deployed on Taiko L2, which are used to settle the protocol's vault and reward pool. Using Taiko's built-in cross-chain messaging infrastructure, we can seamlessly settle funds from Galactic network’s protocol layer to L2. Storing funds on L2 is safer as it is more decentralized compared to our protocol layer, which is more application-specific.
+
+On our protocol layer, we will deploy frequently operated contract logic, such as the circulation of proof fees, streaming payment, and the lifecycle of proving tasks. This will help maintain a low overall cost, allowing network users to focus on their tasks, not the cost of network transactions.
+
+ ![Ethereum L3-Based Appchain](./images/L3.png) 
+ *Ethereum L3-Based Appchain*
+
+L2 is an extension of Ethereum's performance, while L3 is an extension of L2's performance. We estimate that app-specific L3 can have a gas limit of 0.5-1B, which is equivalent to each block containing 1000 ERC20 transfers. And it can achieve sub-second block speed. In summary, it can reach 1000-5000 tps or higher.
+
+The main transaction cost of L3 is the block data storage written to L2. On average, each L3 transaction consumes 2000-3000 L2 gas. If it reaches 1000 tps, it will consume 0.002 ETH at an L2 gas price of 1 gwei. So if L2 is used as the data availability layer, the cost will be high. Our choice is to use other dedicated data availability layers, such as Celestia, EigenDA or Avail. Based on the [calculations](https://medium.com/@numia.data/the-impact-of-celestias-modular-da-layer-on-ethereum-l2s-a-first-look-8321bd41ff25) provided, costs will decrease by approximately 300 to 500 times, making them essentially trivial.
+
+## Galactic Network Modules
+
+The Galactic contract will act as the central hub for essential network records, including projects, provers, tasks, rewards, bonds, and staking, among others. This will be the foundation for the entire decentralized network.
+
+The Oracle node, a component of the network, will handle complex task scheduling, reward distribution, and proof aggregation.
+
+Prover, relayer, and verifier nodes can all function in a decentralized manner externally, using the Galactic contract as their source of truth.
+
+ ![modules](./images/modules.png)
+ *Galactic Network Modules*
+
+### What does the Galactic Contract contain?
+
+ ![Galactic Contract](./images/Galactic%20Contract.png)
+ *Galactic Contracts*
+
+1. Task events for actions: submission, proof, and verification.
+2. Projects, provers, verifiers and tasks.
+3. Provers' rewards: these are updated periodically, for instance, daily.
+4. The default reward calculation is conducted on-chain.
+5. Provers' bonds.
+6. Users' staking.
+
+### What does the Oracle Node contain?
+
+ ![Galactic Oracle nodes](./images/Oracle%20nodes.png)
+ *Galactic Oracle nodes*
+
+1. Task scheduling: This is a complex logic. The final task scheduling results are written to the Galactic contract, while intermediate task statuses are stored in the local DB. Since task data are huge, which could potentially overload the contract, only the most necessary data are written to the chain.
+2. Task split and aggregation: A task might be divided into multiple smaller subtasks and proved in parallel to increase efficiency.
+3. Proof aggregation: generate a batched proof for a group of proofs
+4. Complex reward calculation can be done off-chain if the default version in the Galactic contract cannot handle it or involves too many steps.
+
+### What does the Relayer Node do?
+
+A relayer node acts as an external node that integrates with ZKP projects. It does this by retrieving active tasks from the ZKP projects.
+
+In the meanwhile, the relayer node needs to pay the gas fee and provide necessary ZKP projects’ staking toke if the corresponding projects require.
+
+### What’s the task flow?
+Here are a detailed modules relationship and a sequence diagram:
+
+![Galactic Network Flow](./images/flow.png)
+ *Galactic Network modules relationship*
+
+![Galactic Network Flow Sequence](./images/flow%20chart.png)
+*Galactic Network Flow Sequence*
+
+The steps are like below:
+1. The task request is directly submitted to the Galactic contract (Active mode).
+
+    Alternatively, in Passive mode (as shown in the above diagram), the relayer retrieves the task from another chain and then submits the task, along with the bond, to the Galactic contract. The task should be described as a computation graph.
+
+2. The Galactic contract publishes the proving task. The oracle node then retrieves task information from the contract, schedules the task based on the computation graph and the prover's attributes and availability, and sends the scheduled result to the contract.
+3. The Galactic contract publishes the scheduled results, enabling each prover to determine whether they've been selected to join the task.
+4. The prover node syncs the task from the Galactic contract, generates the proof, and sends it back to the Oracle contract.
+5. An Oracle node monitors the Oracle contract. Plans are in place for an Oracle node to initiate an aggregation proof task, after which the verifiers will only need to verify the aggregated proof.
+6. An Oracle node schedules the verifiers to perform the verification and notifies the Galactic contract.
+7. The Galactic contract publishes the verifier task. The selected verifiers monitor this and begin verification.
+8. The verifier returns the verification result to the contract. Once the Galactic contract determines that the majority of verification results pass, it marks the proof as verified.
+9. The Galactic Oracle calculates the reward. (This logic may be transferred to the contract later.)
+10. The Galactic contract returns the bond and shares the reward with the prover. Also the verifiers will get part of the reward.
+
+In the architecture above there will be lots of interactions between other parties with the Galactic contract. This drives our choice of Ethereum L3 which will further reduce the transaction cost.