chains/zkvm/ATTESTATION_VM_SPEC.md

Z/A-Chain: AttestationVM + ZK Coprocessor Specification

Version: 1.0.0-mainnet
Status: Implementation Phase
Target: Lux Mainnet Launch

---

Executive Summary

The Z/A-Chain (Attestation + ZK Chain) combines zero-knowledge privacy with AI attestation verification to create a quantum-safe, privacy-preserving attestation layer for Lux Network.

Core Functions

1. ZK Privacy Coprocessor: Confidential transactions using ZK-SNARKs
2. AI Attestation Verifier: On-chain verification of Hanzo.network AI compute proofs
3. Global Attestation Registry: Immutable record of verified AI inferences, models, and datasets

---

Architecture

┌─────────────────────────────────────────────────────────┐
│                  Z/A-Chain (ZVM)                        │
│  ┌──────────────────────────────────────────────────┐  │
│  │         Attestation Registry Layer               │  │
│  │  - Provider DIDs                                 │  │
│  │  - Model hashes                                  │  │
│  │  - Dataset commitments                           │  │
│  │  - Inference receipts                            │  │
│  └─────────┬────────────────────────────────────────┘  │
│            │                                            │
│  ┌─────────▼────────────────────────────────────────┐  │
│  │         ZK Verification Layer                    │  │
│  │  - Groth16 verifier (commit-only v1)            │  │
│  │  - Plonk verifier (future)                       │  │
│  │  - Receipt circuit: Hash(input+model+output)     │  │
│  └─────────┬────────────────────────────────────────┘  │
│            │                                            │
│  ┌─────────▼────────────────────────────────────────┐  │
│  │         State Management Layer                   │  │
│  │  - UTXO DB (confidential outputs)                │  │
│  │  - Nullifier DB (double-spend prevention)        │  │
│  │  - Merkle State Tree (commitments)               │  │
│  └──────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────┘
            ▲                           │
            │ Receipts                  │ Verified
            │                           ▼ Attestations
    ┌───────┴────────┐         ┌───────────────┐
    │ Hanzo.network  │         │  P-Chain      │
    │ (Compute)      │         │  (Oracle)     │
    └────────────────┘         └───────────────┘

---

Transaction Types

1. Attestation Transactions

RegisterProviderTx

Registers an AI compute provider on-chain.

type RegisterProviderTx struct {
    ProviderDID     string        // Decentralized Identifier
    PublicKey       []byte        // Provider's public key
    GPUSpecs        []GPUSpec     // Compute capacity
    TEEAttestation  []byte        // Optional TEE attestation
    StakeBond       uint64        // Required stake (100 LUX minimum)
    Signature       []byte        // Provider signature
}

Validation:

• Provider DID unique
• Stake ≥ 100 LUX
• Valid signature
• TEE attestation valid (if provided)

SubmitReceiptTx

Submits an AI inference receipt for verification.

type SubmitReceiptTx struct {
    JobID           ids.ID        // Unique job identifier
    ProviderDID     string        // Provider who executed job
    ModelHash       [32]byte      // SHA256(model_weights)
    DatasetHash     [32]byte      // SHA256(input_data)
    OutputHash      [32]byte      // SHA256(inference_result)
    Proof           []byte        // ZK-SNARK proof
    Timestamp       int64         // Execution timestamp
    Fee             uint64        // Fee in LUX
    Signature       []byte        // Provider signature
}

ZK Circuit (Receipt Circuit v1 - Commit-Only):

Public Inputs:
  - job_id
  - provider_did
  - timestamp

Private Inputs:
  - model_weights
  - input_data  
  - inference_result

Circuit Constraints:
  1. Hash(model_weights) == model_hash (public)
  2. Hash(input_data) == dataset_hash (public)
  3. Hash(inference_result) == output_hash (public)
  4. Inference_result == Model(input_data) [future: in-circuit]

Validation:

• Provider registered
• Proof verifies with Groth16/Plonk
• Fee sufficient
• No duplicate job_id

ChallengeTx

Challenges an attestation as fraudulent.

type ChallengeTx struct {
    ReceiptID       ids.ID        // Receipt being challenged
    ChallengerDID   string        // Challenger identity
    CounterProof    []byte        // Alternative proof
    BondAmount      uint64        // Challenge bond (50 LUX)
    Reason          string        // Challenge reason
    Signature       []byte        // Challenger signature
}

Challenge Period: 1000 blocks (~2 hours)
Resolution:

• Valid challenge: Challenger gets provider stake
• Invalid challenge: Challenger loses bond

SettlementTx

Resolves a challenge through committee vote or timeout.

type SettlementTx struct {
    ChallengeID     ids.ID        // Challenge being resolved
    Decision        bool          // true = challenge valid
    Evidence        []byte        // Evidence for decision
    CommitteeVotes  []Vote        // Committee signatures
}

2. Privacy Transactions

ConfidentialTransferTx

ZK-private asset transfer.

type ConfidentialTransferTx struct {
    Nullifiers      [][32]byte    // Spent UTXO nullifiers
    Commitments     [][32]byte    // New UTXO commitments
    OutputNotes     []EncryptedNote // Encrypted output notes
    RangeProof      []byte        // Proves values non-negative
    ZKProof         []byte        // ZK-SNARK transfer proof
    Fee             uint64        // Public fee
}

---

State Model

UTXO Model

type UTXO struct {
    TxID           ids.ID        // Creating transaction
    OutputIndex    uint32        // Output index in tx
    Commitment     [32]byte      // Pedersen commitment
    Ciphertext     []byte        // Encrypted note
    EphemeralPK    []byte        // Ephemeral public key
    Height         uint64        // Block height created
}

Nullifier Model

