Introduction to NEAR-IBC | How to Implement the IBC Protocol with Smart Contracts

By MiX, Organized and created based on Rivers speech content

In the third quarter of 2022, Octopus Network officially launched the NEAR-IBC project, which is a NEAR protocol based implementation of the IBC protocol transport layer (IBC/TAO). This project integrates the implementation of the IBC protocol based Inter-Blockchain Communication fungible token transfer application (ICS20) to link the NEAR and Cosmos ecosystems, bringing greater composability to the innovation of the entire interchain blockchain Internet.

Octopus Network has completed the development of the pre-release.1 version of the NEAR-IBC project and reached an audit cooperation agreement with Blocksec, entering the contract audit phase.

Yang Zhen, Core Engineer of Octopus Network, was invited by the NEAR Ecosystem Chinese Developer Public Class to introduce the overview and technical implementation plan of the NEAR-IBC project to NEAR developers and COSMOS ecosystem developers.

The core content includes:

1. Basic concepts of the transport layer in the IBC protocol — IBC/TAO (client, connection, channel).
2. Basic concepts and use cases of the typical implementation ICS20 (IBC protocol based fungible token interchain transfer application) in the application layer of the IBC protocol — IBC/APP.
3. Introduction to the technical challenges and specific implementation schemes (NEAR-IBC) of implementing IBC/TAO and ICS20 on smart contract platforms (such as NEAR Protocol).
4. The vision of the NEAR-IBC project.

Part1: Introduction to NEAR-IBC

Hello everyone, I’m Yang Zhen from Octopus Network.

First of all, I would like to thank the NEAR community for the invitation, as well as the IBCL community for organizing and promoting this event.

Our team at Octopus Network launched the first version of our LPoS protocol in the second half of 2021, which is a leased security smart contract deployed on NEAR, using leased OCT assets from the NEAR ecosystem to provide security for Substrate application chains. At the end of 2022, we started planning for Octopus 2.0 version, fully embracing the Cosmos ecosystem. We hope to build a leased security Hub based on the IBC protocol, hosted on NEAR, allowing NEAR assets to provide security for application chains built with Cosmos SDK. This Hub will also be implemented on NEAR through smart contracts.

NEAR-IBC is an implementation of the IBC protocol on NEAR protocol, and is a crucial foundation component for Octopus2.0. Only after realizing NEAR-IBC can we implement Octopus Network’s leased security protocol for Cosmos application chains.

As shown in the figure above, in today’s session, the first half will introduce some fundamental knowledge and key concepts of the IBC protocol, and the second half will be how we implement basic functionalities of the IBC protocol on NEAR protocol, including sharing some technical details about the ICS 20 component.

First let’s take a look at the simplest conceptual model of the IBC protocol. Developers in the Cosmos ecosystem or friends interested in the IBC protocol may have seen the IBC protocol before, and know that it is a very complex infrastructure protocol with many components and specifications. But today I want to simplify it from the highest level to give everyone an initial idea of how the IBC protocol operates.

The IBC protocol is a universal interchain protocol that solves the problem of how two blockchains transmit specific data, achieve interoperability, and complete tasks between each other. Abstractly, it looks like the diagram: Assuming Chain A and Chain B want to conduct interchain interoperability or interchain communication, there will be an implementation of the IBC protocol on each chain, with a Relayer in between the two chains. This Relayer has three responsibilities:

1. Monitor — The Relayer will monitor events generated on both blockchains.
2. Once an IBC Event is received, the Relayer will convert it into an actual IBC message.
3. Deliver the converted IBC message to the other chain.

The Relayer itself is permissionless. The reason the Relayer can be permissionless is that our IBC messages will go through corresponding cryptographic verification and some other types of verification (possibly not cryptographic) before being executed on the receiving chain. This is the general structure of the Relayer.

Specifically, the IBC protocol is a layered protocol, as shown in Figure 3, divided into two layers. One layer is IBC/TAO, where TAO stands for Transport, Authentication and Ordering. That is transport, authentication and ordering. Transport and Authentication refer to the process of this data being Delivered from Chain A to Chain B, and then Verified on Chain B before execution to check that the Proof attached in the Messenger is valid. Ordering mainly means that IBC corresponding Messages have an order, which can be generated based on a unidirectional incrementing Sequence. It can be seen that the IBC/TAO layer mainly provides basic services for the IBC protocol.

