ICON 2.0 is a monumental shift for the ICON blockchain and the broader ecosystem. With ICON 2.0 comes a host of new technologies like BTP for interoperability, Java SCORE support, a completely new core blockchain engine, an EVM-compatible sidechain, and more. In this article, we’ll take a look at ICON 2.0 from a technical perspective to see what kind of potential impact it may have on ICON adoption.

Blockchain Transmission Protocol (BTP)

For many ICON community members, BTP is by far the most exciting feature in ICON 2.0. BTP, short for “Blockchain Transmission Protocol”, is ICON’s cross-chain interoperability solution. BTP allows ICON to facilitate the transfer of information between connected blockchains. In practice, BTP will allow users to move tokens, NFTs, messages, and more across BTP-enabled chains. At this time, BTP integrations are being developed on Polkadot, Kusama, Harmony, NEAR, and Binance Smart Chain.

While BTP has a near-limitless amount of use cases, let’s focus on how BTP can be used to extend the functionality of Balanced, a popular DeFi dApp on ICON. Balanced has two core features – minting bnUSD with supplied collateral and trading supported assets with the built-in DEX. At this time, Balanced only supports ICON-native assets like ICX, BALN, and USDS. While there are solutions like Orbit Bridge for cross-chain transfers (this is what IUSDC uses), there currently isn’t a way to perform cross-chain activity to and from ICON in a fully trustless way.

Balanced, the sexiest DeFi dApp in existence, will be even sexier with BTP.
Balanced, the sexiest DeFi dApp in existence, will be even sexier with BTP.

All of this will change once BTP launches. With BTP, Balanced will be able to easily list assets from all supported chains! In other words, I expect to see additional trading pairs like DOT/bnUSD, NEAR/sICX, and ONE/bnUSD in the near future. Furthermore, BTP will allow bnUSD to be backed by multiple collateral types beyond sICX, which reduces the risk profile of bnUSD.

ICON is not the only interoperability-focused project out there. Cosmos, Polkadot, and Solana also offer cross-chain communication. Let’s quickly go over how BTP differs from other interoperability solutions.

ICON vs. Cosmos and Polkadot

On Crypto Twitter, it’s common to see comparisons between Cosmos and ICON whenever the interoperability debate comes up. In reality, direct comparisons between Cosmos and ICON are not productive because they are completely different in nature.

ICON is a smart contract-enabled L1 blockchain with a built-in interoperability solution (BTP), while Cosmos is a network of independent but interoperable blockchains.

On Cosmos, a developer can use the Cosmos SDK (software development kit) to launch a blockchain that uses the Tendermint consensus algorithm. After launching a blockchain with the Cosmos SDK, it can be connected to other Cosmos-based blockchains via the Cosmos Inter-Blockchain Communication Protocol (IBC). In short, Cosmos provides a framework and a suite of tools that allow developers to deploy blockchains that can communicate with other chains within the Cosmos ecosystem.

Polkadot shares many similarities with Cosmos, though there are a few key differences. On Polkadot, developers can deploy parachains, which are “diverse individual layer-1 blockchains” that can communicate with each other via the Polkadot Relay Chain. Similar to Cosmos, Polkadot parachains are designed to communicate with other parachains, though it is possible to develop a parachain to communicate with a chain outside the Polkadot ecosystem (e.g. Ethereum, Avalanche, Solana, etc.).

At this point, I hope the differences between ICON, Cosmos, and Polkadot are more clear. Cosmos and Polkadot provide frameworks, architectures, and tools to build application-layer blockchains that are interoperable within their respective ecosystems. On the other hand, ICON is an application-layer blockchain that can be connected to any other smart contract-enabled blockchain without any framework or consensus algorithm requirements.

ICON vs. Solana Wormhole

Solana’s Wormhole is an interoperability solution that relies on “Guardians” to relay messages across connected chains. Wormhole’s Guardians are comprised of a handpicked subset of Solana validators. By design, Wormhole is a decentralized trust-based system because it assumes a majority of the Guardians will always act in the best interest of the network.

Wormhole is the first of many such cross-chain bridges to come. It uses decentralized cross-chain oracles — called guardians — operated by a set of node operators that include top Solana validators and other ecosystem stakeholders whose incentives are strongly aligned with Solana and Serum. Those guardians certify token lockups and burns on one chain in order to mint new tokens or release tokens on the other, and vice versa.

