Understanding BTP: ICON’s Unique Interoperability Solution
With the launch of ICON 2.0 right over the horizon, we’re getting closer to the official launch of BTP, the Blockchain Transmission Protocol. BTP is the keystone of the ICON project’s promise of interoperability, and it’s what many ICX holders have waited years for.
Despite that anticipation, BTP remains a complicated technology to understand. In addition, with other interoperability solutions already in operation throughout the blockchain industry, I’ve seen some concern that BTP is too late to the party.
This article will attempt to better explain how BTP works from a technical standpoint, and also take a look at what makes BTP different (and perhaps superior) to other interchain / interoperability solutions.
What is BTP?
At its most basic level, BTP is a mechanism for transferring data between two different blockchains.
But if you’re reading this, you probably know that already.
To get a more detailed understanding of the components that make up BTP, let’s take a look at this excerpt from an overview the ICON Foundation released earlier this year:
Relay (BMR) — passes messages between Message Centers
Message Center Contract (BMC) — Aggregates all BTP messages on a given network
Verifier Contract (BMV) — verifies the messages sent to the Message Center by Relays
Service Contract (BSH) — Holds application-specific logic (i.e. token transfer between networks vs NFT transfer between networks)
Now, unless you’re a blockchain expert, this is probably as clear as mud. So I’ll try to walk through these components, and how they work with one another, a bit more clearly.
Let’s say you want to send 100 ICX to Binance Smart Chain (BSC).
As a user, you’ll interact with what’s called the “Service Contract.” And remember, it’s truly a “contract” — a smart contract — that you’d be interacting with just as you interact with any other smart contract on ICON (or other chains). You probably won’t know you’re interacting with the service contract — it will ultimately have a nice interface where you’d type in how many tokens you want to send and where to send them.
So your first step would be to send 100 ICX to that service contract.
What then happens is that the service contract will lock your ICX within the contract itself. Then the service contract will send a message to the “Message Center Contract.” That message basically says “Hey, this person just locked up 100 ICX.”
As you can imagine, you’re not the only one who wants to send ICX to BSC. So it’s not just a message from your transaction being passed. The message center is truly a “center” that collects all the messages that the service contracts are sending.
So now we have a bunch of messages sitting in the message center. “Jane locked 100 ICX”, “Joe locked 50 ICX”, “Mary locked 500 ICX.”
Remember, just as ICON’s chain has service contracts, a message center contract, and a verifier contract, Binance Smart Chain also has these smart contracts.
This is where the relay comes along. The relay takes a peek at the message center and sees all those messages. It reads them, and carries them over to BSC, and drops them in BSC’s own message center.
Now, here is where some knowledge of cryptography is important.
As you may recall, individuals can serve as relayers, similar to how they can serve as node operators (“P-Reps” in the case of ICON). In theory, a relay could send a “fake” or malicious message, saying “Bob locked 100 ICX”, even if Bob never did such a thing.
That’s where the Verifier Contract comes into play. What the verifier contract will do is analyze the ICON blockchain data (the chain where the message first got sent from) that was forwarded by the Relay. It will make sure that transaction (“Bob locked 100 ICX”) actually happened by verifying the signatures of validators and the consensus process. Put another way, the verifier contract on BSC will conduct the same consensus process that happened on ICON in order to ensure the transaction actually occurred.
If the verifier contract confirms that the transaction actually happened (“Bob did indeed lock 100 ICX!”), it will approve the message. If the verifier contract checks the block chain and doesn’t find consensus that Bob locked 100 ICX, the message gets rejected.
If the message gets accepted, the message center on BSC will send a message to the service contract on BSC, saying “Hey, Bob locked up 100 ICX on ICON. Go ahead and mint 100 BSC-based wrapped ICX tokens.”
If the message is rejected, no tokens get minted.
Now, a couple of notes on this process:
First, keep in mind that BTP charges a 0.2% fee on all cross-chain transactions. So while I mentioned 100 wrapped ICX being minted on BSC, it would technically be 99.8 ICX. If you’ve read my prior breakdown of BTP tokenomics, you know why this fee is important for ICX holders. If you haven’t read it, I encourage you to do so!
More importantly, I want to take a moment to focus on the verifier contract. This is the part of BTP that’s arguably the most important, and also potentially the most unique relative to other interoperability solutions.
By essentially re-creating the consensus mechanism that occurred on the origin chain (in the example above, ICON), the verifier contracts are able to confirm the transaction actually happened. That’s what the ICON Foundation means when they say “BTP is secured entirely through cryptography.”
This is also why ICON says “BTP is as secure with 1 Relay as it would be with 100 Relays. Extra Relays simply ensure more reliability and liveliness.”
Remember, the relays are what passes information from one chain to another. If they’re passing invalid information, the verifier contract will catch that. So having 100 relays doesn’t make BTP more or less secure, because at the end of the day, the verifier contract is what’s making sure the message is valid. And it’s doing that by relying on the consensus process of the underlying chain. In other words, if you trust the underlying security of ICON or BSC (in the above example), then you should trust the security of the BTP connection between the two. If you don’t trust the underlying consensus, then the flaw is with the chain itself, not BTP.
The benefit of multiple relayers is “liveliness” — in other words, making sure someone will be online to pass the message between chains. If there’s only one relayer and they get disconnected from the internet, that’s bad. But if there’s 100 and one goes down, it’s far from the end of the world. That’s why it’s better to have more than less, but having less doesn’t compromise security.
The Interoperability Market
One of the fears I see percolating through the ICON community is the fact that other interoperability solutions already exist.
Rather than going through various other solutions one by one, I’d like to take a broader approach and illustrate some different models and how BTP is different.
Cosmos & Polkadot
What’s important to note about Polkadot and Cosmos is they aren’t actually blockchains, at least in the sense that ICON is a blockchain.
Both Polkadot and Cosmos offer an easily forkable architecture to launch your own blockchain, but do not offer many features themselves.
In more simple terms, these two projects offer a framework, but they don’t support smart contracts themselves. You can’t technically “build” on Polkadot or Cosmos (but you can build on their interconnected chains or launch your own application-specific chain).
The point here is that both Cosmos and Polkadot are more different architectures for a blockchain ecosystem rather than an interoperability solution for other ecosystems.
Most ecosystems have the application layer built in smart contracts on the Layer 1 blockchain (i.e. Balanced built as a contract on ICON), but Cosmos and Polkadot have apps on a separate layer in the form of new blockchains. The form of interoperability they offer is within their own ecosystem (at least at the current stage), while ICON’s BTP is more about connecting different ecosystems with different architectures.
Scott Smiley of ICX Station explains this briefly in an interview he recently conducted with DEFIYIELD.
And this is ultimately where a key distinction is made. Cosmos and Polkadot fall more under the definition of an architecture. In both cases, the architecture is what allows the “network of blockchains” that operate within the Polkadot and Cosmos ecosystems to interoperate with one another.
A potential downside to this approach is that it creates a bit of a “closed” system, where only chains that meet underlying requirements are able to ultimately join the network.
For instance, to operate a parachain on Polkadot, it costs potentially millions of dollars in DOT to prevail in one of the parachain auctions. While the benefits of being part of the Polkadot network are significant, the costs are also high. So while the goal of the Polkadot project is to provide interoperability amongst blockchains, it’s still a bit of a closed garden. (Keep in mind, it’s still possible to connect to Polkadot parachains just like any other blockchain, which is exactly what BTP is doing with Moonriver).
When looking at Cosmos IBC, you also see more of an architecture than a tangible product. Blockchains in the Cosmos ecosystem have the option to add an IBC module, set up their own Relay networks, and build their own bridges using IBC to other IBC enabled networks.
BTP, on the other hand, is more of a product. It’s an “out-of-the-box” solution that is relatively easy to implement on any existing blockchain. BTP is blockchain agnostic, meaning there aren’t really any stringent requirements a blockchain must meet in order to implement BTP. It’s essentially as “easy” as building out the three smart contracts described above (Service Contract, Message Center, and Verifier Contract) on a given chain then adding support for that chain to the existing Relay network.
Now, this may change over the coming years — both Cosmos and Polkadot may make it far easier to integrate into their networks — but for the time being, what’s described above is the current state of affairs.
Is BTP a superior approach? Maybe. Maybe not. But they are definitely different, and each solution likely offers something the other doesn’t in the eyes of the market.
Solana Wormhole & Ren Protocol
Solana’s cross-chain bridge, Wormhole, and Ren Protocol’s RenBridge are a bit more similar to BTP in the sense they can link existing chains, but those chains don’t necessarily have to be within a specific network or ecosystem like Cosmos or Polkadot.
However, while they’re similar in that regard, they remain different in how they’re built and how they operate — especially when it comes to security.
On first glance, Wormhole seems to operate fairly similar to BTP. Wormhole uses a similar “lock and mint” approach, with a verification process sitting between the two chains.
However, instead of transactions being verified at the smart contract layer as they are on BTP, they are instead verified by what are called “Guardians”, which are “operated by a set of node operators that include top Solana validators and other ecosystem stakeholders.” These Guardians are hand-picked in a centralized fashion. Outside users or stakeholders can’t participate in the consensus process, making this a trust-based network.
If 2/3+ of these nodes sign a transaction using their keys, then the transaction is seen as valid. While this solution certainly isn’t insecure, it still at the end of the day requires users to trust that the validators will act in the best interest of the protocol.
RenVM, which helps power the Ren Bridge, is in a similar boat. RenVM has thousands of what are called “darknodes.” Like Wormhole, the darknodes serve as the validators for transactions across the Ren Bridge. Anyone can serve as a dark node, but must deposit 100,000 REN into the Darknode Registry Contract. This deposit incentivizes the darknode operators to refrain from malicious behavior, or else they forfeit their deposit.
While this incentive system sounds good on paper, it could be problematic if, at some point, the dark node deposits become worth far less than the assets secured by RENvm; the nodes will have an incentive to run off with the locked assets. ICON’s BTP does not rely on game theory or slashing of interchain validators, only the security of the source and destination networks.
Once again, while this is a fairly secure approach, it still leaves the verification of bridge transfers in the hands of a trusted 3rd party in a manner where the incentives could skew the wrong way if the scenario described above plays out.
By now you hopefully understand the distinction between what ICON’s BTP approach does compared to Wormhole and Ren, but as a nice summary I am going to quote Scott Smiley from a recent interview he conducted:
“One of the things that I get most excited by is the security aspect of it. So, the way most of these interoperability solutions work currently is some sort of Proof of Authority node system amongst the relays where there needs to be come consensus among relays.
Whether its 2/3+ consensus or a multi-signature wallet, in the end the relays themselves control the minting and burning and locking and unlocking of assets that are being transferred, while in ICON’s BTP, the relays have absolutely no control over any of the smart contracts. They cannot be malicious, even if they colluded. All they can do is fail to deliver messages.
On ICON, relays are a source of liveness, whereas on most other interoperability solutions, relays are a source of security and a source of risk.”
Clearly, other bridge solutions out there are very secure and decentralized, and it is unlikely that a number of nodes would collude in a malicious manner, especially when there may be thousands of them.
So while malicious behavior may be highly unlikely in other interoperability solutions, it’s basically impossible with BTP, because the smart contracts cannot behave maliciously.
And for those who seek to move large amounts of money — especially enterprises — the difference between “highly unlikely” and “impossible” can be a pretty big one.
After all, how many times have we heard that a malicious attack on a blockchain is “highly unlikely” only to see it play out? It’s not zero.
A multitude of options
Hopefully by now you’ve grown to understand why BTP is potentially a superior solution relative to others.
However, let’s assume that might not be the case in the eyes of the market. Or perhaps the other choices out there evolve to become equivalent to BTP from a security or convenience standpoint.
Is that necessarily the end of the world? I don’t think so.
For whatever reason, there’s often a reflexive belief in crypto that only one chain will prevail. Bitcoiners often think everything not Bitcoin will eventually go to zero. Ethereum holders often think that any other smart contract platform will go to zero. Similarly, many think there will ultimately ever be one interoperability solution and all the others will go to zero.
This partly explains why token holders can sometimes be so combative. If you’re worried about a “competitor” sending your token to zero, you’re probably going to try to talk negatively about that project.
But I don’t think that’s quite right for crypto generally nor for interoperability specifically. I ultimately think there will be multiple successful solutions, because the market will demand choices. Just as there are dozens of successful centralized exchanges, there will likely be many options out there for cross chain activity.
Some will try to compete on fees. Some will try to compete on speed. Some will try to compete on security. Some will try to compete on the user experience. Ideally, BTP will compete in all categories. But it’s ultimately difficult to be superior in all categories. Tradeoffs usually exist.
But remember, BTP only needs to do about a 3–6x of Ren’s interchain volume in order to become deflationary.
And before we concluded, I just want to make another key point.
ICON decided to build and launch the ICE blockchain in order to free up transactions on ICON for BTP. There was enough concern that there would be a significant enough amount of BTP transactions that the ICON chain could become too congested in order to ensure application transactions. While it’s hard to tell if this will ever actually be the case, the ICON team presumably felt it was realistic enough to warrant building a sister-chain geared toward application development.
With the phrase “The future is interchain” being used more and more these days, I believe BTP is well positioned to be successful. Being the “best” — however defined — would just be the cherry on top.