Loopchain: Multi-Channel Smart Contract Support Blockchain

Jay Parkjayhpark@icon.foundation

Ⅰ. BlockchainII. loopchainIII. Multi-ChannelIV. Challenges

Contents

Ⅰ. Blockchain Basic

Life cycle of a transaction: from request to completion

1.1 Process of blockchain I. Blockchain

Transaction Broadcast

Transaction Request

Transaction Completion

A new block is added to the existing blockchain(permanent, immutable)

Blockchain Expansion

Transaction validation & approval among several nodes

Consensus

Verified transactions are combined to create a new block

Block Creation

Cryptocurrency, contracts, records

Nodes

A digitalized business algorithm: once transformed to a programming, it can be automatically executed without human interference to meet a predefined condition

1.2 Process of Smart contract I. Blockchain

More Trust (than centralized legacy system)

Lower Cost (because of eliminating middlemen)

Agreement Trigger & Execution Consensus

After the specific contract agreed by both parties is met, digitalized business logic will be automatically triggered and executed without human interference.

Finalize the result of execution of contract through consensus between both parties

A BSmart contract

A

Data

B BA

Data

Data

SQL ▶ Smart ContractServerless Application which automatically executes a contract based on the ledger

6

1.3 Blockchain Application Architecture

Blockchain

API

Ledger/State Database

Tokens(user defined

token: ERC-20)

CryptoCurrencies(base coin)

Smart Contract(business logic)

Ledger DB Ledger DB State DB State DB

Application

Legacy SystemAppWeb Off-Chain

Side-Chain

IPFS(decentralized and distributed

filesystem)

Oracle(trusted source of information)

Plasma(child chains

with their own validator)

Lightning/Raiden(payment channels)

DApp(Decentralized Application) requires both on-chain and off-chain service

I. Blockchain

II. loopchain

Ledger Database and State Database are separated in one peer for efficiency and distributed among several ones for effectiveness.

2.1 loopchain as a Distributed Ledger : Distributed Database II. loopchain

loopchain peer

Ledger

Database

Block 3Block 2Block 1

State DB State DB State DB State DB

TX

TX

TX

TX

TX

TX

TX

TX

TX

Counterfeit Proof of Transaction and Block

Speed Up (finalization of a block requires only one confirm)

1 Confirm

Self-developed Smart Contract for complex service scenarios(for example, issue certificate in blockchain without CA)

2.2 loopchain Smart Contract : SCORE Smart Contract On Reliable Environment II. loopchain

Separate blockchain core and container runtime(smart contract) for stability

Instead of VM, support native execution for performance

SCORE Store

Smart Contract registration, distribution, version management

SCORE local repository

Block storage

loopchain peer

SCORE Container

SCORESCORE Storage

2.3 loopchain Overall Architecture II. loopchain

SCORE Store

Homogeneous Components Easy of Administration and Operation

Administration Business Operation

Query

Node

BlockNetworkEngine

SCORE Engine

ConsensusEngine

State

Proxy

Legacy system

Result

Smart contract Query Result(State)

Administration

Log data

SCORE business logic #2

SCORE business logic #1

RSRadio Station

APMApplication Performance Management

Membership(Node) Management

ElasticSearch

Kibana

Logstash

2.4 loopchain Data flow diagram II. loopchain

Validation NodeBlock

TX

State

SCORE

Block

TX

State

SCORE

Blockchain Nodes

Application

WAS Business logic DBMS

TX

Legacy system

TX

StateQuery

distribution

distribution

voting

votingLeader(Creation) Node

Validation Node

votingBlock

TX

State

SCORE

Block

TX

State

III. Multi-Channel

13

Smart Contract Executionoverhead

3.1 Bottleneck of blockchain performance III. Multi-Channel

Too many Txs

Nodes A

Data

B

Data

Consensus Overhead

TPS(Transaction Per Second) comparison

2000~3000

5~7

15~100 60000~70000 queries

cf)

14

3.2 Solution(1) III. Multi-Channel

Scale Up: vertical scaling

Scale Out: horizontal scaling

Fewer, Large server (add more CPUs, RAMs, and HDDs in one server)

More, small server (add more servers to the server farm)

15

3.3 Solution(2)

And Scale Out in the Software

III. Multi-Channel

A

Data

B

Data

E

Data

F

Data

A

Data

C

Data

A

Data

B

Data

A

Data

C

Data

E

Data

F

Data

Serialization(execute one by one) Parallelization(execute group by group)

16

3.4 Raiden Network III. Multi-Channel

