One, Ika Network Overview and Positioning

Image source: Ika

The Sui Foundation has officially disclosed the technical positioning and development direction of the Ika network, which receives strategic support. As an innovative infrastructure based on Multi-Party Computation (MPC) technology, the network’s most prominent feature is its sub-second response time, a first in similar MPC solutions. The technical compatibility between Ika and Sui blockchain is particularly outstanding, with both sharing highly compatible underlying design concepts in parallel processing, decentralized architecture, etc. 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 the perspective of functionality positioning, Ika is building a new security verification layer: it serves as a dedicated signature protocol for the Sui ecosystem and also provides standardized cross-chain solutions for the entire industry. Its layered design takes into account both the flexibility of the protocol and the ease of development, 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 signatures. Its innovation lies in the use of 2PC-MPC threshold signature protocol combined 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 2PC-MPC protocol, parallel distributed signatures, and closely integrated Sui consensus structure. The core innovation lies in introducing broadcast communication and parallel processing into threshold signature protocols. The following is a breakdown of core functions.

2PC-MPC Signature Protocol: Ika adopts an improved two-party MPC scheme (2PC-MPC), essentially decomposing the user’s private key signature operation into a process involving two roles: ‘user’ and ‘Ika network’. The original complex process requiring pairwise communication between nodes (similar to private chatting with everyone in a WeChat group) is transformed into a broadcast mode (similar to group announcements), maintaining constant level of computational communication overhead for users, independent of network scale, and keeping signature delay within the sub-second level.

Parallel processing, splitting tasks and doing them simultaneously: Ika uses parallel computing to decompose single signature operations into multiple concurrent subtasks that are executed simultaneously between nodes, aiming to significantly improve speed. Here, combined with Sui’s object-centric model, the network does not need to achieve global sequential consensus for every transaction, can handle multiple transactions simultaneously, increase throughput, and reduce latency. Sui’s Mysticeti consensus eliminates block authentication delay 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 only support 4-8 nodes, while Ika can scale to involve thousands of nodes in the signature. Each node only holds a portion of the key fragments, so even if some nodes are compromised, the private key cannot be recovered individually. An effective signature can only be generated when users and network nodes participate together. No single party can operate independently or forge a signature. This distributed node structure is the core of Ika’s zero-trust model.

Cross-chain Control and Chain Abstraction: As a modular signature network, Ika allows smart contracts from other chains to directly control the accounts in the Ika network (referred to as dWallet). Specifically, if a chain (such as Sui) wants to manage multi-signature accounts on Ika, it needs to verify the state of that chain in the Ika network. Ika achieves this by deploying the corresponding chain’s light client (state proofs) in its own network. Currently, state proofs for Sui have been implemented first, enabling contracts on Sui to embed dWallet as a component in their business logic and perform signatures and operations on assets from other chains through the Ika network.

1.2 Can Ika empower the Sui ecosystem in reverse?

Image source: Ika

After Ika goes online, it may expand the capabilities of the Sui blockchain and provide some support to the entire Sui ecosystem’s infrastructure. Sui’s native token SUI and Ika’s token $IKA will be used in synergy, with $IKA being used to pay for the signature service fees on the Ika network, as well as serving as staking assets for nodes.

The biggest impact of Ika on the Sui ecosystem is bringing cross-chain interoperability to Sui, its MPC network supports assets on chains such as Bitcoin and Ethereum to be accessed on the Sui network with relatively low latency and high security, enabling cross-chain DeFi operations such as liquidity mining and borrowing, which helps enhance Sui’s competitiveness in this area. Due to its fast confirmation speed and strong scalability, Ika has been integrated into multiple Sui projects, contributing to 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-signature approach, which is more flexible and secure compared to traditional centralized custody solutions. Even off-chain transaction requests can be securely executed on Sui.

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

In the final aspect, I also believe that Ika has provided a multi-party verification mechanism for AI automation applications to avoid unauthorized asset operations, enhance the security and credibility of AI transaction execution, and provide a possibility for the future expansion of the Sui ecosystem in the AI direction.

Challenges faced by 1.3 lka

Although Ika is closely tied to Sui, if it wants to become a ‘universal standard’ for cross-chain interoperability, it still depends 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. If Ika wants to break through, it needs to find a better balance between ‘decentralization’ and ‘performance’, attract more developers to join, and convince more assets to migrate in.

When it comes to MPC, there are also many controversies. A common issue is that it is difficult to revoke the signing authority. Similar to traditional MPC wallets, once the private key is split and distributed, even if re-sharded, it is still theoretically possible for someone with the old shard to reconstruct the original private key. Although the 2PC-MPC scheme improves security by involving users continuously, I think there is not yet a particularly perfect solution for securely and efficiently changing nodes. This may 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 the MVs2 version, Ika must also adapt. The consensus based on DAG, Mysticeti, supports high concurrency and low transaction fees, but because it lacks a main chain structure, it may make the network path more complex and transaction ordering more difficult. In addition, it is asynchronous accounting, so although it is efficient, it also brings new sorting and consensus security issues. Moreover, the DAG model relies heavily on active users, so if the network usage is not high, issues such as transaction confirmation delays and decreased security may occur.

Comparison of projects based on FHE, TEE, ZKP, or MPC

2.1 FHE

Zama & Concrete: In addition to the general compiler based on MLIR, Concrete adopts a ‘layered bootstrapping’ strategy, which divides large circuits into several small circuits for encryption, and then dynamically concatenates the results, significantly reducing the latency of a single bootstrapping. It also supports ‘hybrid encoding’—using CRT encoding for integer operations sensitive to delay, and bit-level encoding for boolean operations with high parallelism requirements, balancing performance and parallelism. In addition, Concrete provides a ‘key packing’ mechanism, which allows reusing multiple 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 mini Bootstrapping before and after executing arithmetic instructions to recover noise budgets. At the same time, Fhenix has designed an off-chain oracle bridging module, which performs proof checks before interacting with 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 integration of on-chain contracts.

2.2 TEE

Oasis Network: Building on Intel SGX, Oasis introduces the concept of ‘Layered Root of Trust’, with SGX Quoting Service at the bottom to verify hardware trustworthiness, a lightweight microkernel in the middle to isolate suspicious instructions, and reduce the attack surface of SGX. The ParaTime interface uses Cap’n Proto binary serialization to ensure efficient communication across ParaTimes. Additionally, Oasis has developed a ‘Persistent Log’ module to write critical state changes to a trusted log, preventing rollback attacks.

2.3 ZKP

Aztec: In addition to the Noir compiler, Aztec integrates the ‘incremental recursion’ technology in proof generation, which recursively packages multiple transaction proofs in a time-sequential manner and then uniformly generates a small-sized SNARK once. The proof generator uses Rust to write parallelized depth-first search algorithms, and can achieve linear acceleration on multi-core CPUs. In addition, to reduce user waiting time, Aztec provides 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’ to pre-generate Beaver triples off-chain to accelerate online phase computation. Nodes within each shard interact through 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.

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

Image source:@tpcventures

3.1 Overview of Different Privacy Computing Schemes

Privacy computing is currently a hot topic in the blockchain and data security field, with main 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 computations on encrypted data without decryption, enabling end-to-end encryption of inputs, computations, and outputs. Security is ensured based on complex mathematical problems (such as lattice problems), providing theoretically complete computational capabilities, but incurring extremely high computational costs. In recent years, the industry and academia have been optimizing algorithms, specialized libraries (such as Zama’s TFHE-rs, Concrete), and hardware accelerators (Intel HEXL, FPGA/ASIC) to enhance performance, yet it remains a technology that progresses slowly but surely.

● Trusted Execution Environment (TEE): A trusted hardware module provided by the processor (such as Intel SGX, AMD SEV, ARM TrustZone), capable of running code in an isolated secure memory area, preventing external software and operating systems from snooping on execution data and states. TEE relies on hardware root of trust, with performance close to native computation and generally incurring minimal 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.

● Secure Multiparty Computation (MPC): Using cryptographic protocols, it allows multiple parties to jointly compute the function output without revealing their respective private inputs. MPC does not rely on a single point of trust hardware, but the computation requires multiple interactions, leading to high communication overhead. The performance is affected by network latency and bandwidth limitations. Compared to Fully Homomorphic Encryption (FHE), MPC has much lower computational overhead, but it has high implementation complexity and requires carefully designed protocols and architectures.

● Zero-Knowledge Proof (ZKP): Cryptographic technology that allows a verifier to confirm the truth of a statement without revealing any additional information. The prover can demonstrate possession of a secret (such as a password) to the verifier without disclosing the actual information. Typical implementations include zk-SNARK based on elliptic curves and zk-STAR based on hashing.

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

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, it 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. Now there are some more advanced solutions, such as the Ika network, which treats users as one system node as the other party, uses 2PC-MPC to sign in parallel, 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 signature, and the signature logic can be run through the SGX chip, 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 relatively 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 large, 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 safe, 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 service providers such as Fireblocks, which splits the signature into several parts, and different nodes participate in the signature, and any node will not be a problem if it is hacked. Ika’s design is also quite interesting, and the two-party model realizes the “non-collusion” of private keys, reducing the possibility of “everyone agrees to do evil together” in traditional MPC. 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 is more about protecting 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.

In terms of AI and data privacy, the advantages of FHE are more obvious here. It can keep data encrypted from start to finish. For example, if you throw medical data onto the chain for AI inference, FHE can allow the model to make judgments without seeing plaintext, then output the results without anyone being able to see the data clearly. This ‘computing in encryption’ capability is very suitable for handling sensitive data, especially in cross-chain or cross-institutional collaboration. For instance, Mind Network is exploring the use of PoS nodes to complete voting verification through FHE in a state of mutual ignorance, preventing nodes from cheating and ensuring the privacy of the entire process. MPC can also be used for federated learning, such as different institutions collaborating to train models, each retaining local data without sharing, only exchanging intermediate results. However, when there are more participants involved, communication costs and synchronization become issues, and currently, most are experimental projects. Although TEE can run models directly in a protected environment and federated learning platforms use it for model aggregation, its limitations are also apparent, such as memory restrictions and side-channel attacks. Therefore, in AI-related scenarios, the ‘end-to-end encryption’ capability of FHE is the most prominent, while MPC and TEE can serve as auxiliary tools, but specific solutions are still needed to complement them.

3.3 Differentiation of Different Schemes

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 proof and single transaction latency falls between the two; MPC (Partisia) has moderate to low latency, with the greatest impact from network communication.

Trust assumptions: FHE and ZKP are based on mathematical challenges, without the need for trust in third parties; TEE relies on hardware and vendors, with firmware vulnerability risks; MPC relies on semi-honest or at most t abnormal 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 require consideration of computing resources and hardware node supply.

Integration difficulty: TEE project has the lowest access threshold, requiring the least programming model changes; ZKP and FHE both require dedicated circuits and compilation processes; MPC requires protocol stack integration and cross-node communication.

Fourth, the general view of the market: “FHE is better than TEE, ZKP, or MPC”?

It seems that whether it’s FHE, TEE, ZKP, or MPC, all four of them also face an impossible triangle problem in solving practical use cases: “performance, cost, security.” Although FHE is attractive in theoretical privacy protection, it is not superior to TEE, MPC, or ZKP in all aspects. The cost of poor performance makes it difficult for FHE to promote its computing speed far behind other solutions. In applications sensitive to real-time and cost, TEE, MPC, or ZKP are often more feasible.

Trust and applicable scenarios are also different: TEE and MPC each provide different trust models and deployment convenience, while ZKP focuses on verifying correctness. As pointed out by industry views, 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 off-chain complex calculations, ZKP can efficiently solve the problem; 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 processing extremely sensitive data, but currently requires hardware acceleration to be effective.

FHE is not “universally superior”. 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 leans more towards key sharing and signature coordination in its design (users always retain a private key), with its core value lying in decentralized asset control without the need for custody. In contrast, ZKP is good at generating mathematical proofs for on-chain verification of states or computation results. The two are not simply alternatives 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 requirement on the bridging party 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 has started to integrate multiple privacy technologies to enhance overall capabilities. Its blind computing architecture seamlessly integrates MPC, FHE, TEE, and ZKP to balance security, cost, and performance. Therefore, the future of privacy computing ecosystem will tend to combine the most suitable technological components to build modular solutions.

Statement:

1. This article is reproduced from [TechFlow]，copyright belongs to the original author [YBB Capital Researcher Ac-Core]，如对转载有异议，请联系 Gate Learn Team, the team will process it as soon as possible according to the relevant procedures.
2. Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. The other language versions of the article are translated by the Gate Learn team, not mentionedGate.ioDo not copy, distribute, or plagiarize translated articles without permission.