67x Proof Cache Speedup:
Intelligent Cryptographic Caching

Cryptographic proof verification is computationally intensive. But most applications repeatedly verify the same types of proofs for the same users. H33's intelligent proof caching eliminates this redundancy, delivering 67x faster verification for cached proofs.

The Cost of Repeated Verification

Every authentication event in a post-quantum system requires non-trivial computation. H33's full pipeline performs BFV fully homomorphic encryption over encrypted biometric templates, a ZK proof lookup for identity binding, and a Dilithium signature for attestation. On a single call, this runs in approximately 42 microseconds per user on Graviton4 hardware — fast by any standard. But when the same user authenticates dozens or hundreds of times per session, re-running the full cryptographic stack for every request is wasteful.

Consider a trading platform where a user authenticates at session start, then issues hundreds of API calls per minute. Or a collaborative document editor where each keystroke-sync triggers an access-control check. In these patterns, 80–90% of verification requests come from users whose proofs have already been validated within the last few minutes. Without caching, every one of those requests incurs the full cost of FHE inner product, ZKP validation, and Dilithium verify.

How It Works

When H33 verifies a ZK proof, we don't just validate and discard—we extract a cryptographic fingerprint and cache it:

• Proof fingerprinting: Each proof gets a unique, collision-resistant identifier derived from a SHA3-256 digest of the proof payload, user context, and a server-side nonce
• Validity window: Cached proofs remain valid for configurable duration (default: 60 seconds for high-security, up to 1 hour for session-based flows)
• Context binding: Cache entries are bound to user, device, and session context—changing any of these parameters forces a fresh verification
• Secure invalidation: Any context change automatically invalidates cached entries, and all entries carry a monotonic counter to prevent replay

Security Guarantees

Caching doesn't compromise security. Our cache system maintains full cryptographic guarantees:

• No proof reuse attacks: Cache entries include nonces and timestamps. Each entry is valid only for the exact (user, device, session) triple that produced it
• Tamper detection: Any modification invalidates the cache entry. The fingerprint is a commitment—altering any input bit produces a completely different hash
• Context isolation: Users cannot access each other's cached proofs. The DashMap is keyed on a per-user namespace with no cross-tenant leakage
• Automatic expiration: Stale entries are cryptographically invalidated using a time-bound HMAC that becomes unverifiable after the TTL window closes

// Cache-aware verification
const result = await h33.proof.verify({
  proof: userProof,
  cachePolicy: {
    enabled: true,
    maxAge: '1h',
    contextBinding: ['userId', 'deviceId']
  }
});

// First call: full verification (~42µs)
// Subsequent calls: cache hit (~0.6µs, 67x faster)

Cache Architecture

H33's proof cache is a multi-tier system optimized for different access patterns:

• L1 (In-memory DashMap): Hot proofs from active sessions—sub-microsecond access at 0.085µs per lookup, zero TCP overhead
• L2 (Redis): Recent proofs across the cluster—microsecond access for distributed deployments
• L3 (Persistent): Long-term proof history for audit trails and compliance reporting

Smart prefetching predicts which proofs will be needed and warms the cache proactively. When a user establishes a session, H33 preloads their recent proof fingerprints into L1 so the first re-verification is already a cache hit.

Why In-Process DashMap Wins at Scale

Early versions of the proof cache used a TCP-based RESP proxy (Redis protocol) for the L1 layer. Under light load, this worked well. But at 96 concurrent workers on Graviton4 metal instances, the single TCP proxy serialized all connections and became a catastrophic bottleneck—throughput collapsed from 1.51M auth/sec to just 136K, an 11x regression.

The solution was replacing the TCP proxy with an in-process DashMap (a concurrent hash map with per-shard locking). The result: 0.085 microsecond lookups with zero contention, even under full 96-worker load. This single architectural change pushed production throughput to 2,172,518 auth/sec—a 5.5% improvement over running raw ZKP verification with no cache at all.

When to Use Caching

Proof caching is most effective for:

• Session-based applications: Users authenticate once, then perform many actions—each subsequent action validates against cache in under a microsecond
• Real-time systems: Games, collaboration tools, and trading platforms where latency directly impacts user experience
• Mobile applications: Where every millisecond of battery life matters and reducing cryptographic computation translates directly to lower power draw
• High-frequency verification: API rate limiting, access control checks, and microservice-to-microservice auth where the same identity is verified thousands of times per minute

On a typical SaaS application with 10,000 daily active users, proof caching reduces total verification CPU time by approximately 85%, because the vast majority of auth checks are repeat verifications within active sessions.

Performance Impact

In typical applications where 80-90% of verifications are for returning users, proof caching delivers dramatic improvements:

These aren't theoretical numbers—they're measured across our production infrastructure on c8g.metal-48xl instances running 96 Graviton4 cores. See the full benchmark results for detailed methodology and hardware specifications. The 67x speedup applies to individual cache hits (0.085µs vs. the full ~5.7µs ZKP path). Blended across a realistic workload with 80–90% cache hit rates, the aggregate improvement is what drives the throughput and CPU numbers above.

Integration in One Line

Proof caching requires no configuration changes for most deployments. It is enabled by default on all H33 plans and automatically selects the optimal cache backend based on your infrastructure:

// Single-instance deployment: in-process DashMap (default)
// Multi-container deployment: set CACHEE_MODE=tcp for shared cache
// Custom TTL: override per-request with cachePolicy.maxAge

const auth = await h33.auth.verify({
  biometric: encryptedTemplate,   // BFV FHE encrypted
  proof: zkProof,                 // ZK identity binding
  attestation: dilithiumSig,      // Dilithium signature
  cachePolicy: { maxAge: '5m' }  // optional override
});

For single-instance deployments, H33 defaults to in-process DashMap with zero configuration. For distributed deployments spanning multiple containers, setting CACHEE_MODE=tcp enables a shared Redis-backed cache that synchronizes proof fingerprints across the cluster. The API surface is identical in both modes—only the backend transport changes.