Unlike Wormhole, ICON’s BTP is not a trust-based solution. BTP messages are communicated across chains by relayers. While Wormhole’s Guardians perform both verification and relaying of messages, BTP’s relayers only relay messages. In ICON’s BTP model, message verification is performed on destination chain by a verification contract that has the ability to “play back” consensus history of the source chain to ensure the relayed message is correct. Thus, ICON’s BTP makes it impossible for relayers to collude as the only job of relayers is to relay messages.

For a more thorough walkthrough of the differences between BTP, Polkadot, Cosmos, Wormhole, and more, I highly recommend reading Iconographer’s BTP guide.

Goloop – A New Blockchain Engine

At the core of ICON 2.0 is Goloop, a new blockchain engine that’s written in Go. Go, also known as Golang, is a compiled programming language that was originally developed by Google for high-performance networking and concurrency. Now let’s walk through why ICON 2.0’s Goloop is a big deal?

ICON 1.0’s “loopchain” blockchain engine was implemented in Python. While Python is one of the world’s most popular programming languages (it’s very easy to pick up), its performance leaves much to be desired – especially for low-latency use cases that benefit from parallel processing across multiple CPU cores or threads.

So, why was ICON 1.0 implemented in Python when there are more performant languages like Golang, Rust, and C++? While I don’t have any insight into the internal decision making process at ICONLOOP, my guess is that it came down to speed of iteration and efficiency. Python is easy to write, which makes it ideal for rapid prototyping and early production deployments.

For example, YouTube and DropBox both started off as Python-heavy applications in their early days. Over the past few years, both companies have rewritten many of their core backend services in Go – this is exactly what ICON is doing with the transition from ICON 1.0 to ICON 2.0.

Python Performance Bottlenecks

Python’s performance bottleneck in a low-latency blockchain context stems from two characteristics of the programming language – its global interpreter lock (GIL) and its interpreted nature.

Simply put, Python’s GIL ensures only one thread can execute code at any given time. Depending on the use case, Python’s GIL can be a huge performance bottleneck. Unlike Python, Go doesn’t have a GIL. Instead, Go offers first-class concurrency support via “goroutines”, which allow code to execute in a truly concurrent and horizontally-scalable manner.

Unlike Python, which is an interpreted scripting language, Go is a compiled language. Programs written in compiled languages, must be compiled before they can be executed. Without getting into the nuts and bolts of computer science, compilation refers to translating a programming language into machine code – the native language of computers. On the other hand, an interpreted language is not compiled, and is instead processed and executed in realtime by an interpreter like Python, JavaScript, or Perl.

To understand the difference between compiled and interpreted languages, imagine you only speak English and you’re trying to communicate with someone who only speaks Japanese. In this analogy, a compiled language would be akin to you learning Japanese so you can communicate directly and efficiently. Meanwhile, an interpreted language would be like you relying on a professional translator to communicate.

ICON 1.0 vs. ICON 2.0 Performance

Since ICON 2.0 is not live on mainnet yet, it’s impossible to say exactly how much faster Goloop will be. Generally speaking, Go can be exponentially faster than Python. In this blog post from Stream.io, they observed a 40x performance boost after switching from Python to Go.

When discussing exponential performance gains in the context of blockchain, it’s important to distinguish between performance and block time. In other words, a 40x performance boost doesn’t mean ICON’s block time is going to drop from 2 seconds to 0.05 seconds. What it does mean is that ICON 2.0 nodes will likely be able to handle more load in the same amount of time. Ultimately, the switch from Python to Go gives the ICON blockchain more throughput and the ability to handle more transactions per block.

Java SCOREs

Another area where Python is being deprecated in ICON 2.0 is SCORE, ICON’s smart contract execution environment. On ICON 1.0, smart contracts were written in Python – again, a great language for rapid prototyping and initial production deployments. Compared to Python, Java offers several advantages. Like Go, Java is also a compiled language, which means Java programs are typically much faster than Python programs.

Another major difference between Python and Java is typing – Python is dynamically typed, while Java is statically typed. In simple terms, Java’s statically-typed nature makes it a safer choice for developing mission-critical applications because errors are caught at compile time instead of at runtime. When it comes to smart contracts, error-free code execution is extremely important!

Practically speaking, Java SCOREs should be a welcome change for developers in the ICON ecosystem. Previously, Python SCOREs had to be manually audited by ICON. Moving forward, Java SCOREs will not be subject to manual audits because they execute within the Java Virtual Machine (JVM), which provides a secure environment for smart contracts to run.

