Looking at the technological competition between FHE, TEE, ZKP, and MPC from the sub-second MPC network lka launched by Sui

Author: YBB Capital Researcher Ac-Core

1. Overview and Positioning of the Ika Network

Image source: Ika

The Ika network, which receives strategic support from the Sui Foundation, has recently officially disclosed its technical positioning and development direction. As an innovative infrastructure based on Multi-Party Computation (MPC) technology, the most notable feature of this network is its sub-second response speed, which is a first among similar MPC solutions. The technical compatibility between Ika and the Sui blockchain is particularly prominent, as both share a high degree of alignment in underlying design concepts 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.

From a functional positioning perspective, Ika is building a new type of secure 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 and development convenience, making it a significant 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 signatures. Its innovation lies in utilizing a 2PC-MPC threshold signature protocol in conjunction with Sui's parallel execution and DAG consensus, achieving true sub-second signature capability and large-scale decentralized node participation. Ika aims to create a multi-party signature network that meets both ultra-high performance and strict security requirements by closely integrating the 2PC-MPC protocol, parallel distributed signatures, and Sui's consensus structure. The core innovation is the introduction of broadcast communication and parallel processing into the threshold signature protocol, with the following core functionalities.

2PC-MPC Signature Protocol: Ika employs an improved two-party MPC scheme (2PC-MPC), effectively breaking down the user private key signing operation into a process involving both the "user" and the "Ika network." The complex process that originally required pairwise communication between nodes (similar to everyone in a WeChat group chatting privately with each other) is transformed into a broadcast mode (similar to a group announcement), keeping the computational communication overhead for users at a constant level, independent of network scale, allowing signature delays to remain sub-second.

Parallel Processing, Breaking Tasks to Work Simultaneously: Ika utilizes parallel computing to decompose a single signing operation into multiple concurrent subtasks executed simultaneously among nodes, aiming to significantly enhance speed. This incorporates Sui's object-centric model, allowing the network to process numerous transactions simultaneously without achieving global consensus on each transaction, thereby increasing throughput and reducing latency. Sui's Mysticeti consensus eliminates block certification delays with a DAG structure, allowing for immediate block submission, enabling Ika to achieve sub-second final confirmation 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 signatures. Each node holds only a portion of the key fragment, and even if some nodes are compromised, the private key cannot be independently recovered. Only when users and network nodes jointly participate can valid signatures be generated; no single party can operate independently or forge signatures, making this node distribution 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 verify the state of that chain within the Ika network. Ika achieves this by deploying lightweight clients (state proofs) for the corresponding chain within its network. Currently, Sui state proofs have been implemented first, allowing contracts on Sui to embed dWallets as components in business logic and complete signing and operations for assets on other chains through the Ika network.

1.2 Can Ika Empower the Sui Ecosystem in Reverse?

Image source: Ika

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

The greatest impact of Ika on the Sui ecosystem is that it brings cross-chain interoperability to Sui. Its MPC network supports the integration of assets from chains like Bitcoin and Ethereum into the Sui network with relatively low latency and high security, enabling cross-chain DeFi operations such as liquidity mining and lending, which helps enhance Sui's competitiveness in this area. Due to its fast confirmation speed and strong scalability, Ika has already been integrated by multiple Sui projects, also promoting the development of the ecosystem to some extent.

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

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

Lastly, I believe Ika also provides a multi-party verification mechanism for AI automation applications, which can prevent unauthorized asset operations, enhance the security and credibility of AI executing transactions, and offer a potential avenue for the future expansion of the Sui ecosystem in the AI direction.

1.3 Challenges Faced by Ika

Although Ika is closely tied to Sui, whether it can become a "universal standard" for cross-chain interoperability depends on whether other blockchains and projects are willing to adopt it. There are already several cross-chain solutions in the market, such as Axelar and LayerZero, which are widely used in different scenarios. For Ika to break through, it must 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 obtain the old fragments theoretically can still recover the original private key. Although the 2PC-MPC scheme improves security through continuous user participation, I believe that currently there is no particularly well-developed solution for "how to safely and efficiently replace nodes," which may be a potential risk point.

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 its lack of a main chain structure may complicate network paths and make transaction ordering more difficult. Additionally, since it is an asynchronous accounting model, while it is efficient, it also brings new ordering and consensus security issues. Moreover, the DAG model heavily relies on active users; if network usage is low, it can easily lead to transaction confirmation delays and decreased security.

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

2.1 FHE

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

Fhenix: Based 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 noise budgets. At the same time, Fhenix has designed an off-chain oracle bridging module that checks proofs before interacting on-chain ciphertext states with off-chain plaintext data, reducing on-chain verification costs. Compared to Zama, Fhenix focuses more on 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 bottom layer, while a lightweight microkernel at the middle layer isolates suspicious instructions, reducing the attack surface of SGX. The ParaTime interface uses Cap'n Proto binary serialization to ensure efficient cross-ParaTime communication. Additionally, Oasis has developed a "durable logging" module that writes critical 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 single small-sized SNARK. The proof generator uses a parallelized depth-first search algorithm written in Rust, achieving 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 accelerate online phase computations. Nodes within each shard interact via gRPC communication and TLS 1.3 encrypted channels to ensure data transmission security. Partisia's parallel sharding mechanism also supports dynamic load balancing, adjusting shard sizes in real-time based on node load.

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

