In this section, my goal is to explain the architecture of the ICON blockchain network, and many of its technical features, (hopefully) in a manner that anyone with a fundamental understanding of blockchain technology can understand.

Of course, if you have not yet done so, please be sure to check out Chapter 1, Chapter 2, and Chapter 3 of this series before diving into this one!

Loopchain

To understand the technical backbone of the entire ICON infrastructure, first we need to understand what loopchain is.

Loopchain is the enterprise blockchain that was created by ICONLOOP (formerly theloop) in order to provide customized blockchain solutions to entities — whether they are companies, governments, non-profits, or consortiums. It’s important to understand what loopchain is, as it not only operates the private blockchains built by ICONLOOP, but it’s alsothe technology that the ICON public chain is built upon.

Here is a description of loopchain in the ICON Whitepaper:

“Since [a] majority of industries have different operational requirements and governance structures, an enterprise blockchain with flexible features is necessary to accommodate such diverse needs. This idea was the start of loopchain. Loopchain is a high-performance enterprise blockchain with Smart Contract features that can be customized according to operational needs and linked with other distributed ledger networks.”

Let’s say you have two different entities: One is an insurance company, the other is a hospital. They both want to develop a blockchain that they can utilize internally for managing records and other information. However, as you can imagine, the needs, requirements, and processes for a hospital are different than an insurance company. Each can decide to use loopchain, but can tweak how exactly it operates, as well as it’s governance model in order to serve their unique needs.

So what exactly makes loopchain unique? The ICON Whitepaper identifies 4 key areas:

LFT Consensus Algorithm

According to the whitepaper, “LFT (Loop Fault Tolerance) is an enhanced BFT (Byzantine Fault Tolerance)-based algorithm that promotes faster consensus and ensures the finality of the consensus without the possibility of forks within the network.”

This may be complete gibberish to you. That’s okay!

In layman’s terms, loopchain has created a unique technical process for verifying information on the blockchain (consensus).

To be clear, here is a good description of consensus within the context of blockchains:

“Whenever a new transaction gets broadcasted to the network, nodes have the option to include that transaction to their copy of their ledger or to ignore it. When the majority of the actors which comprise the network decide on a single state, consensus is achieved.”

There are a number of ways you can conduct this process. The process that loopchain utilizes is called “Loop Fault Tolerance.” To gain a more in-depth technical breakdown of how this complex process works, you can do so by reading section 4.3 on the ICON Whitepaper. At this point, just know that the process used to achieve consensus within not only loopchain but the entire network is LFT, which is proprietary to ICONLOOP.

SCORE (Smart Contract On Reliable Environment)

First, let’s go back to the description of what a smart contract is as presented in Chapter 1 of this series:

“Smart contract is just a phrase used to describe a computer code that can facilitate the exchange of money, content, property, shares, or anything of value. When running on the blockchain a smart contract becomes like a self-operating computer program that automatically executes when specific conditions are met. Because smart contracts run on the blockchain, they run exactly as programmed without any possibility of censorship, downtime, fraud or third-party interference.”

For the purposes of understanding this component of loopchain, let’s look at a very basic description of how a smart contract blockchain works.

Ultimately, if we view blockchain as a “distributed ledger,” a smart contract system at a basic level has two ledgers.

One ledger tracks transactions: “Bob sent Jim $5.”

The other ledger tracks the smart contracts, and serves as a sort of repository: “If X condition is met, Bob must send Jim $5.”

The bitcoin blockchain only tracks transactions, meaning it does not have smart contract capability. Ethereum is able to track both the transactions, and the “database” of contracts, making it capable of executing smart contracts tied to transactions.

Like Ethereum, loopchain also has the ability to store and execute smart contract data. What makes loopchain’s SCORE system unique is that:

  1. it functions in a more independent manner, “so the basic blockchain process can still function properly even if there is a problem with Smart Contract,” according to the whitepaper.
  2. “Generally, when a Smart Contract is updated, data migration is required. However, with our versioning capability, Smart Contract does not require data migration with every update. This means that Smart Contract update process is easy and quick.” In other words, it’s faster with less friction.
  3. Developers are free to utilize SCORE with several different programming languages, whereas Ethereum is far more limited in this regard. So it’s ultimately more accessible for developers to build on.

For a more in depth breakdown from a technical standpoint of SCORE, please check out this blog post by ICONLOOP.

