ICON's Progress with Interoperability & Comparison to PolkaDot

General Discussion
1

This is to address the following tweet regarding ICON’s progress on interoperability and the comparison to PolkaDot.

“The reasons i started to follow ICON was interoperability. 3 years later there is very little or nothing done about it. Now when I think interoperability I think Polkadot. I really don’t know what have you been doing for 3 years. Icon is by far my biggest disappointment.” - link

Interoperability
Interoperability was also one of the main reasons I got involved in ICON many years ago. I could see why you think this way without having the knowledge or explanation that I now have, so I hope after reading this everything makes more sense.

ICON’s original vision was (and still is) to act as connector between several different private blockchains. Enterprise blockchain adoption itself moves slowly, so for the first stages of ICON’s development it made more sense to focus on “operability” before “interoperability” → meaning lets get our blockchain stable and decentralized, then we can focus on bridging other networks.

These days, the necessity of interoperability is growing with DeFi use cases, creating immutable data for private chains, etc. The work on BTP never stopped and is now complete. The reason you are not seeing it live on the ICON Network currently is because of our decision to prioritize the migration to ICON 2.0 as detailed here. ICON 2.0 will launch with BTP already live with the purpose of doing public chain to public chain interoperability allowing for ICON’s DeFi products to utilize coins from other networks.

BTP itself is actually quite exciting, and as ICON 2.0 gets closer to launch we’ll be sure to promote it more. Unlike every other interoperability protocol I have seen, BTP does not require any trust of the Relayer and there is no game theory necessary. Everything is verifiable and secured via the BTP smart contracts. Relayers can’t collude to steal money, and this is unique among decentralized interoperability solutions that I have seen.

PolkaDot
First thing to point out is that PolkaDot did it’s ICO over 3 years ago in October 2017 (hard to find reliable info), but they chose to release their token just recently and it was listed on Binance in August 2020. ICON released an ERC20 token soon after ICO, so it creates the appearance that we have been around much longer even though we started at around the same time. PolkaDot did not do this, and all investors were locked in for years until the main net was complete.

Narrative is important, and I will never argue with that. PolkaDot certainly has a strong share of the interoperability narrative and many projects are building Parachains. But it’s actually a bit misunderstood by many. PolkaDot has an entirely different architecture compared to typical blockchains. PolkaDot does not have smart contracts , but instead, application specific blockchains that all connect to the base PolkaDot chain. This means you will never see something like ICONbet built on PolkaDot, it would be built as a parachain or parathread that connects to PolkaDot. So if ICONbet were “on PolkaDot”, technically it would be an example of interoperability because ICONbet would be its own chain that would stamp their tx data on the PolkaDot main chain. Most Dapps will be their own chain using PolkaDot’s architecture, while on ICON, DApps build smart contracts rather than their own blockchain. It’s just a different architecture. In terms of connecting to other public/private blockchains that are not parachains / parathreads, PolkaDot is not working in this direction afaik.

11 Likes
2

For what it’s worth, one of my hometown neighbors and friends is on the core PolkaDot team. His name is Chris Hutchinson, and you can find him here: Hutch. He’s a great guy and helped me demo our token for our business that runs on Icon. In any case, he’s expressed interest in working together on something bridging Icon and Polkadot together in the past. It’s worth noting that these are two vastly different projects with different ideas but the same goals of interoperability. We’ve talked about it at length and Polkadot and Icon are not competitors.

Keywords and buzzwords aside, I think Icon is more interesting to be honest.

8 Likes
3

@BennyOptions_LL can you enlighten me how application specific channels instead of normal Dapps can be good for ICON and ICX as ICON Foundation encourages future Dapps to launch application specific channels.
Will those channels be exactly similar to the ones like “kava and band” on cosmos or is there an entirely different infrastructure
(if you have any reading on Icon 2.0 that is not the introducing medium article to Icon 2.0 I’ll take it)
Thanks

1 Like
4

The plan for application specific channel chains would be to have the channel chains stamp data onto ICON. Channel chains would have less nodes, so they could be faster but less secure. So if they need to revert back to a certain block because of a lack of consensus, they could call the most recent block data from the ICON chain. Every channel chain would be stamping data on ICON and paying transaction fees to do so.

Having said that, the need for channel chains is a bit far away imo, as for the time being we have plenty of capacity on the main chain. It was shared in the blog post to show the community and readers that scalability is being planned for, though I’d say there’s no need to prioritize it.

3 Likes