Author: YBB Capital Researcher Ac-Core

I. Overview and Positioning of the Ika Network

Backed strategically by the Sui Foundation, the Ika Network recently unveiled its technical positioning and development direction. As an innovative infrastructure built on Multi-Party Computation (MPC), its most distinguishing feature is its sub-second response time — a first among similar MPC solutions. Ika is especially well-suited for integration with the Sui blockchain, with both networks sharing foundational design principles such as parallel processing and decentralized architecture. In the future, Ika will be directly embedded within the Sui developer ecosystem, offering plug-and-play cross-chain security modules for Sui Move smart contracts.

Functionally, Ika aims to build a next-generation security verification layer: serving both as a native signature protocol for the Sui ecosystem and as a standardized cross-chain solution for the broader industry. Its layered design balances protocol flexibility with developer convenience, making it a strong candidate to be the first large-scale, multi-chain deployment of MPC technology.

1.1 Core Technical Analysis

Ika’s implementation centers around high-performance distributed signing. Its innovation lies in combining a two-party threshold signature protocol (2PC-MPC) with Sui’s parallel execution and DAG-based consensus, achieving true sub-second signing latency and mass decentralized node participation. Key technical breakdowns include:

2PC-MPC Signature Protocol:
 Ika uses an optimized two-party MPC scheme, effectively splitting the user’s private key signing process between the “user” and the “Ika Network.” Traditional threshold signing requires many-to-many communication (like every participant privately messaging everyone else in a group chat). Ika replaces this with a broadcast model (like a public group announcement), significantly reducing the computational and communication overhead for users, which remains constant regardless of network size. This enables sub-second signature latency.

Parallel Processing:
 Ika boosts throughput by decomposing a single signing task into multiple concurrent subtasks, leveraging Sui’s object-centric model that doesn’t require global consensus on each transaction. Sui’s Mysticeti DAG-based consensus allows near-instant finality, letting Ika achieve sub-second confirmation.

Large-Scale Node Participation:
 While traditional MPC solutions support only 4–8 nodes, Ika scales to thousands. Each node only holds a fragment of the key, so even if some nodes are compromised, they cannot reconstruct the private key alone. A valid signature can only be generated when both the user and the network participate — forming the foundation of Ika’s zero-trust model.

Cross-Chain Control and Chain Abstraction:
 Ika allows smart contracts from other blockchains to directly control accounts within its network, known as dWallets. This requires verifying state from external chains within Ika. It achieves this by running lightweight clients for those chains, starting with Sui. This enables smart contracts on Sui to embed dWallets into their logic and use Ika for cross-chain asset signing and interaction.

1.2 Can Ika Empower the Sui Ecosystem?

Once live, Ika may significantly extend Sui’s functional boundaries and provide key infrastructure benefits. Sui’s native token (SUI) and Ika’s token ($IKA) will be used in tandem, with $IKA paying for signing services and serving as staking collateral for nodes.

Ika’s most profound impact is on cross-chain interoperability. It enables low-latency, high-security onboarding of Bitcoin, Ethereum, and other assets into Sui, supporting use cases like cross-chain DeFi, lending, and liquidity mining — enhancing Sui’s competitiveness in these areas. Multiple Sui-based projects have already integrated Ika due to its speed and scalability.

From a security perspective, Ika offers a decentralized custody model. Users and institutions can manage on-chain assets via multi-party signatures — more secure and flexible than centralized custodians. Even off-chain initiated transactions can be securely executed on Sui.

Ika also introduces a chain abstraction layer, allowing Sui smart contracts to directly control assets/accounts on other chains without complex bridges or token wrappers. Native BTC access further enables Bitcoin to participate directly in Sui’s DeFi and custody operations.

Lastly, Ika supports secure automation for AI agents, enabling multi-party validation of asset operations. This reduces unauthorized access risks and improves trust in AI-led transactions — opening potential for AI x DeFi integrations within the Sui ecosystem.

1.3 Challenges Facing Ika

Despite its tight integration with Sui, Ika’s ability to become a “universal standard” for cross-chain interoperability depends on its adoption across other blockchains. Existing competitors like Axelar and LayerZero already dominate various use cases. For Ika to succeed, it must strike a better balance between decentralization and performance to attract more developers and assets.

MPC itself is controversial. One major issue is the difficulty of revoking signing rights. Traditional MPC wallets distribute private key shares, and even after reshuffling, old fragments may still pose a security risk. While 2PC-MPC enhances safety via continuous user involvement, the challenge of securely and efficiently rotating nodes remains unresolved.

Ika’s reliance on both its own network and the stability of Sui is also a factor. If Sui upgrades to a new consensus protocol (e.g., moving from Mysticeti to MVs2), Ika must adapt. While Mysticeti offers high concurrency and low fees, its DAG-based model lacks a canonical chain structure, complicating transaction ordering and consensus guarantees. Additionally, it’s heavily dependent on network activity — low engagement could lead to delayed confirmations and security risks.

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

2.1 FHE

