1st Non-standard IBC Transaction Executed by Persistence

This is a two-blog series highlighting how Inter-Blockchain Communication (IBC) Protocol is relevant for Institutional Finance use-cases.

The first blog introduced IBC and went into detail about how IBC will be used at the Persistence Hub level. The second blog presents the world’s 1st IBC transaction performed by the Persistence team.

Contents:

• Introduction
• What is Comdex?
  – Issuance of NFTs and RFTs
  – Comdex v0.1 Architecture
• First Non-Standard IBC Transaction
  – Implementation Outline
  – Limitations to Implementation

There has been a strong focus on Inter-Blockchain Communication (IBC) research and testing at Persistence since inception and the team was able to successfully implement a proof-of-concept for a Non-Standard (not a general token transfer) Inter-Blockchain transaction. This non-standard Inter-Blockchain transaction was conducted in the Comdex application and was a simulation for a cross-border trade settlement process.

The blockchain related processes involved to conduct a settlement on the v0.1 version of the Comdex platform involved an inter-chain exchange between two commodity traders of a Non-Fungible Token (NFT) that represented a *real world* physical commodity, with a Re-Fungible Token (RFT — Refunged NFT) that would represent a real-world fiat deposit.

What is Comdex?

Comdex is a physical commodity trade tech platform that is currently operating on its own Persistence SDK based zone, powered by the decentralized governance of industry leading validators.

At this point in time, Comdex is being used by SMEs and MEs present in South East Asia and the Middle East for legal agreements, negotiations and document provenance for high-seas trades. Comdex will soon begin its ‘Cross-border Settlement’ service offering, followed by the launch of its ‘Trade Finance’ platform.

NFT Issuance on Platform

On the Comdex platform, NFTs are created to represent physical commodities once a commodity trader lists a public or private sell order on the platform.

These NFTs pertaining to real world commodity consignments contain various data points such as:

• Digital fingerprints of real-world high value ‘Documents of Trade’ and other legally binding contracts
• Listed price of the commodity per unit (before and after negotiations) and its total shipment value
• Shipping and other logistics related information of the consignment

RFT Issuance on Platform

RFTs are issued on the platform to represent real world fiat deposits from commodity traders into Comdex’s exchange account.

These RFTs pertaining to real world banking transactions involved in the process of settlement, contain various data points such as:

• Details of the transaction such as the total amount of the transaction and the value of the transaction that has been redeemed.
• Details of the User Wallet Addresses that hold the ownership to the full amount or partial amount of the transaction.

RFTs are used instead of NFTs to represent real world fiat deposits because RFTs can be used to send/receive partial amount (in addition to full amount) to a wallet/escrow. As a result, RFTs retain the properties of divisibility while also allowing for the storage of unique metadata.

Comdex v0.1 Architectural Design

In the Comdex v0.1 architectural design, the Comdex application modules are split into three chains; the Hub chain, the Asset chain, and the Fiat chain. The commodity ‘asset chain’ handles the NFT metadata as well as the minting and burning of NFT related transactions while the ‘fiat chain’ handles the RFT metadata as well as the minting and burning of RFT related transactions.

Blockchain based storage (state) is the most expensive resource for most if not all decentralized applications and data manipulation is the most computationally intensive part of any transaction. The Comdex commodity trade transactions depend on NFT generations as well as transactions, which rely heavily on both blockchain based data storage as well as data manipulation.

To allow for reasonably sized application state and transaction times (in-other words increased scalability), Comdex v0.1’s architectural approach was to split the storage and transaction handling into two different application specific chains (zones) that are able to communicate with each other.

The Hub chain maintains the wallets for the participants and handles the ownership transfer of NFTs/RFTs through IBC transactions.

First non-standard IBC transaction

At the time of implementation of the non-standard transaction, the Cosmos SDK was on version 0.24 and the official IBC module was still fully work in progress. We extended the relayer from the official module to handle different message types and defined the behavior on each chain for handling these messages. The codebase can be found in the git repo. The main components of this implementation include:

• The main application which contains all application logic and includes all modules for the Hub chain.
• The asset chain application which has the logic for the Comdex NFT creation, modification and exchange.
• The fiat chain application which has logic for the proprietary commit fiat ledger system.
• The modified relayer.

All the transactions implemented:

• ibc.MsgIssueAssets
• ibc.MsgSendAssets
• ibc.MsgRedeemAssets
• ibc.MsgIssueFiats
• ibc.MsgSendFiats
• ibc.MsgRedeemFiats
• ibc.MsgBuyerExecuteOrders
• ibc.MsgSellerExecuteOrders
• ibc.IBCTransferMsg

The video for a demo IBC transaction operation can be found below.

Limitations to the Non-Standard IBC Implementation:

• The relayer for the IBC transaction was centralized and hence, a single point of failure. As a result, the system lost on decentralization, transaction censorship resistance and aspects of trustlessness.
• Only one address had to be allowed permission to relay the IBC transactions to eliminate malicious transactions from entering the system.
• The relayer address had to pay for all the IBC transactions, leading the gas fee to be continuously added to its wallet or risk IBC channel halting.
• Because of the lack of shared security, application logic and metadata storage had to be redundantly replicated at all the participating state machines.
• The cost of running three different chains for one application is extremely infrastructure exhaustive and is not practical in the early stage. Comdex does not and will not utilize an architecture involving multiple zones for the near future.

IBC going ahead…

The Cosmos IBC module is nearing the final stages of its development and it is our responsibility as active community members who wish the best for Cosmos to contribute to the development and proliferation of IBC.

The IBC working group is a community led initiative involving several individuals and organizations aligned in their goal to assist in the creation as well as the deployment of IBC.

About Persistence

Persistence is a Tendermint-based, specialised Layer-1 network powering an ecosystem of DeFi applications focused on unlocking the liquidity of staked assets.

Persistence facilitates the issuance and deployment of liquid-staked stkASSETs, allowing users to earn staking rewards while participating in DeFi primitives, such as lending/borrowing and liquidity provisioning on DEXs.

Persistence aims to offer a seamless staking and DeFi experience for PoS (Proof-of-Stake) users and enable developers to build innovative applications around stkASSETs.

Join Our Movement

Twitter | LinkedIn | Telegram | YouTube | Reddit | [email protected]