Above IBC/TAO there is IBC/APP, which is the application layer protocol. Between IBC/TAO and IBC/APP there will be fixed internal interfaces. That is to say, after the underlying protocol delivers data to the receiving chain, the application on the receiving chain can have corresponding interfaces to receive the data and process it specifically.

So the figure above shows the overall architecture of the entire IBC protocol. There are 4 important concepts: Relayer, IBC Message, and the IBC layered protocol with IBC/TAO as the transport layer and IBC/APP as the application layer. Understanding these concepts is sufficient.

There are three most important basic concepts in the IBC/TAO transport layer, which are Client, Connection and Channel.

The Client is actually equivalent to the Light Client concept discussed earlier in the Ethereum community. That is, it is used to verify on-chain data or verify on-chain state from outside the blockchain. For Chain A to connect with Chain B in IBC, there should be a Chain B Client on Chain A, and a Chain A Client on Chain B. The Client is responsible for verifying the validity of data obtained from the blockchain. Since the blockchain itself is a closed, self-consistent cryptographic system, the data generated within it must go through strict cryptographic algorithm verification and consensus. Therefore, when chain data is needed off-chain, a Client is needed to perform corresponding verification.

The two most important concepts in IBC/TAO are actually Connection and Channel. In the figure above, I tried to introduce the concepts of Connection and Channel in an easier to understand way. Because I believe some friends may have seen IBC related materials that often compare the connection and channel (and possibly port) concepts in IBC with similar concepts in our TCP/IP protocol. But I personally think there are still major technical conceptual differences between them. So I will directly introduce these two core concepts according to the IBC definitions.

Connection, speaking abstractly, can be understood as the pairing relationship between the two blockchains that want to conduct IBC protocol interchain operations. The Connection between Chain A and Chain B in this figure represents the pairing relationship between ClientB on Chain A and ClientA on Chain B. The Connection is not an actual physical connection, but a logical definition that limits all Channels established under that Connection must be verified through the two Clients bound by the Connection.

The unique identifier of a Connection is determined by its Connection ID on both chains. In this picture, the ID on Chain A is 0, and on Chain B it is also 0, which is a pairing relationship. The counting of the Connection ID increments based on the number of Connections on the chain itself. For example, here Chain A is connected to two chains, 0 and 1 respectively, and Chain B is only connected to one, so it is 0. That is to say, the Connection between Chain A and Chain B, consisting of the Connection Ends with ID 0 on both ends, forms a logical pairing relationship. This is the concept of Connection.

The concept of Channel actually refers to a channel of communication between specific APP modules on the two chains for a particular APP. It is similar to Connection, also a logical pairing relationship, consisted of the two Channel Ends on the two chains.

The Channel ID on each chain contains the application module name, also called Port, that the Channel belongs to, plus an auto-incrementing sequence number. For example, here on Chain A the Transfer Port has 4 Channels, so the IDs range from 0 to 3, and on Chain B there are 2, so from 0 to 1. The green lines indicate the corresponding relationship between the two Channel IDs. These are all logical concepts, actual communication is completed through Relayer relay. I think beginners only need to understand these key concepts to basically grasp the operation mechanism of IBC.

We won’t discuss more implementation details of the IBC protocol for now, because it is very complex and rigorous. We just need to focus on the abstracted logical concepts. Here are some commonly used modules in the IBC App application layer, whose specific functions will be briefly introduced later. For now we just need to know that the IBC App layer will have many different applications to enrich protocol functionalities, because the IBC base layer itself does not have business logic, specific business implementations are all in the App layer.

Next, let’s take a look at the IBC Message. It is an abstraction of interchain communication in IBC/TAO (transport layer). There are currently four types of messages defined in the IBC protocol, Client Message, Connection Message and Channel Message, which correspond to the three core concepts mentioned earlier, used to synchronize their states. There is also a Packet Message, which is customized for the IBC/App application layer and can contain custom data for the App to process.

