Looking at the technological competition between FHE, TEE, ZKP, and MPC from the sub-second MPC network Ika launched by Sui

1. Overview and Positioning of the Ika Network

Ika Network is an innovative infrastructure project strategically supported by the Sui Foundation, built on multi-party secure computing (MPC) technology. Its most notable feature is sub-second response speed, which is a first in MPC solutions. Ika is highly compatible with Sui in terms of underlying design concepts such as parallel processing and decentralized architecture, and will be directly integrated into the Sui development ecosystem in the future, providing plug-and-play cross-chain security modules for Sui Move smart contracts.

From a functional perspective, Ika is building a new type of security verification layer: acting both as a dedicated signing protocol for the Sui ecosystem and providing standardized cross-chain solutions for the entire industry. Its layered design balances protocol flexibility with development convenience and is expected to become 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 the 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 creates a multi-party signature network that meets ultra-high performance and strict security requirements through the 2PC-MPC protocol, parallel distributed signatures, and close integration with the Sui consensus structure. Its core innovation is the introduction of broadcast communication and parallel processing into the threshold signature protocol. The following is a breakdown of the core functions:

2PC-MPC Signature Protocol: Ika adopts an improved two-party MPC scheme, decomposing the user's private key signing operation into a process involving both "user" and "Ika network" roles. This design transforms the originally complex inter-node communication into a broadcast mode, keeping the user's computational communication overhead at a constant level, independent of the network scale, thus achieving sub-second signing latency.

Parallel Processing: Ika utilizes parallel computing to decompose a single signature operation into multiple concurrent subtasks executed simultaneously across nodes, significantly improving speed. Combined with Sui's object parallel model, the network can handle numerous transactions at the same time, increasing throughput and reducing latency. Sui's Mysticeti consensus eliminates block authentication delays with a DAG structure, allowing for instant block submissions, enabling Ika to achieve sub-second finality on Sui.

Large-scale Node Network: Ika can scale to thousands of nodes participating in signing. Each node holds only a part of the key fragments, and even if some nodes are compromised, the private key cannot be independently recovered. A valid signature can only be generated when both the user and the network nodes participate together; no single party can operate or forge a signature independently. This distribution of nodes 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, such as (dWallet). Ika achieves cross-chain verification by deploying lightweight clients of the corresponding chains within its own network. Currently, Sui state proofs have been implemented first, allowing contracts on Sui to embed dWallet as a component in their business logic and complete the signing and operation of assets from other chains through the Ika network.

1.2 The impact of Ika on the Sui ecosystem

After Ika goes live, it may expand the capability boundaries of the Sui blockchain and provide support for the infrastructure of the Sui ecosystem:

1. Cross-chain interoperability: Ika's MPC network supports low-latency and high-security access to Sui network for on-chain assets like Bitcoin and Ethereum, enabling cross-chain DeFi operations and enhancing Sui's competitiveness in this area.

2. Decentralized Asset Custody: Ika provides a multi-signature method for managing on-chain assets, which is more flexible and secure than traditional centralized custody.

3. Chain Abstraction: Simplifies the cross-chain interaction process, allowing smart contracts on Sui to directly operate accounts and assets on other chains.

4. Native BTC Access: Enables Bitcoin to participate directly in DeFi and custody operations on Sui.

5. AI Application Security Assurance: Provide multi-party verification mechanisms for AI automation applications to prevent unauthorized asset operations and enhance the security and credibility of AI when executing transactions.

1.3 Challenges faced by Ika

1. Cross-chain standardization: Although closely tied to Sui, in order to become a universal cross-chain interoperability standard, it also requires acceptance from other blockchains and projects.

2. MPC Security Controversy: In traditional MPC schemes, the signing authority is difficult to revoke. Although 2PC-MPC improves security, it still lacks a comprehensive mechanism for securely and efficiently replacing nodes.

3. Dependency Risk: Ika relies on the stability of the Sui network and its own network conditions. If Sui undergoes a major upgrade, Ika must also adapt accordingly.

4. Potential Issues with Mysticeti Consensus: While DAG-based consensus supports high concurrency and low fees, it may make network paths more complex and transaction ordering more difficult. Although the asynchronous accounting model is efficient, it may introduce new ordering and consensus security issues.

5. Network Activity Requirements: The DAG model strongly relies on active users. If the network usage is low, issues such as transaction confirmation delays and decreased security may occur.

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

2.1 FHE

Zama & Concrete:

• General-purpose compiler based on MLIR
• "Layered Bootstrapping" strategy: Large circuits are split into smaller circuits for separate encryption, and then the results are dynamically stitched together.
• "Mixed Coding": Integer operations use CRT coding, Boolean operations use bit-level coding
• "Key Packaging" mechanism: A key can be reused multiple times for isomorphic operations after being imported once.

Fhenix:

