ICON, deconstructed

Part II: Blockchain Layers and the Architecture Behind ICON

This is the second part of a 30+ page series designed to provide an overview of ICON’s technology. Remember, 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. Part II has been updated to reflect LFT 2.0, ICON’s next-generation consensus mechanism.

Introduction

In Part I of ICON, deconstructed we outlined some of the basics of ICON Network. This included an introduction to nodes and a brief look into the blockchain layers. In Part II of this series, we’re going to take a deeper dive into those layers and provide an overview of ICON’s architecture. Also, stay tuned for the next part of our series on DPoC throughput, scalability and SCORE.

Blockchain Layers

In Part I of ICON, deconstructed we broke down the blockchain protocol layers into smaller components. To recap: we said 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. Here’s a quick recap on each layer:

• Sybil resistance layer: protects 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. 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.

We also noted that layers are 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).

Lastly, we noted that each of these layers has a specific function, but there’s a great amount of interplay between them.

In the next section, we’re going to use the framework above to compare layers across several different blockchains. We’ll start with Bitcoin and move our way through Ethereum, Cosmos and lastly through ICON. Let’s dive in.

Bitcoin protocol layers

1. Sybil resistance layer

Proof-of-Work (PoW) is a protocol that requires nodes to compete for each block by performing computational work to solve a complex puzzle. The difficulty of producing a block (mining) is stored in the block header, which means that any node can compare the difficulty between two blocks. Naturally, it takes a lot of computational work (and thus resources) to produce a block with a high difficulty.

By extension, producing the block with the highest difficulty would require an enormous amount of computational work. The Bitcoin network is massive and constantly growing, which makes it highly improbable that a malicious entity could gain control of enough computational power to execute an attack due to the sheer cost of doing so.

2. Propagation layer

Bitcoin uses the gossip protocol, a peer-to-peer protocol to ensure that every mining node broadcasts a mined block to other nodes. To see how it works, consider the following example: a node, N1, mines a block and randomly chooses a peer, N2, to share the block information with. Then, N1 and N2 each randomly pick another peer (N3 and N4) to pass along the same information. This continues until all nodes in the network receive the same information.

Note that all types of nodes can participate in the communication process. The biggest advantage of light clients — the ability to propagate the true ledger across a greater distance at a lower cost than full nodes — comes directly from the gossip protocol.

3. Consensus layer

Fundamentally, Nakamoto Consensus is the agreement that Bitcoin nodes will choose the chain of blocks with the highest total difficulty and add it to their local view of the ledger. Nakamoto Consensus inherently relies on the Proof-of-Work (PoW) protocol, and nodes can check which block has the highest difficulty. Nakamoto Consensus is the origin of the “longest chain” rule — the longest chain is recognized as the one with the highest total block difficulty.

A malicious party could hypothetically broadcast blocks from its local view, but there’s no chance they would be added to other nodes’ local views since their difficulty would be much lower than that of blocks produced by large mining pools. Note that Nakamoto Consensus is a static rule, and does not require any communication between nodes.

Ethereum protocol layers

1. Sybil resistance layer

Ethereum also currently uses the PoW protocol to prevent Sybil attacks, although the network is in the process of transitioning to Proof-of-Stake (PoS), another Sybil resistant scheme.

2. Propagation layer

Ethereum uses the same gossip protocol as Bitcoin to communicate block and transaction information between nodes.

3. Consensus layer

Ethereum uses another PoW-based consensus algorithm called Ethash. This protocol functions similarly to Nakamoto Consensus and also makes use of the longest chain rule.

Ethash modifies Nakamoto Consensus by making computational performance a function of how fast a mining machine can move data across different memory locations (as opposed to a machine’s computation speed). The goal is to prevent large mining pools from obtaining significant influence over the network.

Cosmos protocol layers

1. Sybil resistance layer

Cosmos uses Delegated Proof-of-Stake (DPoS) as its Sybil resistance scheme. On a basic level, DPoS replaces external resources (mining machines and energy) with an internal resource (the blockchain’s native cryptocurrency). Nodes have to stake (lock-up) cryptocurrency or receive delegation (votes) for a chance to become block producers and validators. Validators vote on a block, and voting power is determined by the size of the stake.

Thus, acquiring a disproportionately large voting weight and producing many blocks for a Sybil attack is very expensive. The cost of purchasing additional tokens will likely increase, as the market price increases with each purchase. Even if a malicious entity acquires a significant amount of tokens, there’s little incentive for it to undermine a network that it is heavily invested in.

