Bringing IBC to NEAR: Our NEAR <> Polkadot bridge

Published in

Composable Finance

5 min readJun 17, 2022

The current sentiment around different protocols is beginning to mature regarding leveraging the various breakthroughs in building trustless bridges and achieving a cross-chain future. Communities and core teams realize that working towards the interoperability of their ecosystem with different chains will benefit the growth and widen the array of possibilities. At Composable Finance, we are constantly working on delivering the final consolidated infrastructure for DeFi, tackling the interoperability dilemma and unlocking capital efficiency for users across different chains. Here is our initial share on that idea: Trustless Bridging

Why is the cross-chain future needed?

Rather than competing with trustless bridging, we have the opportunity to enhance the overall user experience and work towards the web 3.0 vision that many protocols and initiatives are aiming for.

Our overarching goal is to abstract the complexities surrounding users’ interaction with multiple blockchains to provide a seamless experience across different ecosystems. With the Centauri bridge connecting IBC-enabled chains with Dotsama and multiple upcoming plans, we are taking charge of transitioning the space into a high-growth interoperable industry.

Bridging Near & Polkadot

The NEAR protocol has been labelled as a developer-centric platform for the creator economy, powering open financial tools for the open web. NEAR already has the Rainbow bridge, allowing users to migrate or send assets within Ethereum, NEAR and Aurora’s EVM Layer. Nonetheless, with multiple rollouts, such as IBC and XCM, being introduced and streamlined, to enable different chains to seamlessly communicate in a trustless manner; we see building a trustless bridge to connect Near to the Dotsama ecosystem as a promising piece of Composable’s infrastructure for a cross-chain DeFi future.

Composable is thrilled to share that the first steps have been taken to see this vision true in collaboration with NEAR’s core team. Our new proposal, pending approval, aims to get the community’s support to make some changes to the NEAR protocol’s runtime, which will enable running a Polkadot light client, following the IBC’s standards, possible.

In this article, we provide the key elements in terms of challenges and solutions surrounding this cross-chain bridging effort, where we leverage IBC to achieve successful communication and asset transfers between these two ecosystems.

The challenges

Signature Verification

The concept of bridging through light clients is a simple concept at its core: deploy a light client that can verify the state of a chain within another chain. However, for this concept to work, there’s a need to verify signatures. Signature verification has proven to be a “ubiquitous” operation. This issue keeps manifesting, especially in PoS consensus mechanisms, due to the fact that some protocols don’t necessarily support certain signatures that might be used by others. Per our proposal, with the current architecture, there will be roughly ~200 signatures that would need to be verified every minute (Polkadot’s authority set is 300 signers). Therefore, there is a need for a mechanism to perform these operations in a cost-effective way in terms of gas and speed.

The challenge with the current solution that doesn’t require any changes to NEAR’s runtime is, in short, a combination of performance and cost. For the time being, validating all signatures in one transaction is impossible. The benchmark results here show that most of the signature verification calls returned an execution error for exceeding the maximum amount of gas allowed to burn per contract.

Adding to that, the NEAR protocol does not have any native signature verification toolbox, which would require the light client operating inside NEAR to import a library compiled to WASM. This would indeed make signature verification an expensive process and defeat our intent to streamline the solution in terms of gas cost.

Missing Valid Proofs

An issue that has manifested when querying an account or a contract’s state through an RPC call is that the NEAR protocol’s relayer is able to feed the IBC pallet running on Polkadot the data requested but leaves the Proof as an empty field. This has presented an incomplete state that would render it unusable without valid proof that the state is indeed correct.

Keep in mind that one of the key aspects of trustless bridging is reaching a consensus on the finality of both protocols with valid proofs of the state of each network. This is a crucial piece in enabling the Near protocol to communicate with Dotsama and any substrate chain in general.

The aim is that our light client can attest to the finality of the Dotsama Parachains state by trailing both relay chains’ finality; that way, the relayer will be able to relay the light client’s proofs and provide finality on the other chain.

Singular Transaction validation process

Currently, the NEAR runtime allows a light client to validate transactions on-chain singularly. However, following the IBC’S Standards, there is a need to validate a set of transactions as a batch. Enabling this batching mechanism would allow verifying that a block’s outcome root matches the block’s header for each transaction and would result in a significantly less expensive proof-verification process.

Our intent at Composable Finance is to streamline our cross-chain infrastructure to serve as a cost-effective approach to connecting different ecosystems and ensure usability to the end-users.

The solutions

The challenges this bridging solution manifested have pushed a rather fruitful collaboration with the NEAR core team about collaborating with us to see this mission through. And so, our team at Composable finance have successfully submitted a proposal to tackle these challenges and make this bridging solution as cost-effective, performant, and trustless as possible.

The proposal can be divided into 3 main requests, pending the NEAR community’s approval:

NEAR’s runtime supports an additional 3 types of cryptographic signatures (ed25519 + sr25519 + ecdsa on secp256k1), which will make the process of verifying these signatures as precompiled in the NEAR’s runtime.
The NEAR relayer is required to feed a complete and valid state-proof to the IBC pallet running on Polkadot in order for the light client to have, in addition to the data, valid proofs that the state is correct.
And finally, the ability to validate a batch of transactions instead of relying on a singular process. This would be feasible through an endpoint which would make it possible to verify that a specific block’s outcome-root matches the block’s header for each transaction, as mentioned before.

We believe our joint effort with the NEAR core team in delivering the bridging infrastructure that connects NEAR and Polkadot will further add to DeFi’s continued growth and interoperability between two innovative ecosystems

Summary

The requested upgrades to the NEAR runtime to support additional signatures and the batching mechanism for transaction validation will definitely be a step forward in abstracting the complexity of the bridge from both an economical and technical point of view.

By leveraging the already existing components being built for the Centauri bridge, as a reference to the NEAR bridging initiative; we believe that we are on the right track to host the necessary infrastructure and provide a seamless cross-chain experience to our end users on both the NEAR side and the Dotsama side.

For more information please reach out to our team via discord or Telegram.