Original Title: "The Technical Game of FHE, TEE, ZKP, and MPC from the Perspective of the Sub-Second MPC Network Launched by Sui"

Original Author: Ac-Core, YBB Capital Researcher

1. Ika Network Overview and Positioning

Image Source: Ika

The Ika Network, supported by the Sui Foundation, has recently publicly announced its technical positioning and development direction. As an innovative infrastructure based on Multi-Party Computation (MPC) technology, the network's most significant feature is its sub-second response time, which is a first in similar MPC solutions. The technical compatibility between Lka and the Sui blockchain is particularly prominent, with both sharing underlying design principles such as parallel processing and decentralized architecture. 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 standpoint, Ika is building a new secure verification layer: serving as both a dedicated signature protocol for the Sui ecosystem and aiming to provide standardized cross-chain solutions for the entire industry. Its layered design balances protocol flexibility and development convenience, with a good chance of becoming a significant practical case for large-scale MPC technology application 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 use of 2PC-MPC threshold signature protocols 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 simultaneously meets ultra-high performance and stringent security requirements through the 2PC-MPC protocol, parallel distributed signatures, and close integration with the Sui consensus structure. Its core innovation lies in introducing broadcast communication and parallel processing into the threshold signature protocol, as outlined in the following core function breakdown.

· 2PC-MPC Signature Protocol: Ika employs an improved two-party MPC scheme (2PC-MPC), essentially decomposing the user's private key signature operation into a process involving both the "user" and the "Ika Network" roles. By transforming the complex process that originally required node-to-node communication (similar to private chats between everyone in a WeChat group) into broadcast mode (similar to group announcements), the computational communication overhead for users remains at a constant level, independent of network scale, allowing the signature delay to remain in the sub-second range.

· Parallel Processing, Breaking Down Tasks and Working on Them Simultaneously: Ika utilizes parallel computing to decompose a single signing operation into multiple concurrent subtasks that are executed simultaneously among nodes, aiming to significantly improve speed. Here, Sui's object-centric model is combined, where the network does not need to achieve global sequential consensus for each transaction, allowing it to process numerous transactions simultaneously, thus increasing throughput and reducing latency. Sui's Mysticeti consensus, with a DAG structure, eliminates block validation delay, enabling instant block submission, allowing Ika to achieve sub-second finality on Sui.

· Large-Scale Node Network: Traditional MPC solutions usually only support 4-8 nodes, while Ika can scale to involve over a thousand nodes in the signing process. Each node holds only a portion of the key fragments, and even if some nodes are compromised, the private key cannot be independently recovered. An effective signature can only be generated when users and network nodes participate together, preventing any single party from operating independently or forging signatures. This distributed node setup is a core element of Ika's zero-trust model.

· Cross-Chain Control and Chain Abstraction: As a modularized signature network, Ika allows smart contracts on other chains to directly control the accounts (referred to as dWallet) in the Ika network. Specifically, if a chain's (such as Sui's) smart contract wants to manage a multi-party signature account on Ika, it needs to validate that chain's status in the Ika network. Ika achieves this by deploying the corresponding chain's light client (state proofs) in its network. Currently, Sui state proofs have been initially implemented, allowing contracts on Sui to embed dWallet as a component in the business logic and perform signature and operation on assets from other chains through the Ika network.

1.2 Can Ika Empower the Sui Ecosystem in Return?

Image Source: Ika

After the launch of Ika, it is possible to expand the capabilities of the Sui blockchain and provide some support to the entire Sui ecosystem's infrastructure. The native token of Sui, SUI, and Ika's token $IKA will be used collaboratively, with $IKA being used to pay for Ika network's signature service fees and also serving as a staking asset for nodes.

The most significant impact of Ika on the Sui ecosystem is bringing cross-chain interoperability to Sui, as its MPC network supports integrating 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 borrowing, enhancing Sui's competitiveness in this area. Due to its fast confirmation speed and strong scalability, Ika has already been integrated by several Sui projects, thus driving ecosystem development to some extent.

Regarding 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 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 interact with accounts and assets on other chains without the need for complex bridging or asset wrapping processes, simplifying the entire cross-chain interaction process. The native integration of Bitcoin also enables BTC to directly participate in DeFi and custody operations on Sui.

Lastly, I believe that Ika also provides a multi-signature validation mechanism for AI automation applications, which can prevent unauthorized asset operations, enhance the security and trustworthiness of AI when executing transactions, and pave the way for the future expansion of the Sui ecosystem in the AI direction.

1.3 Challenges Facing Ika

Although Ika is closely tied to Sui, if it aims to become the "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, widely used in different scenarios. For Ika to break through, it must find a better balance between "decentralization" and "performance," attracting more developers to join and encouraging more assets to migrate.

Speaking of MPC, it is not without controversy, with a common issue being the difficulty of revoking signature permissions. Similar to traditional MPC wallets, once the private key is split and distributed, even if re-sharded, theoretically, individuals holding the old shards could still reconstruct the original private key. Although the 2PC-MPC approach enhances security through continuous user participation, I believe that currently, there is no particularly robust mechanism for "how to safely and efficiently change nodes," which may pose a potential risk.