2. Propagation layer

As mentioned before, validator nodes on the Cosmos network vote to approve blocks. That requires all the nodes to communicate block information to each other, to make sure everyone in the network has the same local view. Cosmos uses the same gossip protocol as Ethereum and Bitcoin to accomplish that.

3. Consensus layer

Cosmos uses the Tendermint consensus algorithm to ensure that nodes agree on every block in a round-based system. Each round consists of 4 steps: propose, prevote, precommit, and commit. The last step is contingent on the success of the first three.

Once a block is proposed, ⅔ of the voting power (based on stake size) needs to do prevote the block for it to proceed to the precommit step. Then, another ⅔ of the voting power is needed to move the block to the next step, where it is committed to the blockchain. Both the prevote and precommit steps require each validator to broadcast their vote to the other nodes. It may take more than a single round for a block to get committed.

Comparing application layers

Now that we’ve acquired some understanding of protocol layers in different blockchains, let’s look at their respective application layers.

Bitcoin application layer

Bitcoin’s primary application is P2P (peer-to-peer) transactions, which are enabled by Scrypt, a simple programming language. Bitcoin’s application layer is inseparable from its protocol layer — Bitcoin transactions are impossible without Nakamoto consensus or PoW.

Ethereum application layer

The core features of the Ethereum application layer are the EVM (Ethereum Virtual Machine) and Solidity, a specialized language for smart contracts. The EVM runs on every node in the network and compiles high-level Solidity contract code into machine code. The EVM can be thought of as a decentralized computer containing millions of executable programs, each with its own permanent data storage.

Smart contracts allow for Decentralized Applications (DApps) to exist on the Ethereum blockchain. Another element of the Ethereum application layer are ERC20 cryptocurrencies (like DAI and USD Coin) which can have issuance and economic structures different from Ethereum’s. However, just like with Bitcoin, you can’t separate Ethereum DApps or ERC20 cryptocurrencies from the underlying Ethash consensus.

Cosmos application layer

Cosmos takes a different approach — it decouples the application layer from the protocol layer. One of the key value propositions of Cosmos is blockchain interoperability, which is why this separation makes sense — a network of blockchains needs to accommodate independent blockchains with different functionalities, requirements, and governance structures. Since interoperability is also one of the core principles of ICON, the separation between the protocol and application layers is likewise present in the network.

The need for interoperability arises from the fact that there is no single all-encompassing blockchain protocol for all blockchain applications. To see what this means, let’s consider building a DApp using the blockchain protocols we’ve discussed above.

Bitcoin’s Scrypt is great for enabling simple P2P transactions, but any application that requires a higher degree of logical sophistication would be tough to build. Bitcoin, just like Ethereum, has a slow transaction speed, which means that an application requiring a high volume of transactions would not function well.

Ethereum has been shown to be somewhat vulnerable to errors and security attacks because of the external nature of the EVM. For an application requiring a high degree of security, that would be unacceptable. Furthermore, updating deployed smart contracts in Ethereum is difficult, which makes iterative development harder to accommodate.

However, Cosmos lacks network-wide incentives and governance mechanisms that stimulate the growth and adoption in the broader ecosystem. Recently, one of the validators on the Cosmos Hub proposed changes to address these issues.

Governance is a core principle of ICON, and the network has multiple incentive mechanisms to stimulate development and accelerate growth. Nonetheless, ICON has many shortcomings of its own that we’ll discuss later. Before that, let’s take a closer look at the blockchain layers in ICON.

The blockchain architecture behind ICON

Public and private blockchains on the ICON network use a proprietary consensus algorithm called Loop Fault Tolerance (LFT). LFT was developed for the loopchain engine, which powers both the ICON public chain and ICONLOOP private chains. The fact that LFT has been used to provide high-performance solutions to enterprise clients in Korea speaks volumes about the algorithm’s efficiency, scalability, and reliability.

LFT is Byzantine Fault-Tolerant and uses Delegated-Proof-of-Contribution (DPoC) for Sybil resistance. Let’s unpack what these terms mean.

Byzantine fault tolerance (BFT)

In distributed computing systems, Byzantine fault tolerance (BFT) refers to the network’s ability to tolerate machines (validator nodes) failing in unpredictable ways. Two conventional assumptions that follow from this concept are that (1) the failure is due to nodes being malicious and (2) no more than ⅔ of the nodes are malicious at any given time.

