How TOKI and LCP Bridge Cosmos SDK Chains and Ethereum via IBC

TOKI aims to become the first cross-chain bridge that achieves 1 click native token swap between Ethereum and Cosmos SDK Chains using IBC. Today, we will deep dive into how it works, focusing on its groundbreaking messaging layer.

TL;DR

• While cross-chain bridges using IBC are in high demand, there are challenges in terms of gas cost and implementation cost, especially on EVMs.
• ZK-based solutions are promising for addressing these problems. However, there still remain issues to be addressed, particularly concerning gas costs and practical implementation methods.
• TOKI resolves these challenges by using secure hardware (TEE), commonly used for advanced privacy protection.
• TOKI will enable users to carry out cross-chain transactions securely between blockchain networks, such as Cosmos SDK Chains and EVMs, in an environment that is securely protected from malicious bridge administrators and others.

Last week, TOKI announced a collaboration with Noble to bring Japanese stablecoins to the interchain ecosystem.

TOKI and Noble to Bring Japanese Stablecoins to the Cosmos Ecosystem, in Partnership with MUFG

In the wake of Terra’s absence, the demand for stablecoins within the interchain ecosystem has been on the rise. However, there are over 100 bridged versions of USDC within the ecosystem because 1) various bridges issuing wrapped USDC, and 2) IBC routing can make different types of USDC even within the ecosystem. This problem is a significant obstacle to achieving efficient liquidity and ensuring a good user experience.
(For a more detailed discussion of these issues, we refer you to Noble’s blog post.)

The native USDC on a specific chain like Noble could potentially alleviate the second issue. However, what’s still missing is the capability for cross-chain native token swaps. This is exactly where TOKI steps in, providing a much-needed solution for native token swaps across chains such as Ethereum and others using IBC.

So, how does TOKI achieve this?

TOKI will address the challenge by offering unified liquidity and IBC messaging for multiple blockchains, including EVMs. These two features will facilitate secure, one-click native token swaps across various chains.

However, establishing secure messaging using IBC across various chains beyond the Cosmos SDK Chains is still challenging. Overcoming this hurdle requires a key focus on the messaging layer. So, in this article, we will focus on the messaging layer of TOKI, which solves IBC’s challenges and enables native token swaps between EVMs and Cosmos SDK Chains.

Before digging into the detail, let us express our gratitude to Ethan Frey, one of the core developers of the Cosmos SDK and also known as the “Father of CosmWasm”, to have had extensive discussions. He now serves as an advisor to TOKI.

Here’s a comment from Ethan:

I am impressed by the level of knowledge of both EVM and IBC that the TOKI team possesses. Various teams have been working on an Ethereum — Cosmos IBC bridge since 2018, but existing solutions have some trust limitations and do not expose the full power of IBC. LCP is a novel solution to make highly secure bridges realistic. TOKI also counts on the maintainers of IBC-Solidity, which exposes the power of custom IBC-enabled Solidity contracts, and the rapid protocol development which is currently only available in CosmWasm. As an advisor, I am delighted to support this initiative and eagerly anticipate the broadening of IBC connections throughout the entire ecosystem.

Table of Contents

• What is TOKI?
• Challenges to Expand IBC into non-Tendermint Chains
• Other Approaches (ZK-based Approach)
• TOKI’s Solution: IBC Enhanced by LCP
• Security Enhancements of LCP
• Summary
• Looking Ahead

What is TOKI?

Let me start by briefly introducing TOKI.

TOKI is the first cross-chain bridge to enable 1 click native token swaps between Ethereum, Cosmos SDK Chains, and other EVM blockchains. We achieve this by leveraging TEE (Trusted Execution Environment) to enhance the IBC and build unified liquidity on top of the messaging.

Here is the high-level architecture of TOKI.

Our idea is to employ a proxy using TEE. That enables more blockchains to use IBC to connect with each other by replacing the light client verification compliant with IBC.

Another key component to connect EVMs using IBC is IBC-Solidity, the IBC implementation in Solidity, described as “IBC-modules” in the diagram.

In addition, we’re working on TOKI Liquidity, unified liquidity on top of the messaging layer. This feature will enable single-transaction native token swaps without using wrapped tokens, providing finality on the source chain and enhancing capital efficiency, thereby offering users a more secure and convenient transaction experience.