Zama & Concrete:
 Beyond its general-purpose MLIR-based compiler, Concrete adopts a “layered bootstrapping” strategy, where large circuits are broken down into smaller encrypted sub-circuits and their results are dynamically stitched together, significantly reducing the latency of individual bootstrapping operations. It also supports “hybrid encoding” — using CRT encoding for latency-sensitive integer operations and bitwise encoding for high-parallelism Boolean operations — balancing performance and scalability. Additionally, Concrete offers a “key packaging” mechanism that allows the reuse of the same keys for homomorphic operations after a single key import, thereby reducing communication overhead.

Fhenix:
 Built on TFHE, Fhenix introduces several custom optimizations targeting the Ethereum EVM instruction set. It replaces plaintext registers with “encrypted virtual registers,” inserting micro-bootstrapping operations automatically before and after arithmetic instructions to restore noise budgets. Furthermore, Fhenix designs an off-chain oracle bridging module that verifies proofs before allowing interactions between on-chain ciphertext states and off-chain plaintext data, lowering on-chain verification costs. Compared to Zama, Fhenix focuses more on EVM compatibility and seamless smart contract integration.

2.2 TEE

Oasis Network:
 Based on Intel SGX, Oasis introduces a “layered root of trust” concept. At the base layer, it uses the SGX Quoting Service to verify hardware integrity, while the intermediate layer incorporates a lightweight microkernel that isolates suspicious instructions to reduce the SGX enclave’s attack surface. The ParaTime interface leverages Cap’n Proto for binary serialization, ensuring efficient cross-ParaTime communication. Oasis also developed a “durable logging” module that records key state changes in a trusted log to prevent rollback attacks.

2.3 ZKP

Aztec:
 In addition to its Noir compiler, Aztec integrates “incremental recursion” for proof generation, packaging multiple transaction proofs sequentially and generating a single compact SNARK. Its proof generator is implemented in Rust with a parallelized depth-first search algorithm that achieves linear acceleration on multi-core CPUs. To reduce user wait time, Aztec also offers a “light node mode” where nodes only need to download and verify the zkStream instead of the full proof, further optimizing bandwidth usage.

2.4 MPC

Partisia Blockchain:
 Partisia’s MPC implementation extends the SPDZ protocol by incorporating a “preprocessing module” that generates Beaver triples off-chain to accelerate online computation phases. Nodes within each shard communicate via gRPC over encrypted TLS 1.3 channels, ensuring secure data transfer. Partisia also supports parallel sharding with dynamic load balancing, allowing the system to adjust shard sizes in real-time based on node workload.

III. Privacy Computing: FHE, TEE, ZKP, and MPC

3.1 Overview of Different Privacy Computing Approaches

Privacy computing has become a hot topic in blockchain and data security, with the primary technologies including Fully Homomorphic Encryption (FHE), Trusted Execution Environments (TEE), Zero-Knowledge Proofs (ZKP), and Multi-Party Computation (MPC):

• Fully Homomorphic Encryption (FHE):
   An encryption method that allows computations to be performed on encrypted data without first decrypting it, enabling end-to-end encryption for inputs, computations, and outputs. Its security is based on complex mathematical problems (such as lattice-based problems), and while it offers theoretically complete computing capabilities, it incurs massive computational overhead. In recent years, both industry and academia have made progress through optimized algorithms, specialized libraries (e.g., Zama’s TFHE-rs and Concrete), and hardware acceleration (e.g., Intel HEXL, FPGA/ASIC). However, the technology remains in a “slow but promising” stage.

• Trusted Execution Environments (TEE):
   Hardware-based trusted modules (such as Intel SGX, AMD SEV, ARM TrustZone) that provide isolated execution environments within processors, ensuring that data and state remain confidential even from the OS. TEEs rely on a hardware root of trust and offer near-native performance with minimal overhead. While they enable confidential computation, their security hinges on the integrity of hardware and firmware, and they are susceptible to backdoors and side-channel attacks.

• Multi-Party Computation (MPC):
   Cryptographic protocols that enable multiple parties to jointly compute a function while keeping their respective inputs private. Unlike TEE, MPC does not rely on a single trusted hardware source, but requires interaction among parties, resulting in high communication overhead and sensitivity to network latency. Compared to FHE, MPC is more efficient but also more complex to implement, requiring precise protocol design and architecture.

• Zero-Knowledge Proofs (ZKP):
   A cryptographic method that allows one party (the prover) to prove to another (the verifier) that a certain statement is true, without revealing any additional information. Typical implementations include curve-based zk-SNARKs and hash-based zk-STARKs.

3.2 Application Scenarios for FHE, TEE, ZKP, and MPC

Each privacy computing method excels in different use cases depending on context.

In cross-chain signature scenarios, where collaboration and private key security are crucial, MPC proves highly effective. Techniques like threshold signatures distribute key shares across nodes, ensuring that no single party can act alone. Advanced implementations like Ika use a 2PC-MPC structure, treating the user and the system as two separate parties, achieving parallel signing with thousands of operations per second and scalable performance. TEE can also handle cross-chain signatures with fast execution using SGX, but if hardware is compromised, private keys are fully exposed — placing trust entirely in the chip manufacturer. FHE is less suitable here due to the mismatch between its arithmetic strengths and signing tasks; while theoretically feasible, it’s computationally prohibitive.

