With so many different blockchains popping up around the world, all having differing compatibility requirements, one wonders how the technology will ever go mainstream. Interoperability is the answer, and ICON is bringing interoperability with other blockchains through its much-anticipated BTP (Blockchain Transmission Protocol).
BTP is being built to overcome many of the limitations and challenges of other interoperability solutions in the industry, and will soon be integrated into many ICON DApps to create bridges with many other blockchains including Binance Smart Chain, Harmony One, Polkadot, Kusama, Moonbeam Network, NEAR Protocol, Algorand, Acala, Astar Network, Edgeware, and — via ICE — Ethereum Virtual Machine. (In fact, we just finished an informational article series about ICON’s BTP partners, which you can read by clicking those preceding links.)
So, how does BTP work, exactly? What makes it so great? Good questions. ICON has released a litepaper for BTP that explains exactly that. Now, this litepaper is mostly written in plain English, but it’s still a 12-page technical paper written with developers in mind as the target audience. So, allow us to offer a summary of the litepaper that is a bit easier to understand:
(Note: The below uses much of the original wording from the litepaper, paraphrased where appropriate and copied ad verbatim when possible.)
BTP in a Nutshell
Interoperability relies on cross-chain messaging protocols to communicate between chains. However, current solutions developed by other blockchains compromise on trade-offs between cost, security, extensibility and speed.
ICON’s BTP is being built as a chain-agnostic and trustless generic messaging protocol that minimizes the aforementioned limitations by using low-cost, gas-efficient, on-chain “light clients”. This enables the development of complex cross-chain applications with smart contracts on two or more blockchain networks, without sacrificing security.
What’s a Light Client?
When you use a blockchain, you really don’t want to go through the hassle (time and energy) to sync with the entire blockchain. That’s where light clients come in — they help you access a blockchain without having to waste resources doing a full sync and storing the blockchain, while still maintaining decentralization and security. They do this by querying a destination blockchain node for specific transactions and blocks you’re interested in.
There are two common challenges associated with light client solutions, both which BTP addresses:
- Extensibility: It can be very difficult and time-consuming to integrate light clients with new networks. BTP works around this limitation with an on-chain hub architecture model that includes light clients of all connected networks to verify and route transactions. When making a new integration, developers need only deploy the light client for the hub itself, which can be easily copied from other existing implementations. Also, because the light client is deployed and maintained at the smart contract layer, it’s no longer necessary to do a hard fork to stay compatible with target validators’ software upgrades.
- Maintenance Costs: BTP keeps maintenance costs down to a bare minimum by creating “BTP blocks” only when a BTP message is sent, instead of using the frequently updated ICON blocks. This results in considerable gas savings, and is also technically much easier to implement as destination chains won’t need to support ICON’s specific hashing algorithm. BTP also maintains a whitelist for message verifier contracts, which further mitigates gas fees.
BTP Components and How They’re Used
BTP uses four components to get the cross-chain messaging job done. These consist of one off-chain component and three on-chain smart contracts to process and verify messages:
Step 1: Service Handler
This is a smart contract that handles requests to send instructions from one blockchain to another. Service Handlers must be permissioned — we don’t want malicious contracts attacking the BTP network — and third-party developers will be able to set up an “Arbitrary Call Service” as their primary service handler so they can create their own extensions of BTP.
In Use: When an end user wants to make a transaction between two blockchains, their BTP-integrated application will call the Service Handler as a first step. This results in a BTP message being sent to the destination blockchain. The application may also be coded with call functions to execute different kinds of transactions on the destination blockchain.
Step 2: Message Broker
Message Brokers are smart contracts that act as a central hub for all BTP messages on their respective network. Message Brokers link permissioned Service Handlers with Message Verifiers (see step 4, below). Think of them as old-school telephone switchboards of sorts.
In Use: On the sending blockchain, the Message Broker translates the Service Handler’s message into a BTP message and routes it to the next step of the process, the Message Relay.
Step 3: Message Relay
The Message Relay is an incentivized off-chain server that forwards messages to the destination blockchain and synchronizes the Message Verifiers between blockchains. It is necessary for the Message Relay to be an off-chain component because blockchain networks are inherently restricted from initiating outward calls to external networks.
In Use: Relay messages are encoded to include block updates, block proofs and message proofs, and forwarded to the destination chain’s Message Verifier. Relay messages are delivered in order, using a sequence number that prevents skipped or duplicated messages.
Step 4: Message Verifier
The Message Verifier is an on-chain light client of the source blockchain, stored in a smart contract on the destination blockchain. It sequentially decodes and verifies relay messages using block headers and validator signatures from the source blockchain. It tracks the merkle root of block headers, as opposed to full blocks, which is a mathematical method that ensures the data blocks received are whole, undamaged, and unaltered.
In Use: Using the information decoded from the relayed messages, the Message Verifier is able to verify the cross-chain message and finalize the interchain transaction.
That’s about it! There is some more technical information in the litepaper that developers would need to understand, but the above is a basic rundown of how BTP technology works that should suffice for most laypeople. If there’s anything that doesn’t make sense or if you have any questions, please drop us a line on Twitter!
