Two cryptographic tools promise to let you compute on private data without exposing it, and they get confused constantly. Zero-knowledge proofs let you prove a statement is true without revealing the underlying data. Fully homomorphic encryption lets you run computation directly on encrypted data and only decrypt the final answer. They solve adjacent problems with almost nothing in common under the hood, and in 2026 both are shipping in production at very different price points. Ethereum rollups process transactions for under six cents apiece using zero-knowledge proofs. Homomorphic encryption, by contrast, still costs hundreds of milliseconds per encrypted operation on a single CPU core. This piece walks through the technical differences, the benchmark numbers from three independent sources, real deployments running today, and a decision framework for choosing between them.
What Is a Zero-Knowledge Proof?
A zero-knowledge proof (ZKP) lets a prover convince a verifier that a statement about a secret input is true, without handing over the secret itself. Say you want to prove you know a password without typing it, or that a transaction is valid without showing the account balances involved. A ZKP produces a short piece of evidence that a verifier can check in milliseconds, while the actual computation that generated the proof can take place off-chain or on a separate machine entirely.
Every ZKP construction has to satisfy three properties for the proof to mean anything. Completeness means an honest prover with a true statement can always convince an honest verifier. Soundness means a dishonest prover cannot convince the verifier of a false statement except with negligible probability. Zero-knowledge means the verifier learns nothing beyond the fact that the statement is true, not the witness that made it true. Early ZKP protocols were interactive, requiring several rounds of challenge and response between prover and verifier. Modern systems use the Fiat-Shamir transform to collapse that interaction into a single non-interactive proof, which is what makes SNARKs and STARKs practical for blockchain use, where a verifier contract cannot hold a multi-round conversation with a prover.
Two families dominate production use. zk-SNARKs (succinct non-interactive arguments of knowledge) need a trusted setup ceremony, produce small proofs, and verify fast, but the security of that setup depends on at least one participant destroying their secret input. zk-STARKs skip the trusted setup entirely, relying only on hash functions and public randomness, which makes them transparent and resistant to quantum attacks on the setup itself. The tradeoff: STARK proofs run larger, and in most implementations they take longer to generate than SNARK proofs, though they can verify faster.
Groth16 and PLONK, two SNARK proving systems already covered on this site, illustrate the internal tradeoffs within the SNARK family alone. ZKPs do not touch encrypted computation at all. The prover runs the real computation once, in the clear, then generates a proof that it was done correctly. Nothing about the underlying data ever needs to be encrypted for the proof itself to work, which is why ZKPs became the backbone of blockchain rollups years before homomorphic encryption saw comparable production traffic.
What Is Fully Homomorphic Encryption?
Fully homomorphic encryption (FHE) takes the opposite approach. Instead of proving a computation happened correctly, FHE lets you perform the computation directly on ciphertext. Add two encrypted numbers and you get an encrypted sum. Decrypt that sum later and it matches what you would have gotten by adding the plaintext values. No party ever needs to see the underlying data, including whoever is running the computation, which makes FHE attractive for outsourcing sensitive workloads to a cloud provider you do not fully trust.
Three scheme families cover most real deployments. CKKS handles approximate arithmetic over real numbers, which suits machine learning workloads where a small rounding error does not break the result. BFV and BGV handle exact integer arithmetic, useful for financial calculations where correctness to the last digit matters. TFHE and FHEW operate gate by gate on individual bits, which supports arbitrary Boolean logic but at the steepest per-operation cost of the three families.
The catch that has kept FHE out of most production systems for two decades is speed. Every homomorphic operation costs orders of magnitude more than its plaintext equivalent, and that overhead compounds as circuits grow deeper. A 2025 systematic evaluation of open-source homomorphic encryption libraries found CKKS to be the fastest scheme tested across several security parameter sets, which is one reason CKKS dominates the current wave of encrypted machine learning experiments.
FHE schemes also come in weaker variants worth knowing about before assuming “homomorphic encryption” always means the fully general case. Partially homomorphic encryption supports only one operation type (RSA supports multiplication, Paillier supports addition) with no depth limit. Somewhat homomorphic encryption supports both addition and multiplication but only up to a fixed circuit depth before noise in the ciphertext overwhelms the signal. Fully homomorphic encryption, the subject of this article, uses a technique called bootstrapping to refresh that noise budget mid-computation, which is what allows arbitrarily deep circuits but is also the single most expensive operation in the entire FHE pipeline. Most of the latency numbers cited later in this piece are dominated by bootstrapping cost, not by the arithmetic itself.
Zero-Knowledge Proofs vs Homomorphic Encryption: Full Spec Comparison
The table below lines up the two approaches across the properties that matter most when picking one for a real system.
| Property | Zero-Knowledge Proofs (SNARK/STARK) | Fully Homomorphic Encryption |
|---|---|---|
| Core guarantee | Proves a statement is true without revealing the witness | Computes on ciphertext without ever decrypting inputs |
| Computation happens on | Plaintext, once, off-chain | Ciphertext, directly, wherever it runs |
| Output | A short proof plus a public result | An encrypted result, decrypted later by the key holder |
| Trusted setup required | Yes for most SNARKs (Groth16); no for STARKs | No, but a decryption key holder must be trusted or distributed |
| Post-quantum security | STARKs: yes (hash-based); SNARKs: scheme-dependent | Yes, lattice-based schemes (CKKS, BFV, BGV, TFHE) |
| Typical proof/ciphertext size | SNARK: hundreds of bytes; STARK: tens of KB | Ciphertext expansion of 10-100x plaintext size, scheme-dependent |
| Verification cost | Sub-second, often constant time regardless of circuit size | Not applicable; correctness follows from the math, no separate check |
| Computation overhead vs plaintext | N/A (computation is in the clear) | Roughly 10³-10⁸x slower depending on operation granularity |
| Dominant production use case | Blockchain rollups, private identity proofs | Confidential smart contracts, encrypted ML inference |
| Maturity of production deployments | High: multiple L2 networks processing live mainnet traffic | Early: pilot deployments and single-vendor rollouts |
| NIST standardization status | No dedicated NIST ZKP standard; ZKProof.org drives community specs | No finalized NIST FHE standard as of 2026; NISTIR 8214C covers related threshold cryptography |
| Best-known toolchains | Circom, snarkjs, Halo2, Cairo, Plonky2 | TFHE-rs, OpenFHE, Concrete, Microsoft SEAL |
Performance Benchmarks: Proof Generation vs Encrypted Computation
Raw numbers explain why these two technologies occupy such different corners of production software. A December 2025 comparative study of zk-SNARKs and zk-STARKs ran identical circuits across four hardware platforms, and the spread between proof generation and verification was substantial. On an Apple M1, SNARK proof generation finished in 55.47 milliseconds against 3,809.64 milliseconds for the equivalent STARK proof, a roughly 68x gap in the SNARK’s favor. Verification flipped the advantage: SNARK verification took 1,807.42 milliseconds against 472.25 milliseconds for STARK, making STARK verification close to 3.8x faster on the same machine. On a Raspberry Pi, SNARK proof generation ran 1.051 seconds against 2.95 seconds for STARK. On Ubuntu, the gap widened to 3.37 seconds versus 26.54 seconds.
A separate 2025 benchmark of Groth16 circuits built with Circom and snarkjs, published in the International Journal of Computing, measured proof generation between 832 and 1,147 milliseconds as circuit complexity increased, while verification held steady between 741 and 884 milliseconds regardless of circuit size, confirming Groth16’s constant-time verification property in practice rather than just in theory.
FHE benchmarks tell a very different story. A 2025 multi-layer evaluation of homomorphic encryption schemes measured TFHE running through the MKTFHE library at roughly 0.220 to 0.227 seconds per single Boolean gate on AVX-capable CPUs, which is somewhere between seven and eight orders of magnitude slower than a native Boolean operation. A separate 2025 survey of TFHE-based transciphering found that running the Trivium and Kreyvium stream ciphers through TFHE-rs still took under 300 milliseconds per 64-bit plaintext block, and that a hybrid construction pairing the Hera cipher with CKKS cut ciphertext expansion by 23x, cut client-side latency by 9,085x, and lifted throughput by 17.8x compared to a CKKS-only pipeline. That hybrid result is the clearest evidence yet that raw FHE, used naively, is still thousands of times too slow for most production workloads, and that the field’s near-term progress is coming from clever engineering around the primitive rather than from the primitive getting dramatically faster on its own.
| Benchmark | Result | Source |
|---|---|---|
| zk-SNARK proof generation (Apple M1) | 55.47 ms | 2025 comparative SNARK/STARK study |
| zk-STARK proof generation (Apple M1) | 3,809.64 ms | 2025 comparative SNARK/STARK study |
| zk-STARK verification (Apple M1) | 472.25 ms, ~3.8x faster than SNARK | 2025 comparative SNARK/STARK study |
| Groth16 proof generation (Circom/snarkjs) | 832-1,147 ms | 2025 Intl. J. Computing benchmark |
| Groth16 verification (Circom/snarkjs) | 741-884 ms, roughly constant time | 2025 Intl. J. Computing benchmark |
| TFHE Boolean gate (MKTFHE, AVX CPU) | 0.220-0.227 sec/gate | 2025 multi-layer FHE evaluation framework |
| TFHE-rs transciphering (Trivium/Kreyvium) | under 300 ms per 64-bit block | 2025 TFHE transciphering survey |
| Hera + CKKS hybrid vs CKKS-only | 9,085x lower latency, 17.8x higher throughput | 2025 TFHE transciphering survey |
Real-World Deployments: Where Each Technology Runs Today
Zero-knowledge proofs already carry live mainnet traffic at meaningful scale. L2Beat lists Starknet at roughly $461.68 million in total value secured, Linea at $366.06 million, zkSync Era at $257.17 million, and Scroll at $47.06 million, all using SNARK or STARK proof systems to batch transactions before settling them on Ethereum. Aztec, a newer privacy-focused zk-rollup, shows only around $1,000 in value secured on the same tracker, a reminder that not every ZKP network has reached meaningful scale yet even within a mature technology category.
Worldcoin’s World ID product is a non-blockchain-scale example: it uses zero-knowledge proofs together with the Semaphore protocol so a person can prove they hold a unique, orb-verified identity without revealing which specific identity it is, and World ID’s own documentation lists integration partners including Tinder, Okta, Razer, Vercel, and Zoom.
Homomorphic encryption’s production footprint looks different: fewer networks, but at least one clear consumer-facing shipping feature. Apple’s Live Caller ID Lookup, which shipped with iOS 18, sends an encrypted query from the Phone app to Apple’s caller-ID database and receives an encrypted response back, decrypting the result only on the device itself, according to reporting on the feature. That is homomorphic encryption running at consumer scale, even if Apple does not market it under the FHE label.
On the company side, Zama, the team behind the TFHE-rs and Concrete toolchains, closed a $57 million Series B in June 2025 led by Pantera Capital and Blockchange Ventures, pushing its valuation past $1 billion and total funding past $150 million, making it the first venture-backed company to reach unicorn status built specifically around FHE. Zama’s stack, spanning Concrete, Concrete ML, TFHE-rs, and an fhEVM aimed at confidential smart contracts, is the closest thing the FHE ecosystem has to a default toolchain in 2026, the way Circom and snarkjs became the default entry point for SNARK development years earlier.
The gap between those two production footprints is worth sitting with for a moment. ZKP-based rollups have spent multiple years processing real economic value, which means their failure modes, gas costs, and proving bottlenecks have already been stress-tested by adversarial conditions: MEV bots, congested blocks, and attempted exploits against live contracts holding real money. FHE’s production examples, by contrast, are narrower in scope and newer, whether that is a single Apple feature or a blockchain still measured in the low thousands of dollars of value secured. That gap is not a knock on FHE’s cryptographic soundness, which researchers consider well understood, but it does mean FHE systems have not yet absorbed the same volume of adversarial, real-money pressure that has already shaped ZKP tooling.
Pricing and Cost Comparison
ZKP costs on public blockchains are transparent because every proof gets submitted and paid for on-chain. Per-proof gas costs on Ethereum-based rollups fell sharply through 2025. Before August 2025, a rollup batch proof cost between 500,000 and 2,000,000 gas. By December 2025 that had dropped to 200,000-400,000 gas, and by February 2026, after the Fusaka upgrade cluster, typical proofs settled between 180,000 and 350,000 gas. Amortized across a full batch, zkSync Era’s 2026 per-transaction cost runs $0.01 to $0.05, and Polygon zkEVM runs $0.02 to $0.06, at roughly 3,000 and 4,000 transactions per second respectively. Zoomed in on a shorter window, per-proof ETH costs still climbed: zkSync Era’s cost per proof rose from 0.0032 ETH in February 2025 to 0.0043 ETH by April 2025, a 34.4 percent jump, while Polygon zkEVM rose 39.3 percent and Starknet rose 31.4 percent over the same window, tracking overall network gas price movement more than any change in the proving system itself.
FHE has no equivalent public price feed, because there is no comparable market of pay-per-operation FHE services with published rates yet. The best available cost proxy is compute latency: TFHE’s roughly quarter-second-per-gate cost on an AVX-enabled CPU translates directly into cloud compute spend, since every encrypted Boolean operation ties up a CPU core for that long. A workload doing millions of gate operations scales that latency into real infrastructure cost, which is the main reason FHE deployments today lean on hybrid schemes like Hera-plus-CKKS specifically to cut that per-operation cost before it reaches production traffic.
| Cost metric | Zero-Knowledge Proofs | Fully Homomorphic Encryption |
|---|---|---|
| Cost model | Public, on-chain gas plus proving hardware | Private compute cost, no published market rate |
| Per-transaction cost (zkSync Era, 2026) | $0.01-$0.05 | Not applicable |
| Per-transaction cost (Polygon zkEVM, 2026) | $0.02-$0.06 | Not applicable |
| Gas per proof (Feb 2026) | 180,000-350,000 gas | Not applicable |
| Cost proxy | Direct, denominated in gas and ETH | Indirect, denominated in CPU-seconds per operation |
Hardware Acceleration: Racing to Make Both Practical
Both fields depend on specialized hardware to close the gap with plaintext performance, and both are still mostly running on general-purpose CPUs today rather than dedicated silicon. A 2025 cross-platform FHE benchmarking study found that Linux consistently outperformed Windows for the same homomorphic encryption workloads, and that OpenFHE came out as the fastest library across most of the cryptographic parameter sets tested, pointing to operating system and library choice as levers teams can pull today without waiting on new hardware. The same evaluation work leaned heavily on AVX-capable CPUs, confirming that wide vector instruction sets already provide a meaningful speedup for gate-level FHE operations like the TFHE benchmark above.
ZKP proving has had a multi-year head start on hardware optimization because blockchain economics create direct financial pressure to cut proving time. GPU-based proving pipelines are now standard in production rollup infrastructure, since proof generation is the most parallelizable step in the pipeline and the step most rollups pay the most to run at scale. FHE’s hardware story is earlier: most acceleration gains published in 2025 research came from software-level techniques such as hybrid transciphering and library selection rather than from purpose-built accelerator chips reaching general availability, which tracks with FHE’s overall position a few years behind ZKP on the production maturity curve.
Standards and Regulatory Status
Neither technology has a finalized government cryptographic standard as of September 2026, but the two are on different standardization paths. NIST’s NISTIR 8214C, its first call for multi-party threshold cryptography, explicitly invites submissions of related advanced primitives, which puts homomorphic encryption schemes inside NIST’s broader review pipeline even though no dedicated FHE standard has shipped yet. The IETF’s Privacy Enhancements and Assessments Research Group has held sessions specifically asking whether FHE is ready for near-term deployment, a sign that standards bodies are actively evaluating the technology rather than treating it as settled.
Zero-knowledge proofs follow a different governance model. Rather than a single government body, ZKProof.org coordinates a community-driven standardization effort covering security definitions, implementation guidance, and interoperability testing across SNARK and STARK proving systems, run by academic researchers and the companies building production proving infrastructure. That community-led approach reflects how ZKPs matured: driven by blockchain deployment pressure years before any government agency turned its attention to formal standardization.
Zero-Knowledge Proofs: Pros and Cons
- Pro: Sub-second verification even for complex statements, which is why proofs can be checked cheaply on a blockchain.
- Pro: Small proof sizes, especially with SNARKs, keep on-chain storage and bandwidth costs low.
- Pro: Mature toolchains (Circom, Halo2, Cairo) and years of production hardening across live rollups.
- Con: SNARKs require a trusted setup ceremony, and a compromised ceremony can undermine the whole system’s soundness.
- Con: The underlying computation still runs in the clear at proof-generation time, so ZKPs alone do not protect data during computation, only during disclosure of the result.
- Con: STARK proof generation can run into the tens of seconds for large circuits, based on the Ubuntu and PPC64 benchmark figures above.
Homomorphic Encryption: Pros and Cons
- Pro: Data stays encrypted through the entire computation, including on the machine that processes it, closing a gap ZKPs leave open.
- Pro: Lattice-based FHE schemes carry believed post-quantum security by design.
- Pro: CKKS suits real-valued machine learning workloads directly, without reformulating a model as a provable circuit.
- Con: Per-operation overhead of roughly 10³ to 10⁸x versus plaintext, depending on scheme and operation granularity, based on the 2025 benchmarks above.
- Con: No established public pricing market yet, making budgeting for production FHE workloads harder than budgeting for ZKP proving costs.
- Con: Ciphertext expansion of 10-100x plaintext size increases storage and network costs on top of the computation overhead.
5 Use Cases: When to Choose Which
Blockchain transaction scaling. Ethereum rollups need to batch thousands of transactions and prove correctness cheaply on layer 1. ZKPs win outright here: zkSync Era and Polygon zkEVM already process live traffic at sub-six-cent per-transaction costs, a price point FHE cannot currently approach for equivalent throughput.
Anonymous identity verification. Proving you are a unique human, or that you meet an age threshold, without revealing your identity is a textbook ZKP problem. World ID’s use of zero-knowledge proofs with the Semaphore protocol is the clearest production example running today.
Confidential smart contracts. When the goal is hiding contract state, not just proving a transaction was valid, FHE fits better because it lets validators execute contract logic directly on encrypted state. Zama’s fhEVM is built specifically for this case.
Privacy-preserving lookups against a third-party database. Apple’s Live Caller ID Lookup needs to query a database it does not control without exposing the query, and get back an answer the server itself cannot read. That is a natural FHE fit, since there is no on-chain verification requirement and no need for a public proof.
Encrypted machine learning inference. Running a model against sensitive input (medical, financial, biometric) while keeping that input encrypted end to end favors FHE, and specifically CKKS, given its approximate-arithmetic design and its lead in the 2025 open-source HE benchmark comparison.
Auditable compliance proofs. Proving a financial institution followed a specific rule, such as a reserve ratio, without disclosing the underlying ledger, is a proof-of-correctness problem more than a computation-privacy problem, which points back toward ZKPs, particularly transparent STARK-based systems where regulators want no trusted setup to audit.
Migration Guide: Moving From Plaintext or Legacy Privacy Tooling
Teams migrating toward either technology tend to follow a similar sequence, even though the destinations differ.
- Identify what actually needs protecting: the correctness of a computation (points toward ZKPs) or the confidentiality of the data during computation (points toward FHE). Most teams that skip this step end up building the wrong system.
- Inventory the operations your workload actually needs. Simple additions and comparisons are cheap under both models, but deep nested logic or floating-point-heavy workloads get expensive fast under FHE specifically.
- For a ZKP migration, pick a circuit language first (Circom, Cairo, or Halo2’s Rust DSL) rather than a proving system, since the circuit language determines most of your development velocity.
- For an FHE migration, start with CKKS if the workload is ML inference, or TFHE if it is bit-level Boolean logic, rather than trying to force one scheme to do both.
- Benchmark on your actual target hardware before committing. The Linux-over-Windows and AVX-CPU findings above show FHE performance varies enormously by environment, more than most teams expect going in.
- Budget for trusted setup risk if you choose a SNARK. Either use an existing, well-audited setup ceremony (many public ones already exist for common circuit sizes) or plan for a STARK-based system if a ceremony is politically or operationally unacceptable.
- Plan for ciphertext or proof size in your storage and bandwidth budget from day one. STARK proofs and FHE ciphertexts both expand well past their plaintext originals, and retrofitting storage assumptions later is expensive.
- Pilot against a narrow, well-bounded use case before generalizing. Every production deployment referenced in this article, from World ID to Apple’s caller-ID lookup to zkSync’s rollup, started as a single, tightly scoped feature rather than a platform-wide rewrite.
Combining ZKPs and FHE: Hybrid Architectures
The two technologies are not mutually exclusive, and some of the most interesting 2025-2026 research sits at their intersection. A system can use FHE to keep data encrypted during computation, then generate a ZKP that the homomorphic computation itself was carried out correctly, giving you both confidentiality and verifiability in a single pipeline. The Hera-plus-CKKS transciphering work referenced earlier is a version of this pattern in miniature: it uses a lightweight symmetric cipher to move data in and out of FHE format efficiently, cutting the cost of the FHE portion of the pipeline without touching its security guarantees.
Confidential blockchain applications are the most active area for this hybrid pattern in production right now. A rollup can use FHE to keep contract state encrypted between transactions, then use a ZKP to prove that a given state transition, applied to that encrypted state, followed the contract’s rules, without the prover or verifier ever needing to decrypt the state itself. That combination directly addresses the gap each technology leaves on its own: ZKPs alone still compute in the clear at proof time, and FHE alone has no built-in way to prove a computation was done correctly to a third party who cannot decrypt.
Security Considerations and Attack Surface
The two technologies fail in different ways, and knowing that difference matters more than either technology’s headline security claim. A ZKP system’s weakest point is usually the setup and the circuit itself, not the proving math. A flawed trusted setup ceremony for a Groth16 SNARK can allow a malicious party who kept their secret input to forge proofs for false statements, which is why public setup ceremonies with many independent participants exist: soundness only breaks if every single participant colluded or failed to destroy their share. A more common real-world failure mode is a bug in the circuit itself, where the constraints the developer wrote do not actually match the property they intended to prove, letting a prover generate a valid-looking proof for an invalid computation. Circuit auditing is consequently its own specialty within ZKP engineering, distinct from auditing the underlying cryptographic library.
FHE’s weakest point sits somewhere else entirely: key management. Because FHE’s guarantee only holds up to the point of decryption, whoever controls the decryption key can read every result the system ever produces. A single-party key holder recreates a classic single point of failure, which is why production FHE deployments increasingly pair the encryption scheme with threshold decryption, splitting the key across multiple parties so no individual party can decrypt alone. Side-channel risk is also a live concern for FHE: because ciphertext operations still run on real hardware, timing and power-analysis attacks against an FHE implementation can, in principle, leak information about the encrypted data or the key, an attack surface that has no real equivalent on the ZKP side since a ZKP verifier never touches secret data at all.
Developer Experience: What It Actually Takes to Ship Each One
Writing a ZKP circuit today means learning a domain-specific language built around arithmetic constraints. Circom, one of the most widely used, requires developers to express a computation as a set of polynomial constraints rather than as ordinary imperative code, which has a real learning curve but comes with mature tooling: snarkjs for proof generation, browser-based verification libraries, and years of public circuits to study and reuse. Cairo, used by Starknet, and Halo2’s Rust-embedded DSL take slightly different approaches, but all of them share the same basic shift in mental model, from writing a program to writing a set of constraints that a valid execution must satisfy.
FHE development looks more like ordinary programming on the surface, since libraries like Concrete and TFHE-rs let a developer write something close to regular arithmetic and have the compiler handle the encryption details underneath. The gap shows up at runtime rather than at write time: the same function that runs in microseconds on plaintext can take seconds on ciphertext, and that cost is not always obvious from reading the source code. Teams adopting FHE typically need to budget real time for profiling, since the naive translation of an existing plaintext function into its FHE equivalent is rarely fast enough to ship without first restructuring it around cheaper operations, smaller integer widths, or one of the transciphering shortcuts referenced earlier in this piece.
The Verdict: Which One Should You Use?
Pick zero-knowledge proofs when the problem is proving correctness cheaply and the underlying computation does not need to stay secret while it runs. The data backs this up decisively: zkSync Era and Polygon zkEVM handle thousands of transactions per second at costs under six cents each, with gas per proof down to 180,000-350,000 as of February 2026, and verification finishing in under two seconds even in the slower SNARK case measured on an Apple M1.
Pick fully homomorphic encryption when the computation itself, not just its correctness, has to stay hidden from whoever is running it. The tradeoff is real: per-gate TFHE operations still cost roughly a quarter second on modern AVX hardware, and naive CKKS pipelines can run thousands of times slower than optimized hybrid designs like Hera-plus-CKKS. That overhead is shrinking, evidenced by the 9,085x latency improvement that hybrid approach delivered over a CKKS-only baseline, but FHE in 2026 remains the right tool for a narrower set of problems than ZKPs, chosen specifically because nothing else protects data during active computation the way FHE does.
For most engineering teams evaluating both in 2026, the practical rule holds: reach for a ZKP first, and reach for FHE only when a ZKP genuinely cannot satisfy the requirement, because the underlying data must remain encrypted throughout computation rather than merely proven correct after the fact.
Frequently Asked Questions
Can zero-knowledge proofs and homomorphic encryption be used together?
Yes. A system can compute on encrypted data with FHE, then use a ZKP to prove that the homomorphic computation followed the correct rules, combining confidentiality during computation with a verifiable correctness guarantee, as described in the hybrid architectures section above.
Is fully homomorphic encryption quantum-resistant?
Yes, the major FHE schemes in production, including CKKS, BFV, BGV, and TFHE, rely on lattice-based hardness assumptions, which are believed to resist attacks from quantum computers, unlike RSA or elliptic-curve cryptography.
Are zk-STARKs always slower than zk-SNARKs?
Not universally. The 2025 comparative benchmark referenced in this article found SNARKs generating proofs roughly 68x faster than STARKs on an Apple M1, but STARKs verified about 3.8x faster on the same hardware. Which one is “slower” depends on whether proof generation or verification is the bottleneck in your system.
Why is homomorphic encryption still so much slower than plaintext computation?
Every homomorphic operation has to preserve enough mathematical structure in the ciphertext to remain decryptable after the operation, which requires far more computation per operation than the equivalent plaintext arithmetic. Benchmarks in this article put that overhead at roughly a quarter second per Boolean gate for TFHE on modern CPUs, several orders of magnitude slower than a native gate operation.
Do zero-knowledge proofs require a trusted setup?
Only some do. Most zk-SNARK systems, including Groth16, require a trusted setup ceremony. zk-STARKs do not, relying instead on public randomness and hash functions, which is why STARKs are often described as transparent.
Which companies are building homomorphic encryption products in 2026?
Zama is the most visible, having raised a $57 million Series B in June 2025 at a valuation north of $1 billion, and building the TFHE-rs, Concrete, and fhEVM toolchains referenced throughout this article. Apple also ships homomorphic encryption in a consumer feature, Live Caller ID Lookup, though it does not market the underlying cryptography by name.
What is the cheapest way to verify a zero-knowledge proof on Ethereum?
Costs depend on network conditions and batch size, but as of February 2026, major rollups settle proofs at roughly 180,000-350,000 gas each, down from 500,000-2,000,000 gas before August 2025, following Ethereum’s Fusaka upgrade cluster and ongoing calldata compression improvements.
Does either technology protect against a malicious verifier?
Zero-knowledge proofs are designed so the verifier learns nothing beyond the truth of the statement, protecting the prover’s data even from a dishonest verifier. FHE protects data from whoever runs the computation, but the party holding the decryption key still sees the final plaintext result, so key management remains the main trust boundary in any FHE system.
