Skip to content

Latest commit

 

History

History
695 lines (563 loc) · 24.4 KB

File metadata and controls

695 lines (563 loc) · 24.4 KB

Zcash Integration: Theory, Architecture & Execution Strategy


1. Core Concept: Why Zcash for Compliance Anchoring?

The Problem CompZ Solves

Traditional compliance audits have trust issues:

  • Reports can be backdated
  • Data can be tampered with
  • No way to prove "when" compliance was verified
  • Centralized storage = single point of failure

Why Blockchain?

Blockchain provides:

  • Immutability - Can't change historical records
  • Timestamp proof - Block time proves "when"
  • Decentralization - No single authority
  • Cryptographic verification - Math-based trust

Why Zcash Specifically?

Feature Bitcoin/Ethereum Zcash
Privacy ❌ All data public ✅ Shielded transactions
Memo Field ❌ No native support ✅ 512 bytes per output
Compliance ⚠️ Reveals business logic ✅ Privacy-preserving
Cost 💰 High fees 💰 Low fees (~$0.001)
Speed 🐌 10-15 min blocks 🐌 ~2.5 min blocks

Key Insight: Zcash lets you prove compliance happened without revealing what was checked.


2. Architectural Pattern: Hash Anchoring

The Three-Layer Model

┌─────────────────────────────────────────────┐
│  LAYER 3: APPLICATION (CompZ SDK)           │
│  - Compliance rules                          │
│  - Business logic                            │
│  - Sensitive data                            │
│  [LIVES OFF-CHAIN]                          │
└─────────────────┬───────────────────────────┘
                  │
                  │ SHA-256 hash
                  ▼
┌─────────────────────────────────────────────┐
│  LAYER 2: CRYPTOGRAPHIC COMMITMENT          │
│  - 256-bit hash (32 bytes)                  │
│  - Deterministic fingerprint                │
│  - No reverse engineering possible          │
│  [ANCHORED ON-CHAIN]                        │
└─────────────────┬───────────────────────────┘
                  │
                  │ Zcash memo
                  ▼
┌─────────────────────────────────────────────┐
│  LAYER 1: BLOCKCHAIN (Zcash)               │
│  - Immutable ledger                          │
│  - Timestamp proof                           │
│  - Decentralized consensus                   │
│  [PERMANENT RECORD]                         │
└─────────────────────────────────────────────┘

What Goes On-Chain vs Off-Chain

ON-CHAIN (Zcash blockchain):

  • ✅ Hash: 0xabc123def456... (32 bytes)
  • ✅ Timestamp: Block time
  • ✅ Proof of existence
  • NO sensitive data
  • NO compliance details
  • NO customer information

OFF-CHAIN (Your systems):

  • Full compliance JSON
  • Audit logs
  • Source code snapshots
  • Evidence files
  • Business logic

Security Model: Even if blockchain is public, nobody can reverse-engineer your compliance data from the hash.


3. Zcash Technical Architecture

The Shielded Pool Concept

┌──────────────────────────────────────────────┐
│         ZCASH TRANSACTION TYPES              │
├──────────────────────────────────────────────┤
│                                              │
│  ┌─────────────┐         ┌─────────────┐   │
│  │ Transparent │         │  Shielded   │   │
│  │   (t-addr)  │         │   (z-addr)  │   │
│  │             │         │             │   │
│  │ - Public    │         │ - Private   │   │
│  │ - Like BTC  │         │ - Encrypted │   │
│  │ - NO memo   │         │ - HAS memo  │   │
│  │ - Fast      │    VS   │ - Slower    │   │
│  │ - Simple    │         │ - Complex   │   │
│  │             │         │ - zk-SNARKs │   │
│  └─────────────┘         └─────────────┘   │
│                                              │
└──────────────────────────────────────────────┘

Why Shielded Transactions Matter

Scenario: You anchor compliance for "Project Alpha"

With Transparent (t-addr):

  • ❌ Everyone sees: wallet address, amount, timestamp
  • ❌ Can link multiple compliance checks
  • ❌ Competitors can track your audit schedule
  • ❌ No place for memo data (need hacky solutions)

With Shielded (z-addr):

  • ✅ Transaction details hidden
  • ✅ Only you can read the memo
  • ✅ Can't link to other transactions
  • ✅ Native 512-byte memo field
  • ✅ Still verifiable by third parties (if you share keys)

4. The Memo Field: Your Data Carrier

What is a Memo?

Think of it as a encrypted post-it note attached to money:

