ICON Network’s Blockchain Transmission Protocol (BTP) Explained

Every year, a host of new blockchain projects emerge that vie to become the de-facto blockchain and home to tomorrow’s most prominent and influential decentralized apps (dApps). Over the years, blockchain technology has slowly and steadily come of age, providing significantly improved scalability, security, and transaction throughput. However, despite the impressive pace of development in the space, the vast majority of blockchains today operate in silos. As a result, the wider blockchain space today resembles a series of stand-alone and disconnected data networks.

Introducing BTP

South Korea-based ICON Network – the network of blockchain networks – has a mission to “hyperconnect the world.” This catchphrase essentially refers to the “interoperability” aspect of blockchains that the ICON Network aims to enable via its Blockchain Transmission Protocol (BTP).

Specifically, in a bid to realize the full potential of distributed ledger technology (DLT), the ICON Network seeks to establish ways to allow different protocols to seamlessly interact and communicate with each other. At the same time, these blockchains must also have the ability to interoperate at the protocol level. To achieve this goal, the ICON Network presents BTP.

BTP Explained

ICON Network’s BTP is a standard the facilitates interoperability among heterogeneous blockchains – including the ones that follow entirely different consensus models and algorithms. Before going ahead with the nitty-gritty of interoperability, it’s necessary to define what exactly we mean by the term. For ICON Foundation, interoperability is the ability to enable value transfer, service invocation, and data exchange among blockchains following different protocols. Interoperability enables these stand-alone blockchains to freely interact with each other via a universal standard that functions as a trustless settlement layer.

Speaking of the scope of application of interoperability solutions, one could zero down on token transfers between different blockchains as an important use-case. BTP facilitates such transfers at the protocol level directly via smart contracts, transferring data from one blockchain to another without involving any central trading platform.

In terms of practical examples from the ICON ecosystem, it could be enabling data exchange between ICONLOOP-enabled enterprise partners, including MyID applications.

Figure 1. MyID application to communicate between chains through BTP

In MyID applications, the registered personal DID (Decentralized ID) data is verified on the public ICON network. This allows the owner of the data to exchange messages to a public or a private network that is interlinked via BTP without requiring them to resubmit their DID document and public key to each chain.

Figure 2. Broof certificate issuance

Similarly, Broof, a DLT-powered service on the public ICON Network that allows issuing and storing verified certificates on the blockchain, can witness significant performance enhancement via BTP. For instance, BTP can aid in automating the process of certification issuance for a private chain. As can be inferred from the above figure, BTP helps in invoking the issuance service to a Broof smart contract on the ICON Network.

Building Blocks of BTP

To ensure the seamless transmission of data and preserve its integrity and validity, the sender and receiver must comply with the below highlighted formally defined BTP standards and functions.

Message Specifications – messages must include sender, recipient, service name, serial number, and service data.

Message Relayers – The application to query and deliver BTP messages between blockchains. The relayer operations are independent of blockchains.

Message Verifiers – Message verifiers act as validators for data collected from relayers.

Service Smart Contract – Verified BTP messages are delivered to the Service Smart Contract so the transaction from the sender blockchain’s smart contract can be executed in the recipient blockchain’s smart contract.

BTP Data Verification

ICON Network gives utmost importance to transparency and trust which reflects in the BTP data verification mechanism.

As BTP verifies external data using smart contracts, all verification procedures are transparently shared on the blockchain. This makes the code publicly available to be audited and verified by anyone. What’s more, under this mechanism, building a BTP environment becomes as easy a task as deploying a smart contract.

Enabling Interoperability Among Blockchains

BTP works as a bridge that connects two blockchains. However, the blockchains connected via BTP can further connect to other blockchains. This architecture helps foster a network of interconnected and interoperable blockchains.

Asynchronous Operations

BTP takes care of inefficiencies and data blockage caused by asynchronous operations. In the unlikely event of temporary network failure, a sender blockchain may stop sending data. Under these circumstances, BTP messages can be restored and retransmitted after the network is restored. All this, without any loss of data.

Enabling Partial Participation

The flexible design of BTP allows blockchains that don’t support smart contracts to partially participate in BTP transactions. That said, it’s worth noting that in such instances, the blockchain would only participate as a sender blockchain and not as a receiving blockchain.

Full Participation

In order to fully utilize BTP features, there are certain conditions to be met. Specifically, the sender blockchain must have block finality and the participating blockchains must have the capability to support smart contracts.

Finality – The sender blockchain is required to reach finality and transmit irreversible results to the recipient blockchain. These results are then verified via the verifier smart contract.

Smart Contract – To leverage the benefits of a fully-fledged BTP, blockchains are required to implement the following components via smart contracts.

• BMC (BTP Message Center) to build BTP messages and pass to a Relay for message delivery,
• BMV (BTP Message Verifier) to verify and decode the message received from a Relay to BTP Messages, and
• BSH (BTP Service Handler) to deliver BTP messages to service smart contracts.

BTP Message Delivery Flow

Figure 3. BTP Message Delivery Flow Chart

The following scenario gives a glimpse of how a public chain application can verify the identity of a user held on a private chain:

1. Jim logs into a Ride Share app and this app requires verification of Jim’s myID identity information

2. When Jim logs in, the Ride Share app sends a transaction with Jim’s encrypted identity information to BSH_A on the public chain.

3. BSH_A sends a service message to BMC_A on the public chain requesting verification of encrypted identity information provided by Jim

4. BTP Message Relay detects the event and gathers Jim’s encrypted identity information

5. BMC_B on the private myID chain receives the request to verify Jim’s information

6. BMV_B on the private myID chain decodes the encrypted information in order to verify Jim’s identity

7. BSH_B on the private myID chain replies back to BMC_B with the results of Jim’s identity-check

8. BMC_B communicates these results to the BTP Message Relay

9. The BTP Message Relay passes the results back to BMC_A

Final Remarks

BTP 0.5 Proof of Concept is available on the ICON Github Page. To learn more about the specifications of the protocol, please refer to the BTP proposal under ICON Improvement Proposal (IIP). At present, BTP 1.0 is pending review before final acceptance.