View the technical game between FHE, TEE, ZKP and MPC from the sub-second MPC network launched by Sui
Reprinted from panewslab
05/09/2025·14DAuthor: YBB Capital Researcher Ac-Core
1. Overview and positioning of Ika network
Source: Ika
The Ika Network, which provides strategic support for the Sui Foundation, recently officially disclosed its technological positioning and development direction. As an innovative infrastructure based on multi-party secure computing (MPC) technology, the most prominent feature of the network is its sub-second response speed, which is the first time that it has appeared in similar MPC solutions. The technical adaptability of lka and Sui blockchain is particularly prominent. The two are highly consistent in underlying design concepts such as parallel processing and decentralized architecture. In the future, Ika will be directly integrated into the Sui development ecosystem to provide plug-and-play cross-chain security modules for Sui Move smart contracts.
From the perspective of functional positioning, Ika is building a new security verification layer: as a dedicated signature protocol for the Sui ecosystem, and also outputs standardized cross-chain solutions to the entire industry. Its layered design takes into account the flexibility of protocols and the convenience of development, and has a certain probability that it will become an important practical case for the large-scale application of MPC technology to multi-chain scenarios.
1.1 Analysis of core technology
The technology implementation of Ika network revolves around high-performance distributed signatures. Its innovation lies in the use of the 2PC-MPC threshold signature protocol in conjunction with Sui's parallel execution and DAG consensus to achieve true sub-second signature capabilities and large-scale decentralized node participation. Through the 2PC-MPC protocol, parallel distributed signature and close combination of Sui consensus structure, Ika wants to build a multi-party signature network that meets ultra-high performance and strict security needs at the same time. Its core innovation lies in introducing broadcast communication and parallel processing into the threshold signature protocol, and the following is the disassembly of the core functions.
2PC-MPC Signing Agreement : Ika adopts an improved two-party MPC solution (2PC-MPC), which essentially decomposes the user's private key signature operation into a process in which the two roles "user" and "Ika Network" participate together. The complex process that originally required nodes to communicate with each other (similar to everyone in WeChat group chats to chat with everyone) is changed to a broadcast mode (similar to group announcements). The computing communication overhead for users is also maintained at a constant level, regardless of network size, so that signature delay can still be maintained at sub-second levels.
Parallel processing, disassemble the tasks and do it simultaneously : Ika uses parallel computing to decompose a single signature operation into multiple concurrent subtasks and execute them simultaneously between nodes, hoping to greatly improve the speed. This combines Sui's object-centric model, so the network does not need to reach a global sequential consensus on each transaction, and can handle many transactions at the same time, improving throughput and reducing latency. Sui's Mysticeti consensus eliminates block authentication delays with a DAG structure, allowing instant block submissions, so that Ika can obtain sub-second final confirmation on Sui.
Large-scale node network : Traditional MPC solutions usually can only support 4-8 nodes, while Ika can be extended to thousands of nodes to participate in signatures. Each node only holds a part of the key fragment, and even if some nodes are compromised, they cannot recover the private key separately. Valid signatures can only be generated when the user and network nodes are involved, and no single party can operate independently or forge signatures. Such node distribution is the core of the Ika 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 for a certain chain (such as Sui) wants to manage multi-party signature accounts on Ika, it needs to verify the status of the chain in the Ika network. Ika does this by deploying the corresponding chain's light client (state proofs) in its own network. At present, Sui state proof has been implemented first, so that the contract on Sui can embed dWallet as a component into business logic, and complete the signature and operation of other chain assets through the Ika network.
1.2 Can Ika reversely empower the Sui ecosystem?
Source: Ika
After Ika goes online, it is possible to expand the capability boundaries of Sui blockchain and will also bring some support to the infrastructure of the entire Sui ecosystem. Sui's native token SUI and Ika's token $IKA will be used together, and $IKA will be used to pay the signature service fee of the Ika network and also serve as a pledge asset for the node.
The biggest impact of Ika on the Sui ecosystem is that it brings cross-chain interoperability capabilities to Sui. Its MPC network supports the access of assets on chains such as Bitcoin and Ethereum to the Sui network with relatively low latency and high security, thereby realizing cross-chain DeFi operations such as liquidity mining and lending, which will help enhance Sui's competitiveness in this area. Because of its fast confirmation speed and strong scalability, Ika has been connected to multiple Sui projects, which has also promoted the development of the ecosystem to a certain extent.
In terms of asset security, Ika provides a decentralized custody mechanism. Users and institutions can manage on-chain assets through its multi-party signature method, which is more flexible and safer than traditional centralized custody solutions. Even transaction requests initiated off-chain can be safely executed on Sui.
Ika also designed a chain abstraction layer, allowing smart contracts on Sui to directly operate accounts and assets on other chains, without the need to go through cumbersome bridging or asset encapsulation processes, which simplifies the entire cross-chain interaction process. The access to native Bitcoin also allows BTC to directly participate in DeFi and hosting operations on Sui.
In the last aspect, I also believe 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 when executing transactions, and also provides a possibility for the Sui ecosystem to expand in the AI direction in the future.
1.3 Challenges Facing LKA
Although Ika and Sui are closely linked, if you want to become the "general standard" for cross-chain interoperability, it depends on whether other blockchains and projects are willing to accept them. There are already many cross-chain solutions on the market, such as Axelar and LayerZero, which are widely used in different scenarios. If Ika wants to break through, it must find a better balance between "decentralization" and "performance", attracting more developers to be willing to access and making more assets willing to migrate in.
Speaking of MPC, there are also many controversies. The common problem is that signature permissions are difficult to revoke. Just like a traditional MPC wallet, once the private key is split and sent out, even if it is resliced, the person who gets the old fragments can theoretically recover the original private key. Although the 2PC-MPC solution improves security through continuous user participation, I think there is no particularly perfect solution mechanism in the field of "how to safely and efficiently replace nodes", which may be a potential risk point.
Ika itself also depends on the stability of the Sui network and its own network status. If Sui makes major upgrades in the future, such as updating the Mysticeti consensus to the MVs2 version, Ika must also adapt. Mysticeti, a consensus based on DAG, supports high concurrency and low handling fees, but because there is no main chain structure, it may make the network path more complex and transaction sorting more difficult. In addition, it is asynchronous accounting, which, although efficient, also brings new sorting and consensus security issues. Moreover, the DAG model is very dependent on active users. If the network usage is not high, transaction confirmation delays and security reductions are prone to occur.
2. 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 the "hierarchical Bootstrapping" strategy, splitting large circuits into several small circuits to encrypt them separately, and then dynamically splicing the results, significantly reducing the delay of a single Bootstrapping. It also supports "hybrid encoding" - the delay-sensitive integer operations are encoded with CRT, and the Boolean operations with high parallelism are encoded with bit-level encoding, taking into account performance and parallelism. In addition, Concrete provides a "key packaging" mechanism, which can reuse multiple isomorphic operations after one 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 miniature Bootstrapping before and after execution of arithmetic instructions to restore noise budgets. At the same time, Fhenix designed an off-chain oracle bridge module to perform proof checks before interacting with the on-chain ciphertext status and off-chain plaintext data, reducing the on-chain verification cost. Compared with Zama, Fhenix focuses more on EVM compatibility and seamless access to on-chain contracts
2.2 TEE
Oasis Network: Based on Intel SGX, Oasis introduced the concept of "Root of Trust". The underlying layer uses SGX Quoting Service to verify the trustworthiness of the hardware. The middle layer has a lightweight microkernel, which is responsible for isolating suspicious instructions and reducing the attack surface of SGX slugs. ParaTime's interface is serialized using Cap'n Proto binary to ensure efficient communication across ParaTime. At the same time, Oasis developed the "Durability Log" module to write key state changes into trusted logs to prevent rollback attacks.
2.3 ZKP
Aztec: In addition to Noir compilation, Aztec integrates "incremental recursion" technology in generating proofs, recursively packages multiple transaction proofs in a time series, and then generates a small-size SNARK once. 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 simply 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" to pre-form Beaver triplets off-chain to accelerate online phase operations. Each node in the shard interacts through gRPC communication and TLS 1.3 encryption channel to ensure the security of data transmission. Partisia's parallel sharding mechanism also supports dynamic load balancing, adjusting shard size in real time according to node load.
3. Privacy calculation FHE, TEE, ZKP and MPC
Source: @tpcventures
3.1 Overview of different privacy computing schemes
Privacy computing is a hot topic in the field of blockchain and data security. The main technologies include full homomorphic encryption (FHE), trusted execution environment (TEE) and multi-party security computing (MPC).
-
Fully homomorphic encryption (FHE): An encryption scheme that allows arbitrary calculations of encrypted data without decryption, realizing the full encryption of input, calculation process and output. It ensures safety based on complex mathematical problems (such as grid problems), and has theoretically complete computing capabilities, but has great computing overhead. In recent years, the industry and academia have improved performance by optimizing algorithms, dedicated libraries (such as Zama's TFHE-rs, Concrete) and hardware acceleration (Intel HEXL, FPGA/ASIC), but it is still a "slow-down fast attack" technology.
-
Trusted Execution Environment (TEE): Trusted hardware modules provided by the processor (such as Intel SGX, AMD SEV, and ARM TrustZone) can run code in isolated secure memory areas, making it impossible for external software and operating systems to peek at the execution data and status. TEE relies on the hardware root of trust, and its performance is close to native computing, and generally only has a small overhead. TEE can provide confidential execution for applications, but its security relies on hardware implementations and vendor-provided firmware, with potential backdoor and side channel risks.
-
Multi-party secure computing (MPC): Using cryptography protocol, multiple parties allow them to jointly calculate function output without revealing their own private inputs. MPC does not have single point of trust hardware, but the computing requires multi-party interaction, the communication overhead is large, and the performance is limited by network latency and bandwidth. Compared to FHE, MPC is much smaller in computational overhead, but has high implementation complexity and requires careful design of protocols and architectures.
-
Zero Knowledge Proof (ZKP): Cryptography technology that allows the verification party to verify that a statement is true without revealing any additional information. The proofer can prove to the verifier that he has a certain secret information (such as a password), but does not need to disclose the information directly. Typical implementations include zk-SNARK based on elliptic curves and zk-STAR based on hash.
3.2 What are the adaptation scenarios for FHE, TEE, ZKP and MPC?
Source: biblicalscienceinstitute
Different privacy computing technologies have their own focus, and the key lies in scenario needs. Take cross-chain signatures as an example. They require multi-party collaboration to avoid single point private key exposure. MPC is more practical at this time. Like Threshold Signature, multiple nodes each save a part of the key fragment and complete the signature together. No one can control the private key separately. There are still more advanced solutions now, such as Ika Network, which treats users as one system node as the other, uses 2PC-MPC parallel signatures, can process thousands of signatures at a time, and can scale horizontally, the more nodes, the faster it is. However, TEE can also complete cross-chain signatures, and can run signature logic through SGX chips, which is fast and easy to deploy. However, the problem is that once the hardware is broken, the private key will be leaked, and trust will be completely entrusted to the chip and manufacturers. FHE is relatively weak in this area because signature calculation does not belong to the "addition and multiplication" model it is good at. Although it can be done theoretically, the overhead is too high, and basically no one does this in the real system.
Let’s talk about DeFi scenarios, such as signing more wallets, vault insurance, and institution custody. Multiple signings are safe, but the problem lies in how to save the private key and share the risks. MPC is the most mainstream method now. Service providers such as Fireblocks split the signature into several copies. Different nodes participate in the signature, and no problem will occur if any node is hacked. Ika's design is also quite interesting. The "no conspiracy" of private keys is realized through the two-party model, reducing the possibility of "everyone discusses and commits evil together" in traditional MPC. TEE also has applications in this area, such as hardware wallets or cloud wallet services, which use a trusted execution environment to ensure signature isolation, but still cannot avoid the hardware trust issue. FHE does not have much direct effect at the custody level at present, but is more about protecting transaction details and contract logic. For example, if you do a privacy transaction, others cannot see the amount and address, but this has nothing to do with private key custody. So in this scenario, MPC pays more attention to dispersing trust, TEE emphasizes performance, and FHE is mainly used in higher-level privacy logic.
In terms of AI and data privacy, the situation will have different advantages. FHE is more obvious here. It can keep the data encrypted from beginning to end. For example, if you throw medical data on the chain for AI reasoning, FHE can allow the model to complete the judgment without seeing the plain text, and then output the results. No one can see the data clearly during the whole process. This “computing in encryption” capability is ideal for sensitive data processing, especially when collaborating across chains or across institutions. For example, Mind Network is exploring to allow PoS nodes to complete voting verification through FHE without knowing each other, preventing nodes from copying answers, and ensuring the privacy of the entire process. MPC can also be used for joint learning, such as different institutions cooperate to train models, each maintaining local data without sharing, and only exchanging intermediate results. However, once there are more participants in this method, communication costs and synchronization will become problems, and most of them are experimental projects. Although TEE can directly run models in a protected environment, and there are federated learning platforms that use it for model aggregation, its limitations are also obvious, such as memory limits and side channel attacks. Therefore, in AI-related scenarios, FHE's "full encryption" capability is the most outstanding. MPC and TEE can be used as auxiliary tools, but specific solutions are still needed.
3.3 Differentiation in different schemes
Performance and latency: FHE (Zama/Fhenix) has high latency due to frequent Bootstrapping, but can provide the strongest data protection in the encrypted state; TEE (Oasis) has the lowest latency, close to ordinary execution, but requires hardware trust; ZKP (Aztec) has controllable delay in batch proof, and a single transaction delay is between the two; MPC (Partisia) has medium and low latency, which is most affected by network communication.
Trust Hypothesis: FHE and ZKP are both based on mathematical problems and do not need to trust third parties; TEE relies on hardware and manufacturers, and poses a risk of firmware vulnerability; MPC relies on semi-honest or at most t-abnormal models, which are sensitive to the number and behavioral assumptions of participants.
Scalability: ZKP Rollup (Aztec) and MPC shards (Partisia) naturally support horizontal scaling; FHE and TEE expansions need to consider computing resources and hardware node supply.
Integration difficulty: The access threshold for TEE projects is the lowest and the programming model is minimal; ZKP and FHE both require special circuits and compilation processes; MPC requires protocol stack integration and cross-node communication.
4. Common market view: "FHE is better than TEE, ZKP or MPC"?
It seems that whether it is FHE, TEE, ZKP or MPC, there is also an impossible triangle problem in solving actual use cases: "performance, cost, and security". While FHE is attractive in theoretical privacy protection, it is not superior to TEE, MPC or ZKP in all respects. The cost of low performance makes it difficult for FHE to promote its computing speed far behind other solutions. TEE, MPC or ZKP is often more feasible in real-time and cost-sensitive applications.
Trust and applicable scenarios are also different: TEE and MPC each provide different trust models and deployment conveniences, while ZKP focuses on verifying correctness. As pointed out in the industry, different privacy tools have their own advantages and limitations, and there is no "one-size-fits-all" optimal solution. For example, for the verification of complex off-chain computing, ZKP can be efficiently solved; for computing where multiple parties need to share private state, MPC is more direct; TEE provides mature support in mobile and cloud environments; while FHE is suitable for extremely sensitive data processing, but hardware acceleration is still required to play a role.
FHE is not "universal and superior". Which technology to choose should be determined by application needs and performance trade-offs. Perhaps in the future, privacy computing is often the result of complementary and integration of multiple technologies, rather than winning by a single solution. For example, Ika focuses on key sharing and signature coordination in design (users always retain a private key), and its core value lies in achieving decentralized asset control without custody. In contrast, ZKP is good at generating mathematical proofs to verify states or calculate results on the supply chain. The two are not simple alternative or competitive relationships, but more like complementary technologies: ZKP can be used to verify the correctness of cross-chain interactions, thereby reducing the trust needs for the bridging party to a certain extent, while Ika's MPC network provides the underlying foundation of "asset control" and 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 integrates MPC, FHE, TEE and ZKP to balance security, cost and performance. Therefore, in the future, the privacy computing ecosystem will tend to use the most appropriate technical components to build modular solutions.
Reference content:
(2) https://blog.sui.io/ika-dwallet-mpc-network-interoperability/
jinse