• Optimization for the Ethereum EVM instruction set
• Use "Ciphertext Virtual Register" instead of plaintext register
• Automatically insert micro Bootstrapping to recover noise budget
• Design an off-chain oracle bridge module to reduce on-chain verification costs.

2.2 TEE

Oasis Network:

• Introduce the concept of "layered trusted roots"
• Use a lightweight microkernel to isolate suspicious instructions
• The ParaTime interface uses Cap'n Proto binary serialization
• Develop the "Durable Log" module to prevent rollback attacks

2.3 ZKP

Aztec:

• Integrate "incremental recursion" technology to package multiple transaction proofs
• Implement a parallel depth-first search algorithm in Rust
• Provide "Light Node Mode" to optimize bandwidth usage

2.4 MPC

Partisia Blockchain:

• Based on the SPDZ protocol extension, adding a "preprocessing module"
• Use gRPC communication and TLS 1.3 encrypted channel
• Support for a dynamic load balancing parallel sharding mechanism

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

Overview of Different Privacy Computing Solutions 3.1

Fully Homomorphic Encryption ( FHE ):

• Allow arbitrary computation in an encrypted state
• Ensuring security based on complex mathematical problems
• It has theoretically complete computational power, but the computational cost is extremely high.
• In recent years, performance has been improved through algorithm optimization, specialized libraries, and hardware acceleration.

Trusted Execution Environment ( TEE ):

• Trusted hardware module provided by the processor
• Run code in an isolated secure memory area
• Performance is close to native computation, with only a small overhead.
• Relies on hardware trust roots, with potential backdoor and side-channel risks

Multi-Party Secure Computation ( MPC ):

• Allow multiple parties to jointly compute while protecting private inputs.
• No single point of trust hardware, but requires multi-party interaction
• High communication overhead, affected by network latency and bandwidth limitations
• The computational overhead is less than FHE, but the implementation complexity is high.

Zero-Knowledge Proof ( ZKP ):

• Allow verifiers to validate statements without disclosing additional information.
• Typical implementations include elliptic curve-based zk-SNARKs and hash-based zk-STARKs.

Adaptation Scenarios of 3.2 FHE, TEE, ZKP and MPC

Cross-chain signature:

• MPC is suitable for scenarios requiring multi-party collaboration and avoiding single point private key exposure.
• TEE can run signature logic through SGX chips, which is fast but has hardware trust issues.
• FHE is theoretically achievable, but the overhead is too large.

DeFi scenarios ( multi-signature wallets, vault insurance, institutional custody ):

• MPC is the mainstream method, such as Fireblocks splitting the signatures among different nodes.
• TEE is used to ensure signature isolation, but there are hardware trust issues.
• FHE is mainly used to protect transaction details and contract logic.

AI and Data Privacy:

• The advantages of FHE are obvious, allowing data processing under full encryption.
• MPC can be used for federated learning, but faces communication costs and synchronization issues.
• TEE can run models directly in a protected environment, but there are memory limitations and side-channel attack risks.

3.3 Differentiation of Different Plans

Performance and Latency:

• FHE has higher latency but provides the strongest data protection.
• TEE delay is minimal, close to normal execution
• ZKP has controllable latency in batch proofs
• MPC latency is low to medium, greatly affected by network communication.

Trust Assumption:

• FHE and ZKP are based on mathematical problems, requiring no trust in third parties.
• TEE depends on hardware and vendors
• MPC relies on a semi-honest or at most t-faulty model

Scalability:

• ZKP Rollup and MPC sharding support horizontal scalability
• The expansion of FHE and TEE needs to consider computing resources and hardware node supply.

Integration Difficulty:

• The threshold for TEE access is the lowest.
• ZKP and FHE require specialized circuits and compilation processes.
• MPC requires protocol stack integration and cross-node communication

IV. Market Observation and Analysis

FHE, TEE, ZKP, and MPC face the "performance, cost, and security" trade-off problem when addressing practical use cases. FHE offers strong theoretical privacy protection but is limited by poor performance, restricting its application. TEE, MPC, and ZKP are more feasible in real-time and cost-sensitive scenarios.

Different technologies provide different trust models and applicable scenarios:

• ZKP is suitable for verifying complex off-chain computations.
• MPC is suitable for multi-party computations that require sharing private states.
• TEE has mature support on mobile and cloud environments.
• FHE is suitable for processing extremely sensitive data, but requires hardware acceleration.

Future privacy computing may be the result of the complementarity and integration of various technologies. For example, Ika emphasizes key sharing and signature coordination, while ZKP excels at generating mathematical proofs. The two can complement each other: ZKP verifies the correctness of cross-chain interactions, while Ika provides the foundation for asset control. Projects like Nillion are beginning to integrate multiple privacy technologies to balance security, cost, and performance.

Therefore, the future privacy computing ecosystem may tend to build modular solutions using the most suitable combinations of technical components, rather than a single technology prevailing. The choice of technology should depend on specific application requirements and performance trade-offs.