Image source: @tpcventures

3.1 Overview of Different Privacy Computing Solutions

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

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

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

• Multi-Party Computation (MPC): Utilizes cryptographic protocols to allow multiple parties to jointly compute function outputs without revealing their private inputs. MPC does not have a single point of trust in hardware, but requires multi-party interaction, leading to high communication overhead and performance limitations due to network latency and bandwidth. Compared to FHE, MPC incurs much lower computational overhead, but has high implementation complexity, requiring careful design of protocols and architectures.

• Zero-Knowledge Proof (ZKP): A cryptographic technique that allows a verifier to confirm the truth of a statement without revealing any additional information. The prover can demonstrate to the verifier that they possess certain secret information (such as 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, and the key lies in the scenario requirements. For cross-chain signatures, which require multi-party collaboration and avoidance of single-point private key exposure, MPC is quite practical. For example, in threshold signatures, multiple nodes each hold a part of the key fragment and complete the signature together, with no one able to independently control the private key. There are also more advanced solutions, such as the Ika network, which treats the user as one party and the system node as another, using 2PC-MPC for parallel signing, capable of processing thousands of signatures at once and horizontally scaling—more nodes mean faster processing. However, TEE can also accomplish cross-chain signatures by running signature logic on SGX chips, which is fast and easy to deploy, but the issue is that once the hardware is compromised, the private key is also leaked, placing complete trust in the chip and manufacturer. FHE is relatively weak in this regard, as signature computation does not fall within its expertise of "addition and multiplication"; although it can theoretically perform such tasks, the overhead is too high, and essentially no one does this in real systems.

In DeFi scenarios, such as multi-signature wallets, vault insurance, and institutional custody, multi-signature itself is secure, but the question lies in how to store the private key and how to share the signing risk. MPC is currently a mainstream approach, with service providers like Fireblocks splitting signatures into several parts, with different nodes participating in the signing process, ensuring that even if one node is compromised, there are no issues. Ika's design is also interesting, as it achieves "non-collusion" of private keys through a two-party model, reducing the possibility of the traditional MPC scenario where "everyone colludes to do harm." TEE also has applications in this area, such as hardware wallets or cloud wallet services, using trusted execution environments to ensure signature isolation, but still cannot avoid hardware trust issues. FHE currently has little direct application in custody, focusing more on protecting transaction details and contract logic; for instance, in a privacy transaction, others cannot see the amount and address, but this is not directly related to private key custody. Therefore, in this scenario, MPC emphasizes decentralized trust, TEE emphasizes performance, and FHE is primarily used in higher-level privacy logic.

In AI and data privacy, the situation differs again, with FHE's advantages becoming quite apparent. It allows data to remain encrypted throughout the process; for example, if you upload medical data to the chain for AI inference, FHE enables the model to make judgments without seeing plaintext, then outputting the results, ensuring that no one can view the data throughout the process. This ability for "computation in encryption" is very suitable for handling sensitive data, especially in cross-chain or cross-institution collaboration. For instance, Mind Network is exploring enabling PoS nodes to complete voting verification through FHE without knowing each other's information, preventing nodes from copying answers and ensuring the privacy of the entire process. MPC can also be used for federated learning, where different institutions collaborate to train models, each retaining local data without sharing, only exchanging intermediate results. However, once the number of participants increases, communication costs and synchronization become issues, and most current implementations are still experimental. TEE can run models directly in a protected environment and has federated learning platforms using it for model aggregation, but its limitations are also evident, such as memory constraints and side-channel attacks. Therefore, in AI-related scenarios, FHE's "full encryption" capability stands out, while MPC and TEE can serve as auxiliary tools, but specific solutions need to be paired.

3.3 Differentiation Among Different Solutions

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

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

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

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

4. Common Market View: "Is FHE Superior to TEE, ZKP, or MPC?"

It seems that whether FHE, TEE, ZKP, or MPC, all four face an impossible triangle problem in solving practical use cases: "performance, cost, security." Although FHE has attractive theoretical privacy guarantees, it does not outperform TEE, MPC, or ZKP in all aspects. The cost of poor performance makes FHE difficult to promote, 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 also differ: TEE and MPC each provide different trust models and deployment conveniences, while ZKP focuses on verifying correctness. As industry perspectives point out, different privacy tools have their advantages and limitations, and there is no "one-size-fits-all" optimal solution. For example, for verifying complex off-chain computations, ZKP can solve it efficiently; for computations where multiple parties need to share private states, MPC is more direct; TEE provides mature support in mobile and cloud environments; while FHE is suitable for extremely sensitive data processing but currently still requires hardware acceleration to be effective.

FHE is not "universally superior"; the choice of technology should depend on application needs and performance trade-offs. Perhaps in the future, privacy computing will often result from the complementary and integrated use 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 being decentralized asset control without custody. In contrast, ZKP excels at generating mathematical proofs for on-chain verification of states or computation results. The two are not simply alternatives or competitors but rather complementary technologies: ZKP can be used to verify the correctness of cross-chain interactions, thereby reducing the trust requirements on bridging parties to some extent, while Ika's MPC network provides the underlying foundation for "asset control rights," which can be combined with ZKP to build more complex systems. Additionally, 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 to use the most suitable technology components in combination to build modular solutions.

References:
(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