ICON, deconstructed

ICX_Station
Hello ICON World
Published in
9 min readFeb 19, 2020

Part I: What is ICON?

This is the first part of a 30+ page series designed to provide an overview of ICON’s technology. The goal for this series is two-fold. First, we want to write this series in a way that’s easy to understand for beginners exploring our project for the first time. But, additionally, we also want to provide enough depth that it can be enjoyed by more advanced blockchain enthusiasts. We’ll be releasing each part in smaller segments, so please let us know if you have feedback as we can make adjustments to the releases as we go. We hope you enjoy!

Introduction

The crypto industry, young as it may be, has already gone through several generations of evolution. The first generation was ushered in by the Bitcoin launch in 2009, followed by the rise of simple altcoins. At that point, the main focus of crypto seemed to be on creating a frictionless network of P2P payments.

The next great advance in the industry was Ethereum, arriving in 2015. Ethereum introduced the smart contract — a tool that automates transactions based on validated triggers. Smart contracts allow for far greater complexity to exist on the blockchain.

The current generation of blockchains is comprised of a diverse set of projects that offer performance enhancements over the previous generation. Scalability and interoperability have been some of the defining buzzwords of this new wave, and a significant reason why the ICON project garnered so much attention when it launched in late 2017.

ICON has a vision of building a digital nation known as the ICON Republic, where heterogeneous communities with differing economic, social and governance ideals can interact seamlessly over the ICON network utilizing the Blockchain Transmission Protocol (“BTP”). Bridging communities allows for value and information to be shared seamlessly across the network, thus empowering the next evolution of digital transformation.

We’re now almost 2.5 years on from the 2017 ICO, and while a lot of material has been published since then on the business aspects of ICON, the technical side of the project hasn’t quite received the level of attention it deserves.

For that reason, let’s deconstruct ICON and take a closer look at how it compares to other projects across the blockchain space.

What is ICON?

Here’s how ICON defines itself:

The ICON Project aims to build a decentralized network that allows independent blockchains with different governances to transact with one another without intermediaries.

This definition allows us to identify the three main principles that underlie the ICON network: decentralization, interoperability, and governance.

  • Decentralization is defined as the transfer of authority from a single entity to a network of participants. Decentralization allows for autonomous governance of the ICON network, which is essential if this network comprises multiple “independent blockchains.”
  • Interoperability refers to how the network allows these independent blockchains to communicate with each other. ICON’s capacity for interoperability makes it an interchain.
  • Governance is the structure that regulates how participants in a network can interact with each other. Without a sound governance system, ICON’s competencies of decentralization and interoperability would be rendered useless as the network would fail to sustain itself and expand.

While these principles of decentralization, interoperability, and governance, are important and valid on their own, it is their convergence that makes ICON stand out. Let’s take a closer look at each of them.

Decentralization

The endgame for the ICON project is a decentralized network of independent blockchains. To better understand what that means, let’s start by revisiting some blockchains basics.

Blockchain revisited

You’ve probably encountered a definition that goes like this: “a blockchain is a distributed, decentralized, public ledger.” This definition is a little confusing, and also depends on how exactly one defines terms like “distributed” and “public ledger.”

Instead, let’s consider another way to describe blockchain. Blockchain is a distributed database that is replicated among the peers (nodes) of a network. A fundamental conclusion that flows from this definition is that every node on a blockchain network stores the same exact data or state.

A consensus algorithm is what allows nodes to agree on the state of the blockchain. Different blockchains use different consensus algorithms, each with their own strengths and weaknesses.

Bitcoin and Ethereum are both blockchains — networks of nodes that reach consensus, leading to the creation of blocks. ICON, like Cosmos and Polkadot, is an interchain. ICON calls itself the “Network of Blockchains” while Cosmos goes with the “Internet of Blockchains,” but the idea is the same. Both are large networks comprised of smaller networks, each with their own nodes and governance.

Decentralized Blockchains

We’ve covered the difference between blockchains and interchains, but we haven’t touched decentralization yet. What exactly does it mean for blockchain to be decentralized?

As it turns out, this question has no easy answer since the definition of “decentralization” itself is quite fluid, as Vitalik Buterin remarks in his article on the subject. One way to “measure” the extent to which a blockchain is decentralized is to look at who controls the nodes.

Remember, nodes are essentially computers on the blockchain network that participate in a consensus algorithm to enable the creation of a new block. Thus, if there was a single entity in control of a significantly higher number of nodes than anyone else, it would be hard to call that blockchain decentralized. The number of nodes on the network is likewise a valid indicator of decentralization.

This figure illustrates a Sybil attack — a network disruption caused by a malicious entity controlling the majority of the nodes. Centralized networks with a small number of nodes are typically more vulnerable to Sybil attacks.

