TEE, MPC, FHE, and ZKP are not competitors. They're friends. Discussions often compare this tech to determine which one is superior. In reality, these technologies are not mutually exclusive and can function together and complement each other. 1. Each solution has trade-offs, but they are unrelated > MPC doesn’t have a single point of failure, but requires heavy data exchange An MPC protocol typically unfolds in three stages. 1. Users secret-share their private inputs, sending encrypted data to computing nodes, ensuring security through non-collusion or a full threshold model (all nodes must collude). 2. Nodes compute these secret shares. 3. Nodes return their shares of the output to users, who reconstruct the result. MPC works best with well-connected nodes, but its cost comes from heavy data exchange between them, so we mainly face overhead in communication problems. In many standard MPC protocols, each node communicates with every other node for operations like multiplication gates. This results in quadratic communication complexity O(n²). What does it mean? • For example, with 10 nodes and a 1 KB computational complexity, the data exchange is approximately 100 GB. • With 100 nodes, it reaches about 10 TB. MPC's data exchange limits practical applications to 2–10 nodes due to communication overhead. So, unlike blockchain, fast MPC with hundreds of nodes isn't yet feasible. > FHE requires less data, but more computation resources FHE addresses a long-standing challenge: how to enable secure computation on encrypted data without requiring decryption? A user can encrypt their sensitive data, upload it to a server, and the server can execute computations on this ciphertext (encrypted message). The resulting output, still encrypted, can then be decrypted by the user using their private key, unlike traditional End-to-End Encryption (E2EE) where computation on encrypted data is not feasible. FHE uses less data transfer than MPC, but requires significantly more server-side computation. This makes FHE generally slower than MPC, except in situations with extremely slow networks or very powerful computing infrastructure. • Simple database query taking milliseconds unencrypted can stretch to 2–10 seconds with FHE • AI inference with FHE takes seconds to minutes compared to milliseconds for unencrypted operations > ZK is not about general computations, and it has a privacy problem While all these technologies enable private computations, ZKPs specifically generate proofs with "true" or "false" (boolean) outcomes. As most people know, ZKPs are widely used in zk-rollups, which are succinct proofs with a small, fixed size and fast verification, ideal for on-chain use. However, zk-rollups utilize the soundness and succinctness of, but not their zk property. While ZKPs ensure that a false proof can't appear valid (soundness) and that anyone can verify a proof, a privacy issue arises in zk-rollups. The entity running the zk circuit has full access to the input data during computation, meaning sensitive data visible to the prover. This compromises the privacy of private user inputs. > TEE is cheap and fast, but also vulnerable to side-channel attacks Unlike other privacy technologies, TEEs rely on specific hardware, such as Intel’s SGX. The security model of TEEs is less transparent than other methods, and vulnerabilities have been identified in various TEE implementations. 2. Different tradeoffs — different ways to complement them Every technology suffers from different problems and also has different pros, so to say that some technology is far better than another without giving any context is certainly incorrect. Each option can't perform better in certain situations than other options and vice versa. To give an example: • Collusion problem doesn’t relate in any way to TEE, because there is only an isolated environment where collusion is impossible • ZKPs can’t relate in any way to MPC or FHE in terms of computations, because ZK technology is only related to generating boolean proofs • TEE’s main trust assumption is hardware being hacked, while the main problem with hardware in FHE is that it has to be fast enough and performant • We are talking about the same subject (hardware), but there are absolutely polar points to think about Following this logic, I decided to take a deeper look into this and see where different technologies can complement each other and offer a better solution. 3. Synergies and Complementary Roles Let’s take TEE as a certain foundation and see how different combinations can work and how we can fix the problems in those options. > TEE + MPC Issue: TEEs rely on hardware-based keys for privacy, creating issues with data portability and potential censorship. Solution: MPC can solve this by replacing hardware keys and serving as a key management service for TEEs. MPC solutions can run computations inside TEEs to ensure that each party’s operations are isolated and secure, making it even more secure, and there are multiple protocols doing this already. • If we look at it from the other way around and see how TEE can benefit from MPC, it's by replicating isolated environments, making them more distributed • Instead of trusting one TEE to handle everything, MPC spreads the responsibility across several TEEs • TEE can distribute trust across multiple secure enclaves and reduce dependence on a single TEE instance • Each enclave contributes to the computation without needing to fully trust the others because of MPC's cryptographic guarantees. > TEE + FHE Problems with TEE (side-channel attacks) and FHE (huge computation resources) are different, as are the techniques they bring. Running code in an isolated environment is not the same as having technology to run computations on decrypted data. Here, TEE seems like an overhead, because pure code is running in an isolated machine and requires decryption, while FHE allows developers to run computations on already encrypted data. While it may be true in some capacity that TEE is technological overhead, using FHE has another overhead of really high computational resources. Approximately, when using TEE, there’s a 5% overhead, while using FHE, the overhead is around 1,000,000x. While it might seem like TEEs and FHE could create overhead for each other, I'm exploring using TEEs to securely manage decryption keys or handle performance-intensive tasks that FHE struggles with. If we look into it from another way, FHE can allow TEE to process encrypted data directly while TEE manages the keys. > TEE + ZK There is also an example of how efficient the usage of TEE and ZK is using TEE for zkVM proving. Issue: outsourcing zkVM proving to any other device is problematic, because privacy becomes at risk as the prover typically needs access to inputs. Solution: If we run zkVM inside a TEE, the computation occurs within a secure enclave and prevents the host from accessing the data. The TEE provides attestation that the proof was generated correctly. For instance, @PhalaNetwork uses TEE-enabled GPUs to run SP1 zkVM, achieving less than 20% overhead for complex workloads like zkEVMs. 4. Phala as TEE Foundation Phala builds the decentralized TEE cloud in crypto, so anyone can leverage TEE and use it for their purposes, including teams whose main product offering is either MPC, FHE, or ZK. I wanted to learn more and explore the teams that are using Phala for these purposes. > Phala + MPC @0xfairblock does confidential computing to mitigate centralized risks and prevent information leakage and manipulation in apps, where their main technology is MPC. However, they can still benefit from TEEs: • Phala's TEE enclave generates private keys, which are then threshold-encrypted and split into shares for storage across Fairblock's MPC • Smart contracts monitor TEE operations by requiring regular submission of encrypted keys and basically act as a failure detection mechanism • If TEE fails, smart contracts trigger Fairblock's MPC to privately reconstruct and decrypt the keys to maintain share confidentiality. In such a setting, keys remain encrypted within TEEs at all times, with MPC ensuring that no single party can access the complete key. Automated recovery mechanisms safeguard against data loss due to system crashes or reboots. > Phala + zkTLS There are a lot of zk protocols using Phala, but I want to highlight @primus_labs, because their core offering is around zkTLS. I already did a comprehensive article on zkTLS, but the most important thing you have to know is that in zkTLS, the attestor serves as a validator looking at encrypted data streams to verify their authenticity. Difficulty: reducing reliance on the attestor’s trustworthiness. • Using Phala's Dstack, attestors in Primus can run the attestations inside a TEE to make sure that every ZKP is backed by attestation issued inside a TEE. • In that case, anyone can verify the proof using an attestation explorer. TEE keeps latency low and doesn’t come with any time overhead. > Phala + FHE @sporedotfun uses both FHE on the @mindnetwork_xyz side and TEE on the Phala side. In Spore's staking-to-vote system, attackers can stake tokens before deadlines to mislead voters, then unstake and distort outcomes and markets. Difficulty: strike a balance between transparency and security to ensure governance decisions align with long-term contributors’ intentions. • To counter vote sniping, Spore adopts FHE via Mind Network and enables blind voting that protects voter privacy. • FHE keeps votes encrypted to eliminate the ability for snipers to vote maliciously. • TEE provides a zero-trust environment for aggregation and publication of votes before final publication. 5. Possibilities are infinite, but it's worth considering the risks & performance overhead As I said before, there are a lot of use cases possible with TEE foundation, so possibilities are infinite. The main consideration is this one: • The industry is currently experiencing a growing demand for complex computations, primarily driven by AI • Rapid expansion of the AI sector increases performance requirements. • As performance demands rise, we must consider not only the performance and security features of specific technologies but also their costs. To provide approximate performance overhead estimates using rough figures, the following projections are: • TEE — 5% overhead • MPC — 100x overhead • ZK — 1,000x overhead • FHE — 1,000,000x overhead As we can see, TEE introduces very little overhead to any system and is basically the most performant and cost-effective environment for complex computations like AI inference. In current systems, and even more so in future systems, developers should consider TEE as one of the parts of the final system design, even if the core offering is not around TEEs. TEE not only mitigates individual trade-offs of MPC, FHE, or ZK, but also unlocks a lot of possibilities for developers and users.