For the data that needs to be sent to the application layer module, IBC/TAO encapsulates it into a custom binary array. When this data is relayed to the IBC implementation on the target chain, it will find the corresponding Module implementation according to the target App specified in the Packet, and then hand over the data to it for decoding and execution.

Briefly introduced some basic concepts of IBC/TAO. Next, let’s take a look at the ICS20 module, which is possibly the easiest to implement and most valuable module in IBC right now. It implements Fungible Token cross-chain transfer, similar to ERC20 on Ethereum.

The main function of ICS 20 is just four Use Cases: transfer Fungible Token from Chain A to Chain B, and can Redeem Token back to Chain A; transfer Fungible Token from Chain B to Chain A, and can also Redeem Token back to Chain B. Although it looks like a peer-to-peer, the technical implementation will be quite different due to the differences in implementation on different chains, which we will introduce later the actual design used in NEAR-IBC.

Next, let’s discuss what technical challenges will be faced when implementing the IBC protocol using smart contracts.

First is the gas Limitation. Because smart contracts are subject to resource limitations of the underlying execution platform itself, we cannot give smart contracts unlimited computing resources. Whether it’s Ethereum or NEAR, they have designed a gas Limit to limit the available computing power of contracts. With the gas Limit, it is possible to encounter insufficient gas when verifying signatures in IBC verification. Because on the side chain, POS chains usually have a concept of a Validator Set, which is a set of validators that ensures security on the chain. This set needs to be updated periodically, and the update requires collecting signatures of old validators for the new set to reach a certain threshold, such as 2/3 of the total stake on NEAR. To do the update verification, signatures need to be verified in the smart contract. If the number of validators on a chain is very large, for example more than 200 or 300, then the computation required to verify signatures may exceed the gas limit of a single function on the smart contract platform, causing the verification to fail. For example, the limit on NEAR is 200T gas. According to our tests, 200T gas is only enough to verify 50 to 100 signatures. In addition, the contract needs to do other processing, including various data conversions and check logic, etc., which also requires gas. So the actual usable gas will definitely not reach the maximum limit. Another problem is that at the IBC/App layer, the specific computational resources required by different modules are unknown. So it is possible to encounter a newly added App module that exceeds the current gas limit when processing Packet messages. These gas Limits will all make IBC implementation difficult and challenging.

The second challenge is On-chain Asset Management. We know that similar to Cosmos SDK or Substrate, on-chain asset registration is handled through protocol-level logic, and user assets can even be operated directly without user transactions. But this cannot be done on smart contract platforms, where Fungible Token data is managed by separate smart contracts. So this kind of logic cannot be directly used on smart contract platforms, and specific implementation solutions need to be changed, which is also the point that will be discussed the most later.

The third point is the Sandbox Limitation of virtual machines. We know that current smart contract platforms are based on virtual machines, which provide an enclosed and controllable environment, but the ability to access the host chain is limited. For example, smart contracts cannot obtain consensus status information on the chain. We know that Ethereum has the concept of world state, which is actually organized using a data structure that organizes all storage changes that have occurred on the chain into a tree, and then uses the root hash of this tree to represent this world state. NEAR also has a similar concept of state root. This state information is inaccessible to smart contracts, this is information that the host environment cannot directly expose to the virtual machine, which requires additional processing in the implementation. There is also a minor detail that can be mentioned, that because NEAR is an asynchronous chain, if a cross-contract call crosses blocks, it will also increase complexity. This will lead to deviations when Relayer retrieves state. Therefore, the sandbox mechanism of the virtual machine will also bring some challenges.