Multi-Channel

According to Speculative Rationality (this article will refer back to the Speculative Rationality article several times), “The multi-channel feature enables a blockchain network to consist of independent channels that can in a contained manner execute requests, consensus and Smart Contracts within the network without having to establish a separate ledger.”

We are going to go into further detail regarding how this is constructed further down, but the most simple way to describe this is that loopchain’s blockchain is able to handle a number of different process that technically occur separately, but are important for the harmony of the entire network.

Tiered System

According to the ICON whitepaper:

“Apart from the initial authentication process to participate in a blockchain network, each transaction is validated and secured through PKI-based authentication. loopchain can also set different access privileges to create nodes with specific functions (e.g. audit, supervision) to monitor certain transactions, if necessary, without participating in the actual transaction.”

At its most basic level, this means that the hospital’s blockchain can be customized in order to set different permission levels for interaction within their own blockchain. Theoretically, this would ensure that one department has certain privileges that another department may not have, or vice versa.

Summary

If you’ve read the first chapters of this series, you’re aware that ICONLOOP is a company that develops private blockchains for entities to utilize. However, simply saying they “build blockchains” is overly simple.

ICONLOOP has created its own proprietary blockchain technology, that it’s able to tweak to meet the specific needs of the end user. An analogy would be that they’ve ultimately created a blockchain operating system, such as Windows, with unique features that can be customized to fit the needs of the operator.

And what makes it unique?

  1. A proprietary mechanism for achieving consensus in an efficient manner that protects and enhances the blockchain’s transactions and history (LFT).
  2. An architecture for the implementation of smart contracts that is more efficient, faster, and can be utilized with more programming languages (SCORE).
  3. A multi-channel design that allows for multiple activities at once.
  4. The ability to customize who can access the blockchain and how they can interact with it.

While there are other features that make loopchain unique, these are the key 4 that the ICON whitepaper chose to focus on.

So why did I just spend so much time focusing on loopchain? Not only is loopchain the technology that underpins the blockchain systems for private companies and other entities, but it’s the same technology that will power the ICON Public ledger — meaning the ICON Network as we know it will utilize these same capabilities and runs on the same technical engine.

Here is a quote from CEO of ICONLOOP and ICON Council Member Jonghyup Kim:

“Currently, most, if not all of ICON’s development resources are dedicated to building out ICON’s public chain, and as ICONLOOP is built on the same blockchain engine, just a few additional developers are required for customization of private blockchain implementations.”

The hospital’s blockchain system built with loopchain is a “mini-ICON” with the technical ability to easily connect with the “big-ICON.” That means that the blockchains that LOOPCHAIN has been building for the past several years for companies, industries, and governments will have very little trouble connecting to the ICON Public chain when the time comes.

So let’s take a look at just how that process will play out on a technical level.

ICON Republic

There are a number of moving technical pieces involved in a system this complex. Accordingly, I will take a moment to describe them, and then try to explain how they interact together. In order to do so, I am going to utilize the analogy that was included in Chapter 1 of this series, so please keep it in the back of your mind as you continue to read:

“Imagine a student at a university requires surgery. On the day of her operation, she checks into the hospital. In doing so, she presents her digital identity — recorded on blockchain via ICON — and provides permission to the hospital to share her medical records, stored on the hospital’s blockchain, with her insurance company. Now, the insurance company can immediately — and automatically — process the claim, since the records are tamper-proof on the blockchain and do not require an additional party to verify them. Just through this process alone, we’ve reduced time (the process is virtually instant), resources (no paperwork to fax or mail), and labor cost (by eliminating the need for a 3rd party).”

To make it flow a bit easier, let’s give the student in this example a name: Ashley.

Community

In a practical sense, a “community” within the ICON world could be a collection of hospitals, banks, or schools. This is not simply theoretical, as ICONLOOP has deployed loopchain technology in the following communities:

Capital Markets

“Their first project launches in September, allowing a consortium of securities brokerages to share client identification directly with each other on the blockchain so that their clients can open new accounts easily between the brokerages and skip the “know-your-customer” process.”

Hospitals

“Korea University Hospital is also applying the blockchain technology to help with data integrity, a cross-border digital signing system, and a health coin. Its first project, in cooperation with the government and other hospitals, is a cloud-based precision medicine hospital information system that will help with synchronizing databases between hospitals, according to Sangheon Lee, a professor at the hospital.”