In DeFi use cases like multi-signature wallets, insurance vaults, or institutional custody, MPC shines again. Providers like Fireblocks split signatures across nodes, securing the process even if one node is compromised. Ika’s two-party model ensures that key fragments can’t collude, improving over traditional MPC’s collusion risk. TEE can also be used in secure hardware or cloud wallets for isolated signature execution but faces similar hardware trust limitations. FHE plays a limited role in custody, better suited for encrypting transaction details or contract logic. So here: MPC focuses on decentralizing trust, TEE emphasizes performance, and FHE contributes to upper-layer privacy.

In AI and data privacy, FHE takes the lead. It enables computation over fully encrypted data — for instance, running AI inference on encrypted medical records without ever seeing plaintext, yielding results without exposing sensitive data. This “encrypted computing” model is ideal for cross-organizational collaboration. Projects like Mind Network explore FHE-powered confidential PoS voting, ensuring nodes can’t cheat. MPC can support federated learning, enabling institutions to jointly train models while keeping data local. However, with many parties, communication cost and synchronization become bottlenecks. TEE supports AI execution within protected environments and has been used in model aggregation, but is constrained by memory and side-channel risks. For AI tasks, FHE offers the strongest confidentiality, while MPC and TEE serve as auxiliary tools depending on specific requirements.

3.3 Key Differences Between These Approaches

Performance and Latency:

• FHE (e.g., Zama/Fhenix): High latency due to bootstrapping, but offers maximal encrypted data protection.

• TEE (e.g., Oasis): Lowest latency, nearly native speed, but dependent on hardware trust.

• ZKP (e.g., Aztec): Moderate latency; batch proofs are manageable, with lighter verification modes available.

• MPC (e.g., Partisia): Medium to low latency, but sensitive to network quality.

Trust Assumptions:

• FHE and ZKP rely on cryptographic hardness with no external trust requirements.

• TEE depends on hardware and vendors, potentially exposing users to firmware vulnerabilities.

• MPC operates under semi-honest or t-bounded malicious models, making outcomes sensitive to participant integrity and coordination.

Scalability:

• ZKP rollups (e.g., Aztec) and MPC sharding (e.g., Partisia) inherently support horizontal scaling.

• FHE and TEE scalability depends on compute and hardware availability.

Integration Difficulty:

• TEE has the lowest entry barrier and least impact on developer workflows.

• ZKP and FHE require circuit design and specialized compilers.

• MPC demands integration of complex protocol stacks and cross-node communication.

IV. A Common Market View: “FHE Is Superior to TEE, ZKP, or MPC”?

Across FHE, TEE, ZKP, and MPC, the real-world application of these technologies inevitably runs into a “privacy computation trilemma”: performance, cost, and security. Although FHE is theoretically compelling due to its strong privacy guarantees, it is not universally superior to TEE, MPC, or ZKP. Its high computational cost significantly limits practical adoption — its processing speed lags far behind other methods. In latency-sensitive or cost-constrained applications, TEE, MPC, and ZKP are often far more practical.

Each technology also carries a different trust model and use-case fit. TEE and MPC provide distinct operational assumptions and deployment convenience, while ZKP specializes in verifying correctness rather than conducting computation. As many in the industry have pointed out, no privacy solution is one-size-fits-all. Each has its strengths and limitations:

• ZKP is ideal for verifying the correctness of complex off-chain computations.

• MPC is more suitable for collaborative computation involving private states across multiple parties.

• TEE provides mature support for cloud-based and mobile environments.

• FHE is best for processing highly sensitive data, but currently requires hardware acceleration to be feasible.

FHE should not be seen as a universally superior option. The selection of privacy technology should depend on application-specific trade-offs. It’s likely that future privacy systems will combine multiple approaches in complementary ways, rather than relying on a single dominant technology.

Take Ika as an example. Its design emphasizes key sharing and coordinated signing, where users always retain a portion of their private key. The value of Ika lies in non-custodial decentralized asset control. On the other hand, ZKP excels at generating mathematical proofs to verify state or computation results on-chain. These two are not competing solutions, but rather complementary: ZKP can reduce reliance on bridge operators by verifying the correctness of cross-chain interactions, while Ika’s MPC network serves as the foundational infrastructure for asset control.

This modular integration mindset is gaining traction. For instance, Nillion is building a blind computation architecture that seamlessly incorporates MPC, FHE, TEE, and ZKP to balance security, cost, and performance. The direction of privacy computation seems clear: use the most suitable components to assemble modular, fit-for-purpose solutions, rather than expecting a single method to solve everything.

About YBB

YBB is a web3 fund dedicating itself to identify Web3-defining projects with a vision to create a better online habitat for all internet residents. Founded by a group of blockchain believers who have been actively participated in this industry since 2013, YBB is always willing to help early-stage projects to evolve from 0 to 1.We value innovation, self-driven passion, and user-oriented products while recognizing the potential of cryptos and blockchain applications.

Website | Twi: @YBBCapital

Reference:
(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