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

Original Author: YBB Capital Researcher Ac-Core

1. Overview and Positioning of the Ika Network

Image source: Ika

The IKA network, which is strategically supported by the Sui Foundation, has recently made public its technology positioning and direction. As an innovative infrastructure based on Multi-Party Secure Computing (MPC) technology, the network is most notably characterized by its sub-second response time, which is the first of its kind in an MPC solution. In the future, Ika will be directly integrated into the Sui development ecosystem to provide a plug-and-play cross-chain security module for Sui Move smart contracts.

From a functional perspective, Ika is constructing a new type of security verification layer: serving both as a dedicated signing protocol for the Sui ecosystem and providing standardized cross-chain solutions for the entire industry. Its layered design balances protocol flexibility and development convenience, and has 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 signatures, with its innovation lying in the utilization of the 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 through the 2PC-MPC protocol, parallel distributed signatures, and close integration with the Sui consensus structure. Its core innovation is the introduction of broadcast communication and parallel processing into the threshold signature protocol, with the following being a breakdown of core functionalities.

2PC-MPC Signing Protocol: Ika uses an improved two-party MPC scheme (2PC-MPC) that essentially decomposes the signing of a user's private key into a process in which both the "user" and the "Ika network" are involved. The complex process that originally required nodes to communicate in pairs (similar to the private chat between everyone in a WeChat group chat) was changed to a broadcast mode (similar to a group announcement), and the computational communication cost for users was also kept at a constant level, regardless of the network scale, so that the signature delay could still be maintained at the sub-second level.

Parallel processing, breaking tasks down to execute them simultaneously: Ika utilizes parallel computing to decompose a single signing operation into multiple concurrent subtasks that are executed simultaneously across nodes, aiming to significantly enhance speed. This integrates Sui's object-centric model, where the network does not need to reach global consensus on each transaction, allowing it to handle numerous transactions simultaneously, increasing throughput and reducing latency. Sui's Mysticeti consensus eliminates block authentication delays with a DAG structure, allowing for immediate block submission, enabling Ika to achieve sub-second finality 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, so even if some nodes are compromised, the private key cannot be reconstructed independently. An effective signature can only be generated when both the user and network nodes participate together; no single party can operate or forge a signature independently. 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 in the Ika network (called dWallet). Specifically, if a smart contract on a certain chain (such as Sui) wants to manage multi-signature accounts on Ika, it needs to verify the status of that chain within the Ika network. Ika achieves this by deploying light clients (state proofs) of the corresponding chain in its own network. Currently, Sui state proofs have been implemented first, enabling contracts on Sui to embed dWallet as a component within business logic and complete signatures and operations on assets from other chains through the Ika network.

1.2 Can Ika reverse empower the Sui ecosystem?

Image source: Ika

After Ika goes live, it may expand the capability boundaries of the Sui blockchain and also 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 the signature service fees on the Ika network and also serving as the staking asset for nodes.

Ika's biggest impact on the Sui ecosystem is that it brings cross-chain interoperability capabilities 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. This enables cross-chain DeFi operations such as liquidity mining and lending, helping to 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, which has also promoted the development of the ecosystem to some extent.

In terms of asset security, Ika offers 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 transaction requests initiated off-chain can be securely executed on Sui.

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

In the last aspect, I also think that IKA also provides a multi-party verification mechanism for AI automation applications, which can avoid unauthorized asset operations, improve the security and credibility of AI execution transactions, and also provide a possibility for the future expansion of the Sui ecosystem in the direction of AI.

Challenges faced by 1.3 lka

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 many cross-chain solutions on 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 to integrate and encourage more assets to migrate in.

When it comes to MPC, there are quite a few controversies. A common issue is that signature permissions are hard to revoke. Just like traditional MPC wallets, once the private key is split and distributed, even if the shards are re-split, theoretically, the person who holds the old shard could still restore the original private key. Although the 2PC-MPC scheme improves security through continuous user participation, I believe that currently there is still no particularly refined solution for "how to securely and efficiently change nodes", which could be a potential risk point.

IKA itself also relies on the stability of the Sui network and its own network conditions. If Sui makes a major upgrade in the future, such as updating the Mysticeti consensus to MVs 2, Ika will have to adapt as well. Mysticeti, a DAG-based consensus, supports high concurrency and low fees, but because it does not have a main chain structure, it may make the network path more complex and the transaction ordering more difficult. Coupled with the fact that it is asynchronous bookkeeping, although it is efficient, it also brings new ordering and consensus security issues. Moreover, the DAG model is very dependent on active users, and if the network usage is not high, it is prone to transaction confirmation delays and security degradation.

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