You remember from our discussion of the Cosmos consensus layer that Tendermint requires ⅔ of the total voting power on the network to commit a block. Tendermint and LFT are both BFT consensus algorithms, which is why the ⅔ majority is important in both protocols.

Delegated-Proof-of-Contribution (DPoC)

Delegated-Proof-of-Contribution, a modified version of Proof-of-Stake, offers two key advantages over PoS:

1. It also relies on staking for Sybil resistance, but token holders stake to elect delegates who validate blocks on their behalf, instead of voting on the validity of the blocks themselves.
2. It provides unique incentives for early adopters and token holders who actively engage with the community and contribute to the growth of the ICON ecosystem.

We’ll return to DPoC later when we delve into ICON’s governance structure. For now, let’s go back to LFT consensus and see how it works in detail.

How LFT consensus works

As a refresher, recall that the primary function of a consensus algorithm is to ensure state invariance across nodes in a network after a transaction is completed. LFT defines how nodes on the ICON network agree on the next block to be added to the blockchain. Let’s refresh a few topics first.

P-Reps

We learned earlier that the full nodes that produce blocks and verify transactions are called P-Reps (Public Representatives) on the ICON Network. Initially, we have 100 P-Reps, and each of them receives a reward proportional to the number of votes they receive. 1 vote is equal to 1 ICX, the native cryptocurrency of ICON.

The top 22 P-Reps (Main P-Reps) serve as validators, receiving block rewards as an incentive to continue securing the network. The other P-Reps (Sub P-Reps) function as non-validator full nodes, storing a copy of the ledger and stepping up to replace the Main P-Rep if necessary. LFT aggregates votes from the Main P-Reps to determine the next correct block.

Sybil Resistance

DPoC is an extension of PoS, and it utilizes a similar Sybil resistance logic to its predecessor. For a malicious entity to gain sufficient control of the network to cause harm, it would need to (1) obtain a very large amount of ICX, (2) get enough votes to be elected as a P-Rep, and (3) stake their ICX.

Attacking the ICON network would almost invariably crash the value of ICX, thus destroying the entity’s initial investment. So it is assumed that no rational actor would be willing to face such a loss, thus the probability of a Sybil attack is very low.

Consensus LFT 1.0

There are two types of nodes in most BFT consensus algorithms: a “leader” that creates and broadcasts a block, and a “validator” that votes on the block and verifies other nodes’ votes. Like Tendermint, LFT consensus runs on a round-based system.

Before we go into more detail on LFT consensus, let’s talk about the concept height — a non-unique block identifier.

If you visualize the blockchain as a vertical stack with blocks layered on top of each other, each block will be at a different distance, or height, from the genesis block at the foundation (the genesis block has a height of zero).

Height is a non-unique identifier — while each block will have a specific and invariant height, a certain block height does not always identify a single block. Two blocks competing for the same spot in the stack (a scenario that could lead to a blockchain fork) would have the same height until one of the blocks is rejected via a consensus algorithm.

LFT resembles Tendermint with its two-vote broadcast steps (prevote and precommit) but reduces the block data verification to a single vote broadcast. Each round consists of 3 steps: propose, vote, and commit.

1. Before the consensus process begins, the validator nodes communicate transactions to the leader node.
2. The leader node creates a block from collected transactions and embeds its digital signature in it. In the propose step, the leader broadcasts the created block to all validators.
3. In the vote step, validators verify the block by looking at three things: (1) the leader’s digital signature is correct, (2) the height of the block and the hash of the previous block are correct, and (3) the transaction data itself is valid. If all three criteria are met, validators propagate their consensus vote data to all other nodes in the network.
4. A new leader node replaces the previous leader.
5. Once the new leader receives vote data from more than ⅔ of the voting weight (remember, total voting power is not distributed evenly across validators), it commits the block by adding it to its local view of the blockchain and creating a new block with the consensus vote data embedded in it. Validators confirm the block by updating their local view and incrementing block height when they vote to verify the new block.

Since the previous block is committed at the same time as the new block is proposed, LFT can be seen as having 2.5 steps instead of 3. Combining the propose and commit steps eliminates the need to transmit data after counting the consensus votes to allow validators to verify that a ⅔ majority was attained.

It might take more than a single round to add a block to the blockchain for a given height. This scenario could result from:

• The leader node misses the window to propose a block, or a significant number of validators are offline and the ⅔ consensus is not reached. ICON has a built-in penalty system that punishes such negligent behavior by stripping validators off their block production rights for some time or burning a fraction of their delegated ICX.
• The block broadcast by the leader node is invalid and more than ⅓ of the validators propagate a null vote on the block.

