Skip to content

Latest commit

 

History

History
59 lines (43 loc) · 2.58 KB

File metadata and controls

59 lines (43 loc) · 2.58 KB

Basic Concepts

Understanding the core architecture and mechanisms of Setu.

High-Level Architecture

The Setu network operates as a two-tier system: the Consensus Layer (Validators) and the Compute Layer (Solvers).

graph TD
    User[User / Client] -->|Submit Task| Val[Validator Network]
    
    subgraph "Consensus Layer (DAG)"
        Val -->|Consensus| Val2[Validator 2]
        Val2 -->|Consensus| Val3[Validator 3]
    end
    
    Val -->|Route Task| Sol[Solver Node]
    
    subgraph "Compute Layer (TEE)"
        Sol -->|Execute| Enclave[Secure Enclave]
        Enclave -->|Proof| Sol
    end
    
    Sol -->|Submit Result + Proof| Val
    Val -->|Verify & Settle| User
Loading

1. Task Submission

A user submits a compute task (e.g., "Run Inference on Model X with Input Y") to the Validator network via RPC.

2. Consensus & Routing

Validators receive the task and reach consensus on its ordering using the DAG protocol. The protocol then deterministically selects a Solver based on:

  • Capacity: Current load reliability.
  • Capabilities: Hardware specs (e.g., H100 GPU).
  • Reputation: Historical performance.

3. Execution (TEE)

The assigned Solver executes the task. Crucially, this happens inside a Trusted Execution Environment (TEE). The TEE generates an Attestation — a cryptographic proof that the code ran exactly as specified on genuine hardware.

4. Verification & Settlement

The result and the Attestation are sent back to the Validator. The Validator verifies the proof (without re-running the heavy compute) and updates the state. The user receives the result, and the Solver receives payment.

Core Technologies

DAG Consensus & VLC

Setu uses a Directed Acyclic Graph (DAG) structure for consensus, rather than a linear blockchain. This allows blocks (or events) to reference multiple parents, enabling parallel processing.

  • Virtual Logical Clocks (VLC): Used to order events in the DAG without relying on synchronized system clocks, ensuring causal consistency and high speed.

Sharding (Storage & State)

To handle massive scale, Setu employs Sharding.

  • State Sharding: The global state is partitioned across multiple shards.
  • RocksDB: Each node uses RocksDB for high-performance, persistent local storage of its shard data.

Anemo Networking

Setu nodes communicate via Anemo, a specialized P2P networking library designed for:

  • Resiliency: Auto-discovery and reconnection handling.
  • RPC: Efficient typed RPC calls between nodes.
  • Pub/Sub: Event propagation for consensus.