FHE/zK/mpc combined usage makes encryption infrastructure more secure. Some time ago, @VitalikButerin had a discussion about this on X. If you're interested, you can scroll back and check it out. The zama @zama protocol also uses a similar approach, combining the strengths of three different algorithms to make zama FHE more secure. Of course, the core of zama is still FHE, while the other parts take on some important responsibilities. Here’s a simple and easy-to-understand basic process: User-side goal: ZK ensures input validity. When a user submits a transaction: 1/ Encrypt the input using the FHE public key. 2/ Generate a ZK proof (to prove the input was encrypted correctly). 3/ Send the ciphertext (encrypted input) + proof to the chain. On-chain: FHE executes the smart contract. Validator nodes: 1/ Execute the smart contract in an encrypted state (FHE compute). 2/ Execute the smart contract in an encrypted state (FHE compute). 3/ Get the ciphertext output (still encrypted, the output remains encrypted). Public verification: FHE allows everyone to replay the computation. 1/ Any observer can: 2/ Take the ciphertext input. 3/ Re-execute the FHE according to the on-chain contract logic. 4/ Check if the output ciphertext matches. This achieves transparent public verification. MPC (threshold decryption): Only the user can retrieve the plaintext. When the user needs the plaintext result: Nodes collaborate using their secret key shares (MPC). Generate partial decryptions. 1/ Combine them into the final plaintext. 2/ Send it back to the user. 3/ No single node can decrypt on its own. FHE handles encrypted computation, maintaining privacy and public verification. MPC manages the keys, ensuring nodes can never decrypt alone. ZK ensures input validity (it doesn’t verify the FHE contract computation but instead provides a ZK proof for the FHE encryption process, balancing efficiency and security), ensuring users cannot forge ciphertext.