┌──────────────────────────────────┐
│  ZCASH SHIELDED TRANSACTION      │
├──────────────────────────────────┤
│                                  │
│  From: ztestsapling1abc...       │
│  To:   ztestsapling1xyz...       │
│  Amount: 0.0001 ZEC              │
│                                  │
│  ┌────────────────────────────┐ │
│  │ MEMO (512 bytes)           │ │
│  │                            │ │
│  │ compz:v1:0xabc123def...    │ │
│  │                            │ │
│  │ (encrypted, only visible   │ │
│  │  to sender/receiver)       │ │
│  └────────────────────────────┘ │
│                                  │
└──────────────────────────────────┘

Memo Design Pattern for CompZ

FORMAT: compz:v1:<hash>

BREAKDOWN:
- "compz:"     = Protocol identifier (namespace)
- "v1:"        = Version (future-proofing)
- "<hash>"     = SHA-256 hash (0x prefix + 64 hex chars)

EXAMPLES:
✅ compz:v1:0xabc123...
✅ compz:v2:0xdef456...  (future version)
❌ random text          (not parseable)
❌ just a hash          (no version info)

Why Version Prefix?

  • Future upgrades (v2 might use different hash algorithm)
  • Backward compatibility
  • Easy filtering on-chain explorers

5. Transaction Flow: Step-by-Step

Anchoring Flow (Write Operation)

STEP 1: PREPARE DATA
┌─────────────────────────────────┐
│ Compliance Result JSON          │
│ {                               │
│   "repo_id": "myrepo",          │
│   "frameworks": ["PCI"],        │
│   "controls": [...]             │
│ }                               │
└────────────┬────────────────────┘
             │
             ▼
STEP 2: NORMALIZE (Canonical JSON)
┌─────────────────────────────────┐
│ Remove metadata                 │
│ Sort keys alphabetically        │
│ Remove whitespace               │
│ UTF-8 NFC normalization         │
└────────────┬────────────────────┘
             │
             ▼
STEP 3: HASH (SHA-256)
┌─────────────────────────────────┐
│ 0xabc123def456789abcdef...      │
│ (deterministic, 256-bit)        │
└────────────┬────────────────────┘
             │
             ▼
STEP 4: FORMAT MEMO
┌─────────────────────────────────┐
│ "compz:v1:0xabc123..."          │
└────────────┬────────────────────┘
             │
             ▼
STEP 5: SEND TO ZCASH
┌─────────────────────────────────┐
│ z_sendmany(                     │
│   from: my_zaddr,               │
│   to: my_zaddr,  (send to self) │
│   amount: 0.0001 ZEC,           │
│   memo: "compz:v1:0x..."        │
│ )                               │
└────────────┬────────────────────┘
             │
             ▼
STEP 6: WAIT FOR CONFIRMATION
┌─────────────────────────────────┐
│ Block mined (~2.5 min)          │
│ Transaction ID (txid) returned  │
└────────────┬────────────────────┘
             │
             ▼
STEP 7: RECORD PROOF
┌─────────────────────────────────┐
│ Store in your database:         │
│ {                               │
│   "compliance_id": "...",       │
│   "hash": "0xabc123...",        │
│   "txid": "9c8f7e6d...",        │
│   "block_height": 2500123,      │
│   "timestamp": "2024-01-01..."  │
│ }                               │
└─────────────────────────────────┘

Verification Flow (Read Operation)

STEP 1: RECEIVE CLAIM
┌─────────────────────────────────┐
│ User claims:                    │
│ "We passed PCI audit on Jan 1"  │
│                                 │
│ Provides:                       │
│ - compliance_result.json        │
│ - txid: 9c8f7e6d...             │
└────────────┬────────────────────┘
             │
             ▼
STEP 2: RECOMPUTE HASH LOCALLY
┌─────────────────────────────────┐
│ Take their JSON                 │
│ → normalize()                   │
│ → hash()                        │
│ = 0xabc123... (local_hash)      │
└────────────┬────────────────────┘
             │
             ▼
STEP 3: FETCH FROM BLOCKCHAIN
┌─────────────────────────────────┐
│ Query Zcash node:               │
│ z_viewtransaction(txid)         │
│                                 │
│ Extract memo from output:       │
│ "compz:v1:0xabc123..."          │
└────────────┬────────────────────┘
             │
             ▼
STEP 4: COMPARE
┌─────────────────────────────────┐
│ local_hash  == onchain_hash?    │
│ 0xabc123... == 0xabc123...      │
│                                 │
│ ✅ MATCH = Valid proof          │
│ ❌ MISMATCH = Tampered data     │
└────────────┬────────────────────┘
             │
             ▼
STEP 5: CHECK TIMESTAMP
┌─────────────────────────────────┐
│ Get block timestamp:            │
│ Block 2500123 mined at:         │
│ 2024-01-01 10:30:00 UTC         │
│                                 │
│ Proves: Compliance existed      │
│         BEFORE this time        │
└─────────────────────────────────┘