Universities

“Meanwhile, Korea’s top-tier Sogang University is using the blockchain to create a university currency for students to pay through QR codes for the first time in Korea at on-campus stores, shopping malls and vending machines, as well as lending to classmates and paying tuition, and it is expected to benefit students overseas.”

(Source: Forbes)

Based on how these have been described in the Forbes article and other areas, these entities will share a blockchain among themselves. For instance, when Ashley checks into the hospital (Hospital A) for her surgery, they are able to pull her medical records from her prior hospital from her hometown (Hospital B). Both hospitals would be utilizing the same intra-community blockchain network developed with loopchain, and they would be considered part of the same “community” in the context of the ICON Network.

C-Node

First, let’s make sure we have a basic definition of “node.” Here is a helpful definition from the LISK Academy:

“A node can be any active electronic device, including a computer, phone or even a printer, as long as it is connected to the internet and as such has an IP address. The role of a node is to support the network by maintaining a copy of a blockchain and, in some cases, to process transactions.
Nodes are the individual parts of the larger data structure that is a blockchain. As the owners of nodes willingly contribute their computing resources to store and validate transactions they have the chance to collect the transaction fees and earn a reward in the underlying cryptocurrency for doing so.”

Within the context of the ICON Network, a C-Node “is the building block of a Community that affects the consensus or decision-making process of Community governance,” according to the whitepaper.

For instance, in our community of hospitals described immediately above, each hospital (let’s pretend there are 10) can function as a C-Node. The 10 C-Nodes work together to operate and govern the blockchain network that the hospital community operates on.

C-Rep

According to the whitepaper, “C-Rep (Community Representative) is a representative unit of Community and a unit that comprises ICON Republic governance at the same time. It has the right to vote on transaction verifications and its governance in ICON Republic. C-Rep is selected according to the decision of each community, and C-Rep can be changed from one node to another. In other words, C-Reps are subject to change depending on the situation and purpose of each governance. Furthermore, C-Rep will receive incentives for its maintenance and activation of ICON Republic.”

In simplified terms, the C-Rep, which can be operated by a single individual, a group of individuals, or an entire hospital, serves as a “portal” between the “mini-ICON” network that the community runs on, and the “big-ICON” public network. Circling back to our example, let’s say among the community of hospitals, “Hospital A” is chosen by the other 9 to serve as the C-Rep for the hospital community.

This means Hospital A’s node is in charge of verifying the transactions being sent to and from the “mini-ICON” hospital network to the “big-ICON” public network. It also has a vote when it comes to governance decisions of the “big-ICON” network as it relates to how communities are governed.

Nexus / ICON Republic

The ICON Nexus is essentially the primary mechanism that serves to “hyperconnect” other blockchains; however, it’s structure is a bit more nuanced than that, so let’s break down what the Nexus is, as well as what makes it (slightly) distinct from the ICON Republic.

Let’s look at the exact definition of the term “nexus”:

“a connection or series of connections linking two or more things.”

That’s exactly what the ICON Nexus does. ICON calls this nexus the “ICON Republic.”

So let’s look at the definition of “republic:”

“a government in which supreme power resides in a body of citizens entitled to vote and is exercised by elected officers and representatives responsible to them and governing according to law”

Moving forward, the simplest way to understand the distinction between the ICON Nexus and the ICON Republic is that the ICON Nexus describes the technology that ICON utilizes to connect blockchain communities, and ICON Republic refers to the conceptual connection between those communities, especially as it relates to governance.

The ICON Republic is comprised of the C-Reps described in the section above. That means the C-Rep for the hospitals is connected to the ICON Republic. So is the C-Rep for insurance companies. So is the C-Rep for universities. As the whitepaper describes, “Governance of ICON Republic is determined by the consensus of C-Reps, with the scope of governance limited to ICON Republic.”

To understand how all this works, let’s take a visual approach.

Imagine a large, one-story building that is designed as a loop. This is the nexus. Now, surrounding the nexus are several smaller loop-shaped buildings, each with hallways connecting to the nexus. One of these smaller buildings could be labeled “Hospitals,” another “Insurance,” and another as “Universities.”

Remember our friend Ashley from the example described above? Let’s take the step where she gives permission to the hospital to share her medical records with the insurance company.

