logo

Multi-Prover for IBC Connection: Enhancing Security with a Combination of SGX, MPC and ZKP

Daiki Ishikawa
March 13, 2024
6 Min
article cover image

This is a guest post by TOKI Finance founder Daiki Ishikawa. For more about the author, please read his bio at the bottom of this post.

TOKI is at the forefront of developing an IBC (Inter-Blockchain Communication) Protocol cross-chain infrastructure and the testnet launch of a cross-chain bridge using the infrastructure is on the horizon. This blog post will delve into TOKI's security model.

TOKI has worked on connecting Ethereum and BNB Smart Chain via IBC as its first pair of blockchain networks. However, enabling IBC on EVM chains is challenging due to high gas and implementation costs. To address this, TOKI has implemented LCP (Light Client Proxy) to replace light client verification with a cryptographically secure enclave using Intel Software Guard Extensions (SGX).

SGX’s enclave itself is secure enough, but to further enhance its security, TOKI adopts a multi-prover approach. The basic idea of our approach is that multiple operators perform light client verification within an SGX enclave and run the signing protocol of MPC to generate a single commitment proof.

The multi-prover approach mitigates the drawbacks of running light client verification natively on chains, such as impractical gas costs and high implementation costs, while relying on minimal trust assumptions. The underlying concept of utilizing multiple proofs leveraging SGX to bolster security has been adopted by notable projects such as Taiko and Scroll.

By embedding the multi-prover security, a combination of SGX and MPC, within IBC—a protocol that is optimally modularized and has the largest builder community in the blockchain messaging protocol space, maintaining a record of zero exploits since its first deployment in 2021— TOKI is committed to constructing a truly safe and open interoperability infrastructure in a cost-efficient way.

In addition, as TOKI leverages the IBC protocol, it’s easier for various applications to make use of our cross-chain infrastructure across any blockchains. Initially, TOKI is building unified liquidity as its first application to enable a one-click native token swap.

TOKI is working on stablecoin transfers, issued by Japanese banks, across multiple blockchains in a partnership with Progmat. This approach has a lock-and-mint mechanism in common with Circle's CCTP (Cross-Chain Transfer Protocol), which enables native USDC cross-chain transfers.

Why the Multi-prover Approach?

TOKI adopts the multi-prover approach for an IBC-enabled cross-chain bridge. Before diving into the details of our approach, let us clarify what IBC is and why we need to take that approach.

What is IBC?

IBC is a messaging protocol for heterogeneous blockchains, standardized by the Cosmos community. Since the first IBC transaction on the mainnet in 2021, according to MapofZones, over 110 blockchain zones have been connected through IBC, with the total value of IBC transfers in the last 30 days reaching $2.7 billion. Proudly, there has been 'zero loss' to date.

Some people think that ‘IBC is for Cosmos blockchains,’ but it’s actually not true. Several teams, such as Polymer Labs, Composable Finance, Union, and TOKI, have worked on applying IBC to non-Cosmos blockchains. In 2024, IBC will land on major blockchains such as Ethereum, Rollups, Solana, and Avalanche, thanks to the efforts of those teams. These initiatives will cause an explosion of IBC connections among those chains.

However, there are some challenges to applying IBC for other blockchains. The primary challenge is how to generate and verify consensus proofs efficiently in terms of gas cost, computational cost, and implementation cost.

Problems in Verifying Consensus Proofs in IBC

Implementing light client verification natively is inefficient from a gas-cost perspective, and particularly impractical on Ethereum. As an alternative, approaches using ZK have emerged. While ZK-based methods are cryptographically secure and can somewhat improve gas efficiency, there is a limitation to gas optimization when using ZK, as it can only be applied to a part of the verification process for now (You can learn more in our post on the Interchain Ecosystem Blog). Additionally, as ZK is a relatively new technology, there may be potential risks of bugs and vulnerabilities.

Here is another emerging option: hardware-based security solutions, exemplified by SGX. It is significantly more efficient in terms of gas and computational costs, as well as implementation costs, compared to a ZK-based approach. And, it's gradually gaining momentum since industry figures like Georgios, a partner at Paradigm, frequently express high expectations for its impact. And, popular ZK-Rollup projects such as Taiko and Scroll have considered using SGX. However, we cannot conclude that SGX is 100% bullet-proof; potential vulnerabilities, while minimal and unlikely, cannot be entirely dismissed.

Another option is using a PoS intermediary chain to verify cross-chain requests from one blockchain by validators of the network and send them to the destination chain. Those intermediary blockchains secure their networks with a distributed set of validator nodes, where the staked amount by these validators can reach hundreds of millions of dollars for some chains. These chains typically set staking rewards. Compared to native IBC bridges or connection methods bypassing intermediary chains, like ZK-based approaches, these staking rewards could be an extra cost. Furthermore, the rewards paid are not minor, considering the expected revenue from the current volume of bridge transactions. Thus, if there is a more efficient method available, it would be preferable.

Simply put, native light client, ZK technology, SGX, and economic security all involve trade-offs. There is no one-size-fits-all method that guarantees completely secure connections among various chains while keeping gas and computational costs low.

Solution: Multi-Prover Approach

Since all individual approaches have some challenges in terms of cost and security risk, the best way to mitigate these potential risks while maintaining the cost at a relatively lower level is the multi-prover approach that combines each method.

