Technical Architecture

The zkVerse protocol is structured as a three-layer stack:

Layer 1: Sovereign Client Layer

Components:

  • Encryption Engine: AES-256-GCM for symmetric encryption, X25519 for key exchange

  • Proof Generator: WASM-compiled zk-SNARK prover (Groth16/Plonk) running in-browser

  • Key Management: BIP-39 hierarchical deterministic wallets integrated with Solana keypairs

Workflow:

  1. User performs action (e.g., upload file, send message)

  2. Data is encrypted locally with ephemeral keys

  3. Prover generates $\pi$ attesting to action validity

  4. Only $\pi$ and encrypted payload are transmitted

Layer 2: Zero-Knowledge Verification Layer

Proof Aggregation:

  • Aggregators are specialized nodes that batch multiple user proofs into a single "SuperProof" $\Pi$

  • Uses recursive SNARKs: $\Pi = Prove(\pi_1, \pi_2, ..., \pi_n)$

  • Reduces on-chain verification cost from $O(n)$ to $O(1)$

Circuit Registry:

  • Library of audited ZK circuits for common operations:

    • Transfer(amount, recipient): Prove sufficient balance without revealing amount

    • Store(file_hash, access_policy): Prove file ownership and access rights

    • Vote(choice, eligibility_proof): Anonymous voting with eligibility verification

Layer 3: Solana Settlement Layer

Smart Contracts:

  • Verifier Program: On-chain Rust program that verifies $\Pi$ using Groth16 verification algorithm

  • State Root Manager: Maintains Merkle tree of encrypted data commitments

  • Access Control: Enforces ZK-based permissions for data retrieval

Data Availability:

  • On-Chain: State roots, proof hashes, access control lists

  • Off-Chain: Encrypted file shards stored on IPFS/Arweave, pinned by zkVerse storage nodes

PreviousProtocol Design PhilosophyNextCryptographic Foundations

Last updated