The last challenge is On Chain Storage, which is how we store data on the chain. The way data is stored on smart contract platforms is different from how it is stored on Cosmos chains. At present, the on-chain storage of most blockchain systems is a KV database. So how is the key of the KV database determined? Like Cosmos and Substrate chains, it is determined by the on-chain native protocol-level logic. But on smart contract platforms, the platform itself has a design. For example, in EVM, it uses the account address plus the Slot Number in the contract to generate the storage key, then generates it into the state tree. For NEAR, it uses the tools provided in modules like Collection or Store in the NEAR SDK, such as the Lookup Map. When storing data on chain, a key is generated by a convention algorithm in the SDK. For example, when we New a new Lookup Map, a Prefix is ​​passed as the prefix of the storage key, and the actual key generated in storage is the Prefix plus the actual value of the key in the Map, and then a storage key-value is generated. However, the IBC protocol has strict requirements to obtain the value corresponding to the key value from on-chain based on the storage key value, so it requires a fairly strict Path Rule for the storage key value. For example, if I want to store the state data of the NEAR Client, I have to get the Proof of this data based on this Path Rule, which is a fixed Path defined in the IBC protocol, namely Clients/<client ID>. Use this fixed Path to obtain the Proof of this data on chain. Because smart contract platforms have their own rules for generating on-chain storage key values, if the rules of the smart contract platform do not conform to the specifications stipulated by the IBC protocol, we have to do additional processing. This will introduce additional complexity and additional bug risks.

In general, some of the characteristics and limitations of smart contract platforms themselves will make IBC implementation more challenging, requiring us to work on engineering solutions. Later we will focus more on easier-to-understand high-level solution ideas, such as account design and other specific solutions.

The NEAR IBC project was launched by our team at the end of last year. Pre-release.1 version has been completed. It is currently undergoing security audit by Blocksec. The current version implements all the interfaces of the IBC/TAO basic transport layer, as well as the 4 use cases of ICS20. This pre-release.1 version is developed based on IBC-RS version 0.28. IBC-RS is a repository maintained by the Cosmos community and is an IBC protocol implementation written in Rust. NEAR IBC stands on the shoulders of giants, enhancing and adapting on the basis of IBC-RS, mainly implementing chain storage related interfaces, as well as getting protocol-level interfaces for on-chain data. We are developing the pre-release.2 version, which will upgrade the base library to IBC-RS 0.4x, while adding support for the Solomachine Client to support our own VP solution, the verification proxy, combined with our own verification solution, Adaptive IBC, which we mentioned earlier this year, so I won’t go into details here.

Another change is to modify the on-chain storage key generation logic. Because the pre-release.1 version still directly uses the NEAR SDK’s storage structure, but the rules do not conform to IBC specifications, the pre-release.2 version will re-implement the storage related code according to the specifications.

From a high level perspective, NEAR IBC is mainly customized for ICS20 asset management in engineering implementation. We adopted a design based on NEAR’s sub-account mechanism. In this design, the sub-accounts in the upper half are used to support assets transferred from other chains to NEAR, as well as deposit and redeem processes. The sub-accounts in the lower half are used to support assets transferred from NEAR to other chains.

The top part supports assets coming from other chains. Each asset will have an Asset ID. The sub-account mechanism in NEAR is a relatively good mechanism for us to implement complex protocols like IBC, allowing us to avoid hard-coded implementation of some access control.

A complete account, such as the full account for asset ID1, is asset ID 1.token-factory.transfer.<NEAR ibc>. Among them, asset ID 1 is an account, token-factory is an account, transfer is an account, and NEAR ibc is an account, a total of 4 accounts. Since cross-account calls are no longer in one account, they must be untrusted. But with the sub-account mechanism (because sub-accounts can only be created by the parent account), there is a natural authorization mechanism. Sub-accounts can be thought of as an internal module of the parent account. In contract code, you can compare the account ID of the predecessor account with the current account ID to determine if the caller is the parent account or sub-account, thereby natively performing access control. I think this is a useful experience, and I hope more NEAR developers can flexibly use this mechanism to develop some complex smart contracts.