For more detail, please visit our website.

Challenges to Expand IBC into non-Tendermint Chains

IBC requires light client implementations on each blockchain to verify the consensus and validity of transactions with each other. While this nature of mutual verification enables the most secure way of blockchain communications, it is indispensable for the communication protocol to be extensible to various blockchain networks.

The constraints bring two following challenges for IBC to expand it to other networks beyond Cosmos SDK Chains:

1. High verification cost (gas cost)
2. High implementation cost

The high verification cost depends on the consensus algorithm for each blockchain and the availability of support for the cryptographic primitives required for verification. For example, the Tendermint light client requires verification of the validator’s signatures, serialization, Merkle Proof verification, etc.

Those series of procedures demand considerable cost, especially on Ethereum and other EVMs. For example, according to Chorus One’s report, tendermint-sol, which implements Tendermint light client on IBC-Solidity, requires over 10 million gas costs.

The high implementation cost means that it takes so much time and cost to expand its network and maintain them because it is required to implement various light clients on each chain to support a variety of consensus algorithms each counterparty blockchain has. It must be a massive problem if you want to connect more and more blockchains with each other.

To overcome those challenges, Datachain developed LCP (Light Client Proxy), which can solve both challenges by replacing light client verification in cryptographically secure areas on memory.

Other Approaches (ZK-based Approach)

Other than that, there are several approaches to address the above-mentioned issues, one of which is the ZK-based approach. Recently, some projects have used ZK to verify validators’ signatures, which is one of the processes in light client verification.

When classifying ZK-based approaches, they fall into two categories:

• Direct verification: construct a zk-proof of signature validity and verify the proof on-chain. Some notable examples include Polyhedera Network, Wormhole, Electron Labs, and Succinct Labs.
• Hub verification: where a hub network verifies and constructs a zk-proof of the result. The primary example is Polymer Labs.

Now, if we organize these two categories based on trust assumption, gas cost, and implementation cost, the classifications would look something like this:

Trust Assumption

• Direct verification: It basically doesn’t require additional trust assumptions outside of the connected chains.
  (Some methods require a trusted setup.)
• Hub verification: It requires putting additional trust in the hub network.

Gas Cost

There are various types of costs regarding the light client verification using ZK, including the cost of header verification, the cost of packet verification, and the proving cost to construct zk-proofs.

• Direct verification: It can reduce the cost of verifying validators’ signatures, a part of the header verification cost.
• Hub verification: It can reduce the whole header verification cost by adjusting the consensus ZK-friendly as Polymer Labs did in zkMint.

Both types of verification can reduce some costs, but the costs of packet verification and proving still need to be addressed. That’s why the use cases for ZK solutions are currently limited. As for the proving cost, according to the research by Electron Labs, there is a tradeoff between proving cost and latency.

The Electron labs’ report also indicates that in instances with 200 validators and 50 signatures included per zk-proof, verifying a Tendermint light client header on Ethereum takes approximately 8 minutes. Polymer Labs’ research demonstrates that when utilizing zkTree, the runtime required to verify 32 ed25519 proofs on Ethereum could potentially be reduced to 77 seconds.

Implementation Cost

• Direct verification: It takes a lot of implementation resources to connect with various blockchain networks because it has the same challenges as the standard light client verification.
• Hub verification: It takes fewer resources to connect with multiple blockchain networks as it doesn’t require distinct implementations for each blockchain connection.

Beyond these three aspects, another distinct challenge of utilizing ZK is the complexity of security audits. The security incident that occurred just after Electron Labs’ mainnet launch recently provides a clear example of this.

In summary, although ZK-based approaches are promising, the challenges of high gas and implementation costs are yet to be fully addressed. This indicates the need for an alternative solution.

TOKI’s Solution: IBC Enhanced by LCP

So, how does TOKI approach these issues without sacrificing the degree of security?

In a nutshell, TOKI adopts TEE to solve those challenges and enhance IBC capabilities.

TEE is a hardware-based tamper-proof solution by separating the area of the processor from the rest of the CPU. Among some types of implementations of TEE, the most widely adopted implementation of TEE is Intel SGX.