The basic idea of the multi-prover approach is to use several types of proofs for one verification. This can prevent potential hacking or vulnerabilities from occurring because, even if an attacker successfully hacks one proof system, they would need to compromise the other proof systems at the same time.

One of the drawbacks of the multi-prover approach is its higher cost compared to a single-proof approach. Therefore, it's crucial to thoroughly understand the trade-offs involved in integrating an additional verification method to refine the overall solution.

The concept of the multi-prover approach is common. For example, the approach shares similarities with client diversity in Ethereum as mentioned in a blog post by Taiko Labs. In a similar manner, we could say that TOKI has implemented this concept for proof verification within the IBC security model.

TOKI’s Security Model: Light Client with SGX & MPC

TOKI, as an IBC interoperability infrastructure, adopts a multi-prover security model that combines several hardware-based and software-based security models. Specifically, it incorporates light clients, SGX, and MPC to enable interoperability between multiple blockchains securely and cost-effectively.

The motivation for integrating MPC with SGX stems from the fact that while SGX is secure and cost-efficient, it is not entirely bulletproof. SGX has faced some documented vulnerabilities in the past, such as the ÆPIC Leak. So, integrating an additional verification method would enhance its reliability. Given TOKI's core values of security and cost-efficiency, the chosen verification method should be low-cost and promote decentralization; MPC fits this criterion.

MPC is a protocol that enables mutually distrustful parties to collaboratively compute a function over their private data without disclosing the data to each other. In the context of blockchain, it is commonly used in crypto wallet applications, allowing multiple individuals from an organization to access accounts and funds. (If you want to learn more about MPC, please visit this post by Fireblocks.)

toki-finance-architecture-1-compressed.gif
The TOKI Finance architecture using LCP, SGX, and MPC.

Architecture

Let’s look into TOKI’s high-level architecture. The substantial components from a security model perspective are LCP (Light Client Proxy) using SGX and MPC, and LCP client compliant with ICS-02.

LCP is a middleware to replace light client verification for gas-efficient and trust-minimized cross-chain transactions. Using SGX and MPC makes it possible to generate proofs securely and efficiently for the destination to verify its validity. Find out more about LCP here.

The main components, including the LCP client, are as follows:

  • LCP client: light client middleware to verify commitments generated other LCPs.
  • ibc-solidity: IBC implementation in Solidity, which enables IBC in EVM blockchains. Learn more here.
  • Enclave Light Client (ELC): light client which runs in an enclave.
  • Relayer: we use yui-relayer, a forked version of Go Relayer. It supports heterogeneous blockchains using the abstraction of “chain” (communication module to chain) and “prover” (commitment and proof).
  • Contracts: any contract can be deployed and executed.

Roadmap

We will launch our cross-chain bridge on testnets between Ethereum and BNB Chain in the first half of 2024, followed closely by the mainnet launch. After the launch, we plan to expand support to major blockchains, including L2s such as Arbitrum and Optimism.

Regarding our multi-prover approach, the initial implementation will feature a combination of SGX and MPC. To further enhance security and mitigate potential risks, we will add ZK as one of its multi-proving options. ZK is promising in terms of increasing security, but it would cost much more than other verification methods. Therefore, we are considering applying ZKP to large-volume cross-chain transactions and whatever requires higher security.

Conclusion

In this article, we have covered how TOKI’s messaging layer works. On top of the messaging layer, there are some upcoming applications: unified liquidity for efficient cross-chain transfers and burn-and-mint cross-chain transfer for stablecoins (details).

The multi-prover approach is set to thrive with SGX emerging as a crucial security method within this strategy. TOKI aims to apply this technology to its IBC cross-chain infrastructure, striving to realize an open and secure "Internet of blockchains" across various ecosystems.

Furthermore, TOKI seeks to contribute to the expansion of the Web3 ecosystem through the use of SGX and the multi-prover approach, not only in collaboration with projects that employ SGX-based multi-provers like Taiko and Scroll but also alongside teams such as Oasis Network, Flashbots, Secret Network, and Fireblocks, which utilize SGX.

If you're interested in crypto projects using Intel SGX, read more on TOKI's blog. See LCP development work on Github at https://github.com/datachainlab/lcp.

About TOKI Finance

TOKI Finance is bringing IBC infrastructure with SGX to expand IBC interoperability to new ecosystems. Their development partner Datachain contributes to IBC, LCP, Hyperledger, and Corda. Follow TOKI on Twitter or send them an email at [email protected].

Daiki Ishikawa
Founder of TOKI Finance

Recent Articles

Cover for Getting Started With IBC: Understanding the Interchain Stack and the Main IBC ImplementationsGetting Started With IBC: Understanding the Interchain Stack and the Main IBC Implementations
This article aims to provide an overview of IBC and its main implementations, ibc-go and ibc-rs, as well as other components of the Interchain stack, namely CometBFT and the Cosmos SDK.
avatar
Adi Ravi Raj
October 16, 2023
5 Min
Cover for Winners of the IBC Ideathon, Ideahacker's Guide to IBCWinners of the IBC Ideathon, Ideahacker's Guide to IBC
Announcing the winners of the first-ever IBC Ideathon, Ideahacker's Guide to IBC!
avatar
IBC Protocol
November 15, 2024
4 Min
Head to our Github to begin.

Ready to get started?