6. Infrastructure Architecture

Deployment Model Options

Option A: Self-Hosted Full Node (Maximum Control)

┌──────────────────────────────────────────┐
│         YOUR INFRASTRUCTURE              │
├──────────────────────────────────────────┤
│                                          │
│  ┌────────────────┐                     │
│  │  CompZ API     │                     │
│  │  (FastAPI)     │                     │
│  └───────┬────────┘                     │
│          │                               │
│          │ JSON-RPC                      │
│          ▼                               │
│  ┌────────────────┐                     │
│  │  zcashd Node   │◄─────── Syncs       │
│  │  (testnet)     │         with        │
│  │                │         network      │
│  │  - Full chain  │                     │
│  │  - Your wallet │                     │
│  │  - Private     │                     │
│  └────────────────┘                     │
│                                          │
└──────────────────────────────────────────┘

PROS:
✅ Full control
✅ No dependencies
✅ Can read all memos
✅ Audit-ready

CONS:
❌ Requires ~50GB storage (testnet)
❌ Sync time ~2-4 hours
❌ Maintenance overhead
❌ Server costs

Option B: Hybrid (Public RPC + Light Client)

┌──────────────────────────────────────────┐
│         YOUR INFRASTRUCTURE              │
├──────────────────────────────────────────┤
│                                          │
│  ┌────────────────┐                     │
│  │  CompZ API     │                     │
│  └───────┬────────┘                     │
│          │                               │
│          │ gRPC                          │
│          ▼                               │
│  ┌────────────────┐                     │
│  │ Lightwalletd   │                     │
│  │ Public RPC     │◄─────── Internet    │
│  └────────────────┘                     │
│                                          │
│  ┌────────────────┐                     │
│  │  Local Wallet  │                     │
│  │  (keys only)   │                     │
│  └────────────────┘                     │
│                                          │
└──────────────────────────────────────────┘

PROS:
✅ Fast setup (minutes)
✅ Low storage
✅ No sync required
✅ Lower costs

CONS:
❌ Depends on external service
❌ Privacy concerns (IP exposure)
❌ Rate limits possible
❌ Less reliable

Option C: Managed Service (Future)

┌──────────────────────────────────────────┐
│         COMPZ CLOUD SERVICE              │
├──────────────────────────────────────────┤
│                                          │
│  Your API Key → CompZ Managed Nodes     │
│                                          │
│  [Abstract away all blockchain stuff]   │
│                                          │
└──────────────────────────────────────────┘

PROS:
✅ Zero setup
✅ Just API calls
✅ SLA guarantees
✅ Turnkey solution

CONS:
❌ Trust third party
❌ Subscription cost
❌ Less control

Recommendation for v1: Option A (Self-hosted) for credibility and demos.


7. Key Design Decisions

Decision 1: Transparent vs Shielded

Consideration Transparent Shielded
Privacy Public Private
Memo support No (need OP_RETURN hack) Yes (native)
Speed Fast Slower (zk-SNARK proof)
Complexity Simple Complex
CompZ choice

Rationale: Privacy is core value prop. Competitors shouldn't see your audit schedule.


Decision 2: Send to Self vs Third Party

OPTION A: Send to Self
┌──────────────────┐
│  Your z-address  │────┐
│                  │    │
│  my_zaddr_1      │◄───┘ (loop back)
└──────────────────┘

PROS:
✅ Keep all ZEC in your wallet
✅ No need for recipient address
✅ Can read memos anytime

CONS:
❌ Looks like "self-dealing"
❌ All eggs in one basket
OPTION B: Send to Archive Address
┌──────────────────┐     ┌──────────────────┐
│  Your z-address  │────►│  Archive z-addr  │
│                  │     │  (cold storage)   │
│  my_zaddr_1      │     │  archive_zaddr   │
└──────────────────┘     └──────────────────┘

PROS:
✅ Clear separation
✅ Immutable archive
✅ Can be multisig

CONS:
❌ Lose funds (intentional burn)
❌ More complex key management

Recommendation: Send to self for v1 (simpler, recyclable).


Decision 3: Memo Encoding Format

OPTION A: Plain Text
"compz:v1:0xabc123..."

PROS:
✅ Human readable
✅ Easy debugging
✅ Simple parsing

CONS:
❌ Limited to UTF-8
❌ No binary data
OPTION B: JSON
{"protocol":"compz","version":1,"hash":"0x..."}

PROS:
✅ Structured data
✅ Extensible

CONS:
❌ Wastes space
❌ Harder to parse
❌ Overkill for simple hash
OPTION C: Binary (CBOR/Protobuf)
[binary encoding of structured data]

