Good post done in good faith by @EliBenSasson so let's break it down point by point and debunk some of his concerns: 1/ "FHE solves confidentiality, but not integrity. In this sense it's complimentary to ZK, and in an ideal world you'd want to use the two of them combined." Agreed, and afaik no one claims otherwise. But the way this is written is misleading. As in, you could say the inverse is also true - ZK solves integrity but not confidentiality. ZKPs hide the inputs from the verifier that produced the proof, but the prover still sees and computes over those inputs. Whereas, in FHE computation happens over encrypted data so the operator never actually sees the inputs. Overall, yes most real-world applications benefitting from FHE will also require ZK in some way. 2/ "FHE gives you the same privacy guarantees as a TEE" This is close, and I get what Eli is trying to say but it's not accurate. It *can* be argued that FHE provides similar privacy guarantees as TEEs, but they are slightly different. TEEs are hardware-based and are vulnerable to side-channel attacks. FHE guarantees privacy via lattice-based math problems (considered quantum-secure for now), and therefore is agnostic to host compromise. So the difference is really on the security side of things. Some applications may require hardware-isolation and therefore go with TEEs, but FHE is a clear winner for applications where confidentiality is required from the service provider/operator themselves. 3/ "You can’t really use modern programming languages like Cairo for writing smart contracts. You have to work with circuits, which are more limited." Thanks for pointing this out @EliBenSasson since this is now a solved problem, thanks to @sunscreentech. As has been pointed out by several comments on this post, Sunscreen's Parasol is an LLVM-based compiler that lets you write FHE programs in mainstream languages like C (C++/Rust coming soon), compiling them to efficient FHE circuits. We’re inspired by your work on Cairo, but we respectfully disagree that building a new DSL is the way to go. We believe FHE should extend existing developer workflows and work with languages they are already familiar with. 4/ "If you ask the blockchain to run FHE you will need *all* nodes to re-execute that computation, which is very costly." This is true and candidly, fully onchain FHE is just not economically viable atleast for some more years. Despite incredible cost savings both on performance and onchain cost via Sunscreen, both compute and ciphertext storage costs scale poorly to make any economic sense for serious builders. That’s why SPF moves FHE offchain via a pull-oracle model, storing only pointers onchain. Smart contracts can require ZK proofs for verifying that the ciphertext was correctly produced. btw there are some teams working on verifiable FHE (using ZK or TEEs with FHE) too, but a long way to go still. 5/ "The third issue is that of maturity. Like MPC (and unlike ZK), so far there’s been limited experience and usage of it, but I hope this will change with time. " Also true, but this is not an issue. FHE has only recently transitioned from theory to production, and is actually progressing quite fast. E.g. Apple’s private image matching system, Sunscreen’s Parasol compiler research accepted at IEEE S&P ’26. This progress will only accelerate with advanced hardware.