oib/aitbc
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
aitbc/docs/reference/zk-technology-comparison.md
oib c8be9d7414 feat: add marketplace metrics, privacy features, and service registry endpoints 
- Add Prometheus metrics for marketplace API throughput and error rates with new dashboard panels
- Implement confidential transaction models with encryption support and access control
- Add key management system with registration, rotation, and audit logging
- Create services and registry routers for service discovery and management
- Integrate ZK proof generation for privacy-preserving receipts
- Add metrics instru
2025-12-22 10:33:23 +01:00

5.2 KiB
Raw Blame History

ZK Technology Comparison for Receipt Attestation

Overview

Analysis of zero-knowledge proof systems for AITBC receipt attestation, focusing on practical considerations for integration with existing infrastructure.

Technology Options

1. zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge)

Examples: Groth16, PLONK, Halo2

Pros:

  • Small proof size: ~200 bytes for Groth16
  • Fast verification: Constant time, ~3ms on-chain
  • Mature ecosystem: circom, snarkjs, bellman, arkworks
  • Low gas costs: ~200k gas for verification on Ethereum
  • Industry adoption: Used by Aztec, Tornado Cash, Zcash

Cons:

  • Trusted setup: Required for Groth16 (toxic waste problem)
  • Longer proof generation: 10-30 seconds depending on circuit size
  • Complex setup: Ceremony needs multiple participants
  • Quantum vulnerability: Not post-quantum secure

2. zk-STARKs (Zero-Knowledge Scalable Transparent Argument of Knowledge)

Examples: STARKEx, Winterfell, gnark

Pros:

  • No trusted setup: Transparent setup process
  • Post-quantum secure: Resistant to quantum attacks
  • Faster proving: Often faster than SNARKs for large circuits
  • Transparent: No toxic waste, fully verifiable setup

Cons:

  • Larger proofs: ~45KB for typical circuits
  • Higher verification cost: ~500k-1M gas on-chain
  • Newer ecosystem: Fewer tools and libraries
  • Less adoption: Limited production deployments

Use Case Analysis

Receipt Attestation Requirements

  1. Proof Size: Important for on-chain storage costs
  2. Verification Speed: Critical for settlement latency
  3. Setup Complexity: Affects deployment timeline
  4. Ecosystem Maturity: Impacts development speed
  5. Privacy Needs: Moderate (hiding amounts, not full anonymity)

Quantitative Comparison

Metric Groth16 (SNARK) PLONK (SNARK) STARK
Proof Size 200 bytes 400-500 bytes 45KB
Prover Time 10-30s 5-15s 2-10s
Verifier Time 3ms 5ms 50ms
Gas Cost 200k 300k 800k
Trusted Setup Yes Universal No
Library Support Excellent Good Limited

Recommendation

Phase 1: Groth16 for MVP

Rationale:

  1. Proven technology: Battle-tested in production
  2. Small proofs: Essential for cost-effective on-chain verification
  3. Fast verification: Critical for settlement performance
  4. Tool maturity: circom + snarkjs ecosystem
  5. Community knowledge: Extensive documentation and examples

Mitigations for trusted setup:

  • Multi-party ceremony with >100 participants
  • Public documentation of process
  • Consider PLONK for Phase 2 if setup becomes bottleneck

Phase 2: Evaluate PLONK

Rationale:

  • Universal trusted setup (one-time for all circuits)
  • Slightly larger proofs but acceptable
  • More flexible for circuit updates
  • Growing ecosystem support

Phase 3: Consider STARKs

Rationale:

  • If quantum resistance becomes priority
  • If proof size optimizations improve
  • If gas costs become less critical

Implementation Strategy

Circuit Complexity Analysis

Basic Receipt Circuit:

  • Hash verification: ~50 constraints
  • Signature verification: ~10,000 constraints
  • Arithmetic operations: ~100 constraints
  • Total: ~10,150 constraints

With Privacy Features:

  • Range proofs: ~1,000 constraints
  • Merkle proofs: ~1,000 constraints
  • Additional checks: ~500 constraints
  • Total: ~12,650 constraints

Performance Estimates

Groth16:

  • Setup time: 2-5 hours
  • Proving time: 5-15 seconds
  • Verification: 3ms
  • Proof size: 200 bytes

Infrastructure Impact:

  • Coordinator: Additional 5-15s per receipt
  • Settlement layer: Minimal impact (fast verification)
  • Storage: Negligible increase

Security Considerations

Trusted Setup Risks

  1. Toxic Waste: If compromised, can forge proofs
  2. Setup Integrity: Requires honest participants
  3. Documentation: Must be publicly verifiable

Mitigation Strategies

  1. Multi-party Ceremony:

    • Minimum 100 participants
    • Geographically distributed
    • Public livestream

  2. Circuit Audits:

    • Formal verification where possible
    • Third-party security review
    • Public disclosure of circuits

  3. Gradual Rollout:

    • Start with low-value transactions
    • Monitor for anomalies
    • Emergency pause capability

Development Plan

Week 1-2: Environment Setup

  • Install circom and snarkjs
  • Create basic test circuit
  • Benchmark proof generation

Week 3-4: Basic Circuit

  • Implement receipt hash verification
  • Add signature verification
  • Test with sample receipts

Week 5-6: Integration

  • Add to coordinator API
  • Create verification contract
  • Test settlement flow

Week 7-8: Trusted Setup

  • Plan ceremony logistics
  • Prepare ceremony software
  • Execute multi-party setup

Week 9-10: Testing & Audit

  • End-to-end testing
  • Security review
  • Performance optimization

Next Steps

  1. Immediate: Set up development environment
  2. Research: Deep dive into circom best practices
  3. Prototype: Build minimal viable circuit
  4. Evaluate: Performance with real receipt data
  5. Decide: Final technology choice based on testing