Understanding the Technical Competition between FHE, TEE, ZKP, and MPC from Ika's Sub-second MPC Network Launched on Sui

Author: YBB Capital Researcher Ac-Core

1. Ika Network Overview and Positioning

Image source: Ika

The Ika network, supported strategically by the Sui Foundation, has recently officially disclosed its technical positioning and development direction. As an innovative infrastructure based on multi-party secure computation (MPC) technology, the most notable feature of this network is its sub-second response speed, which is unprecedented among similar MPC solutions. The technical compatibility between Ika and the Sui blockchain is particularly prominent, with both highly aligned in underlying design philosophies such as parallel processing and decentralized architecture. In the future, Ika will be directly integrated into the Sui development ecosystem, providing plug-and-play cross-chain security modules for Sui Move smart contracts.

Functionally, Ika is constructing a new type of security verification layer: serving as a dedicated signature protocol for the Sui ecosystem while also providing standardized cross-chain solutions for the entire industry. Its layered design balances protocol flexibility with development convenience, with a certain probability of becoming an important practical case for the large-scale application of MPC technology in multi-chain scenarios.

1.1 Core Technology Analysis

The technical implementation of the Ika network revolves around high-performance distributed signing. Its innovation lies in using the 2PC-MPC threshold signing protocol in conjunction with Sui's parallel execution and DAG consensus, achieving true sub-second signing capability and large-scale decentralized node participation. Ika aims to create a multi-party signing network that meets ultra-high performance and strict security requirements through the 2PC-MPC protocol, parallel distributed signing, and close integration with Sui's consensus structure. The core innovation is the introduction of broadcast communication and parallel processing into the threshold signing protocol, detailed in the following core function breakdown.

2PC-MPC Signature Protocol: Ika adopts an improved two-party MPC scheme (2PC-MPC), essentially breaking down the user private key signing operation into a process involving both 'user' and 'Ika network'. It transforms the complex process that originally required nodes to communicate in pairs (similar to everyone in a WeChat group privately chatting with each other) into a broadcast mode (like group announcements), keeping the computational communication overhead for users constant, regardless of network scale, allowing signature delays to remain below one second.

Parallel processing, breaking tasks into concurrent execution: Ika utilizes parallel computation to decompose a single signing operation into multiple concurrent subtasks executed simultaneously across nodes, aiming to significantly enhance speed. This integrates Sui's object-centric model, allowing the network to process numerous transactions simultaneously without achieving global consensus on every transaction, thus improving throughput and reducing latency. Sui's Mysticeti consensus eliminates block authentication delays through a DAG structure, allowing for instant block submissions, enabling Ika to achieve sub-second final confirmations on Sui.

Large-scale node network: Traditional MPC solutions typically support only 4-8 nodes, while Ika can scale to thousands of nodes participating in signing. Each node holds only a fragment of the key, and even if some nodes are compromised, the private key cannot be recovered independently. Only when both users and network nodes participate together can valid signatures be generated, and no single party can independently operate or forge signatures. This distribution of nodes is the core of Ika's zero-trust model.

Cross-chain control and chain abstraction: As a modular signature network, Ika allows smart contracts on other chains to directly control accounts within the Ika network (referred to as dWallets). Specifically, if a smart contract on a certain chain (like Sui) wants to manage multi-signature accounts on Ika, it needs to validate the state of that chain within the Ika network. Ika achieves this by deploying corresponding light clients (state proofs) of that chain within its own network. Currently, Sui state proofs have been implemented first, enabling contracts on Sui to embed dWallets as components within their business logic and complete signatures and operations on assets from other chains through the Ika network.

1.2 Can Ika Empower the Sui Ecosystem?

Image source: Ika

After Ika's launch, it may expand the capability boundaries of the Sui blockchain and provide support for the entire Sui ecosystem's infrastructure. The native Sui token SUI and Ika's token $IKA will be used in conjunction, with $IKA being used to pay for Ika network's signing service fees, while also serving as collateral for nodes.

Ika's greatest impact on the Sui ecosystem is the introduction of cross-chain interoperability capabilities. Its MPC network supports integrating assets from chains like Bitcoin and Ethereum into the Sui network with relatively low latency and high security, enabling cross-chain DeFi operations like liquidity mining and lending, thus enhancing Sui's competitiveness in this area. Due to its fast confirmation speed and strong scalability, Ika has already been adopted by multiple Sui projects, contributing to the development of the ecosystem.

