POA based Side-Chain Architecture

POA based Side-Chain Architecture
2018.07
presented by Lambda256

INDEX
About Lambda256
Current Issue & Approaches
Reference Model
PoA Consensus
Inter-chain Architecture
Lambda Chain

Copyrightⓒ 2018. Lambda256. All rights reserved
About Lambda256 (Dunamu Blockchain Lab)01.
Research and development of BaaS 2.0 that can solve various
problems of existing block chain platform and provide total
solution for commercialization of block chain
Build the global BaaS 2.0
platform
Developing blockchain tech
company & cultivating it globally
Support economy model for
crypto currency

Current Issue & Approaches
 Requirements of DApp
• Support for millions of users
• High performance
 Sequential execution
 Parallel execution
• Great user experience
 Free for use (No Gas payment)
 Easy to access and use
• Easy Upgradable
 But,
• High transaction cost
• Low performance (10~20 TPS)
• Long block confirmation time
02.

Approaches
 How to solve it
1. Wait until Ethereum solves the scalability problem
• PoS (Casper), Sharding , Plasma, Raiden
2. Believe another blockchain platform’s whitepaper
3. Create a new blockchain platform from scratch
4. Develop new side chain based blockchain platform
5. …

What approach in Lambda256
Lambda256 developed the PoA based side-chain, main-chain, and
BaaS platform.
Today ,
It will be covered how to build PoA based high performance side-
chain and how to connect it to Ethereum based main-chain for high
trust and reliability.

Reference Model
 Consensus Algorithm
 POA (Proof of Authority)
03.
...
A
B
C
D
A
B
C
D
A
B
C
No. 2320
No. 2321
No. 2322
No. 2323
No. 2324
No. 2325
No. 2326

Reference Model
 Inter-Chain Architecture
 Multi-Sig Bridge

PoA Consensus
 What is POA (Proof of Authority)
 Utilizing the authority of miner for block consensus
• Every proposed block is signed with miner’s private key.
• Every propagated block is verified using signature. (If the signer is not known, given block is ignored)
 Authority governance
• The way to manage correct signer list in network.
• On-chain vote (add/remove signer)
• Vote threshold (i.e., 50%)
• Regulations and penalties useful to sustain the network
04.

Clique
 POA implementation of Go-Ethereum
 Rinkeby PoA testnet
https://www.rinkeby.io

Clique Consensus Engine
...
What happens if the node in turn
becomes unavailable?
No: 738
DF: 2
TD: 1476
No: 739
DF: 2
TD: 1478
No: 740
DF: 2
TD: 1480
No: 741
DF: 2
TD: 1482
No: 742
DF: 2
TD: 1484
genesis
network failure!
I was
too late..
No: 743
DF: 1
TD: 1485
State
DB
Clique
vote-
snapshot
No: 743
DF: 1
TD: 1485
It was
my turn..
It was
lucky!
On-Chain Vote
Signer[0]
Signer[1]
Signer[2]
Authority Governance
Newcomer
738 % 3 = 0
739 % 3 = 1
740 % 3 = 2
Block
Number % Total
Signers = Target
Index

Signers in POA
 Signer is an entity which has the authority to propose and verify the block.
 Signer owned node can participate to POA network as a miner and it is called as
authority node.
 Block proposal is only possible by authority node. (That is, any blocks proposed by
non-authority node are ignored.)
 Addresses of initial signers are written to Genesis block.
 Afterward, signer list is maintained in the memory and disk by Clique Engine of each
authority node.
 Signer list can be changed by the real time on-chain vote.

Example: Genesis.json

Block Proposal
 In Clique, is block proposal based on contention between authority nodes?
• Theoretically, Yes.
• But, practically in normal condition it doesn’t. (It runs in the turn based mode, which gives block
generation opportunities to every authority nodes evenly)
 In Clique, block proposer is determined by modular operation with block number.
(i.e., 190,000th % 5 = 0th )
• But, any authority node who is not in its turn can make block and propose block to
network. (So, it is possible that many side blocks are proposed and propagated to
network)
(*) To charge more penalty to authority node who is not in its turn,
it waits for more wiggle time in addition to the delta time which is the remaining time until the block period.
 select additional wait time randomly from following time window. [0, ((N. / 2) + 1) * wiggleTime(500ms)]

Block Consensus (Sealing / Verify-Seal)
 Sealing
 Adding signer’s signature into “Extra” field.
 Difficulty “2” is assigned to header of block proposed by authority node in its turn.
 For authority node not in its turn, Difficulty “1” is assigned.
 Verify Seal
 Verify signer’s signature in “Extra” field, check “Difficulty” field, and execute “Spam
Protection check”.

Signature for POA
 POA is totally based on the signature of block proposer.
• Every block header includes signature of authority node.  Blue box in figure
(1) 65 bytes-length (compact ECDSA)
• Digest of signature is header’s hash value of 32 bytes-length
(2) not including extra-seal area in Extra field
extra vanity
(32 bytes)
extra seal
(65 bytes)
extra vanity
(32 bytes)
signer list
(variable-length: 20 bytes * N)
extra seal
(65 bytes)
Extra field
(Normal block)
Extra field
(Checkpoint block)

