Principle and design goals

Technology implementation

Consensus mechanism

Background
Bitcoin, the first service to implement blockchain, has achieved the consensus of all bitcoin nodes transaction ledger in a network of a global scale using algorithm of Proof of Work34. However, the algorithm of Proof of work used in Bitcoin experienced difficulties under the circumstances requiring efficiency and spontaneity of payment due to low processing speed, inefficient energy usage, and partial network split.
To resolve this type of the problem, we started to use BFT (Byzantine Fault Tolerance)series consensus algorithm mainly used for a traditional state machine replication. For data consensus, BFT series consensus algorithms (famous for PBFT (Practical Byzantine Fault Tolerance)  ), make consensus by voting for validation of data and sharing the results. Tendermint announced blockchain consensus algorithm that modified PBFT algorithm into DPOS (Delegated Proof Of Stake). In addition, IBM Fabric, a private blockchain project for enterprise, chose PBFT as a consensus algorithm in version 0.6. and attempted to utilize SBFT (Simple Byzantine Fault Tolerance) that simplified PBFT as a consensus algorithm for Orderer service in version 1.0.
LFT (Loop Fault Tolerance)
LFT is a traditional BFT consensus algorithm that improved Raft algorithm, one of the State machine replication algorithms that is often used as Fault Tolerance mechanism in the current distributed environment, to be Byzantine Fault Tolerant and optimize itself to the nature of blockchain network. 

The object that organizes the blockchain network is called node. These nodes are responsible for generation, validation, retention of blocks and each node can create a signature that can distinguish its own message. Most of the networks using consensus BFT series algorithms can be divided into leader nodes and validation nodes. Leader nodes vote for validation of a block by verifying the contents that leader has made. LFT can be also divided into leader nodes and validation nodes.
In the initial stage of the network, verification nodes transfer the transactions that need to be executed to the leader node. The leader node then creates a block from collected transactions and transfers the block to all the other verification nodes with its own signature. When each verification node receives the block, they 1) confirm the creation of the block, 2) check if the block level and the prior block hash are correct, and 3) validate the block data. If step 1 to 3 are correct, ‘vote data’ is generated and shared to all nodes. It is important to transmit vote data to every node. If leader node is Byzantine, it is possible to separate certain nodes from the network by transmitting blocks only to the nodes that is above the quorum. To prohibit this sort of problem, vote data is transmitted to every node. A node without any block can know if the block is created or not and also request the block to the others.
To create blocks, leader receives vote data from nodes more than quorum. Leader creates new blocks with vote data and transmits to every node. This saves the need to transmit every data once again to guarantee that nodes more than the quorum have finished the same vote. It also allows to confirm the block by verifying the vote of new blocks. If transmitted block is not the initial one, validated node performs verification of vote data more than quorum when verifying blocks. This is when every node final commits prior blocks.
The blockchain is a technique for nodes without trust to construct a trust network through distributed data agreement. Not every state machine guarantees a response like the current state machine replication system. Each node provides a service and creates a transaction. Leader nodes can reject a transaction of a specific node when a block is created. To minimize this problem, Spinning40 was used to reduce the number of service faults that could be caused by the Byzantine leader by replacing the leader for every block creation. In addition, we have developed a method to directly tolerate a fault handler by avoiding the complicated leader fault tolerance algorithm used in existing algorithms such as Tangora.
LFT is a distributed consensus algorithm for permissioned blockchain. We improved the existing BFT algorithm for the blockchain and simplified the process using block data. Details of the consensus process can be found in LFT white paper. 

Accounts and transactions

Smart contract system

SCORE indicates Smart Contract provided from loopchain. SCORE ensures a high-performance since it runs directly in real runtime but not a separate VM. It is executed on a runtime based on a container separated from basic blockchain process, so the basic blockchain process can still function properly even if there is problem with Smart Contract.
One of the key characteristics of SCORE is the repository based versioning features. 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.
It provides a local repository by default for SCORE distribution, and developers can easily deploy and update Smart Contracts by using a remote repository called SCORE Store.

 

Cryptography

Distributed storage protocol

Cross-chain and exchange technology

Special technology

Economic model and incentive

Incentives
Transaction fees of ICX transaction and other types of transactions from different channels are stored in Public Treasury of Nexus together with ICX, which is steadily generated by Reserve channel.
ICX stored in Public Treasury is exchanged for bonds of nodes participating in Nexus and distributed to the respective nodes. The limit of the bond depends on how much the node has contributed to invigorate the ICON Network. A scoring system called IISS (ICON Incentives Scoring System) is applied here with a variety of criteria: the node’s 1) frozen ICX, 2) C-Rep status, 3) ICX exchange volume, 4) ICX exchange volume of the whole community if it has one, 5) ICX volume traded through DEX if it has one, and so on. Scoring model calculated according to these standards of IISS will be consistently updated to invigorate the ICON Network to the maximum on the basis of A.I. prediction model.

According to IISS, the more actively the nodes participate in the ICON Network, the more ICX they can secure.
Nodes participating in Reserve channel can use the acquired ICX as the basis for business such as banking. One can issue bonds of higher limit based on ICX transaction volume and the ICX secured by enlisting customers in a variety of deposit products, and then secure more ICX based on the relevant bonds to pay for interests on the deposits.

A variety of services, in addition to banking, can be operated through DAPPs of Public channel. Besides making profit from charging fees on the services, one can also benefit from securing ICX allocated by IISS, which may activate a variety of services. One can also receive predefined incentives in ICX after participating in Representation channel to conduct proposal and cast vote.  

Governance mechanism

Applications