Off-chain scaling solution for performing ERC-20 token transfers on the Ethereumcf) Bitcoin’s Lightning Network(low-fee, scalable, privacy preserving payment)

Micro Payment channel technology

Tx

Block Pros:• Speed: No consensus, No confirmation• Low Fee: especially a few dollars or even a

cent• Scalability: linear scaling with # of users• Privacy: private transfer(off-chain)

Cons:• Token locked up: during the lifetime of the

payment channel• Token only - We need Smart Contract!

17

3.5 Plasma III. Multi-Channel

Off-chain scaling solution for performing fast smart contract on the Ethereumcf) Bitcoin’s Segregated Witness (SegWit) (eliminates unnecessary data in smart contrac

Child blockchains are attached to the main blockchain

Pros:• Speed: delegation of complex

operations to children• Low Fee: dependent on only small

block producers• Resource: elimination unnecessary

data to save CPU power and storage• Scalability: distribution of data

storage

Cons:• Too many “exit transaction”: hard

pressure on the main blockchain to process enormous final Txs from child blockchains

18

3.6 Sharding III. Multi-Channel

Root

Shard 1

Shard 1-a

Shard 1-b

Shard 1-c

Shard 2

Shard 3

Horizontal Partitioning of datacf) scale-out

• Tx data are divided and distributed into multiple servers performance

• Total number of Tx data per storage is reduced scalability

• Considerations:• Sharding rule

• Static vs Dynamic• Rebalancing

• expansion or reduction• dynamic rule

Virtual Blockchain system: Tx, consensus, and Smart Contract Execution for different business purposes

3.7 expandability of loopchain : Multi-Channel III. Multi-Channel

Virtualization: Single peer, Multi Blockchain easier deployment

Access control: isolation per channel more secure

Channel Manager

Channel A Channel B

Transaction SCORE Transaction SCORE

Channel A Channel B

loopchain peer

20

2-a. update separately

SCORE ch.n

SCORE ch.2

ICX ch.n

ICX ch.2

SCORE ch.1

ICX ch.1

sharding by #addr

Each SCORE states is independent of each other so introduce Multi-Channel.

Dapp A

Dapp B

Dapp C

Dapp D

hx...01 hx...11 hx...21 hx...31 ...

1.checked as ‘updating’

2-b.wait until updating ends

3.8 Multi-Channel and SCORE III. Multi-Channel

ICX

SCORE

Shard + Multi-Channel: ICX is base coin for ICON - all the SCORE depend on ICX so introduce not Multi-Channel but Shard.

21

SCORE ch.n

SCORE ch.2

SCORE ch.1Dapp A

Dapp B

Dapp C

Dapp D

3.9 Multi-Channel and Routing

Which Dapp?

hx1234...

address Dapp Channel

hx1234 A 1

hx2134 B 1

hx3145 C 2

hx4234 D n

Answer: routing table

III. Multi-Channel

Routing mechanism: address translation using a dynamic routing table to find out the target channel

22

Performance(theoretically): TPS * # of channel

3.10 Multi-Channel and Performance III. Multi-Channel

https://insights.sei.cmu.edu/sei_blog/2017/08/multicore-processing.html

job partitioning to leverage the modern multi-core architecture

I/O bound task• Network• Disk

CPU bound task Concurrency• Smart Contract Execution• Hash Calculation

IV. Challenges

BTP(Blockchain Transmission Protocol): interchain protocol between Nexus and other Blockchain.

4.1 BTP IV. Challenges

• Notary channel is based on the Multi-Channel service

• Tx issued by transmitter blockchain is transferred to receiver blockchain via Notary channel

• Nexus check the agreed Tx via Light Client connected to the Nexus

Blockchain A Blockchain B

Blockchain B

Nexus Node

Node

Node

Node

Blockchain A Nexuslight client A

light client A

light client A

lightclient A

Nexuslightclient B

light client B

light client B

light client B

Comments

25

4.2 Multi-Channel interchain(1) IV. Challenges

SCORE ch.n

SCORE ch.2

SCORE ch.1Dapp A

Dapp B

Dapp C

Dapp D

Question: What if Dapp A calls DappC?Answer: Access Denied.

Notice: each channel is isolated from other channels!

SCORE ch.1Dapp A

Dapp BSCORE ch.2Dapp

Cinterchain

Solution:

No free lunch: the disadvantages of advantages in Multi-Channel

26

4.3 Multi-Channel interchain(2) IV. Challenges

Quiz: Difficult problem to solve: Smart Contract calling between blockchains or channels How about query function to request a state?

Hint: query is not Tx.

Thank you