Let me explain the asset Asset ID generation logic mentioned earlier. In IBC, suppose we have an asset called asset 0, which is an asset on chain A. It is transferred to chain B through a channel with chain B, transfer/channel-0 to transfer/channel-0 on chain B. These two channels form a channel to chain B. Then this asset is transferred to chain C again through an independent channel, from transfer/channel-1 to transfer/channel-5, through this channel to chain C. In this case, the actual origin of this asset 0 is chain A. So in order to uniquely identify this asset, we need the concept of a tracing path. On chain B, this asset comes from channel 0 of chain A to channel 0 of chain B, so its tracing path is uniquely identified by the channel end on chain B, which is identified by transfer/channel-0. But when transferred to chain C, it comes from chain B. So its channel ID on chain C is transfer/channel-5. Then the original tracing path will be added with its previous incoming channel ID, the channel ID on chain B, indicating where it came from. So the tracing path for this asset becomes transfer/channel-0/transfer/channel-5. In this way, because the asset comes from a different source, it will have a corresponding tracing path to identify this asset in IBC. In fact, assets are identified by this tracing path plus the asset’s own denomination in the IBC protocol. We can understand it as the name or symbol in NEP-141, this name and symbol are concepts similar to the name and symbol in ERC20.

To uniquely identify assets, NEAR IBC uses the tracing path plus the denomination of the asset, hashes them with SHA256, takes the first 128 bits, converts to HEX, which is a 32-character HEX encoding. The reason for doing this is because account IDs in NEAR have length limitations, up to 64 maximum. So according to the previous sub-account design, the full sub-account ID also needs to be limited, otherwise the account name will be too long, and subsequent use of the factory to create sub-accounts will fail because it is an invalid sub-account name. Therefore, this processing is done to ensure that the account ID length is within the allowed range of the protocol.

The following pages are high-level sequence (timeline) designs used for the 4 main use cases of ICS20 that NEAR IBC needs to solve.

First, transfer assets from other chains to NEAR. According to IBC protocol requirements, the corresponding connection and channel must be created in IBC/TAO. After the channel is created, the Governance account (NEAR IBC will have a preset Governance account) can be used. This Governance account is usually the DAO on the chain, such as NEAR’s AstroDAO, or AstroDAO’s account as the Governance account. When this bridge Governance determines that it now wants to support a certain asset, it can issue a Proposal in the DAO. After this Proposal is voted and passed, a Function Call can be generated to call NEAR IBC’s Setup Token function. This function needs to pass in the Tracing ID of the asset, which is the Tracing Path and Denomination mentioned earlier, and other information. NEAR IBC contract will then call its sub-account, which is token factory.transfer.<near-ibc>. There is a setup asset function in this token factory, which will create the corresponding sub-account. Generate the sub-account ID using the algorithm introduced earlier, then create the sub-account, do the necessary initialization, and initialize the token account. This is a one-time operation. That is, when NEAR IBC decides to receive a certain asset from a certain chain, first create the required Connection and Channel, and then get information such as Tracing Path and Denomination from the counterpart chain. Initiate a call through Governance to create the corresponding sub-account. This is equivalent to an initialization work.

This work in Cosmos SDK may be to register an asset using the Bank module; similarly in Substrate, it is probably to register a new asset using the Assets module. This is a one-time process. After the sub-account is successfully created, subsequent transfers use the standard process. Notify the Relayer, which converts the transfer message from the other side into a Packet Message (introduced earlier, the Packet Message will specify that this is a message to be handled by the Transfer Module.) Then relay it to the NEAR IBC contract. Because the IBC contract inherits from IBC RS, it will parse, route messages, and determine that this is a message to be handed over to the Transfer Module. The Transfer Module will have corresponding functions, which is an interface it exposes, called mint/burn. This interface can call the Mint Asset function of the Token Factory. Then the Token Factory calls the Mint function of the actual Token account contract that manages cross-chain assets.

Why is there no direct call from NEAR IBC to the Token contract here, because there is Asset ID logic. I want this part of the logic to be handled in the Token Factory, without coupling with the NEAR IBC contract. So a decoupled design is made, with the Factory uniformly managing logic related to Asset ID. The Asset is actually a Fungible Token contract customized based on the NEP-141 standard contract on NEAR. It has a privileged Mint function. The permission of the Mint function is the sub-account mechanism introduced earlier. The mint of this contract only accepts requests from the parent account. This is a simple, natural access control method.

This is the process of transferring assets from other chains to NEAR.

The opposite process is the process of redeeming transferred assets back to the original chain.

This process is initiated directly by the Token Holder on NEAR. It is equivalent to me transferring assets from other chains to the token sub-account on NEAR. Then I need to send a signed transaction directly to the sub-account, indicating that I want to redeem some of the Tokens back to the original chain.