2.1 FHE

Zama & Concrete: In addition to the general-purpose compiler based on MLIR, Concrete adopts a "layered Bootstrapping" strategy, which breaks down large circuits into several small circuits for individual encryption and then dynamically stitches the results together, significantly reducing the latency of a single Bootstrapping. It also supports "hybrid encoding"—using CRT encoding for delay-sensitive integer operations and bit-level encoding for Boolean operations that require high parallelism, balancing performance and parallelism. Additionally, Concrete provides a "key packing" mechanism, allowing multiple reuse of homomorphic operations 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 budget. At the same time, Fhenix has designed an off-chain oracle bridging module that performs proof checks before interacting between on-chain ciphertext states and off-chain plaintext data, reducing on-chain verification costs. Compared to Zama, Fhenix focuses more on EVM compatibility and seamless access to on-chain contracts.

2.2 TEE

Oasis Network: Based on Intel SGX, Oasis introduces the concept of "Root of Trust" with a layered approach. The underlying layer uses the SGX Quoting Service to verify hardware trustworthiness, while the middle layer features a lightweight microkernel responsible for isolating suspicious instructions and reducing the attack surface of SGX side-channel attacks. The ParaTime interface employs Cap’n Proto binary serialization to ensure efficient communication across ParaTime. Additionally, Oasis has developed a "durable logs" module that writes critical state changes into a trusted log to prevent rollback attacks.

2.3 ZKP

