Loopchain: Multi-Channel Smart Contract Support Blockchain · 2018-06-06 · 1.2Process of Smart...
Transcript of Loopchain: Multi-Channel Smart Contract Support Blockchain · 2018-06-06 · 1.2Process of Smart...
Loopchain: Multi-Channel Smart Contract Support Blockchain
Ⅰ. 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