This function we call requestTransfer. This requestTransfer will generate a Transfer Request in the Token contract. Equivalent to a journal entry, meaning that because this is a cross-contract call, and NEAR contracts are executed asynchronously, asynchronous processing may also fail. So I have to do bookkeeping first in the original contract, that is, transfer the portion of the Token that the user wants to transfer from the user’s account to the current contract account, locked in the contract. Then initiate processTransferRequest call to NEAR IBC contract. The NEAR IBC contract will come to handle this situation, which is the sendTransfer function in IBC RS. This is also a privileged function that only receives requests from the NEAR IBC sub-account, which is also a natural way of access control. Then in the processTransferRequest function, call IBC RS’s sendTransfer, which will have corresponding checks according to the business checks in the ICS20 module of the IBC protocol. If the check passes, it will callback to the token contract to call applyTransferRequest. That is, actually burn the previously booked portion. Because this is to transfer assets crossed over from other chains back to other chains, burn is used here. I locked the token to the contract before, and now when I cross it back, I burn it. Then NEAR IBC generates an IBC event to notify the relayer. The relayer then relays the successful message back to the IBC implementation on the other side of the chain. If the sendTransfer check fails or fails for other reasons, if the program can still execute, it will execute cancelTransferRequest and callback to the token contract. Because it was just a journal entry before, if you know you want to cancel, just refund the locked tokens in the contract back to the user. If it panics here and cannot callback, manual intervention is required. But because there is a transfer request counter in the contract, refunds can be processed. It is processed like this. This process introduces complexity because it is cross-account processing. But because we have no way to process all cross-chain assets in one NEAR IBC account, this design is necessary.

This diagram has a lot of content. Let me briefly introduce the process. Actually it is similar to the previous process, just reversed. This process is to transfer NEAR side assets to other chains, which also requires one-time initialization. The sub-contracts generated by initialization are identified by the Channel ID. That is, when doing reverse transfers with a certain chain, as long as the channel is created, initialization of the escrow contract can be done through Governance.

After the escrow contract is initialized, the asset also needs to be registered to the escrow account through Governance. That is, Register Asset For Channel. One Channel can transfer different assets. The registered assets need to be registered in the escrow account. The sequence at the bottom is to initiate cross-chain transfer from NEAR, which is also initiated by the Token Holder.This diagram has a lot of content. Let me briefly introduce the process. Actually it is similar to the previous process, just reversed. This process is to transfer NEAR side assets to other chains, which also requires one-time initialization. The sub-contracts generated by initialization are identified by the Channel ID. That is, when doing reverse transfers with a certain chain, as long as the channel is created, initialization of the escrow contract can be done through Governance.

After the escrow contract is initialized, the asset also needs to be registered to the escrow account through Governance. That is, Register Asset For Channel. One Channel can transfer different assets. The registered assets need to be registered in the escrow account. The sequence at the bottom is to initiate cross-chain transfer from NEAR, which is also initiated by the Token Holder.

The last process is relatively simple, equivalent to initiating Redeem from the counterpart chain, and transferring assets out of NEAR back to NEAR. Similarly, the Relayer converts the IBC Event on the counterpart side into a Packet Message and sends it to the NEAR IBC contract. It determines that this is an asset of a certain escrow contract, and will call the escrow contract’s doTransfer to refund the locked Tokens to the recipient. It’s relatively simple.

This is how NEAR IBC uses cross-account implementation to achieve the four main sequences of ICS20. We can see that the four processes are implemented differently, and the actual processes are also different. This is due to the additional complexity introduced by the design of smart contract platforms themselves, which requires us to deal with during implementation.

Finally, let’s briefly talk about the vision of the NEAR IBC project. This project is still hoped to be a public base contract, so that any other project or developer can fork and use it when building cross-chain bridges based on IBC.

We are preparing to add LPOS as a must-have APP for Octopus 2.0. LPOS is similar to the CCV module in IBC, a shared security scheme that passes NEAR validator data to application chains via IBC. This requires customization on both sides: NEAR IBC needs to add the LPOS module, and integrate support for the LPOS module in the Cosmos SDK Appchain template.