In terms of asset security, Ika provides a decentralized custody mechanism. Users and institutions can manage on-chain assets through its multi-signature approach, which is more flexible and secure compared to traditional centralized custody solutions. Even transaction requests initiated off-chain can be securely executed on Sui.

Ika has also designed a chain abstraction layer that allows smart contracts on Sui to directly operate accounts and assets on other chains without cumbersome bridging or asset encapsulation processes, effectively simplifying the entire cross-chain interaction. The integration of native Bitcoin also enables BTC to directly participate in DeFi and custody operations on Sui.

In the last aspect, I also believe that Ika provides a multi-party verification mechanism for AI automation applications, helping to avoid unauthorized asset operations, enhancing security and trustworthiness during AI execution of transactions, and offering a potential avenue for future AI expansion within the Sui ecosystem.

1.3 Challenges Faced by Ika

Although Ika is closely tied to Sui, to become a 'universal standard' for cross-chain interoperability, it will depend on whether other blockchains and projects are willing to adopt it. There are already many cross-chain solutions in the market, such as Axelar and LayerZero, which are widely used in different scenarios. For Ika to break through, it needs to find a better balance between 'decentralization' and 'performance' to attract more developers and encourage more assets to migrate.

Speaking of MPC, there are also many controversies. A common issue is that signature permissions are difficult to revoke. Just like traditional MPC wallets, once the private key is split and distributed, even if it is re-fragmented, those who still have access to the old fragments theoretically can recover the original private key. Although the 2PC-MPC scheme enhances security through continuous user participation, I believe that currently there is no particularly robust mechanism in place for 'how to securely and efficiently change nodes', which may represent a potential risk.

Ika itself also relies on the stability of the Sui network and its own network conditions. If Sui undergoes significant upgrades in the future, such as updating the Mysticeti consensus to the MVs2 version, Ika must also adapt. The Mysticeti consensus, based on DAG, supports high concurrency and low fees, but the absence of a mainchain structure may complicate network paths and make transaction ordering more difficult. Additionally, being asynchronous, while efficient, introduces new ordering and consensus security issues. The DAG model also heavily depends on active users; if network usage is low, it can lead to transaction confirmation delays and decreased security.

2. Projects Based on FHE, TEE, ZKP, or MPC Comparison

2.1 FHE

Zama & Concrete: In addition to the MLIR-based general-purpose compiler, Concrete adopts a 'layered Bootstrapping' strategy, breaking down large circuits into several smaller circuits for separate encryption and then dynamically stitching the results together, significantly reducing the latency of each Bootstrapping. It also supports 'mixed encoding'—using CRT encoding for latency-sensitive integer operations and bit-level encoding for Boolean operations requiring high parallelism, balancing performance and parallelism. Additionally, Concrete provides a 'key packing' mechanism that allows multiple homomorphic operations to be reused after a single key import, reducing communication overhead.

Fhenix: Built on TFHE, Fhenix has made several customized optimizations for the Ethereum EVM instruction set. It replaces plaintext registers with 'ciphertext virtual registers' and automatically inserts micro Bootstrapping before and after executing arithmetic instructions to restore the noise budget. Additionally, Fhenix has designed an off-chain oracle bridging module that performs proof checks before interacting with on-chain ciphertext states and off-chain plaintext data, reducing on-chain verification costs. Compared to Zama, Fhenix emphasizes EVM compatibility and seamless integration of on-chain contracts.

2.2 TEE

Oasis Network: Based on Intel SGX, Oasis introduces the concept of 'layered root of trust', using SGX Quoting Service to verify hardware trustworthiness at the lowest level, while a lightweight microkernel at the middle layer isolates suspicious instructions to reduce the attack surface of SGX. ParaTime interfaces use Cap’n Proto binary serialization to ensure efficient cross-ParaTime communication. Additionally, Oasis has developed a 'durable log' module that writes key state changes to a trusted log to prevent rollback attacks.

2.3 ZKP

Aztec: In addition to Noir compilation, Aztec integrates 'incremental recursion' technology in proof generation, recursively packaging multiple transaction proofs in chronological order and generating a small-sized SNARK. The proof generator, written in Rust, employs a parallel depth-first search algorithm that achieves linear acceleration on multi-core CPUs. Furthermore, to reduce user waiting time, Aztec offers a 'light node mode' where nodes only need to download and verify zkStream instead of the complete Proof, further optimizing bandwidth.

2.4 MPC

Partisia Blockchain: Its MPC implementation is based on the SPDZ protocol extension, adding a 'preprocessing module' that generates Beaver triples off-chain to speed up online phase computations. Nodes within each shard communicate via gRPC and TLS 1.3 encrypted channels to ensure secure data transmission. Partisia's parallel sharding mechanism also supports dynamic load balancing, adjusting shard sizes in real-time based on node loads.