Aztec: In addition to Noir compilation, Aztec integrates the "incremental recursion" technology in the generation of proofs, which recursively packages multiple transaction proofs according to time series, and then generates a small SNARK in a unified manner. The proof generator uses Rust to write a parallelized depth-first search algorithm that enables linear acceleration on multi-core CPUs. In addition, to reduce user waiting, Aztec provides a "light node mode", where nodes only need to download and verify zkStream instead of full 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 in advance 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 current hot topic in the 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): An encryption scheme that allows arbitrary computation of encrypted data without decryption, and realizes the full encryption of input, computational process and output. It is safe based on complex mathematical problems (such as lattice problems) and has theoretically complete computing capabilities, but the computational overhead is extremely high. In recent years, industry and academia have improved performance through optimized algorithms, dedicated libraries (e.g., Zama's TFHE-rs, Concrete), and hardware acceleration (Intel HEXL, FPGA/ASIC), but this is still a "slow-fast-breaking" technology.
• Trusted Execution Environment (TEE): A trusted hardware module provided by the processor (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 a hardware root of trust, offering performance close to native computation with generally minimal overhead. TEE can provide confidential execution for applications, but its security depends on the hardware implementation and firmware provided by the vendor, which may have potential backdoors and side-channel risks.
• Multi-Party Computation (MPC): Utilizing cryptographic protocols, it allows multiple parties to jointly compute function outputs without revealing their private inputs. MPC does not have a single point of trusted hardware, but requires multi-party interaction, resulting in high communication overhead, and performance is limited by network latency and bandwidth. Compared to Fully Homomorphic Encryption (FHE), MPC has much lower computational overhead, but the implementation complexity is high, requiring careful design of protocols and architecture.
• Zero-Knowledge Proofs (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 a secret piece of information (such as a password) without having to directly disclose that information. Typical implementations include elliptic curve-based zk-SNARK and hash-based zk-STAR.

What are the adaptation scenarios for 3.2 FHE, TEE, ZKP, and MPC?

Image source: biblicalscienceinstitute

Different privacy-preserving computing technologies have their own emphasis, and the key lies in the scenario requirements. Take cross-chain signatures as an example, which requires multi-party collaboration and avoids single-point private key exposure, in which case MPC is more practical. Like Threshold Signature, multiple nodes each save a portion of the key fragment and sign it together, so that no one can control the private key alone. There are some more advanced solutions, such as the Ika network, which treats users as one system node as the other, and uses 2PC-MPC to sign in parallel, which can process thousands of signatures at a time, and can be scaled horizontally, the more nodes the faster. However, TEE can also complete cross-chain signatures, and can run signature logic through SGX chips, which is fast and easy to deploy, but the problem is that once the hardware is breached, the private key is also leaked, and the trust is completely pinned on the chip and the manufacturer. FHE is weak in this area, because signature calculation does not belong to the "addition and multiplication" mode that it is good at, although it can be done theoretically, but the overhead is too great, and basically no one does it in a real system.

In DeFi scenarios, such as multisig wallets, vault insurance, and institutional custody, multisig itself is secure, but the problem lies in how to save the private key and how to share the risk. MPC is now a more mainstream way, such as Fireblocks and other service providers, the signature is split into several parts, different nodes participate in the signing, and any node is hacked without problems. Ika's design is also quite interesting, using a two-party model to achieve "non-collusion" of private keys, reducing the possibility of traditional MPC "everyone agrees to do evil together". TEE also has applications in this regard, such as hardware wallets or cloud wallet services, which use a trusted execution environment to ensure signature isolation, but it still can't avoid the hardware trust problem. FHE does not have much direct role at the custody level at present, but more to protect the transaction details and contract logic, for example, if you make a private transaction, others can't see the amount and address, but this has nothing to do with private key escrow. Therefore, in this scenario, MPC focuses more on decentralized trust, TEE emphasizes performance, and FHE is mainly used for higher-level privacy logic.

When it comes to AI and data privacy, the situation will be different, and the advantages of FHE are evident here. It can keep the data encrypted from beginning to end, for example, if you throw medical data on-chain for AI inference, FHE can make the model complete the judgment without seeing the plaintext, and then output the results so that no one can see the data in the whole process. This ability to "compute in encryption" is ideal for handling sensitive data, especially when collaborating across chains or institutions. For example, Mind Network is exploring allowing PoS nodes to complete voting verification without knowing each other through FHE, preventing nodes from copying answers and ensuring the privacy of the whole process. MPC can also be used for federated learning, such as different institutions cooperating to train models, each holding local data without sharing, and only exchanging intermediate results. However, once there are more participants in this method, the cost and synchronization of communication will become a problem, and most of the projects are still experimental. Although TEE can directly run models in a protected environment, and some federated learning platforms use it for model aggregation, it also has obvious limitations, such as memory limitations and side-channel attacks. Therefore, in AI-related scenarios, the "full encryption" capability of FHE is the most prominent, and MPC and TEE can be used as auxiliary tools, but specific solutions are still needed.

3.3 Differences between different solutions

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

Trust Assumption: FHE and ZKP are based on mathematical problems and do not require trust in third parties; TEE relies on hardware and vendors, which poses risks of firmware vulnerabilities; MPC depends on the semi-honest or at most t faulty model, sensitive to the number of participants and behavioral assumptions.

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

Integration Difficulty: The TEE project has the lowest entry threshold and requires the least modification to the programming model; both ZKP and FHE require specialized circuits and compilation processes; while MPC requires protocol stack integration and cross-node communication.

4. General Market Opinion: "Is FHE Superior to TEE, ZKP, or MPC?"

It seems that whether it's FHE, TEE, ZKP, or MPC, all four face an impossible triangle problem in addressing practical use cases: "performance, cost, and security." Although FHE has theoretical appeal in terms of privacy guarantees, it does not outperform TEE, MPC, or ZKP in all aspects. The cost of poor performance makes it difficult for FHE to be promoted, as its computational speed lags far behind other solutions. In applications sensitive to real-time requirements and costs, TEE, MPC, or ZKP are often more feasible.

Trust and applicable scenarios differ: TEE and MPC each provide different trust models and deployment convenience, while ZKP focuses on verifying correctness. As industry perspectives point out, different privacy tools have their own advantages and limitations, and there is no "one-size-fits-all" optimal solution. For instance, ZKP can efficiently solve the verification of complex off-chain computations; for computations where multiple parties need to share private states, MPC is more direct; TEE provides mature support in mobile and cloud environments; and FHE is suitable for handling extremely sensitive data, but currently still requires hardware acceleration to be effective.

FHE is not a "one-size-fits-all", and the choice of technology should depend on the trade-off between application needs and performance, and perhaps the future of privacy computing is often the result of the complementarity and integration of multiple technologies, rather than a single solution wins. For example, IKA is designed with a focus on key-sharing and signature coordination (the user always keeps a copy of the private key), and its core value is to enable decentralized asset control without the need for custody. In contrast, ZKP excels at generating mathematical proofs for on-chain verification of state or computational results. The two are not simply substitutes or competitors, but more like complementary technologies: ZKP can be used to verify the correctness of cross-chain interactions, thereby reducing the need for trust in the bridging party to some extent, while Ika's MPC network provides the underlying foundation for "asset control" that can be combined with ZKP to build more complex systems. In addition, Nillion began to incorporate multiple privacy technologies to improve overall capabilities, and its blind computing architecture seamlessly integrated MPC, FHE, TEE, and ZKP to balance security, cost, and performance. Therefore, in the future, the privacy-preserving computing ecosystem will tend to use the most appropriate combination of technical components to build modular solutions.

Reference content:

( 1)

( 2)

( 3) caff.com/zh/archives/29752? ref= 416

( 4)