LPOS and CCV in IBC are not peer-to-peer protocols, there is a distinction between main chain and sub-chain. Here, NEAR is the main chain, and the application chain is the sub-chain. This is not a peer-to-peer protocol, unlike ICS20. This plan will go online this year.

For LPOS, we will also do a Restaking contract on NEAR, which is equivalent to validators being able to do Restaking with native NEAR Tokens in our Restaketing Base contract. That is, stake NEAR into this contract, and then interact with the LPoS Market contract we are going to build through this contract. The main function of this LPoS Market contract we want to achieve is the Delegator function we implemented in 1.0. These contracts will be introduced again when they are developed later. Because we believe that Restaking is also one of the important innovations in the NEAR ecosystem.

Looking at other modules now, Interchain Accounts has the biggest imagination space. It can bind accounts on Chain A and Chain B, transact on Chain A, and relay requests to Chain B through interchain accounts, use the bound Chain B account to generate a specific transaction on Chain B. This is a very imaginative feature.

NFT transfer is somewhat similar to the Foundable Token Transfer I mentioned in ICS 20. To implement NFT transfer on the NEAR side, the sub-account method also needs to be used for implementation.

When introducing sub-accounts earlier, I mentioned that transfer is a placeholder sub-account reserved for the IBC/APP layer. In the future, if we need to implement NFT transfer, we will create another NFT Transfer sub-account under this sub-account to manage corresponding cross-chain NFT assets.

This sub-account reservation is considered from the middleware perspective, and the middleware can provide better compatibility and reuse.

For example, Fee Management is in IBC, which can get rewards for Relayers from users. Because Relayer does not have incentive mechanism, if a project wants to run its own Relayer, it needs to bear the cost. If you want to build a public network, with other chains acting as Relayers, no one is willing to do this because there is no incentive.

Fee Management proposes that protocol can obtain user rewards for Relayers. This is obviously a general function that different applications may need. For example, transfer, NFT transfer, etc. all need users to pay fees to Relayers. So the APP needs a reusable mechanism.

Therefore, the idea of middleware is proposed, adding a Middleware layer above the IBC APP layer. The APP above Middleware only needs to implement two fixed interfaces to interact with Middleware, thereby integrating the functionality of Middleware. This is equivalent to two interfaces, that is, the APP inputs messages to Middleware, and gets output from Middleware. After implementing these two interfaces, the additional logic inside Middleware is appended to the entire process.

This approach can improve reusability. If interested, you can take another look at the IBC specifications.

The last application is Atomic Swap, which allows exchange of different assets on two chains without cross-chain.

Without Atomic Swap, we need to first cross-chain assets, then exchange on the other chain, and transfer back after exchange, the process is complicated. Atomic Swap can complete the exchange in one step by locking assets on different chains. The user only needs to sign one transaction. This brings more possibilities to DEX.

In addition, there are some modules that are under drafting or conception that I will not explain in detail. The above introduces the modules I think are relatively important or imaginative.

We are doing NEAR IBC in the hope that it can become a public infrastructure in the NEAR ecosystem. Interested friends can use this contract or fork it to build their own cross-chain bridges and add their own modules. This open protocol approach is clearly more promising than a closed protocol approach, and is more likely to gain community support. We hope NEAR IBC will become a project with long-term viability in the NEAR ecosystem, and will continue to maintain high-quality code for everyone.

Today’s sharing ends here, thank you.

Part2:Q&A:

Q: You said it can already serve as an asset bridge due to ICS20. Will Octopus build an asset bridge? Or don’t plan to implement it?
A: Yes, because our current version already contains ICS20, the launched bridge will definitely include this module.

Q: So you will create a public asset bridge, right?
A: Yes, because each NEAR IBC contract instance contains a set of account logic, which is a bridge. We will run a bridge ourselves. Its main function is still to support our own APPs. If solely building an asset bridge, there is no plan for now. But our own bridge will definitely have asset bridging capability, meaning it supports this functionality. Just because the bridge is maintained by us, I also mentioned earlier that to enable asset bridging on the bridge requires going through our governance process.