ICE = EVM × eWASM × BTP

Earlier this year, the ICON Foundation revealed ICE, a brand new BTP-enabled blockchain with EVM and eWASM compatability. EVM, short for “Ethereum Virtual Machine”, is Ethereum’s computational layer. It consists of all the primitives required to execute compiled smart contracts written in Solidity – Ethereum’s smart contract programming language.

In the blockchain space, EVM compatability is important because it allows Ethereum dApps to be deployed on other (often faster and cheaper) blockchains. An EVM-compatible chain is one that can execute Solidity smart contracts within a native implementation of the Ethereum Virtual Machine. Aave is an example of a dApp that has been deployed on multiple EVM-compatible blockchains. After starting off on Ethereum, Aave made its way to Polygon, and most recently, Avalanche.

Aave deployed on Avalanche.
Aave deployed on Avalanche.

Without Polygon and Avalanche’s EVM compatability, it would’ve been impossible or economically unfeasible to migrate Aave. To illustrate this point further, imagine the process for migrating Aave to ICON, a blockchain that isn’t EVM-compatible. In order to do this, the Aave smart contracts would have to be completely rewritten in Java, ICON’s smart contract language. This would take considerable resources, and would probably never happen because it’s much easier to just deploy Aave on an EVM-compatible chain.

Just like Polygon and Avalanche, ICE will allow developers to deploy Solidity contracts designed for Ethereum. To make things even better, ICE will likely be BTP-enabled at launch, which means it’ll be the first EVM-compatible blockchain with direct connections to top projects like ICON, Polkadot, Kusama, Binance Smart Chain, NEAR, Harmony, and more. I think ICE’s BTP connectivity will be a huge selling point for developers. Think about it – would you rather deploy to an EVM-compatible chain with no cross-chain integrations, or an EVM-compatible chain with many cross-chain integrations?

So, how will ICE benefit the ICON blockchain? Here are a few potential scenarios that come to mind:

  • ICE governance is handled by the ICX token, and not the ICE token. This means validators on ICE who don’t already hold ICX will need to buy ICX on the open market.
  • ICE allows Ethereum dApps to interact with assets across different chains. For example, an ICE version of Aave could support borrowing and lending of wrapped assets at scale from Polkadot, NEAR, and Harmony. Use cases like this one will drive BTP usage, which benefits ICON.
  • ICE gives ICX holders another strategy to maximize yield. Since ICON and ICE are both proof-of-stake blockchains, ICX holders can reallocate their ICX stake between the two chains in response to market conditions.

Unlike many EVM-compatible blockchains, ICE will also be eWASM-compatible. eWASM, short for “Ethereum WebAssembly”, is a subset of WebAssembly – an open source instruction set for code execution. eWASM will replace the EVM in Ethereum 2.0. Compared to the EVM, eWASM provides a much faster execution environment for smart contracts, along with access to more WebAssembly-based tools for developers.

By including eWASM support from the get-go, ICE will be compatible with dApps designed for Ethereum 2.0 at launch. Combined with ICE’s BTP connectivity, its eWASM compatibility gives it several distinct advantages over other EVM-compatible chains in the space. With this in mind, I predict we’ll see quite a few Ethereum dApps migrate over to ICE because there is very little to lose, and very much to gain in doing so.

Summary

ICON 2.0 isn’t just another blockchain upgrade. For the ICON ecosystem, ICON 2.0 represents the vision highlighted in the original ICON whitepaper – a vision to “hyperconnect the world”. With ICON 2.0 comes a host of technical improvements, so here’s what you should walk away with:

  • BTP is a fully-trustless interoperability solution that connects heterogenous blockchains. Unlike Wormhole, BTP doesn’t rely on trusted validators to verify messages. Unlike Polkadot and Cosmos which focus on their internal ecosystems (Cosmos SDK blockchains and Polkadot parachains), BTP is blockchain-agnostic and works with all public and private blockchains that support smart contracts.
  • Java SCORE is a brand new smart contract execution environment with a focus on performance and safety. It allows developers to write safer code and deploy contracts faster. On the infrastructure side, Java SCOREs should run faster than their Python counterparts.
  • Goloop is a redesigned core blockchain engine with more throughput and concurrency. It lets ICON process more transactions per second, which is important for adoption.
  • ICE is an EVM and eWASM-compatible “application chain” with first-class support for BTP. It lets developers deploy Ethereum dApps and extend their functionality with cross-chain features.

Sir, WAGMI.