In the Hospital “building,” her records are carried to the door of the hallway connecting to the nexus. Standing at the door is a metaphorical individual with a computer. This is the C-Rep. They review the information, verify it, and allow it to pass through the door.

The medical records travel into the larger loop building, where they move down the hallway until the insurance company is reached. Another individual is standing at that door — the C-Rep for the insurance community. They, too, review the information to verify it and allow it into the insurance building.

Meanwhile, every once in a while, the C-Reps gather together to vote on decisions that have to be addressed involving the network. This is when they function as the ICON Republic.

Easy enough?

Well it does get a bit more complicated.

Remember the section above where I mentioned the “multi-channel” features of the loopchain technology? Remember, the ICON Nexus is part of the loopchain architecture, so the multi-channel element is featured here too.

So what exactly are the channels?

Pretend that larger-loop building isn’t just one giant hallway, but rather multiple hallways running adjacent to one another. They are labeled as:

1. Representation Channel

2. Public Treasury

3. Notary Channel

4. Public Channel

Let’s examine closer what each of those does.

Representation Channel

This is the “hallway” where decisions about governance are made, as described above. This is where the C-Reps “meet” to decide such issues. Here is how it’s described in the whitepaper: “in a Representation channel, one can manage node policies regarding node addition and removal in Nexus, adjust ICX transaction fee, manage node selection and removal.”

How much say in these decisions does each community C-Rep have? Again, the whitepaper: “The voting rights are distributed to the community based on I_score, which is the contribution level of corresponding community towards the invigoration of ICON Network.”

We will go into the details of I_score at a different time, but for now just know it is a mechanism for objectively determining the level of contribution being made to the network based on community size and transaction scale.

Public Treasury

According to the whitepaper, “Any ICX newly issued, as well as ICX allocated to be distributed as transaction fees, is first held in the Public Treasury. The Public Treasury is the account from which Incentives are distributed. Any ICX not allocated or distributed to a particular party due to reasons including but not limited to the elimination of incumbent C-Reps will be held in the Public Treasury and held as source of incentives to be distributed at a later date.”

Imagine this hallway as simply holding piles of currency— in this case, ICX — like a vault, to be distributed to participating nodes as an incentive for validating transactions, as described in the whitepaper: “the transaction fees generated from transactions will be distributed only to those who have contributed directly. As a result, a direct incentive to participate in the transaction is generated and the incentives are given out stably.” Like the voting rights described above, the amount of ICX to be distributed is calculated based on I_score.

Notary Channel

Earlier on, I referenced how, once information left the “hospitals” building, it passed through the nexus to reach the “insurance” building.

In that case, the information needs to travel through the notary channel. To better understand just how this happens, let’s again refer to Speculative Rationality:

“A research institute from a Research Institute Community wishes to access the historical records of a Hospital that belongs to a Hospitals Community.
The elected C-Nodes within the research Institute Community who have voting rights to the notary channel will authenticate the request before registering it to be processed with the notary channel.
The light clients representing each of the blockchains on the Nexus certify the registered blocks according to the LFT Consensus algorithm. Once two thirds or more of the signatures on the block are verified, the block is transmitted to the Hospitals Community through the portal.
The Hospitals Community blockchain verifies the transaction block according to the PKI system, to validate the certification issued by the light clients. The transaction is processed, and the Hospital records requested by the research institute are released.”

In other (and simpler) terms, the Notary Channel is, to a certain degree, the “master blockchain” that validates and stores the history of transactions between different communities, and allows them to pass between one another.

Public Channel

Let’s imagine this hallway is the one closest to the outer walls of our large loop building, but with a front door that anyone can walk through.

In this case, those that can utilize the public channel include:

  • Anyone making ICX transactions (if you’ve sent ICX to someone, you’ve used the public channel)
  • Creating dApps (decentralized applications)
  • Using dApps

If you walk through the door of the public channel, you become a “citizen node.” Unfortunately, as explained in the whitepaper, a citizen node “does not hold rights to verify transactions or vote on governance issues. Only allowed to generate new transactions.” However, a “Citizen Node can also be a C-Rep with voting rights if certain conditions are met.” While the whitepaper doesn’t specify how, Speculative Rationality hypothesizes that, as an example, “the provider of a Medical Data Exchange DAPP stakes ICX to gain permission to act as representative for those using his/her DAPP.”

Now that we’ve described the entire Nexus, here’s what it would look like within the context of our building analogy:


