H33 vs RISC Zero

H33 and RISC Zero represent two fundamentally different approaches to the same goal: ensuring that computations are performed correctly and can be verified by third parties. Understanding the differences requires understanding what each system actually does, what guarantees it provides, and where each approach excels or falls short in practice.

The Approaches

H33: FHE + STARK. H33 combines fully homomorphic encryption (which allows computation on encrypted data) with STARK proofs (which prove the computation was performed correctly). The data remains encrypted throughout the computation. The STARK proof attests to the correctness of the encrypted computation. The three-family post-quantum signature scheme attests to the authenticity of the proof. The result is a system where data is never exposed AND the computation is mathematically verified.

RISC Zero: zkVM. RISC Zero provides a zero-knowledge virtual machine that executes arbitrary RISC-V programs and generates a STARK proof of correct execution. The prover runs the program with the inputs and produces a proof that the execution followed the program's logic correctly. The verifier checks the proof without re-executing the program. The key property: the prover has access to the plaintext inputs (they need to run the program), but the verifier learns only what the proof reveals.

Privacy Guarantees

This is the fundamental difference. In H33's model, the computation server never sees plaintext data. FHE ensures that the server operates exclusively on encrypted ciphertexts. Even a fully compromised server cannot extract the underlying data because it never possesses the decryption key. The privacy guarantee is unconditional: it does not depend on the server's behavior or trustworthiness.

In RISC Zero's model, the prover must have access to plaintext inputs to execute the program. The privacy guarantee is for the verifier, not the computation provider. The verifier learns only the proven statement without seeing the inputs. But the prover (the party running the computation) has full access to all inputs. This is a different threat model: it protects against verifier curiosity but not against prover compromise.

For biometric authentication, this distinction is critical. H33's model means the authentication server never sees biometric templates. RISC Zero's model would require the authentication server to have plaintext access to templates in order to execute the matching program, then prove the execution was correct. The server sees the biometrics. The proof hides them from verifiers but not from the server itself.

Computation Model

RISC Zero's zkVM can prove any program that compiles to RISC-V. This generality is powerful: developers write standard Rust code, compile it to RISC-V, and get proofs of correct execution without modifying their programs. The computation model is familiar (it is just a CPU executing instructions), and the proof system handles the translation from execution trace to mathematical proof automatically.

H33's FHE model requires expressing computations in terms of homomorphic operations (additions and multiplications on ciphertexts). Not every program translates naturally to this model. Control flow (if/else branches) is particularly challenging because FHE operates on encrypted data where the branch condition is unknown. H33's FHE-IQ engine handles this translation for supported workloads, but the set of efficiently expressible computations is more constrained than a general-purpose zkVM.

For workloads that fit the FHE model well (vectorized arithmetic, inner products, polynomial evaluation), H33's batched FHE is extremely efficient. For workloads with complex control flow (parsers, interpreters, general business logic), RISC Zero's zkVM is more natural.

Post-Quantum Security

Both systems use STARK proofs, which are hash-based and quantum-resistant for the proof verification component. H33 adds post-quantum security for the data privacy component through lattice-based FHE, and for the attestation component through three-family PQ signatures. RISC Zero's data privacy relies on the prover's trustworthiness rather than encryption, so the quantum-resistance question applies differently.

Performance Characteristics

H33 excels at batched parallel operations. The BFV SIMD batching processes 32 operations in a single ciphertext operation. For workloads like biometric matching where many independent matches happen simultaneously, this parallelism is extremely efficient.

RISC Zero excels at proving complex sequential programs. The zkVM overhead is proportional to the number of CPU cycles executed, not the complexity of any single operation. For programs with many sequential steps but low parallelism, the zkVM model is more natural than FHE.

The Complementary Case

These approaches are not mutually exclusive. FHE can encrypt the inputs, ensuring the computation server never sees plaintext. A zkVM can then prove that the FHE computation was performed correctly on those encrypted inputs. This combination provides both data privacy (from FHE) and computation correctness verification (from the zkVM proof), addressing both threat models simultaneously.

H33's architecture already combines elements of both approaches: FHE for encrypted computation and STARKs for computation verification. The key architectural decision is where data privacy sits. In H33's model, privacy is in the encryption layer (mathematical guarantee). In a pure zkVM model, privacy is in the proof system (the verifier does not see inputs). The right choice depends on whether your threat model requires protecting data from the computation server or from external verifiers.

Use Case Analysis

The choice between H33's FHE+STARK approach and RISC Zero's zkVM approach depends on the specific use case and threat model. Let us analyze several common scenarios.

Biometric authentication: H33 is the clear choice. The threat model requires protecting biometric data from the authentication server, which FHE provides. A zkVM approach would require the server to see plaintext biometrics to execute the matching program, which defeats the privacy purpose. The proof of correct matching is a secondary benefit; the primary benefit is that the server never sees the biometric data.