NEO and Ripple are two examples of blockchains that are mostly centralized. On the other hand, Bitcoin, Ethereum, and Cosmos are all decentralized blockchains, with many independent entities controlling the nodes.

ICON is a decentralized network consisting of 22 Main P-Reps and 78 Sub P-Reps. Main P-Reps are responsible for producing blocks and verifying transactions. Every person who holds ICX can delegate their vote to P-Reps to help secure the network.

Before delving deeper into governance on the ICON Network, let’s discuss the types of nodes in greater detail.

Nodes on the ICON Network

At a fundamental level, there are two types of nodes on a blockchain network: full nodes (in the ICON network, we call them peer nodes) and light clients. Full nodes store the full state of the blockchain. But what exactly does that mean?

Full Nodes

Remember that we defined blockchain as a distributed database that is replicated among the peers (nodes) of a network. This database itself is a chain of blocks, where each block contains a block header and all the transactions stored in it.

The architecture of the distributed ledger is a rather complicated subject on its own, and you can explore it further here. The important thing to know is that block headers contain a hash, or encryption, of the previous block’s header and a Merkle Root, which is a fingerprint of all the transaction data stored in that block. If a tiny bit of transaction data changes, the Merkle Root will change as well.

Full nodes store all state, including block headers and transactions. Most nodes don’t need to store the entire state of the blockchain, which is why the role of full nodes is usually reserved for validators — P-Reps on the ICON network.

Main P-Reps are full nodes that verify blocks and participate in consensus, thus serving as validators in the ecosystem. Sub P-Reps also function as non-validator full nodes, adding to the security of the network and stepping up to replace a Main P-Rep if needed.

Light Clients

Light clients only store the block headers from the genesis block to the most recent one. They do not participate in consensus or store transaction data. Light clients use the Merkle Roots in block headers to verify the authenticity of transaction data.

Since they don’t store the full state of the blockchain, light clients require significantly less storage and than full nodes — in fact, light clients can sometimes run on mobile devices. Light clients will be really important once we get into interoperability on the ICON network.

Citizen nodes

Another type of node on the ICON network is the citizen node. Citizen nodes don’t participate in block generation, but synchronize block data and relay transaction requests to the full nodes. Citizen nodes are typically used by DApps and exchanges on ICON Network allowing full nodes to focus on consensus, producing and validating blocks.

Now, let’s explore ICON’s blockchain layer structure and how it differs from other blockchains.

A primer on blockchain layers

So far, we’ve taken a look at the role of nodes on a blockchain network and discussed the structure of the distributed ledger. All public blockchains have validator nodes, and they generally utilize the ledger structure described in the previous section (with minor adjustments).

To compare one blockchain project with another, it helps to decompose its blockchain into separate layers. The most basic distinction can be drawn between the protocol and application layers of a blockchain.

This distinction is best understood by looking at the Internet, where the protocol layer consists of protocols like HTTP and TCP/IP, while the application layer represents user-facing platforms like Google, Facebook, and Netflix. The application layer can also be viewed from a more general perspective (e.g. search engines, social media, video streaming).

The protocol layer for blockchains represents the underlying frameworks and mechanisms that enable communication between nodes and guarantee consensus. The application layer is different for each blockchain. The diagram below shows the application layer for Bitcoin, which is a network for peer-to-peer (P2P) transactions.

The protocol layer in Internet technologies can be further decomposed into a set of specialized protocols — the Internet Protocol (IP) underlies the Transmission Control Protocol (TCP), which sits below the HyperText Transfer Protocol (HTTP).

Similarly, the blockchain protocol layer can be broken down into smaller components. There’s no conventional standard for this decomposition, but one way to think about the protocol layer is by dividing it into consensus, propagation, and Sybil resistance layers.

  • Sybil resistance layer: provides protection from a Sybil attack — an attempt by a single malicious entity to prevent finality on the network by gaining an overwhelmingly large influence. Finality is the guarantee that all well-formed blocks are irreversible once added to the ledger. A lack of finality can lead to transaction reversals and double-spending.
  • Propagation layer: defines how the state (blocks and transactions) are communicated between nodes in the network.
  • Consensus layer: ensures that nodes can agree on the state of the network, which means that the local view of the ledger for each node is the same. This layer also defines the rules for adding new blocks to the ledger.

Each of these layers has a specific function, but there’s a great amount of interplay between them.

In the next part of our series, we’ll apply this protocol layer decomposition to Bitcoin, Ethereum, and Cosmos. And also discuss ICON’s composition in greater detail.

Your Partner in Blockchain,

ICX Station

--

--