Skip to content

zk-proofs-scalability.md

Latest commit

 

History

History
140 lines (104 loc) · 5.11 KB

zk-proofs-scalability.md

File metadata and controls

140 lines (104 loc) · 5.11 KB

Use Case: Zero-Knowledge Proofs for Scalability and Privacy

Problem

The blockchain SQL database (RFC-0101, RFC-0102, RFC-0103) provides verifiable state and Merkle proofs, but faces three fundamental limitations:

  1. Proof Bandwidth - Verifying N rows requires N separate HexaryProofs (~68 bytes each)
  2. No Privacy - All data and queries are public on-chain
  3. Limited Throughput - Every transaction executes on-chain, constraining TPS

As the database grows and more applications build on Stoolap Chain, these limitations become critical bottlenecks.

Motivation

Zero-knowledge proofs enable three transformative capabilities:

1. Proof Compression (Scalability)

  • Aggregate 100+ HexaryProofs into a single STARK proof (~10KB vs ~6.8KB)
  • Verify batch of operations with one cryptographic verification
  • Reduce bandwidth by ~90% for large queries
  • Enable lightweight clients to verify complex queries efficiently

2. Confidential Queries (Privacy)

  • Prove query results without revealing underlying data
  • Enable private business logic (e.g., "is user creditworthy?" without revealing credit history)
  • Selective disclosure: prove value constraints without exposing actual values
  • Compliance-friendly: verify data access without leaking sensitive information

3. L2 Scaling (Throughput)

  • Execute thousands of transactions off-chain
  • Post single validity proof to Stoolap Chain
  • Achieve 1000+ TPS vs ~100 TPS on-chain
  • Preserve verifiability while increasing capacity

Impact

If implemented, this enables:

  1. Enterprise Adoption - Private database operations with public verifiability
  2. High-Volume Applications - DeFi order books, gaming worlds with millions of state changes
  3. Regulatory Compliance - Prove data handling without revealing customer data
  4. Cross-Chain Bridges - Compressed proofs for efficient cross-chain state sync
  5. Mobile Clients - Full verification with minimal bandwidth

Target Users

Privacy-Requiring Applications

  • Healthcare - Verify patient eligibility without revealing medical history
  • Financial Services - Credit checks, KYC verification with data minimization
  • Enterprise - Confidential business analytics with auditability

High-Volume Applications

  • DeFi Protocols - High-frequency trading with compressed proof batches
  • Gaming - MMOs with millions of state updates per day
  • Social Networks - Private messaging with spam prevention proofs

Infrastructure Providers

  • Rollup Operators - Run L2 networks settling to Stoolap Chain
  • Data Availability Layers - Provide storage with ZK proof access

Technical Approach

Why STWO and Cairo?

STWO (Circle STARK prover/verifier):

  • Written in Rust (native integration with Stoolap Chain)
  • State-of-the-art proving performance
  • Actively maintained by Starkware

Cairo (provable programming language):

  • Turing-complete for arbitrary logic
  • Compiles to CASM for STWO proving
  • On-chain verification via Cairo VM
  • Growing ecosystem and developer community

Why Cairo Contract Verification?

  • Simplicity - No consensus changes needed
  • Flexibility - Upgradeable verification logic
  • Safety - Cairo VM provides sandboxed execution
  • Ecosystem - Leverages existing Cairo tooling

Phased Delivery

Phase 1: Proof Compression

  • Enables bandwidth-efficient verification
  • Foundation for subsequent phases
  • Immediate value for data-heavy applications

Phase 2: Confidential Queries

  • Adds privacy layer
  • Enables enterprise adoption
  • Leverages Phase 1 compression

Phase 3: L2 Scaling

  • Maximum throughput
  • Requires Phases 1+2 infrastructure
  • Enables new application categories

Related RFCs (Proposed)

  • RFC-0301 - STWO Integration and Cairo Program Registry
  • RFC-0302 - Compressed Proof Format
  • RFC-0303 - Confidential Query Operations
  • RFC-0304 - L2 Rollup Protocol

Non-Goals

  • This does NOT replace HexaryProofs for basic verification
  • This does NOT provide anonymity by default (confidentiality ≠ anonymity)
  • This does NOT solve data availability (layer below state)
  • This does NOT eliminate the need for on-chain execution entirely

Success Criteria

Phase 1: Compression

  • STARK proof verifies 100+ row inclusions
  • Proof generation <1s for 100 rows
  • Proof size <10KB (vs ~6.8KB for uncompressed)
  • Verification time <100ms on Cairo VM

Phase 2: Confidential Queries

  • Prove query result without revealing inputs
  • Zero-knowledge property verified formally
  • Query proof <500ms to generate

Phase 3: L2 Scaling

  • 1000+ transactions per second
  • Finality time <1 minute
  • Batch proof <50KB for 1000 transactions

Risks and Mitigations

Risk Impact Mitigation
STWO prover too slow High Benchmark early, have fallback to HexaryProofs
Cairo VM verification expensive Medium Optimize programs, gas meter appropriately
Proof size exceeds expectations Medium Compression techniques, size limits
Complexity increases attack surface High Formal verification, staged rollout, bug bounties
STWO/Cairo breaking changes Low Version pinning, upgrade path design