Q: It will be publicly usable, right?
A: Yes, correct. As long as governance approves enabling the feature, and the counterpart channels are created, it will be public for anyone to use.

Q: What do you estimate the bridging latency to Cosmos chains will be?
A: Latency does not have actual data from production yet, but expected to be in the minute level.

Q: Speaking of latency, what will be the future relationship between your bridge and Rainbow Bridge? Can you contrast for us?
A: Rainbow Bridge is an independent Ethereum to NEAR bridge. Our main goal is to connect Octopus Appchains or other potential Cosmos chains using our bridge, so the difference lies here, no direct relationship.

Audience Discussion:

Theoretically any chains with IBC enabled can plug into it, right? You mentioned earlier latency is minute-level. I’m quite looking forward to it, because in the heterogeneous chain field many IBC proposals have been put forward, but still in progress. You building it first can have a great demonstration effect. Because IBC has much better security than single chain bridges, it’s already consensus, but no actual implementations seen, so people don’t acknowledge it. Someone building first can advance the entire field. I think you can apply for Grants, the workload is not small. Also the Cosmos ecosystem is IBC’s territory, no competitors, the potential to extend IBC to every corner is huge. So I think your work is very critical. Teams like Polyman did it for a period then slowed down, so a team needs to push hard for it, once a demonstration effect forms it will be great. Because IBC capabilities are severely underestimated now, pressed to the ground unable to get up. Mainly because Ethereum community people are unwilling to face it, other ecosystems haven’t seen these capabilities. But looking at the Cosmos ecosystem overall it’s still very optimistic.

So after you take the first step, needs full support from all community parties, whether technical or end users. We can keep deepening collaboration with the Foundation, you can also get some support, can increase efforts later. I feel completing launch before October will have very good demonstration effect.

Q: You mentioned EVM earlier, what would be the impact if connected via the bridge in the future?
A: We are preparing the first Cosmos chain for Octopus2.0, a community chain called Ottochain, which will support EVM. So any Solidity ecosystem projects can develop on Ottochain.

Q: It will use bridges to connect with current EVM compatible chains, how is your bridge different from regular bridges?
A: Depends if it’s an independent chain or appchain. Ottochain is the first appchain for Octopus 2.0, needs the LPoS module, is a Cosmos SDK chain, will natively support EVM on chain. If an independent chain wants to connect to NEAR, currently can only use IBC/TAO and ICS20. These functionalities will be supported after our bridge launches. An independent chain wishing to only use ICS20 is also fine, can satisfy needs.

Q: Plans to launch in October right?
A: Yes, launching on mainnet in October.

Q: Compared to current other bridges, what are the difficulties and differentiators for you?
A: For example many ZK solutions do on-chain verification through Light Clients, with ZK verification during Relayer relay.
We introduced the Adaptive IBC concept, supports Solomachine Client, which is for our verification solution. Simply put uses Solomachine for on-chain verification instead of peer chain’s Client. The actual verification client is placed on a third chain, with Relayer relay, and both chains use Solomachine Client. This can perfectly complement other solutions. This is also our next focus.

Q: It’s harder for Cosmos to verify Ethereum, easier the other way around right?
A: The issue the other way is if Cosmos chain’s validator set is too large, verification gas may exceed limit and fail more easily.

Q: You mentioned earlier that providing the framework will allow more NEAR developers opportunities for application development, leveraging your technical architecture, right?
A: This project is open source, anyone can build new APPs. We will build according to our own plans first, maybe Interchain Accounts will be higher priority, but still needs discussion, currently only the LPOS module is finalized.

中文版｜NEAR-IBC 介绍&如何使用智能合约实现 IBC 协议

Disclaimer: This article is for reference only and should not be used as legal, tax, investment, financial or any other advice.

Follow Octopus Network!

Website: https://oct.network
Doc: https://docs.oct.network
Github: https://github.com/octopus-network
Email: hi@oct.network
Twitter: @oct_network
Telegram: https://t.me/octopusnetwork
TelegramZN: https://t.me/octchinese
Medium: https://medium.com/oct-network
Discord: https://discord.gg/6GTJBkZA9Q