1 of 41

CodeChain Deep Dive

June 27, 2018

2 of 41

Table of Contents

  • Consensus
  • Sharding
  • Storage
  • Transaction
  • Script
  • Sync
  • P2P

3 of 41

Consensus

4 of 41

PoW vs BFT

PoW

BFT

Safety

(= Finality)

Not Guaranteed

Guaranteed

Liveness

Guaranteed

Guaranteed in Partial Synchronous Network

Openness

Excellent

Limited

Energy usage

Inefficient

Efficient

Throughput

Low

High

Latency

High

Low

5 of 41

CodeChain Consensus

  • Pluggable consensus architecture
    • PoW (Proof of Work)
    • PoA (Proof of Authority)
    • Tendermint
    • Hot-Stuff�
  • Separation between beacons and replicas
    • Beacon: a mechanism for triggering proposals
    • e.g., PoW (Beacon) + Wendy (Replicas)
  • See https://codechain.io/slides/ccs1

6 of 41

Sharding

7 of 41

Scalability Problem

8 of 41

Scalability Solution

  • Candidates
    • Large block size
    • High Performance Consensus Algorithm
    • Lightning Network
    • Inter-chain
    • Sidechain
    • Sharding

9 of 41

Sharding

  • Global root has only the root of the shards
  • All assets are stored in the shards

root

account

shard1

shard2

account

shard1

asset

asset

shard2

asset

asset

10 of 41

Participants

Collect transactions

Create Parcel

Collect signatures from Validators

Validate transactions in Parcel

Gateway

Shard Validator

Beacon

3. Signed Parcel

1. Unsigned Parcel

2. Signature

Execute Parcel(top-level transaction)

11 of 41

Mental model

validator

validator

validator

validator

validator

validator

Shard-level

Consensus

node

node

node

node

node

node

Top-level

Consensus

node

node

node

node

node

node

Top-level

Consensus

Threshold Signature

validator

validator

validator

validator

validator

12 of 41

Shard Validator

  • Allocate validators every epoch
  • Register and deregister to validator sets are applied after E epoch
  • Every epoch, validator is rewarded P ccc from shard budget
    • Validator receives the given reward on deregister
  • The shard becomes inactive if the shard has not enough budget
  • Use consistent hashing to minimize the effect of validator set change

13 of 41

Storage

14 of 41

Merkleized UTXO

Key Idea

  • UTXO set embedded in Merkle Trie

Benefits

  • Piggy-back “undo” feature from Merkle Trie

15 of 41

Asset Transfer in Merkleized UTXO 1/3

‘A’000000...FEFE - Asset A

asset type

amount

lock script hash

Block 100

StateRoot

0xAAAA...

Branch

Branch

Branch

Branch

Branch

...

...

...

...

...

16 of 41

Asset Transfer in Merkleized UTXO 2/3

Block 100

‘A’0000…FDFD - Asset B

asset type

amount

lock script hash

Block 101

AssetTransfer

A → B

‘A’000000...FEFE - Asset A

asset type

amount

lock script hash

StateRoot

0xAAAA...

Branch

Branch

Branch

Branch

Branch

...

...

...

...

...

17 of 41

Asset Transfer in Merkleized UTXO 3/3

Block 100

Branch

Branch

Get “Asset A” from StateRoot 0xBBBB… returns null

‘A’0000…FDFD - Asset B

asset type

amount

lock script hash

Block 101

AssetTransfer

A → B

‘A’000000...FEFE - Asset A

asset type

amount

lock script hash

StateRoot

0xAAAA...

Branch

Branch

Branch

Branch

Branch

...

...

...

...

...

StateRoot

0xBBBB...

18 of 41

Transactions

19 of 41

CodeChain Transactions

Mint

Transfer

Asset

Gold

Silver

Silver

Gold

Scheme

20 of 41

Sending CodeChain Transaction

CodeChain Network

Gateway

Asset owner

Asset owner

Asset owner

AssetTransfer

Node

Node

Node

Node

ChangeShardState

  • Group transactions to ChangeShardState Parcel
  • Signs to parcel. Signer pays fee for the parcel
  • Sends signed parcel to network

21 of 41

Game Service Example - AssetMint

AssetMint

output 1

999999 sword

owner A

Game server mints new item

create

AssetScheme

* metadata

* amount

Game Gateway

account 0xDE..

Send transaction to the gateway

Game server

owner A

22 of 41

Game Service Example - AssetMint

AssetMint

output 1

999999 sword

owner A

AssetScheme

* metadata

* amount

Game Gateway

account 0xDE..

verify transaction and create parcel

23 of 41

Game Service Example - AssetMint

Parcel

Transactions

AssetMint

Game Gateway

account 0xDE..

Fee, Signature, ...

...

...

Send signed parcel

create parcel and sign

CodeChain node

CodeChain Network

Node

Node

Node

Node

24 of 41

Game Service Example - AssetTransfer

Game client

asset owner B

A user buys a sword with 5 gold from NPC

AssetTransfer

input 0

20 gold

owner B

output 0

999998 swords