Ika itself also relies on the stability of the Sui network and its own network conditions. If Sui undergoes a major upgrade in the future, such as transitioning from the Mysticeti consensus to the MVs2 version, Ika must also adapt. Mysticeti, based on a DAG consensus, supports high throughput and low fees, but due to its lack of a main chain structure, it may result in more complex network paths and increased transaction ordering difficulty. Furthermore, being asynchronous, although efficient, it introduces new ordering and consensus security challenges. Additionally, the DAG model heavily relies on active users, and if the network utilization is low, issues like transaction confirmation delays and reduced security may arise.

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

2.1 FHE

Zama & Concrete: In addition to a MLIR-based universal compiler, Concrete adopts a "Layered Bootstrapping" strategy, breaking down a large circuit into several smaller circuits encrypted separately, and then dynamically concatenating the results, significantly reducing the latency of a single Bootstrapping. It also supports "Hybrid Encoding" — using CRT encoding for latency-sensitive integer operations and bit-level encoding for operations requiring high parallelism, balancing performance with parallelism. Furthermore, Concrete provides a "Key Packing" mechanism, allowing multiple reuse of homomorphic operations after a single key import, reducing communication overhead.

Fhenix: Building on TFHE, Fhenix has made several customized optimizations for the Ethereum EVM instruction set. It uses "Cipher Virtual Registers" instead of plaintext registers, automatically inserting lightweight Bootstrapping before and after executing arithmetic instructions to restore noise budget. Additionally, Fhenix has designed an off-chain oracle bridging module that performs proof checks before interacting the on-chain ciphertext state with off-chain plaintext data, reducing on-chain verification costs. Compared to Zama, Fhenix focuses more on EVM compatibility and seamless integration with on-chain contracts.

2.2 TEE

Oasis Network: Building on Intel SGX, Oasis introduces the concept of "Layered Root of Trust," where the bottom layer uses the SGX Quoting Service to validate hardware trustworthiness, a lightweight microkernel in the middle layer to isolate suspicious instructions, reducing the attack surface of SGX enclave attacks. The ParaTime interface uses Cap’n Proto binary serialization to ensure efficient cross-ParaTime communication. Additionally, Oasis has developed a "Durability Log" module that writes critical state changes to a trusted log to prevent rollback attacks.

2.3 ZKP

Aztec: In addition to the Noir compiler, Aztec integrates "Incremental Recursion" technology in proof generation, packaging multiple transaction proofs recursively in a time-series manner before uniformly generating a small-sized SNARK. The proof generator is implemented in Rust with a parallelized depth-first search algorithm that achieves linear acceleration on multi-core CPUs. Furthermore, to reduce user wait time, Aztec offers a "Light Node Mode" where nodes only need to download and verify zkStream instead of the full proof, further optimizing bandwidth.

2.4 MPC

Partisia Blockchain: Its MPC implementation is based on the SPDZ protocol extension, which added a "preprocessing module" to pre-generate Beaver triples off-chain to accelerate the online phase computation. Nodes within each shard communicate via gRPC over TLS 1.3 encrypted channels to ensure secure data transmission. Partisia's parallel shard mechanism also supports dynamic load balancing, adjusting shard sizes in real-time based on node loads.

Three, Privacy Computation FHE, TEE, ZKP, and MPC

Image Source: @tpcventures

3.1 Overview of Different Privacy Computation Schemes

Privacy computation is a current hot topic in the blockchain and data security field, 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 on encrypted data without decryption, achieving end-to-end encryption of inputs, the computation process, and outputs. Security is ensured based on complex mathematical problems (such as lattice problems), providing theoretically complete computational capabilities, but incurring high computational overhead. In recent years, 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-burn fast-break" 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 a secure isolated memory area, preventing external software and operating systems from observing executed data and state. TEE relies on hardware roots of trust, offering near-native performance with minimal overhead. TEE can provide confidential execution for applications, but its security relies on hardware implementation and firmware provided by vendors, exposing potential backdoors and side-channel risks.

· Multi-Party Computation (MPC): Using cryptographic protocols, MPC allows multiple parties to jointly compute a function's output without revealing their private inputs. MPC lacks a single point of trust hardware but requires multi-party interaction, incurring high communication overhead with performance impacted by network latency and bandwidth constraints. Compared to FHE, MPC has significantly lower computational overhead but higher implementation complexity, requiring carefully designed 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 prove to the verifier that they know a certain piece of 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 Suitable Scenarios for FHE, TEE, ZKP, and MPC?

Image Source: biblicalscienceinstitute