3. Privacy Computing: FHE, TEE, ZKP, and MPC

Image source: @tpcventures

3.1 Overview of Different Privacy Computing Solutions

Privacy computing is currently a hot topic in the blockchain and data security fields, with main technologies including Fully Homomorphic Encryption (FHE), Trusted Execution Environments (TEE), and Multi-Party Computation (MPC).

• Fully Homomorphic Encryption (FHE): An encryption scheme that allows arbitrary computation on encrypted data without decryption, achieving full encryption during input, computation, and output. It guarantees security based on complex mathematical problems (like lattice problems) and has theoretically complete computational capabilities, but incurs significant computational overhead. In recent years, the industry and academia have improved performance through optimized algorithms, specialized libraries (like Zama's TFHE-rs, Concrete), and hardware acceleration (Intel HEXL, FPGA/ASIC), but it remains a 'slow walk, quick attack' technology.

• Trusted Execution Environment (TEE): A trusted hardware module provided by processors (such as Intel SGX, AMD SEV, ARM TrustZone) that can execute code in an isolated secure memory area, preventing external software and operating systems from viewing execution data and states. TEE relies on a hardware root of trust, with performance close to native computation and generally incurs only minimal overhead. TEE can provide confidential execution for applications, but its security depends on the hardware implementation and firmware provided by manufacturers, posing potential backdoor and side-channel risks.

• Multi-Party Computation (MPC): A cryptographic protocol that allows multiple parties to jointly compute function outputs without revealing their private inputs. MPC does not require a single point of trusted hardware, but computation requires multi-party interaction, leading to significant communication overhead and performance being affected by network latency and bandwidth limitations. Compared to FHE, MPC incurs much less computational overhead but has high implementation complexity, requiring carefully designed protocols and architectures.

• Zero-Knowledge Proof (ZKP): A cryptographic technique that allows a verifier to prove a statement is true without revealing any additional information. The prover can demonstrate to the verifier that they possess a secret piece of information (like a password) without directly disclosing that information. Typical implementations include zk-SNARK based on elliptic curves and zk-STAR based on hashes.

3.2 What are the Adaptation Scenarios for FHE, TEE, ZKP, and MPC?

Image source: biblicalscienceinstitute

Different privacy computing technologies have their own focuses, with the key lying in scenario requirements. For instance, cross-chain signatures require multi-party collaboration and avoidance of single-point private key exposure, making MPC quite practical in such cases. For example, in threshold signatures, multiple nodes each hold a part of the key fragments and complete the signature together, preventing anyone from solely controlling the private key. There are also more advanced schemes, such as the Ika network, which treats the user as one party and the system node as another, employing 2PC-MPC for parallel signing, capable of handling thousands of signatures at once and scaling horizontally, with faster speeds as more nodes are added. However, TEE can also complete cross-chain signatures, running signature logic via SGX chips, offering speed and ease of deployment, but the problem is that once the hardware is compromised, the private key is leaked, placing complete trust in the chip and manufacturer. FHE is relatively weak in this area, as signature computation does not fit its strengths in 'addition and multiplication' modes. Although it can theoretically perform such operations, the overhead is too high, and practically no one does this in real systems.

In DeFi scenarios, such as multi-signature wallets, vault insurance, and institutional custody, while multi-signatures are inherently secure, the issue lies in how to securely store private keys and distribute signing risk. MPC is currently a mainstream approach; service providers like Fireblocks split signatures into several parts, with different nodes participating in signing, ensuring that even if one node is compromised, there won't be an issue. Ika's design is also intriguing, achieving 'non-collusion' of private keys through a two-party model, reducing the possibility of the traditional MPC scenario where 'everyone colludes to commit malice'. TEE is also applied in this regard, such as in hardware wallets or cloud wallet services, using trusted execution environments to ensure signature isolation, yet it cannot escape the hardware trust issue. FHE currently has little direct role in custody layers, mainly protecting transaction details and contract logic; for example, in a privacy transaction, others cannot see the amount and address, but this has little to do with private key custody. Therefore, in this scenario, MPC focuses more on decentralized trust, TEE emphasizes performance, and FHE is primarily used in higher-level privacy logic.

In terms of AI and data privacy, the advantages of FHE become more apparent. It allows data to remain encrypted from start to finish; for example, if you upload medical data to the blockchain for AI inference, FHE enables the model to make judgments without seeing the plaintext, subsequently outputting the results, during which no one can view the data. This 'computation in encryption' capability is particularly suitable for sensitive data processing, especially in cross-chain or cross-institution collaborations. For instance, Mind Network is exploring enabling PoS nodes to complete voting verification through FHE without knowledge of one another, preventing nodes from copying answers and ensuring confidentiality throughout the process. MPC can also be used for federated learning, where different institutions collaboratively train models, each retaining local data without sharing, only exchanging intermediate results. However, as more participants join, communication costs and synchronization become challenges, and most implementations remain experimental. TEE can run models directly in a protected environment and has federated learning platforms for model aggregation, but its limitations are evident, such as memory constraints and side-channel attacks. Thus, in AI-related scenarios, FHE's 'full encryption' capability stands out, while MPC and TEE can serve as auxiliary tools, but still require specific schemes for integration.

3.3 Differentiation of Different Solutions

Performance and Latency: FHE (Zama/Fhenix) has higher latency due to frequent Bootstrapping but provides the strongest data protection in encrypted states; TEE (Oasis) has the lowest latency, close to native execution, but requires hardware trust; ZKP (Aztec) offers controllable latency in batch proofs, with single transaction latency between the two; MPC (Partisia) has medium-low latency, most affected by network communication.

Trust Assumptions: Both FHE and ZKP are based on mathematical problems that do not require trust in third parties; TEE relies on hardware and manufacturers, posing risks of firmware vulnerabilities; MPC depends on a semi-honest or at most t-fault model and is sensitive to the number of participants and behavioral assumptions.

Scalability: ZKP Rollup (Aztec) and MPC Sharding (Partisia) naturally support horizontal scaling; FHE and TEE scaling must consider computing resources and hardware node supply.

Integration Difficulty: TEE projects have the lowest entry threshold, requiring minimal changes to programming models; ZKP and FHE both require specialized circuits and compilation processes; MPC requires protocol stack integration and cross-node communication.

4. General Market View: 'Is FHE Superior to TEE, ZKP, or MPC?'

It seems that whether FHE, TEE, ZKP, or MPC, all four face a 'performance, cost, and security' trilemma when solving practical use cases. Although FHE is attractive in theoretical privacy guarantees, it does not outperform TEE, MPC, or ZKP in all aspects. The low performance cost makes it difficult for FHE to scale, as its computational speed lags far behind other solutions. In applications sensitive to real-time performance and cost, TEE, MPC, or ZKP are often more feasible.

Trust and applicable scenarios differ: TEE and MPC each provide different trust models and deployment conveniences, while ZKP focuses on verifying correctness. As pointed out by industry perspectives, different privacy tools each have their advantages and limitations, with no 'one-size-fits-all' optimal solution. For example, ZKP can efficiently solve the verification of complex off-chain calculations; for computations requiring multiple parties to share private states, MPC is more direct; TEE offers mature support in mobile and cloud environments; and FHE is suitable for processing extremely sensitive data, but currently requires hardware acceleration to be effective.

FHE is not universally superior; the choice of technology should depend on application needs and performance trade-offs. In the future, privacy computing will often result from the complementary integration of multiple technologies rather than a single solution prevailing. For instance, Ika emphasizes key sharing and signature coordination in its design (users always retain a copy of the private key), with its core value lying in achieving decentralized asset control without custody. In contrast, ZKP excels at generating mathematical proofs for on-chain verification of states or computational results. The two are not simply replacement or competitive relationships but rather complementary technologies: ZKP can be used to verify the correctness of cross-chain interactions, thereby reducing trust requirements on bridging parties to some extent, while Ika's MPC network provides the underlying basis for 'asset control rights' that can be combined with ZKP to build more complex systems. Moreover, Nillion is beginning to integrate various privacy technologies to enhance overall capabilities, seamlessly incorporating MPC, FHE, TEE, and ZKP into its blind computation architecture to achieve a balance between security, cost, and performance. Thus, the future privacy computing ecosystem will tend toward using the most suitable technological components in combination, creating modular solutions.

Reference Content:

(1)https://docs.dwallet.io/#:~:text=Ika%20has%20a%20native%20token,to%20authorities%20according%20to%20their

(2)https://blog.sui.io/ika-dwallet-mpc-network-interoperability/

(3)https://research.web3caff.com/zh/archives/29752?ref=416

(4)https://medium.com/partisia-blockchain/mpc-fhe-dp-zkp-tee-and-where-partisia-blockchain-fits-in-c8e051d053f7