c8be9d7414
- 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
182 lines
5.2 KiB
Markdown
182 lines
5.2 KiB
Markdown
# 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
|