A blockchain is an electronically distributed database that is shared amongst nodes of a computer network. One distinct feature of blockchains is that data is shared in blocks amongst groups, where one data block is linked to the previous block, forming a chain of data. This data is then verified, recorded, and distributed, but cannot be edited .
Different blockchains will have different use cases, requiring each blockchain to have its own distinct characteristics and capabilities. Due to the variation in blockchain protocols and design, blockchain data cannot flow freely between the independent and incompatible blockchains, resulting in siloed blockchains, forcing developers and users to use single isolated platforms for their ambitious development. It is therefore desirable to achieve interoperability between blockchains, enabling the freedom of exchange between blockchains, allowing components to work together, despite the difference in language, interface, and execution environment .
Notably, for decentralised blockchains, it is important interoperability is fundamentally built on decentralisation, permitting a connection of blockchains to access information from one another and changing a state from another blockchain, without compromising on decentralisation . A cross-chain protocol refers to a model which achieves a synchronised and consistent state amongst chains , optimistically going beyond the scope of wrapped assets, and aims to achieve cross-chain communication, facilitating the exchange of data and most aspiringly, the functionality available on other chains . This is an ambitious goal. Cross-blockchain communication protocols would therefore require different blockchains with different consensus protocols, block sizes, confirmation times, hashing algorithms and network models to all communicate.
Blockchain Transmission Protocol (BTP)
Icon developed its novel cross-chain interoperability protocol, BTP, built upon the ethos to connect and allow for free-roaming of data across all blockchains. At the core of the BTP protocol is a relay (BMR) communicating with the other components of the BTP protocol to verify and deliver messages between blockchains.
The infrastructure of BTP consists of four components :
· BTP Service Handler (BSH): a smart contract that holds and controls application-specific logic (i.e. Coins, Tokens, and NFTs transferring among networks)
· BTP Message Verifier (BMV): a smart contract that verifies messages being sent from other blockchains to the Message Center, similar to an on-chain light client for connected networks.
· BTP Message Center (BMC): a smart contract that aggregates BTP messages on a given network, which also acts as a router, forwarding messages onto another chain when the BMC receives a message
· BTP Message Relay (BMR): Backend software that routes messages between Message Centers, utilising Simple Payment Verification (SPV) proofs.
The security and reliability of the Blockchain Transmission Protocol (BTP) rely entirely on a set of three types of smart contracts (BSH, BMV, and BMC) on each connected network. The significant security checkpoint of the BTP Network is the Message Verifier contract (BMV), which is tasked with verifying that a BTP message was sent from another network, utilising Merkle proof verifications (see below for a deeper dive into SPV).
Additionally, there is the Fee Aggregation contract on the ICON network where fees are sent to be auctioned off in exchange for ICX. Other interoperability solutions rely on centralised custodians, the trust of Validators or types of game theory. However, BTP maintains its security and reliability through cryptography which provides robustness and trust.
A misconception would be to equate BTP with other current centralised interoperability solutions that only facilitate the single-use of bridging wrapped assets, rather, BTP is a protocol linking blockchains with a unique set of components that can verify and facilitate messages of many forms across blockchains. As BTP is a protocol that can verify and deliver messages between chains, going beyond the use case of aiding bridges in token transfer, BTP can be used to verify and deliver messages of data across chains, creating the opportunity for NFT transfers, cross-chain contract calls, data aggregation and oracles to name a few, further enhancing the use case of the BTP.
Simplified Payment Verification (SPV) was originally outlined in the Bitcoin Whitepaper that allowed light clients to verify transactions on a blockchain without having to download the full state of the blockchain from the genesis block — reducing the need to download data at hand, saving data and time. Light clients can do this because blockchains store their data in Merkle trees, which groups transactions in pairs and hashes them together, continuing to hash the results, until there is only one hash left, this is called the Merkle root. This results in a tree, where each node has two off-springs, which can be used to create their parent node .
As a result of the hashing, Merkle trees can be verifiable just by looking at the Merkle root/top hash. Proofs are then created by bundling together nodes in the path, with one of the bottom transactions.
Hence, with only access to the top hash, SPV can follow the ‘stems’ of the tree back to the roots, to verify a transaction.
BTP utilises SPV in its BMR mechanism. SPV mechanisms used in interoperability create a two-way peg, which works as follows: tokens sent from a primary chain destined to its target chain are sent to a specific address, this address is part of the BTP mechanism which locks the tokens and sends a BTP message. Utilising SPV proofs, this message is then verified and passed on to the target chain to unlock a corresponding token on its own chain by presenting the SPV proof.
Normally, this would require a re-org period, where a user could present a Merkle tree proof to dispute any contradictory result. However, as BTP only deals with more secure chains that have deterministic finality, this is not required making the cross-chain transaction faster. Importantly, each chain has its own length of confirmation period, and the cross-chain process will depend on the pre-defined security parameters of each chain. This model allows for the avoidance of using third parties to be custodians and facilitate token transfers between blockchains. SPV-based designs also migrate the issue of requiring ‘majority of honest participation’, a time-consuming mechanism, that other systems such as HTCL (a form of atomic swap) rely on, whereas BTP relies on the cryptography of the Merkle tree and liveliness, making sure the node is online to verify cryptographic proofs.
An example of a centralised bridge would require a user to send their primary tokens to a smart contract, that is controlled by a single entity, that holds the private keys of that smart contract, giving them access to all the funds. The smart contract would then mint tokens from a second single entity-controlled wallet, on the destination chain.
Importantly, a centralised cross-chain is not only vulnerable to rug-pulls but it is also vulnerable to be targeted by law enforcement due to being considered as a financial activity, this would result in law enforcement requiring the wallet signatories that control the bridge to lock funds if they do not enforce KYC on those that have locked their tokens on the bridge. Secondly, in the use case of handling data, two parties that are conducting business, would not aspire for a third party middleman, to have access to the data (examples will be shared later).
BTP Token Economics
BTP enhances the token economics of $ICX — the native token for the ICON blockchain -, as BTP charges ~0.1% of every cross-chain transaction, selling the native tokens at a discounted rate in exchange for $ICX. The $ICX used to purchase other native tokens would be sent to Icon’s Contribution Proposal System (CPS), which is a decentralised on-chain treasury where proposals for grants are submitted to build and improve the Icon ecosystem. Once the CPS is full, up to 1,000,000 $ICX, it will start to burn any remaining $ICX sent to the treasury. This results in Icon funding its chain through the use of foreign assets, whilst creating token economics that contributes to icon becoming deflationary .
An example of the charge would be:
· Alice send 1,000 $MOVR tokens across the BTP network
· The network charges Alice ~0.1% which is 1 $MOVR token
· The token(s) is then sold to the open market at a discount from the market rate, in exchange for $ICX
· The $ICX bought in exchange for the $MOVR are sent to CPS, which funds development on the ICON chain, and once >1,000,000 $ICX, the excess in $ICX will be burnt.
BTP is a full-service protocol, all networks with BTP contracts deployed will immediately recognize the benefits without needing their own relay network. As BTP is a protocol that can verify and deliver messages between chains, BTP’s utility can go beyond the use case of aiding bridges in token transfer and can be used to verify and deliver messages of data across chains, creating the opportunity for oracles to build upon the protocol, further enhancing the use case of the BTP.
With a decentralised internet, blockchains can freely interconnect with each other, to increase use-case, scalability, speed, extensibility, and flexibility of each blockchain, thus creating better opportunities for business to business and business to consumer applications.
Example Use Cases
Developers and users of the decentralised web are attracted to chains that are faster, cheaper and more scalable alternatives than congested chains such as Ethereum. BTP provides the opportunity for users and developers to onboard tokens from one chain to use on another. An example of this would be a user who would like to participate in a DeFi dapp on Binance Smart Chain (BSC), whilst maintaining hold of their $ALGO (Algorand) token. In a siloed environment, without interoperability, a user would not be able to send their token across chains to use an alternative ecosystem dapp, however, BTP presents the opportunity for the holder of the $ALGO tokens to participate with DeFi on BSC without parting ways with their $ALGO. Importantly, by bridging your tokens, the tokens you hold will always be interchangeable 1:1 with the token on the original chain, regardless of price movement. For example, 1 iALGO on BSC will be interchangeable for 1 $ALGO on the Algorand network. BTP enables users to freely roam their wealth across the decentralised web, without the worry of parting ways with their tokens or having to find a central custodian. Future versions of BTP could also pioneer the multi-chain blockchain gaming industry, by facilitating the transfer of game NFT’s across chains, allowing users to freely trade their game items, whilst remaining in their selected chain.
BTP would also provide the opportunity for developers to build aggregator dapps to find the best deal on pricing and yields across many chains, this would entail sourcing and interpreting data from across many chains, by utilising the BTP protocol. Use cases such as cross-chain smart contracts would also arise from utilising BTP.
An enterprise industry where blockchain interoperability is fertile is in the healthcare industry. The healthcare industry is riddled with different organisations such as hospitals, clinics, specialist doctors and pharmacies, all of which will have their own siloed blockchain , this creates problems in sharing of data of the client’s health and examples such as an individuals new general practise wanting to retrieve data from their old practice. This is why IconLoop includes BTP technology in banking, healthcare, government, and other industries . In these cases, blockchain interoperability is highly sought after, creating an interoperable and trustless platform, whilst guaranteeing the security of a blockchain, such as authenticity and enabling privacy-preserving schemes .
Inevitably, the BTP protocol will create the decentralised web, a network facilitating communication between chains on token transfers and data, without the compromise on decentralisation and underlying infrastructure of each different blockchain, providing support for multiple communication services. BTP is flexible and prepared for not only existing use cases in the blockchain industry, but also what is yet to come, what we don’t even know exists yet. The future is cross-chain, and BTP will be part of that future.
As of the 4th January 2022, BTP has partnered with the following chains to join the BTP network:
- Binance Smart Chain ($BSC)
- Algorand ($ALGO)
- NEAR Protocol ($NEAR)
- Harmony One ($ONE)
- Palsm Network (Parachain: $PLM)
- Moonbeam and Moonriver (Parachains: $GLMR $MOVR)
- Acala Network (Parachain: $ACA)
- ICE Network (Parachain: $ICY)
- ICE Canary Network (Parachain: $SNOW)
The Parachain collaborations would integrate the entire Polkadot ($DOT) and Kusama ($KSM) ecosystems with the BTP protocol. There are many other chains in the works, as community members have been digging trails in the BTP GitHub, two more in the top 15 coinmarketcap rankings are yet to be announced.
- P. Wegner, “Interoperability,” ACM Computing Surveys (CSUR), vol. 28, no. 1, pp. 285–287, 1996. https://doi.org/10.1145/234313.234424
- E. J. Scheid, T. Hegnauer, B. Rodrigues, and B. Stiller, “Bifrost: a ¨ modular blockchain interoperability api,” in 2019 IEEE 44th Conference on Local Computer Networks (LCN). IEEE, 2019, pp. 332–339
- M. Kuhne, “Extending cross-blockchain token transfers,” Ph.D. dis- ¨ sertation, Wien, 2020
- P. Robinson, “Consensus for crosschain communications,” arXiv preprint arXiv:2004.09494, 2020.
- B. P. Center, “Clinician perspectives on electronic health information sharing for transitions of care,” Washington, DC: Bipartisan Policy Center, 2012.
- W. J. Gordon and C. Catalini, “Blockchain technology for healthcare: facilitating the transition to patient-driven interoperability,” Computational and structural biotechnology journal, vol. 16, pp. 224–230, 2018.