type Nullifier struct {
    Hash           [32]byte      // PRF(spend_key, serial)
    SpentAt        uint64        // Block height spent
    TxID           ids.ID        // Spending transaction
}

Attestation Registry

type AttestationRecord struct {
    JobID          ids.ID        // Unique job ID
    ProviderDID    string        // Provider identity
    ModelHash      [32]byte      // Model commitment
    DatasetHash    [32]byte      // Input commitment
    OutputHash     [32]byte      // Result commitment
    ProofHash      [32]byte      // ZK proof hash
    Timestamp      int64         // Attestation time
    Status         AttestStatus  // Pending/Verified/Challenged/Invalid
    ChallengeID    *ids.ID       // Challenge (if any)
}

type AttestStatus uint8
const (
    AttestPending    AttestStatus = 0
    AttestVerified   AttestStatus = 1
    AttestChallenged AttestStatus = 2
    AttestInvalid    AttestStatus = 3
)

---

Proof Systems

Receipt Circuit v1 (Commit-Only)

Purpose: Prove hash consistency without in-circuit inference
Proof System: Groth16 (fast verify, ~200ms)
Circuit Size: ~100K constraints

Proof Statement:
  "I know (model, data, result) such that:
   Hash(model) == model_hash AND
   Hash(data) == dataset_hash AND  
   Hash(result) == output_hash"

Receipt Circuit v2 (Future - Full Inference)

Purpose: Prove correct inference execution in-circuit
Proof System: Plonk or Halo2
Circuit Size: Depends on model (millions of constraints)

Proof Statement:
  "I executed Model(input) == output correctly"

Privacy Transfer Circuit

Purpose: Prove valid confidential transfer
Proof System: Groth16
Circuit Size: ~50K constraints per input/output

Proof Statement:
  "I know secret keys and values such that:
   - Nullifiers are valid spends
   - Commitments are well-formed
   - Input_sum == Output_sum + Fee
   - Values are non-negative"

---

Economic Model

Fees

• Receipt Submission: 0.1 LUX + proof verification cost
• Confidential Transfer: 0.01 LUX + 0.001 LUX per input/output
• Provider Registration: 100 LUX stake (refundable)
• Challenge Bond: 50 LUX (slashed if invalid)

Incentives

• Providers: Earn from Hanzo.network for compute
• Validators: Earn block rewards + tx fees
• Challengers: Earn slashed stakes for valid challenges

---

Security Model

Threat Model

1. Fraudulent Attestations: Provider submits fake proofs
2. Double-Spend: User tries to spend UTXO twice
3. Challenge Spam: Malicious challenges on valid receipts
4. Front-Running: MEV on attestation submissions

Mitigations

1. ZK Proofs: Cryptographic verification of attestations
2. Nullifier DB: Prevents double-spends
3. Challenge Bonds: Economic penalty for spam
4. Encrypted Mempools: Prevents front-running (future)

Quantum Resistance

• Receipt Hashes: SHA-256 → SHA-3 (quantum-safe)
• Signatures: ECDSA → ML-DSA (via P-Chain integration)
• Commitments: Pedersen → Lattice-based (v2)

---

API Endpoints

Attestation APIs

POST /attestation/register      - Register provider
POST /attestation/submit        - Submit receipt
POST /attestation/challenge     - Challenge receipt
GET  /attestation/query         - Query attestations
GET  /attestation/provider/:did - Get provider info

Privacy APIs

POST /privacy/transfer          - Confidential transfer
GET  /privacy/balance           - Get shielded balance
GET  /privacy/utxos             - List available UTXOs

Indexer APIs

GET  /index/providers           - List all providers
GET  /index/jobs                - Query job history
GET  /index/models              - List attested models
GET  /index/datasets            - List attested datasets

---

Implementation Checklist

Phase 1: Core Infrastructure (Mainnet Launch)

• UTXO database
• Nullifier database
• Merkle state tree
• ZK proof verifier framework
• Groth16 verifier integration
• Receipt Circuit v1 implementation
• Attestation registry storage

Phase 2: Transaction Types

• RegisterProviderTx
• SubmitReceiptTx
• ChallengeTx
• SettlementTx
• ConfidentialTransferTx (base)

Phase 3: Integration

• P-Chain PQC signature verification
• Hanzo.network receipt ingestion API
• B-Chain fee routing
• Indexer for attestation queries

Phase 4: Advanced Features (Post-Launch)

• TEE attestation policy
• Receipt Circuit v2 (in-circuit inference)
• Encrypted mempool
• Dispute resolution DAO

---

Testing Requirements

Unit Tests

• UTXO/Nullifier DB operations
• State tree updates
• Transaction validation logic
• Proof verification

Integration Tests

• End-to-end attestation flow
• Challenge and settlement
• Confidential transfer flow
• P-Chain PQC integration

Load Tests

• 1000 TPS attestation submission
• 100 concurrent challenges
• 10K provider registrations

Security Tests

• Double-spend attempts
• Invalid proof submissions
• Challenge spam scenarios
• Front-running attacks

---

Deployment Plan

1. Testnet (Week 1-2)

   • Deploy Z/A-Chain on testnet
   • Public bug bounty
   • Load testing

2. Mainnet Beta (Week 3-4)

   • Limited provider whitelist
   • Manual challenge review
   • Graduated fee reduction

3. Mainnet General Availability (Week 5+)

   • Open provider registration
   • Automated challenge resolution
   • Full feature set

---

References

• ZK-SNARK Explainer
• Groth16 Paper
• Zcash Sapling Protocol
• Lux Consensus
• Hanzo AI Network

---

Maintainers: Lux Core Team
Last Updated: 2025-10-31
Next Review: Pre-Mainnet Launch