LFT 2.0

Our next-generation consensus mechanism, LFT 2.0, also resembles Tendermint with its two-vote broadcast steps (prevote and precommit), and still reduces the block data verification to a single vote broadcast. Each round consists of 2 steps: propose and vote. LFT 2.0 uses something called a pipelined consensus where each block is committed when a connected block vote is completed.

Below is an infographic describing the process by which one block is committed in LFT 2.0. It’s a bit technical but we’ll try to break it down into simpler terms.

• B: Block ID
• V(N, B’, B): Vote(Node Number, Candidate Block ID, Target Block ID)
• C(N, B’, B): Candidate(Node Number, Previous Candidate Block ID, Candidate Block ID)

The stages can be differentiated by Round or the block height. Here is a summary of the events that take place for each stage:

Propose

• As a new Round gets started, theProposeTimer is reset and starts running. The Leader gets replaced by the next node in line that will create a new block.
• The new Leader generates a block of new height which contains the information of transactions and the votes of Candidate Block.
• The Leader sends the new block and its digital signature to other Validators.

Vote

• Validators receive the new block generated by the Leader.
• Validators check whether the delivered block is generated by a valid Leader.
• Validators check whether the block height and the hash of the previous block written in the delivered block are valid.
• Validators check whether the delivered block is connected to Candidate Block.
• Validators make a vote message according to the results of the tests above and send it to Node Set.

Candidate

• A Node Set gets vote messages from Node Set except itself.
• When Node Set gets more than enough votes to meet a quorum but consensus is not reached, VoteTimer starts running and it follows VoteTimer.
• Candidate Block information is not included in the next block and only each node knows it.

Commit

• When Node Set gets the same V(N, B’, B) votes enough to form a quorum, it Commits the block B’.
• It enters the Propose stage in the next Round

That’s a brief overview of LFT 2.0. In the coming weeks, we’ll have even more information about LFT 2.0 and its advantages.

ICON propagation layer

LFT consensus relies on round-based block and vote broadcasts between validators. ICON uses the gossip protocol to get all the nodes up to speed. It’s important to note that light clients and non-validator full nodes can also participate in the propagation process.

We’ve seen how LFT differs from Tendermint because it has a reduced number of steps required to achieve consensus. Let’s look at some of the other differences between the two protocols.

Finality

While LFT and Tendermint vary in some regards, both of them are BFT consensus algorithms, and thus they differ significantly from PoW-based Nakamoto Consensus and Ethash. One key difference is each class of protocols interprets the meaning of “finality.” Remember that finality is the guarantee that blocks are irreversible once added to the blockchain, and a lack of finality can lead to transaction reversals and double-spending.

One issue with PoW-based consensus algorithms is that the gossip protocol is not instantaneous and thus there exists the possibility that disparate geographic regions of the network may receive competing blocks of the same height that claim to have solved the current puzzle. This would cause a temporary fork as different regions choose to build upon different chains of blocks; eventually, one branch will grow longer than the other.

Thus, blocks within PoW-based chains have a chance of being reverted, and the Bitcoin whitepaper suggests waiting for 6 blocks to ensure that a transaction will not be discarded. On the other hand, in BFT-based chains, blocks are guaranteed to be irreversible as soon as validators successfully vote to commit the block. ICON and Cosmos are thus said to be “deterministic” blockchains, while Bitcoin and Ethereum are called “probabilistic.”

Now that we have a good understanding of how consensus works on the ICON network and how it differs from other protocols, let’s take a look at the application layer.

ICON application layer

The ICON application layer is heavily tied in with one of the network’s core principles — governance. Earlier, we defined governance as the structure that determines how participants in a network can interact with each other. That is a rather broad definition, so let’s examine some concrete initiatives that ICON is building towards.

As one might infer from its name, the Delegated-Proof-of-Contribution protocol emphasizes distributing rewards based on relative contribution. The measurement of contributions and distribution of rewards on the ICON network is regulated by a system called IISS (The ICON Incentives Scoring System).

IISS is much more than a measurement mechanism; it serves as an ICON-funded incubator that provides “grants” to entities looking to build on or expand the ICON network. These grants are funded through a decentralized funding design called the contribution proposal system.

All of these activities require a high transaction throughput and a solid technical framework behind the scenes. So in the next part of our series, we’ll take a look at some of these technical advantages that the ICON network confers.

Your Partner in Blockchain,

ICX Station