OpenVector
  • OpenVector
  • Introduction
    • Our Thesis
    • Our Solution
    • Other Approaches
    • Benchmarks
  • Network Architecture
    • Overview
    • Networking
    • Deploy Compute Node
    • Deploy CoFHE Node
    • Deploy Client Node
  • Quick start
    • Overview
    • Setting up Client Node
    • Encrypting Data
    • Tensor Multiplication
    • Decrypting the Ouput
    • Verifying the Output
    • Running the Program
  • Tutorials
    • Building MLP Block
  • Use Cases
    • Confidential LLM Inference
    • Training on Encrypted Data
    • Vector Search on Encrypted Data
    • Encrypted Data Access Control
  • API references
    • CryptoSystem Interface
    • ClientNode Class
    • ComputeRequest Class
    • ComputeResponse Class
  • PYTHON API REFERENCES
    • Overview
    • Tensor
    • nn.Module
    • nn.Functional
  • Contribution
    • Call for Research
    • CoFHE Library
Powered by GitBook
On this page
  • Subnet
  • CoFHE Nodes
  • Compute Nodes
  • Client Node
  1. Network Architecture

Overview

PreviousBenchmarksNextNetworking

Last updated 5 months ago

The OpenVector network consists of several Subnets, anyone can host Compute nodes and CoFHE nodes in any of the subnet, contributing to a decentralized, permission less ecosystem.

Subnet

OpenVector operates as a large, decentralized network. To achieve low latency for certain computations, it partitions the network into subnets. Each subnet is associated with a specific environment that defines parameters such as encryption key, the total number of nodes and their threshold counts, and so forth.

Before running an actual computation, a user can submit a reservation request. At this stage, the network selects nodes—both compute nodes and cofhe nodes—based on the request’s requirements. These criteria include factors like computational demands, timing/latency, security levels, and availability needs. For instance, a user might request a higher threshold of nodes for stronger security guarantees or/and maintain a lower threshold-to-total-node ratio for better availability. The compute nodes are chosen first according to the computation requirements; afterwards, cofhe nodes are selected.

Nodes in the OpenVector network can choose which subnets they wish to join, provided they hold sufficient funds to be staked and potentially slashed if they fail to meet their obligations. If a subnet has open slots, new nodes can join mid-operation to preserve the subnet’s original requirements. Conversely, if a node leaves before fulfilling its assigned work quota, it will be subject to slashing.

CoFHE Nodes

A subnet may consist of 100s of CoFHE nodes out of which a defined threshold number of CoFHE nodes participate to support secure encrypted operations for compute nodes, within the same subnet.

Compute Nodes

Our approach achieves decentralization through cryptography, focusing on decryption key decentralization rather than compute. Compute tasks can be handled by a high performance node we call compute node, ensuring flexibility and scalability.

Client Node

A Client Node is the device that can initiate a compute request to the OpenVector network. It can be a regular user seeking inference for personal use, such as through a browser or in the case of web3, it can be an oracle providing this service to the blockchain.

The diagram illustrates the multi-layered structure of OpenVector, consisting of subnets (Subnet X, Subnet Y, etc.) with compute nodes (CON) and CoFHE nodes (CFN).