PROS:
✅ Space efficient
✅ Strongly typed

CONS:
❌ Not human readable
❌ Requires decoder
❌ Too complex for v1

Recommendation: Plain text (Option A) - simplicity wins.


8. Security Model & Trust Architecture

Threat Model

What CompZ DOES protect against:

  • Backdating audits: Blockchain timestamp proves "when"
  • Data tampering: Hash mismatch detects changes
  • Repudiation: Can't deny on-chain record exists
  • Data loss: Blockchain backup (hash survives)

What CompZ DOES NOT protect against:

  • Bad initial data: Garbage in, garbage out
  • Compromised keys: Attacker can create false proofs
  • 51% attack: Theoretical blockchain risk
  • Quantum computing: SHA-256 vulnerable (far future)

Trust Boundaries

┌─────────────────────────────────────────┐
│  TRUST LEVEL 1: No Trust Needed         │
│  ─────────────────────────────          │
│  Anyone can verify hash on blockchain   │
│  Math-based, no human in the loop       │
└─────────────────────────────────────────┘

┌─────────────────────────────────────────┐
│  TRUST LEVEL 2: Trust the Data          │
│  ─────────────────────────────          │
│  Auditor must trust the compliance      │
│  JSON represents reality                │
│  (Solved by AI/rules in evaluator.py)  │
└─────────────────────────────────────────┘

┌─────────────────────────────────────────┐
│  TRUST LEVEL 3: Trust the Process       │
│  ─────────────────────────────────────  │
│  Auditor must trust CompZ SDK code      │
│  hasn't been modified                   │
│  (Solved by open-source + reproducible) │
└─────────────────────────────────────────┘

9. Execution Roadmap

Phase 1: Proof of Concept (2-3 days)

Goal: Demonstrate basic anchoring works

Tasks:

  1. Spin up Zcash testnet node (Docker)
  2. Create z-address, get testnet funds
  3. Manually send transaction with memo
  4. Verify can retrieve memo back
  5. Document txid for demos

Deliverable: Working testnet transaction with CompZ memo format


Phase 2: SDK Development (3-4 days)

Goal: Package as reusable library

Tasks:

  1. Build Python modules (normalize, hash, client)
  2. Create CLI tools (compz-anchor, compz-verify)
  3. Write unit tests
  4. Package as pip-installable library

Deliverable: pip install compz works


Phase 3: API Gateway (2-3 days)

Goal: REST API for integrations

Tasks:

  1. FastAPI endpoints
  2. Request/response schemas
  3. Error handling
  4. API documentation (auto-generated)

Deliverable: Swagger UI at /docs


Phase 4: Production Hardening (2-3 days)

Goal: Make it audit-ready

Tasks:

  1. Comprehensive error handling
  2. Retry logic for Zcash RPC
  3. Logging & monitoring
  4. Security audit (keys, inputs)
  5. Performance testing

Deliverable: Production-ready system


10. Success Metrics & Demo Strategy

Technical Proof Points

✅ ANCHOR: Deterministic hashing works
   - Same JSON → always same hash
   - Different JSON → different hash

✅ ANCHOR: Zcash integration works
   - Testnet transactions successful
   - Memos retrievable

✅ VERIFY: End-to-end flow works
   - Anchor → wait → verify → valid

✅ VERIFY: Tamper detection works
   - Change 1 field → verification fails

✅ SCALE: Performance acceptable
   - < 5 sec to anchor (excluding block time)
   - < 2 sec to verify

Demo Narrative

Act 1: The Problem (30 sec)

"Traditional compliance audits are PDFs and Excel sheets. Easy to forge, backdate, or lose."

Act 2: The Solution (60 sec)

"CompZ creates cryptographic proof anchored to Zcash blockchain. Here's a live demo..." [Run CLI command, show txid, check on block explorer]

Act 3: The Verification (60 sec)

"Now anyone can verify. I'll change one character in the JSON..." [Show verification failing] "See? Tamper-proof."

Act 4: The Value (30 sec)

"Your auditors trust math, not Excel. Privacy-preserving, immutable, verifiable."


Next Execution Steps

Ready to build? Here's your action plan:

  1. Set up Zcash testnet node (1 hour)

    • Docker compose file
    • Wait for sync
  2. Manual transaction test (30 min)

    • Send first memo
    • Verify retrieval
  3. Build normalize + hash modules (2 hours)

    • Core logic
    • Unit tests
  4. Build Zcash client wrapper (3 hours)

    • RPC abstraction
    • Error handling
  5. Integration test (1 hour)

    • End-to-end flow
    • Real testnet txid

Want me to start building any of these components?