owner A

input 1

999999 sword

owner A

output 1

1 sword

owner B

output 2

5 gold

owner A

output 3

15 gold

owner B

sign

sign

Game server

owner A

25 of 41

Game Service Example - AssetTransfer

AssetTransfer

input 0

20 gold

owner B

input 1

999999 sword

owner A

Game Gateway

account 0xDE..

Send transaction to the gateway

output 0

999998 swords

owner A

output 1

1 sword

owner B

output 2

5 gold

owner A

output 3

15 gold

owner B

Game server

owner A

26 of 41

Game Service Example - AssetTransfer

Parcel

Transactions

AssetTransfer

Game Gateway

account 0xDE..

...

...

Send signed parcel

verify transaction and

create parcel

CodeChain node

Fee, Signature, ...

27 of 41

Scripting

28 of 41

CodeChain Script

  • Native support for P2SH
  • Guaranteed termination
    • No loops
    • No backjump allowed
  • Separation between lock script and parameters
    • Script identification without original script
    • Required for implementing wallet
  • Multiple return types
    • Success, Fail, Burn

29 of 41

Burn

  • Eliminate asset permanently
    • Transaction is invalid if burnt asset is used
  • Programmable control of asset circulation
    • Automatic disposal of single-use objects
  • Smaller state size

TX0

TX1

BURNT!

30 of 41

CodeChain Asset Transfer

Lock Script Hash

Parameters

Lock Script

Unlock Script

Output

Input

Lock script Hash

Lock script

BLAKE256

Lock script

Run CCVM

Unlock script

Sanity Checker

Unlock script

Initial State

Parameters

Success

Fail

Burn

31 of 41

Synchronization

32 of 41

Full Block Synchronization

  • Pull gossip for block propagation
    • Requester have full control on bandwidth
    • Small message duplication
    • Header first style block request
  • Fully parallel header fetching
    • Fast catch up for best peer

?

?

?

33 of 41

Snapshot Synchronization

  • Block validation without history
    • Faster startup time
    • Reduced storage requirement
  • Verifiable snapshot header
    • Use “head” of state trie as manifest
  • Compressed subtree as state chunk
    • Upper limit for number of chunks
    • Out-of-order fetching available

R

snapshot

chunk

Head

34 of 41

Network

35 of 41

Network Extensions

  • Multiple extensions can perform the same task in different ways
    • Tendermint consensus vs Hot-stuff consensus
    • Block sync vs Snapshot sync
    • Unstructured discovery vs Kademlia discovery
  • UDP for Session Initiator
  • TCP for P2P Connection
  • Pluggable extension mechanism
    • States are not shared among extensions to make it easy to implement each extension
    • Each extension is isolated
    • A single connection per node is shared among extensions

Node

Session

Initiator

P2P

Connection

Extensions

Node

Node

Node

36 of 41

Peer Discovery

  • Discovery is one of extensions
  • Network formation and policy can be changed
  • Currently, Unstructured and Kademlia discovery is implemented
    • Kademlia in CodeChain uses NodeId based on IP address to prevent Sybil attack

37 of 41

Session Initiation

Connection Request

Node

Node

Connection Allowed

ECDH Request

ECDH Allowed

ECDH

Share secret key

Create a session

Connection Request

Node

Node

Connection Allowed

Set shared secret with RPC

Share session without network

Set shared secret with RPC

Share secret key

Create a session

38 of 41

Authentication

  • Each connection has a unique session key
  • All messages have signature field
    • Signature = blake2b(message, session key, outlen=32)

head

version

0x05

extension-name

extension-version

body

aes256(extension-message, session-key)

signature

blake2b(head.body, session-key)

head

version

0x06

extension-name

extension-version

body

extension-message

signature

blake2b(head.body, session-key)

39 of 41

Encryption

  • An extension can optionally enable encryption
  • Messages are encrypted with aes256

head

version

0x05

extension-name

extension-version

body

aes256(extension-message, session-key)

signature

blake2b(head.body, session-key)

head

version

0x06

extension-name

extension-version

body

extension-message

signature

blake2b(head.body, session-key)

40 of 41

Extension API

pub trait Extension {

fn name(&self) -> String;

fn need_encryption(&self) -> bool;

fn versions(&self) -> Vec<Version>;

fn on_initialize(&self, api: Arc<Api>);

fn on_node_added(

&self, _node: &NodeId, version: Version);

fn on_node_removed(&self, _node: &NodeId);

fn on_message(

&self, _node: &NodeId, _message: &[u8]);

fn on_timeout(&self, _timer: TimerToken);

fn on_local_message(&self, _message: &[u8]);

}

pub trait Api {

fn send(

&self, node: &NodeId, message: &Vec<u8>);

fn set_timer(

&self, timer: TimerToken, d: Duration)

-> Result<()>;

fn set_timer_once(� &self, timer: TimerToken, d: Duration)

-> Result<()>;

fn clear_timer(&self, timer: TimerToken)

-> Result<()>;

fn send_local_message(

&self, message: &Encodable);

}

41 of 41

Q & A