Datachain has worked on cross-chain interoperability issues by researching and developing products such as Hyperledger Labs YUI, which enables interoperability between multiple different blockchains using the Cosmos’ IBC protocol, and Cross Framework, which enables cross-chain transactions. YUI has a lot of modules, and one of its modules, “IBC-Solidity,” the Solidity implementation of IBC, is being developed with a grant from the Interchain Foundation.

Using these technologies, we have demonstrated interoperability between multiple blockchains using IBC with public blockchains projects such as Harmony and major enterprise companies such as NTT DATA and JCB.

Based on these achievements and the soaring demands for secure cross-chain bridges, Datachain has announced “LCP (Light Client Proxy)” as a new middleware to solve the current interoperability and cross-chain bridge issues.

LCP adopts a “Proxy Method” that performs Light Client verification for a target chain on behalf of a verifying chain, and verifies its validity on the verifying chain. This is achieved by using TEE to perform Light Client verification in the Enclave.

LCP supports IBC (Inter-Blockchain Communication), a cross-chain communication protocol stack, as the communication protocol between chains. LCP and IBC enable to build secure, gas-efficient and scalable cross-chain bridges.

In this post, we will explain the current issues of cross-chain bridges and an overview of LCP that can solve the problems. We look forward to cooperating with various players in developing this project, so please get in touch with us if you are interested. For more details, please refer to the document below.

‍

https://docs.lcp.network/

https://form.run/@datachain-contact-en

‍

You can read this post in Japanese here.

Current Issues of Cross-chain Bridges

With the launch of various blockchain applications on multiple blockchain platforms, the need for cross-chain transactions across each blockchain platform is growing as time goes on. In fact, several cross-chain bridges are already in use.

They can be categorized as follows.

1. HTLC method（for an atomic swap of tokens）
   e.g. Hop, Connext
2. External Validators method（Verified by single or multiple off-chain parties）
   e.g. Multichain, Portal(Wormhole), Axelar, LayerZero
3. Light Client method（Verifies the consensus of each chain）
   e.g. IBC

Among the various types of bridges, the External Validators method (2) is currently the most widely used. However, this method, which requires a new trust additional trust of both chains, is prone to security holes. Although there are many factors, in 2022 alone, more than 1 billion dollars was lost due to the hacking of cross-chain bridges. Therefore, there is a strong need for a highly secure cross-chain bridge solution.

The Light Client method (3) is a mechanism to verify consensus on each other’s chains. It is said to be the most secure cross-chain method because it does not require a new trust other than the chains of both parties.

However, the Light Client method has the following two issues

1. Low extensibility
2. High verification cost

Due to the nature of the mutual verification of consensus in each other’s chain, it is necessary to implement a Light Client that corresponds to the other chain when connecting to a new chain. In other words, extending to a number of blockchains is not easy. In addition, the verification cost depends on the consensus algorithm for each chain and the availability of support for the cryptographic primitives required for verification. For this reason, the verification process’s high execution cost (gas cost) is often a problem, especially for EVM-based chains.

What is LCP (Light Client Proxy) ?

LCP is a solution that solves the two problems mentioned above of the light client method (low extensibility and high verification cost) with a proxy using TEE.

As mentioned in the introduction, LCP uses the proxy method to replace the verification of the target chain. The proxy performs light client verification on behalf of the chain to be verified and generates proof that enables low-cost verification of the validity of the chain.

This method allows LCP to enable cross-chain communication with high security, equivalent to on-chain light client verification at a lower cost.

The three main features of the LCP are:

1 Minimal trust assumptions
In addition to the trust assumptions of the Light Client scheme, which is the most secure verification scheme, LCP needs to add as little trust as possible, the TEE trust.

2. Ultra efficient on-chain verification
In many cases, it is challenging to perform on-chain verification due to verification cost constraints; LCP does not require on-chain light client verification for the target chain. Instead, a client on the verifying chain verifies a single signature on a resulting commitment generated in the Enclave. In other words, LCP achieves efficient verification by reducing the verification cost and the size of verification transactions.

3 Extensible
There is no need for an on-chain light client implementation for each chain combination; only a light client implementation per chain that the Enclave in the LCP node can execute. Therefore, it is easier to support new chains.

A communication protocol between chains is required to build cross-chain applications such as token swap and token transfer using LCP. For this purpose, LCP first supports IBC (Inter-Blockchain Communication), a cross-chain communication protocol stack.

‍

https://docs.lcp.network/key-components/ibc/

https://www.ibcprotocol.dev/

‍

‍

The above figure shows the architecture of the verification mechanism when sending packets between two chains using LCP:

1. Source chain writes a commitment of sending a packet to itself.
2. Relayer sends the commitment of step 1 and proof to the LCP node.
3. Light client verification is performed in the LCP node’s Enclave, and generates a commitment indicating the verification result and proof, which is a signature with the key generated in the Enclave, are generated.
4. The commitment and proof generated in step 3 are sent to the Destination chain via Relayer.
5. The Destination chain verifies the commitment and proof sent in step 4.

The initial implementation of LCP uses Intel SGX as the TEE

‍

https://docs.lcp.network/key-components/intel-sgx/

‍

For more information on the architecture and flow, please see the architecture part of the documentation.

‍

https://docs.lcp.network/architecture/

‍

‍

Roadmap

We plan to develop the LCP on the following roadmap.
(The timeline is subject to change.)

In Q3 of 2022, we will finalize the target network to build the initial bridge and proceed with the initial design. We assume a bridge between Ethereum and other networks. In Q4 of 2022, we plan to release a cross-chain bridge application with LCP on a test net. Then, in Q1 2023, we will have a mainnet launch of the application.

After the mainnet launch, in addition to supporting new networks and cross-chain applications, we plan to decentralize the nodes that make up the bridge and consider token economics to build more secure cross-chain bridges.

The Future of Cross-chain

LCP will connect all the chains in the world in a trust-minimized and gas-efficient manner. In order to realize this big vision, we need to collaborate with various developers and partners rather than proceeding only with the Datachain team, LCP’s core contributors.

For example, we would like to hear from the following companies and projects:

• Layer 1 Blockchains that want to build a bridge together using LCP
• DeFi Application developers who want to support cross-chain token swaps
• Bridge Application developers interested in developing a Bridge Application using LCP

‍

https://form.run/@datachain-contact-en

E-mail: contact[at]datacain.jp

Let’s create the future of cross-chains together!

‍

Twitter | GitHub | Document

‍