Various privacy computing technologies have different focuses, depending on the scenario requirements. Take cross-chain signatures, for example. It requires multi-party collaboration to avoid single-point private key exposure, making MPC more practical in such cases. For instance, in Threshold Signatures, multiple nodes each hold a portion of the key fragments and collectively complete the signature, with no single entity controlling the private key. There are even more advanced solutions like the Ika network, which treats users as one-party system nodes and the other party as a system node, using 2PC-MPC parallel signatures that can process thousands of signatures at once and can horizontally scale faster with more nodes. However, TEE can also perform cross-chain signatures by running the signature logic through an SGX chip, offering speed and easy deployment. The downside is that if the hardware is compromised, the private key is also compromised, relying entirely on trust in the chip and the manufacturer. FHE is weaker in this area as signature computation is not within its strong suit of the "addition and multiplication" pattern. Although theoretically possible, the overhead is too high, and practically, hardly anyone does this in real systems.

Now, looking at DeFi scenarios such as multi-signature wallets, vault insurance, and institutional custody, multi-signature itself is secure, but the issue lies in how private keys are stored and signature risks shared. MPC is currently a mainstream approach, with service providers like Fireblocks splitting signatures into several parts, involving different nodes in the signing process, so if any one node is compromised, there will be no issues. Ika's design is quite interesting, achieving private key "non-collusion" through a two-party model, reducing the traditional MPC scenario of "everyone conspiring together to commit fraud." TEE also has applications in this area, such as hardware wallets or cloud wallet services, using a trusted execution environment to ensure signature isolation, but still cannot avoid hardware trust issues. FHE currently has little direct impact on the custody layer but is more focused on protecting transaction details and contract logic. For example, in a privacy transaction where outsiders cannot see the amount or address, this is not closely related to private key custody. Therefore, in this scenario, MPC focuses more on distributed trust, TEE emphasizes performance, and FHE is mainly used in higher-level privacy logic.

In terms of AI and data privacy, the situation is different, and the advantages of FHE are more pronounced here. It can keep data encrypted from start to finish. For example, if you throw medical data onto the blockchain for AI inference, FHE can allow the model to make a judgment without seeing the plaintext, and then output the result, ensuring that nobody can see the data clearly throughout the process. This "compute on encrypted data" capability is very suitable for handling sensitive data, especially in cross-chain or cross-institutional collaboration scenarios. Projects like Mind Network are exploring enabling PoS nodes to perform vote validation through FHE in a state of mutual ignorance, preventing nodes from cheating the 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 holding their local data without sharing, only exchanging intermediate results. However, once there are many participants, communication costs and synchronization become issues, and currently, most of them are experimental projects. Although TEE can run models directly in a secure environment and some federated learning platforms use it for model aggregation, its limitations are also evident, such as memory constraints and side-channel attacks. Therefore, in AI-related scenarios, FHE's "end-to-end encryption" capability is the most prominent, while MPC and TEE can serve as auxiliary tools but require specific solutions to complement.

3.3 Differentiation of Various Solutions

· Performance and Latency: FHE (Zama/Fhenix) has higher latency due to frequent Bootstrapping but can provide 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 in batch proofs, with transaction latency between the two; MPC (Partisia) has medium to low latency, most affected by network communication.

· Trust Assumption: Both FHE and ZKP are based on mathematical challenges and do not require trust in third parties; TEE relies on hardware and manufacturers, exposing risks of firmware vulnerabilities; MPC relies on semi-honest or at most t malicious models, 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 computational resources and hardware node provisioning.

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

4. Common Market Perception: 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 issue in solving practical use cases: "Performance, Cost, Security." Although FHE is theoretically attractive for privacy preservation, it is not superior to TEE, MPC, or ZKP in all aspects. The high cost of performance degradation makes it difficult for FHE to expand its use, as its computational speed lags far behind other solutions. For real-time and cost-sensitive applications, TEE, MPC, or ZKP are often more feasible.

Trust and use cases also vary: TEE and MPC each provide different trust models and deployment convenience, while ZKP focuses on correctness verification. As industry views have pointed out, different privacy tools have their own advantages and limitations, and there is no "one-size-fits-all" optimal solution. For example, for off-chain complex computation verification, ZKP can efficiently solve it; for multi-party computations requiring sharing of private state, MPC is more direct; TEE provides 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," and the choice of technology should be based on application requirements and performance trade-offs. Perhaps in the future, privacy computing will often be the result of the complementary integration of multiple technologies, rather than a single solution winning out. For example, Ika is designed with a focus on key sharing and signature coordination (users always retain a private key), and its core value lies in achieving 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 substitutes or in a competitive relationship but more like complementary technologies: ZKP can be used to verify the correctness of cross-chain interactions, thereby reducing the trust requirements to some extent for bridge operators, while Ika's MPC network provides the underlying foundation for "asset control," which can be combined with ZKP to build more complex systems. Additionally, Nillion has begun integrating multiple privacy technologies to enhance overall capabilities. Its blind computation architecture seamlessly integrates MPC, FHE, TEE, and ZKP to achieve a balance between security, cost, and performance. Therefore, the future privacy computing ecosystem will tend to combine the most suitable technological components 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

This article is contributed content and does not represent the views of BlockBeats.

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia