From a functional perspective, Ika is building a new type of security verification layer: serving both as a dedicated signature protocol for the Sui ecosystem and providing standardized cross-chain solutions for the entire industry.
Author: YBB Capital Researcher Ac-Core
1. Overview and Positioning of 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, a first among similar MPC solutions. The technical compatibility between Ika and the Sui blockchain is particularly prominent, with both highly aligned 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 perspective, Ika is constructing a new type of security 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, 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 utilizing a 2PC-MPC threshold signature protocol in conjunction with Sui's parallel execution and DAG consensus, achieving true sub-second signature capabilities 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 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 adopts an improved two-party MPC scheme (2PC-MPC), essentially 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), maintaining a constant level of computational communication overhead for users, 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 combines with Sui's object-centric model, allowing the network to process numerous transactions simultaneously without reaching a global consensus on each transaction, thereby improving throughput and reducing latency. Sui's Mysticeti consensus eliminates block certification delays with a DAG structure, allowing for instant block submissions, enabling Ika to achieve sub-second final confirmations 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, making it impossible to recover the private key even if some nodes are compromised. An effective signature can only be generated when both the user and network nodes participate, preventing any single party from independently operating or forging signatures. This node distribution 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 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 must verify the state of that chain within the Ika network. Ika achieves this by deploying lightweight clients (state proofs) for the corresponding chains 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 signatures and operations on assets from other chains through the Ika network.
1.2 Can Ika Empower the Sui Ecosystem?
Image source: Ika
After its launch, Ika has the potential to expand the capability boundaries of the Sui blockchain and will 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 utilized to pay for signature service fees on the Ika network and also serving as staking assets for nodes.
The greatest impact of Ika 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, 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, thereby promoting 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 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 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 directly participate 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-sharded, 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 there is currently no particularly well-developed solution mechanism for "how to safely and efficiently replace 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 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 sorting and consensus security issues. Moreover, the DAG model heavily depends 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 employs a "layered bootstrapping" strategy, breaking large circuits into several smaller circuits for separate encryption and dynamically stitching the results together, significantly reducing the latency of a single bootstrapping operation. It also supports "hybrid encoding"—using CRT encoding for latency-sensitive integer operations and bit-level encoding for Boolean operations requiring high parallelism, balancing performance and parallelism. Additionally, Concrete provides a "key packing" mechanism, allowing multiple homomorphic 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," automatically inserting 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 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 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, with a lightweight microkernel in the middle layer responsible for isolating suspicious instructions and reducing the attack surface of SGX segment blocking. The ParaTime interface uses Cap’n Proto binary serialization to ensure efficient cross-ParaTime communication. At the same time, Oasis has developed a "durable log" module that writes key state changes into 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, recursively packaging multiple transaction proofs in chronological order and generating a single small-sized SNARK. The proof generator is written in Rust and employs a parallelized depth-first search algorithm, 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 communicate via gRPC 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): An encryption scheme that allows arbitrary computations on encrypted data without decryption, achieving end-to-end encryption of input, computation process, and output. It is based on complex mathematical problems (such as lattice problems) to ensure security, possessing theoretically complete computational capabilities, but with 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 and steady" 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 viewing execution data and states. TEE relies on hardware roots of trust, with performance close to native computing and generally only a small overhead. TEE can provide confidential execution for applications, but its security depends on hardware implementation and vendor-provided firmware, 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 trusted hardware, but requires multi-party interaction, leading to high communication overhead, with performance limited by network latency and bandwidth. Compared to FHE, MPC has much lower computational overhead, but its implementation complexity is high, 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 demonstrate to the verifier that they possess certain secret information (such as a password) without directly disclosing that information. Typical implementations include elliptic curve-based zk-SNARKs and hash-based zk-STARs.
3.2 What are the Adaptation Scenarios for FHE, TEE, ZKP, and MPC?
Image source: biblicalscienceinstitute
Different privacy computing technologies have their own focuses, with the key being the scenario requirements. For cross-chain signing, it requires multi-party collaboration and avoids single-point private key exposure, making MPC quite practical. For instance, in threshold signing, multiple nodes each hold a portion of the key fragments and complete the signing together, ensuring no one can 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 nodes as another, using 2PC-MPC for parallel signing, capable of processing thousands of signatures at once and horizontally scaling—more nodes lead to faster processing. However, TEE can also accomplish cross-chain signing by running signing logic through SGX chips, which is fast and easy to deploy, but the issue is that if the hardware is compromised, the private key is also leaked, placing complete trust in the chip and manufacturer. FHE is relatively weak in this area because signing computations do not fall within its expertise of "addition and multiplication" patterns; although it can theoretically perform them, 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 issue 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 hacked, it won't cause issues. Ika's design is also interesting, achieving "non-collusion" of private keys through a two-party model, reducing the possibility of the traditional MPC scenario where "everyone colludes to do evil." TEE also has applications in this area, such as hardware wallets or cloud wallet services, using trusted execution environments to ensure signing isolation, but it still cannot escape the hardware trust issue. FHE currently has little direct application in custody, focusing more on protecting transaction details and contract logic; for example, in a privacy transaction, others cannot see the amount and address, but this is not closely related to private key custody. Therefore, in this scenario, MPC emphasizes decentralized trust, TEE emphasizes performance, and FHE is mainly used in higher-level privacy logic.
In AI and data privacy, the situation is different, and FHE's advantages become more apparent. It allows data to remain encrypted throughout the process; for instance, if you put medical data on the chain for AI inference, FHE can enable the model to make judgments without seeing plaintext, then output the results, ensuring that no one can view the data during the entire process. This capability of "computing in encryption" is very suitable for sensitive data processing, especially in cross-chain or cross-institution collaborations. For example, Mind Network is exploring how PoS nodes can 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 federated learning, where different institutions collaborate to train models while retaining local data without sharing, only exchanging intermediate results. However, once the number of participants increases, communication costs and synchronization become issues, and currently, most projects in this area 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 is the most prominent, while MPC and TEE can serve as auxiliary tools, but specific solutions are still needed.
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 states; TEE (Oasis) has the lowest latency, close to normal execution, but requires hardware trust; ZKP (Aztec) has controllable latency for 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 vendors, 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 scaling; FHE and TEE scalability need to consider computational resources and hardware node supply.
Integration Difficulty: TEE projects have the lowest entry barriers, requiring minimal changes to programming models; both ZKP and FHE require specialized circuits and compilation processes; MPC requires protocol stack integration and cross-node communication.
4. General 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 theoretical appeal in privacy protection, it is not superior to 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 instance, ZKP can efficiently solve the verification of complex off-chain computations; for computations requiring multiple parties 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 example, 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 the need for 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," 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 combine the most suitable technological components to build modular solutions.
References:
(2)https://blog.sui.io/ika-dwallet-mpc-network-interoperability/
(3)https://research.web3caff.com/zh/archives/29752?ref=416
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