Summary

So let’s take another look at Ashley’s experience, but this time we’ll incorporate what we know about what actually happens “under the hood.” Here is that example typed out again:

“Imagine a student at a university requires surgery. On the day of her operation, she checks into the hospital. In doing so, she presents her digital identity — recorded on blockchain via ICON — and provides permission to the hospital to share her medical records, stored on the hospital’s blockchain, with her insurance company. Now, the insurance company can immediately — and automatically — process the claim, since the records are tamper-proof on the blockchain and do not require an additional party to verify them.”

Ashley walks into Hospital A, in the same city where she is attending university. Upon doing so, she gives permission for Hospital A to access her records from Hospital B, where she grew up. Within the “Hospital” community blockchain, powered by loopchain, the C-Node from Hospital A verifies the transaction releasing her information (utilizing the Loop Fault Tolerance mechanism for achieving consensus), and the C-Node from Hospital B verifies her identifying information on their blockchain, and sends over her records, using the same process.

Following her surgery, she gives permission for Hospital A to share her information with her insurance company, which is part of the Insurance Community. In order to do so, her information will need to travel within the ICON Nexus to reach the Insurance Community, which will then pass the information to her insurance company.

As she grants permission to share her records, the C-Rep for the Hospital Community verifies the transaction, allowing it to enter the Notary Channel of the ICON Nexus, where the information is verified and stored within the nexus blockchain (again, using LTF), before being passed to the C-Rep for the insurance community, who also verifies the information before handing it to the C-Node of her insurance company.

As this process occurs, ICX transaction fees are paid into the public treasury, where they are held until the next round of distribution to C-Reps, who receive an amount commensurate with their overall contribution to the network, as calculated by their I_score.

Meanwhile, in order to prescribe the correct post-surgery medication, Ashley’s doctor utilizes a medical data exchange dApp built on the Public Channel that facilitates the exchange of information among medical professionals belonging to the hospital community. With this dApp, a medical professional anywhere in the world is able to have equal access to information better informing their decisions while data privacy is protected from public access. (Note: I borrowed this particular analogy from Speculative Rationality.)

Before Ashley leaves the hospital, she pays her bill with Ethereum. However, since the hospital’s payment to her insurance company is settled in ICX, the DEX automatically converts her Ethereum into ICX based on the conversion rate at the time.

When Ashley gets home, she tells her family how the surgery was more expensive than anticipated. Feeling generous, they send her some ICX to help reimburse her, which arrives in a matter of seconds. In doing so, they’ve participated in the Public Channel of the ICON Nexus as a Citizen Node.

Conclusion

First, we have the unique, innovative characteristics of loopchain, the enterprise blockchain that ICONLOOP used to build blockchain networks for consortiums in healthcare, insurance, capital markets, and elsewhere, including ChainID.

Meanwhile, we also have the ICON Nexus, built on loopchain technology, that serves as the public blockchain that will hyperconnect ICONLOOP Blockchains who have identified use cases that makes it worthwhile to utilize the public chain.

To summarize more clearly, here is a helpful paragraph in Speculative Rationality:

“The strength of its real-world partnerships places the ICON project in a truly rarified sphere within the blockchain landscape. The breadth and scope of the ICON network can be a little difficult to grasp to begin with. It may be useful to define some of the central players first. ICON itself may best be thought of as the public ledger iteration of loopchain (a proprietary blockchain technology developed by “theloop”) and is stewarded by The ICON foundation established in Switzerland. There are two chief technology partners for ICON — “theloop” which provides the blockchain technology and “DAVinci” which will leverage artificial intelligence tech and big data analysis to optimise the function of the ICON network.”

One of the criticisms thrown about most often in the blockchain universe is that a given project “has no working product.” Indeed, this is a criticism that has been levied at ICON as well.

I would argue, however, that loopchain technology is the working product. It’s been working for a while, as it’s what ChainID was built on, and we know ChainID — built by ICONLOOP using loopchain — works well enough to have received approval from Korean regulators. We know the technology — and the product works as a private product; there’s little doubt in my mind it will function just as well as a public chain.

In a subsequent chapter, we’ll dig deeper into the connection between the ICON Public chain and ICONLOOP chains, but from a business perspective.

In the meantime, the next chapter will focus on the ICX token and how it will function within the ICON ecosystem.