Block (Normal Block)
 Non 30,000th block
 It can include Cast-Vote information. (i.e., `Coinbase`, `Nonce`)
 Signer list is maintained in “on-chain vote consensus snapshot” by applying cast-
vote.
 Snapshot includes following information:
① List of signers who has been known to have the authority.
② List of signers who has mined block recently. (N / 2 + 1)
③ History of cast-vote for each signers.
④ Tally of vote.
extra vanity
(32 bytes)
extra seal
(65 bytes)

Block (Checkpoint Block)
 30,000th block.
 It does not include cast-vote information.
 Checkpoint block is a special block used to terminate current epoch and start a new
epoch by verifying and resetting any information like follows.
① Verifies entire signer list in “Extra” field.  Yellow box in figure
② Reset “history of cast-vote for each signers” and “tally of vote”.
extra vanity
(32 bytes)
signer list
(variable-length: 20 bytes * N)
extra seal
(65 bytes)

On-Chain Vote (Proposal)
 In Clique, following JSON RPC operations are provided to support on-chain vote.
(1) Registering Cast-Vote
(2) Deregistering Cast-Vote
(3) Listing registered Cast-Votes
 Once Cast-Vote proposal is registered, it is included in normal block.
• “Coinbase” field: Miner address which will be added/dropped
• “Nonce” field: Symbol for add/drop. (Add: 0xffff… / Drop: 0x0000…)

On-Chain Vote (Consensus)
• Miner received new block from network can determine whether received block
contains Cast-Vote information or not by checking `Coinbase` and `Nonce` field.
• The propagated vote proposal is reflected to the in-memory signer list as soon as
each receiving node counts the votes in real time and tally of vote is reaches the
majority.

Example: (Block including Cast-Vote)

Block Spam Protection
 Definition:
• This is a function that prevents further block generation and propagation until "(N / 2) + 1" blocks
have elapsed since the last block was generated.
 Purpose:
• To prevent the nodes in the list from continuously generating and propagating blocks.

vs ETHASH (PoW)
 No block reward
 No uncle calculation & compensation
 No hashimoto, No DAG, No mixed-digest

Possibility of POA freezing
 Symptom:
 If more than half of nodes are in failure state, all remaining nodes can not generate additional block
and become wait state. As a result, whole POA network is stopped.
 Cause:
 "Block Spam Protection" function which suppresses the block generation for a certain period. (i.e.,
until (N / 2) + 1 additional block is generated)
 What would happen if miner’s private key is lost ?
• Block proposal and consensus of the POA chain may be stopped.
(It is possible when such an account loss occurs on multiple nodes)
• If an unrecoverable H / W failure occurs during POA chain operation or operator accidentally
deletes a node instance, the keystore containing the signer's private key information is also lost.

Experiment Environments
 S/W requirements
 OS: Ubuntu 16.04 LTS
 Go-Lang: 1.10.3
 Go-Ethereum: v1.8.11 (stable)
 Web3.js: v1.0 (websocket provider)
 Node.js: v8.11.3
 H/W requirements
 AWS EC2
 Miner-node: 12*EA (c5.4xlarge)
 Tx-node: 12*EA (c5.4xlarge)
 Go-Ethereum configurations
 Block time: 1sec
 Block sync mode: fullsync
 Block gas limit: 0x6422C40
 Max transactions per block: 2,000 (src
fixed)

Experiment Result
Scenario Configurations Result
Threshold Performance Test
Repeated ether transfer between users.
Execution time: 30min
VU: 12 EA
Think time: 2ms
TPS: 2,000 TPS
Aging Test
Repeated ether transfer between users for 24
hours.
Execution time: 24h
VU: 12 EA
Think time: 5ms
TPS: 1,500+ TPS
Failover/Failback Test
Disabling randomly selected nodes up to “2/N +
1”. Then, enable nodes again.
Execution time: 10min
VU: 12 EA
Think time: 10ms
OK

Experiment Result
12 miners, 12 agents, 2ms

Inter-Chain Architecture (Multi-Sig Bridge)
 Bridge is an entity which connects two chains and relays assets or values between
them.
 Generally, bridge assumes that two chains are running same block chain protocol.
(i.e., Ethereum based chain  bridge  Ethereum based chain)
 If not, translator needs to be adapted.
 In Ethereum based chains, bridge can be implemented easily using contract.
 Staking/Redeem  SimpleToken
 Deposit/Withdraw  Parity Bridge
 Above reference models designed DApp to deploy two contracts in both chains.
05.

Bridge Architecture Example: Parity-Bridge

Lambda Chain
 What is Lambda Chain ?
Cloud VPC based security and performance assured
chain solution for BaaS platform.
 What does the Lambda Chain
provide ?
Provisioned high performance
High availability & scalability
Fast block confirmation time
Easy to use
(sign-up, sign-in, and Tx with MSISDN/PIN)
No-Gas fee
Easy integration of token economy for DApp
06.
UDC 2018, September

POA based Side-Chain Architecture

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to POA based Side-Chain Architecture

Similar to POA based Side-Chain Architecture (20)

More from Luniverse Dunamu

More from Luniverse Dunamu (13)

Recently uploaded

Recently uploaded (20)

POA based Side-Chain Architecture