Verifiable computation on public data: RISC Zero is the better choice. If the input data is not sensitive (publicly available financial data, blockchain state, open datasets), there is no need for FHE's encryption overhead. A zkVM can prove the computation was correct more efficiently because it does not need to operate on encrypted ciphertexts.

Private ML inference: H33's FHE approach is preferred when the model input is sensitive (medical images, personal financial data). RISC Zero's zkVM is preferred when the model weights are sensitive but the input is not (proving that a proprietary model produced a specific output without revealing the model). The threat model determines the choice: protect the input (use FHE) or protect the model (use zkVM).

Regulatory compliance verification: Both approaches work, but ZKPs without encryption (RISC Zero's model) are simpler for cases where the prover is a trusted party proving compliance to an external verifier. FHE is needed when the compliance verification must be performed by an untrusted third party on the regulated entity's encrypted data.

Ecosystem and Developer Experience

RISC Zero offers an outstanding developer experience for general-purpose verified computation. Developers write standard Rust code, the zkVM handles the cryptographic proof generation, and the verification is automatic. The learning curve is minimal for developers already familiar with Rust. The ecosystem includes guest programs, host programs, and a growing library of verified computation templates.

H33 offers a different developer experience optimized for encrypted computation. The API abstracts FHE operations behind familiar programming patterns, and FHE-IQ handles parameter selection automatically. The learning curve is minimal for the common use cases (biometric auth, encrypted search, encrypted analytics) where the SDK provides ready-to-use components. Custom FHE circuits require more cryptographic understanding but are needed only for specialized workloads.

Both ecosystems are actively developed with strong communities. RISC Zero benefits from the broader zkVM ecosystem including Succinct, Boundless, and other zkVM projects. H33 benefits from the broader FHE ecosystem including academic research, NIST standardization efforts, and the growing adoption of lattice-based cryptography.

Future Convergence

The distinction between FHE+STARK and zkVM approaches may narrow over time. Research into verifiable FHE (using a zkVM to prove that FHE operations were performed correctly on encrypted data) would combine the privacy of FHE with the computation correctness of zkVMs. Research into encrypted zkVMs (using FHE to encrypt the inputs to a zkVM execution) would add data privacy to the zkVM model.

H33's architecture is designed for this convergence. The modular pipeline separates encryption (FHE layer), computation verification (STARK layer), and attestation (three-key signature layer). As new techniques for combining FHE and zkVM emerge, they can be integrated into the pipeline without changing the external API. The goal is to provide developers with the strongest possible combination of privacy and verifiability, regardless of which specific cryptographic techniques achieve it.

Deployment Architecture Comparison

The deployment architectures for H33 and RISC Zero reflect their different approaches to verifiable computation.

H33 deploys as a service. The H33 API handles FHE key management, encrypted computation, STARK proof generation, and three-key attestation. Client applications interact with the API through SDKs that handle encryption and decryption on the client side. The architecture is client-server with the server operating on encrypted data. This model minimizes the client's computational burden (only encryption and decryption, which are relatively lightweight) while centralizing the heavy computation (FHE matching, proof generation) on optimized server infrastructure.

RISC Zero deploys as a developer toolkit. The developer compiles their application to RISC-V, runs it in the zkVM, and deploys the verification contract to a blockchain or other verification endpoint. The proving can happen on the developer's infrastructure or through a decentralized proving network. This model gives the developer more control over the computation and the proving infrastructure, at the cost of more operational complexity.

For enterprises that want post-quantum privacy with minimal operational complexity, H33's service model is more appropriate. For blockchain projects that want verifiable computation with developer control over the proving infrastructure, RISC Zero's toolkit model is more appropriate. Both are production-ready; the choice depends on the deployment context and operational preferences of the organization.

Cost Comparison

Cost structures differ between the two approaches. H33's API pricing is based on the number of operations processed, with pricing tiers that decrease per-operation cost at higher volumes. The computational cost of FHE is absorbed by the service; customers pay for outcomes (authenticated users, verified transactions) rather than computational resources.

RISC Zero's cost is primarily computational: the proving cost is proportional to the number of CPU cycles in the program being proven, and the developer bears this cost on their own infrastructure or through a proving marketplace. For simple programs, the proving cost is modest. For complex programs with millions of cycles, the proving cost can be significant.

For biometric authentication workloads, H33's per-authentication cost is well-optimized due to BFV batching (32 authentications per ciphertext operation). For general-purpose computation verification workloads, RISC Zero's per-cycle cost is well-optimized due to the efficiency of their STARK proving system. The cost comparison favors whichever system is better optimized for the specific workload in question.