作者：YBB Capital Researcher Ac-Core
1. Ika Network Overview and Positioning
Image source: Ika
The Ika network, which is strategically supported by the Sui Foundation, recently officially announced its technical positioning and development direction. As an innovative infrastructure based on multi-party secure computing (MPC) technology, the network’s most notable feature is its sub-second response speed, which is the first of its kind among MPC solutions. The technical compatibility of Ika and Sui blockchain is particularly outstanding. The two are highly compatible 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 a plug-and-play cross-chain security module for Sui Move smart contracts.
From the perspective of functional positioning, Ika is building a new security verification layer: it is not only a dedicated signature protocol for the Sui ecosystem, but also outputs standardized cross-chain solutions for the entire industry. Its layered design takes into account both protocol flexibility and development convenience, and has 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 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 signatures, and close integration with the Sui consensus structure, Ika wants to create a multi-party signature network that meets both ultra-high performance and strict security requirements. Its core innovation is to introduce 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 (2PC-MPC), which essentially decomposes the user private key signature operation into a process in which the "user" and the "Ika network" participate together. The complex process that originally required nodes to communicate with each other (similar to everyone chatting privately with everyone in a WeChat group chat) was changed to a broadcast mode (similar to a group announcement), and the computational communication overhead for users also remained at a constant level, regardless of the network size, so that the signature delay can still be kept at the sub-second level.
Parallel processing, splitting tasks and doing them simultaneously: Ika uses parallel computing to decompose a single signature operation into multiple concurrent subtasks that are executed simultaneously between nodes, hoping to greatly increase the speed. Sui's object-centric model is combined here. The network does not need to reach a global sequential consensus on each transaction, and can process 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 submission, so that Ika can obtain sub-second final confirmation on Sui.
Large-scale node network: Traditional MPC solutions usually only support 4-8 nodes, while Ika can expand to thousands of nodes participating in the signature. Each node only holds a part of the key fragment, and even if some nodes are compromised, the private key cannot be recovered alone. Only when users and network nodes participate together can a valid signature be generated. No single party can independently operate or forge a signature. Such 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 in the Ika network (called dWallet). Specifically, if a smart contract on a chain (such as Sui) wants to manage multi-party signature accounts on Ika, it needs to verify the state of the chain in the Ika network. Ika achieves this by deploying light clients (state proofs) of the corresponding chain in its own network. Currently, Sui state proofs have been implemented first, allowing contracts on Sui to embed dWallet as a component into business logic, and complete the signing and operation of assets on other chains through the Ika network.
1.2 Can Ika reversely empower the Sui ecosystem?
Image source: Ika
After Ika goes online, it is possible to expand the capabilities of the Sui blockchain and provide some support for the infrastructure of the entire Sui ecosystem. Sui's native token SUI and Ika's token $IKA will be used in conjunction. $IKA will be used to pay for the signature service fee of the Ika network and also as a staked asset for nodes.
The biggest impact of Ika on the Sui ecosystem is that it brings cross-chain interoperability 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 helps to improve Sui's competitiveness in this area. Due to its fast confirmation speed and strong scalability, Ika has been connected to multiple Sui projects and 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 secure than traditional centralized custody solutions. Even transaction requests initiated off-chain can be securely executed on Sui.
Ika also designed a chain abstraction layer, which allows smart contracts on Sui to directly operate accounts and assets on other chains without going through cumbersome bridging or asset packaging processes, which simplifies the entire cross-chain interaction process. The access to native Bitcoin also allows BTC to directly participate in DeFi and custody operations on Sui.
On the last aspect, I also believe that Ika also provides a multi-party verification mechanism for AI automated applications, which can avoid unauthorized asset operations, improve the security and credibility of AI when executing transactions, and also provide a possibility for the future expansion of the Sui ecosystem in the direction of AI.
1.3 Challenges faced by lka
Although Ika is closely tied to Sui, if it wants to become a "universal standard" for cross-chain interoperability, it depends on whether other blockchains and projects are willing to accept it. 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" to attract more developers to join and more assets to migrate in.
Speaking of MPC, there are also many controversies. A common problem is that the signing authority is difficult to revoke. Just like the traditional MPC wallet, once the private key is split and sent out, even if it is re-sharded, the person who gets the old fragment can theoretically still restore the original private key. Although the 2PC-MPC solution improves security through continuous user participation, I think there is currently no particularly perfect solution mechanism for "how to replace nodes safely and efficiently", which may be a potential risk point.
Ika itself also relies on the stability of the Sui network and its own network status. If Sui makes a major upgrade in the future, such as updating the Mysticeti consensus to the MVs2 version, Ika must also adapt. Although Mysticeti, a DAG-based consensus, supports high concurrency and low fees, it may make the network path more complicated and transaction sorting more difficult because it does not have a main chain structure. In addition, it is asynchronous accounting, which is efficient but also brings new sorting and consensus security issues. Moreover, the DAG model is highly dependent on active users. If the network usage is not high, it is easy to have transaction confirmation delays and reduced security.
2. Comparison of projects based on FHE, TEE, ZKP or MPC
2.1 FHE
Zama & Concrete: In addition to the MLIR-based general compiler, Concrete adopts a "hierarchical bootstrapping" strategy, which splits a large circuit into several small circuits and encrypts them separately, and then dynamically splices the results, significantly reducing the latency of a single bootstrapping. It also supports "hybrid encoding" - CRT encoding is used for latency-sensitive integer operations, and bit-level encoding is used for Boolean operations that require high parallelism, taking into account both performance and parallelism. In addition, Concrete provides a "key packaging" mechanism, which can reuse multiple isomorphic operations after a key is imported once, 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 micro-bootstrapping before and after executing arithmetic instructions to restore the noise budget. At the same time, Fhenix has designed an off-chain oracle bridge module to perform proof checks before interacting with the on-chain ciphertext state and the 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 "hierarchical root of trust". The bottom layer uses SGX Quoting Service to verify the hardware trustworthiness. The middle layer has a lightweight microkernel responsible for isolating suspicious instructions and reducing the SGX segfault attack surface. ParaTime's interface uses Cap'n Proto binary serialization to ensure efficient cross-ParaTime communication. At the same time, Oasis has developed a "durability log" module to write key state changes into a trusted log to prevent rollback attacks.
2.3 CPC
Aztec: In addition to Noir compilation, Aztec integrates "incremental recursion" technology in generating proofs, recursively packaging multiple transaction proofs in time series, and then uniformly generating a small-size SNARK. The proof generator uses Rust to write a parallelized depth-first search algorithm, which can achieve linear acceleration on multi-core CPUs. In addition, to reduce user waiting, Aztec provides a "light node mode" where nodes only need to download and verify zkStream instead of the 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-generate Beaver triples off-chain to accelerate online operations. Nodes in each shard communicate through gRPC and interact with TLS 1.3 encrypted channels to ensure data transmission security. Partisia's parallel sharding mechanism also supports dynamic load balancing, adjusting the shard size in real time according to the 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. The main technologies include fully homomorphic encryption (FHE), trusted execution environment (TEE) and multi-party secure computing (MPC).
● Fully homomorphic encryption (FHE): An encryption scheme that allows arbitrary calculations to be performed on encrypted data without decryption, achieving full encryption of input, calculation process, and output. It is based on complex mathematical problems (such as lattice problems) to ensure security and has theoretically complete computing capabilities, but the computing overhead is extremely high. In recent years, the industry and academia have improved performance through optimized algorithms, dedicated libraries (such as Zama's TFHE-rs, Concrete), and hardware acceleration (Intel HEXL, FPGA/ASIC), but it is still a "slow-moving, fast-break" technology.
● Trusted Execution Environment (TEE): A trusted hardware module provided by the processor (such as Intel SGX, AMD SEV, ARM TrustZone) that can run code in an isolated secure memory area, making it impossible for external software and operating systems to spy on execution data and status. TEE relies on a hardware root of trust, and its performance is close to native computing, generally with only a small amount of overhead. TEE can provide confidential execution for applications, but its security depends on hardware implementation and firmware provided by the manufacturer, and there are potential backdoor and side channel risks.
● Multi-party secure computation (MPC): Using cryptographic protocols, multiple parties are allowed to jointly compute the output of a function without revealing their private inputs. MPC does not have a single point of trust in hardware, but computation requires multi-party interaction, high communication overhead, and performance is limited by network latency and bandwidth. Compared to FHE, MPC has much lower computational overhead, but its implementation is complex and requires carefully designed protocols and architectures.
● Zero-knowledge proof (ZKP): Cryptography technology that allows the verifier to verify that a statement is true without revealing any additional information. The prover can prove to the verifier that he or she has a secret information (such as a password) without directly disclosing the information. Typical implementations include elliptic curve-based zk-SNARK and hash-based zk-STAR.
3.2 What are the applicable scenarios for FHE, TEE, ZKP and MPC?
Image source: BiblicalScienceInstitute
Different privacy computing technologies have different focuses, and the key lies in the scenario requirements. Take cross-chain signatures as an example. It requires multi-party collaboration to avoid the exposure of single-point private keys. At this time, MPC is more practical. Like threshold signatures, multiple nodes each save a part of the key fragments and complete the signature together. No one can control the private key alone. There are some more advanced solutions now. For example, the Ika network treats users as one party and system nodes as the other party, using 2PC-MPC parallel signatures. It can process thousands of signatures at a time, and can be expanded horizontally. The more nodes, the faster. However, TEE can also complete cross-chain signatures, and can run the signature logic through the SGX chip. It is fast and easy to deploy, but the problem is that once the hardware is compromised, the private key is also leaked, and trust is completely placed 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 it is good at. Although it can be done in theory, the overhead is too large, and basically no one does this in a real system.
Let's talk about DeFi scenarios, such as multi-signature wallets, vault insurance, and institutional custody. Multi-signature itself is safe, but the problem is how to store private keys and how to share risks. MPC is now a more mainstream method. Service providers such as Fireblocks split the signature into several parts, and different nodes participate in the signature. If any node is hacked, there will be no problem. The design of Ika is also very interesting. It realizes the "non-collusion" of private keys through a two-party model, reducing the possibility of "everyone agrees to do evil together" in traditional MPC. TEE also has applications in this area, such as hardware wallets or cloud wallet services, which use trusted execution environments to ensure signature isolation, but still cannot avoid hardware trust issues. FHE currently has little direct effect at the custody level, and is more about protecting transaction details and contract logic. For example, if you make a private transaction, others cannot see the amount and address, but this has little to do with private key custody. So in this scenario, MPC focuses more on decentralized trust, TEE emphasizes performance, and FHE is mainly used in higher-level privacy logic.
In terms of AI and data privacy, the situation will be different. The advantages of FHE are 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 "computation in encryption" capability is very suitable for sensitive data processing, especially when cross-chain or cross-institutional collaboration. Mind Network is exploring the possibility of PoS nodes completing 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. For example, different institutions cooperate to train models, each retains local data and does not share, and only exchanges intermediate results. However, once there are more participants in this method, communication costs and synchronization become problems. At present, most of them are experimental projects. Although TEE can run models directly in a protected environment, and some federated learning platforms use it for model aggregation, its limitations are also obvious, such as memory limitations and side channel attacks. Therefore, in AI-related scenarios, FHE's "full encryption" capability is the most prominent. MPC and TEE can be used as auxiliary tools, but specific solutions are still needed.
3.3 Differences among different solutions
Performance and latency: FHE (Zama/Fhenix) has a 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 proofs, and the latency of a single transaction is between the two; MPC (Partisia) has a medium to low latency and is 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 manufacturers and has the risk of firmware vulnerabilities; MPC relies on semi-honest or at most t-anomaly models and is sensitive to the number of participants and behavioral assumptions.
Scalability: ZKP Rollup (Aztec) and MPC sharding (Partisia) naturally support horizontal expansion; FHE and TEE expansion need to consider computing resources and hardware node supply.
Integration difficulty: TEE projects have the lowest entry threshold and require the least changes to the programming model; both ZKP and FHE require specialized circuits and compilation processes; MPC requires protocol stack integration and cross-node communication.
4. The general view of the market: "FHE is better than TEE, ZKP or MPC"?
It seems that no matter FHE, TEE, ZKP or MPC, there is 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 low performance makes FHE difficult to promote and its computing speed lags far behind other solutions. In applications that are 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 conveniences, while ZKP focuses on verifying correctness. As pointed out by the industry, different privacy tools have their own advantages and limitations, and there is no "one-size-fits-all" optimal solution. For example, ZKP can efficiently solve the verification of complex off-chain calculations; MPC is more direct for calculations where multiple parties need to share private states; TEE provides mature support in mobile and cloud environments; and FHE is suitable for extremely sensitive data processing, but currently still requires hardware acceleration to work.
FHE is not "universally superior". The choice of technology should depend on application requirements and performance trade-offs. Perhaps in the future, privacy computing will often be the result of the complementarity and integration of multiple technologies, rather than a single solution winning. For example, Ika focuses on key sharing and signature coordination (users always keep a private key), and its core value lies in the realization of decentralized asset control without custody. In contrast, ZKP is good at generating mathematical proofs for on-chain verification of status or calculation results. The two are not simply alternative or competitive, but more like complementary technologies: ZKP can be used to verify the correctness of cross-chain interactions, thereby reducing the need for trust in the bridge party to a certain extent, while Ika's MPC network provides the underlying foundation of "asset control rights", which can be combined with ZKP to build more complex systems. In addition, Nillion has begun to integrate multiple privacy technologies to enhance overall capabilities. Its blind computing architecture seamlessly integrates MPC, FHE, TEE and ZKP to strike a balance between security, cost and performance. Therefore, the future privacy computing ecosystem will tend to use the most appropriate combination of technical components to build modular solutions.
References:
(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