As the diagram above illustrates, Intel SGX has a key component called an “enclave,” which is an isolated environment in the computer’s memory. Intel SGX acts like a secure vault in the processor itself, combining strong encryption and hardware-level isolation to safeguard enclave programs. Anyone, even the node operators, could observe or tamper with its codes. In fact, no practical attack has happened in the latest version of Intel SGX.

TEE (SGX) is a proxy middleware for light client verification to securely replace the on-chain verification process. We call it Light Client Proxy, or “LCP” for short. The initial implementation of LCP utilizes Intel SGX as its TEE.

As the diagram above illustrates, the relayer sends a commitment and proof from a source chain to the LCP node. This node then securely executes light client verification within the enclave and generates a commitment that indicates the verification result along with proof. These are then sent to the destination chain, which verifies them.

The main features of the LCP are:

1. Minimal trust assumptions
In addition to the trust assumptions of the native IBC, LCP needs to add as little trust as possible, the TEE trust.

2. Ultra-efficient on-chain verification
LCP does not require on-chain light client verification for the target chain. Instead, a client on the verifying chain verifies a signature(s) on a resulting commitment generated in the enclave.

3. Efficient Implementation
With LCP, there is no need for on-chain light client implementations for each chain combination. Instead, we need only a light client implementation (LCP Client) for each individual chain. As a result, supporting new chains becomes significantly easier.

Those features make LCP enable cross-chain communication with high security, equivalent to on-chain light client verification at a lower cost.

If we compare on the same axis as we did with ZK earlier:

• Trust assumption: LCP is based on the TEE trust.
• Gas cost: By replacing the entire verification process, not just a part of it, LCP can dramatically reduce verification costs without compromising latency. It can execute cross-chain transactions within milliseconds.
• Implementation cost: LCP dramatically reduces the implementation costs, as it necessitates the implementation of only a single light client per chain to establish connections with multiple chains. Furthermore, it can be coded in Rust (e.g., ethereum-ibc-rs).

Compared to ZK-based solutions, which still have some technical issues to work out, it’s fair to say that LCP is currently more practical. It improves gas and implementation efficiency without sacrificing security.

Furthermore, app developers can effortlessly establish their own LCP nodes, thereby streamlining the process and facilitating rapid environment setup. This could further enhance the widespread usability of LCP.

Security Enhancements

While questions about TEEs and their security levels have been raised due to some documented vulnerabilities (e.g., ÆPIC Leak), it’s important to note that there have been no practical attacks on the latest patched version of SGX so far.

Moreover, the type of attack that compromised the Secret Network would not prove effective against LCP. This is because LCP does not possess the shared component among nodes that was exploited during the Secret Network attack. (See the FAQ for more detail).

Not only that, LCP has other security enhancements:

1. Node validation: LCP client will check the LCP nodes to ensure that each of them does not include unacceptable Advisory IDs at the registration. (Advisory ID refers to a vulnerability reported by Intel.)
2. Key rotation: The key pair used to prove and verify messages between blockchains is changed periodically. LCP nodes are checked to see if they support the latest Advisory ID every time period continuously
3. Multiple operators: LCP is designed to provide additional securities by running a sufficient number of LCP nodes to enable the multiple key signature operation(e.g., 4 of 6 multi-sig) by multiple individual LCP node operators. This prevents unforeseen vulnerabilities and improves the decentralization of LCP nodes. This effort is in collaboration with node operators such as Everstake, Allnodes, DSRV, Swiss Staking, and others.

Visit the link below to learn more about LCP

• Medium
• Docs
• GitHub
• FAQ

Summary

Summarizing our discussion thus far, we can present the main points in the following table:

* To clarify our comparisons, we’ve created a new ‘Latency’ category and reorganized the issues we discussed under ‘Cost’ into this new category.

Looking Ahead

Datachain and TOKI have been doing research on ZK as well. While ZK for light client verification is not entirely practical at present, we are poised to consider it as one of the promising options. TOKI aims to empower users and developers to choose the appropriate message protocol (for instance, Native IBC, IBC enhanced by TEE, or ZK-based IBC) based on their specific security requirements.

TOKI is set to launch its testnet in 2023 Q3, with the mainnet following in Q4.

Stay tuned for more announcements!

Follow us on @tokifinance.
Discover more about TOKI at https://tokifinance.notion.site/.