trading derivatives on hyperledger

Trading Derivatives on Hyperledger

Siriwat Kasamwattanarote, Thierry Gibralta, Vsevolod Yugov, Shibo Lin

Hideaki Takei, Fernando Vazquez

LinuxCon + ContainerCon Japan 2016

15 July 2016

We are We use

People

• SBI BITS (Better IT Solution)

• We’re building a next generation trading platforms

Fernando Vazquez

Siriwat Kasamwattanarote Vsevolod Yugov

Thierry Gibralta Shibo Lin

Hideaki Takei2

Agenda

• What are we doing?• Trading derivatives

• Hyperledger with container technology.

• Our design

• Performance evaluation

• Next challenges

• Key takeaways

3

A little more about us

4

Trading Derivatives

• What are derivatives?• Derivatives are securities linked to the other securities.• E.g. options, futures, and swaps.

• In case of an option• Option created when

• Client sells their Put/Call option andother client buys the available Put/Call option.

• Fee is called premium.• Transaction happen when

• The option is created.• Existing option is bought/sold/transferred.

• Exercising• At the maturity time• Premium < Payout = Profit

Timeline

Pri

ce

Make profit?

5

Call

Put

Matu

rity time

Trading Derivatives (2)

• Traditional platform

Client FX trader(broker)

Order

Trading platform

Order

Back office

SQL Transaction

Problems6

The new approach

7

Blockchain

• A chain of blocks.

• Blockchain is a framework.

• A block may contain code as a smart contract.

• Ideal smart contract examples• Car insurance activates only when driving.

• Money is transferred from A to B at 11:00 AM 15 July 2016 JST.

• The contract triggers automatically.• When a contract meets its true conditions.

8

Header/Contract

Header/Contract

Header/Contract

Header/Contract

Header/Contract

Data Data Data Data Data

Genesis Block 1 Block 2 Block 3 Block 4

Hyperledger

• A blockchain framework.

• Open standard/source.

• Customizable• Smart contract

• Namely, chaincode.

• Consensus plugins• Data payload

• Community driven.

• Written in Go.

• Heavily depends on the container technology.

9Ref: https://www.hyperledger.org

Container

• Docker is a kind of containerization platform.

• No guest OS.

• Only bin/lib/app.

• We all know : )

Ref: https://www.docker.com10

+ =

• Becomes a fully distributed blockchain framework.• Motivated by

• Our benefits• Simplified back office (BO).• Shareable BO between holder.• Less operating expenses (OPEX).• De-centralized database.• Contributing a common ledger.• Increasing transaction volume.

• Customer benefits• Lower fee

• Expected benefits• High availability• Disaster recovery

Client

Distributedtrading platform

Order

11

ClientOrder

Order

Client

Our design

12

Use case

• Aims for derivative trading platform

• Trust model• Trusted nodes

• Know your customer (KYC) procedure (by law)

• Private network

• Permissioned blockchain

• Regulatory oversight

13

Consensus

• Hyperledger’s default consensus plugins:• Noops

• Trusts everyone.

• No integrity.

• PBFT• Trusts majorities

• Partially recoverable.

• What could be the optimal consensus algorithm for us?

14

Private

Public

Prototype

• Vanilla github.com/hyperledger/fabric • Two consensus plugins• No additional features

• Two simple chaincodes• Account management• Option trading

• Two type of nodes• Validator node – Validating the blocks.• Non-validator node – Providing the REST API service.

• Tested on the variety of architectures.

15

Account Option

Hyperledger control center - HyperCC

• Currently• We use our specific node controller script.• Namely, HyperCC

• Built with• Docker CLI• SSH• ENV variables

• Parameters (port, volume, etc.)• Programmable• On-the-fly

• Available functions• Start – To create the nodes.• Stop – To terminate the nodes.• Upgrade – To rolling upgrade the nodes.• SyncDB – To recovery broken chains (experiment).

…

HyperCC 16

Deployment example

• 1 host machine• 1 Client

• 1 Validator node

Trusted domain

RES

T A

PI

17

Client Validator

Host machine

V1

Deployment example (2)

• 1 host machine• 2 Clients

• 1 Validator node

Trusted domain

18

Client 2

Validator

Client 1

RES

T A

PI

Host machine

V1


• 1 host machine• 3 Clients

• 3 Validator nodes

• 1 Non-validator node

Trusted domain

19

Client 2

Validators

Client 1

Client 3

RES

T A

PI

V4

V3

V2

N1

Host machine


• 4 machines• 3 Clients

• 3 Validator nodes

• 1 Non-validator nodes

• each!

20

Client 2

Client 1

Client 3

RES

T A

PI

V

V

V

N

Host machine 3

Trusted domain

Client 2

Client 1

Client 3

RES

T A

PI

V

V

V

N

Host machine 1

Client 2

Client 1

Client 3

RES

T A

PI

N

V

V

V

Host machine 2

Client 2

Client 1

Client 3

RES

T A

PI

N

V

V

V

Host machine 4

Performance evaluation

21

Test protocol and configurations

• What we measure?• Throughput, CPU, memory, storage, latency , and discrepancy

• How we send the transactions?• REST API

• What kind of transaction?• Randomly transfer money between users.

• Docker configuration• v. 1.11• --storage-driver=overlay

• Node configurations• Single VM, multiple VMs, multiple physical servers• Node size: 1/2/4/5/6/10/15/20

22

Trusted domain

Client 2

Validators

RES

T A

PI

V

V

V

N

Host machine

= Avg( ) = Avg(Diff( ))

Overall result*

CPU

Storage

Memory

Latency

Discrepancy

Throughput

Multiple configurations (PBFT)1 VM 4 VMs 4 Servers

23

CPU

Storage

Memory

Latency

Discrepancy

Throughput

Multiple configurations (Noops)1 VM 4 VMs 4 Servers

*Higher is better, comparing relatively to 1 VM.

Overall result* (2)

• Noops vs. PBFT

CPU

Storage

Memory

Latency

Discrepancy

Throughput

Consensus algorithms comparisonPBFT NOOPS

24*Higher is better, comparing relatively to PBFT.

Throughput result in detail

• Estimated for market hours (7 hours)• Clients connect directly to validator node.

0.0

0.5

1.0

1.5

2.0

2.5

3.0

3.5

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Tran

sact

ion

/ d

ay (

mill

ion

)

Number of nodes

Throughput

2.92 M 2.91 M

25

Trusted domain

RES

T A

PI

Client Validator

Host machine

V1

Number of nodedefines number of machine.

• With non-validator node enabled

Throughput result in detail (2)

0.0

1.0

2.0

3.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Tran

sact

ion

/ d

ay (

mill

ion

)

Number of nodes

Throughput

1 machine, 3 V nodes, 1 N node, 1 Client

4 machines, 3 V nodes, 1 N nodes, 1 Clients, each



4 machines, 1 V node, 1 N nodes, 3 Clients, each

2.6 M

10.75 M

17.98 M

19.2 M

21.17 M

26

Client 2

Client 1

Client 3

REST

API

V

V

V

N

Host machine 3

Trusted domain

Client 2

Client 1

Client 3

REST

API

V

V

V

N

Host machine 1

Client 2

Client 1

Client 3

REST

API

N

V

V

V

Host machine 2

Client 2

Client 1

Client 3

REST

API

N

V

V

V

Host machine 4

V = validatorN = non-validator

Result summary

• Noops gives higher performance than PBFT.

• Higher throughput can be achieved with physical servers.

• Better to send transaction through a non-validator node.

27

Trusted domain

RES

T A

PI

Client Validator

Host machine

V1

Trusted domain

RES

T A

PI

Client Non-Validator

Host machine

N1 V1

Validator

Recommended!

Next challenges

28

Hyperledger side

1. Backup / Recovery2. Something in between Noops and PBFT consensus.

• Hybrid consensus?

3. Throttling rather than silent rejection.4. ROOT discovery node fail?5. Way to get transaction result on commit (transaction-specific event?).6. Deprecated HostConfig in Docker 1.12

• go-dockerclient still not support Docker 1.12.• Chaincode cannot be created.

7. Slow chaincode deployment.8. Container not recycles automatically.

29

Docker side

1. Image is quite big

2. Make Docker image smaller

3. Might need runC/containerd runC

30

3 things to takeaway

• Hyperledger + Docker provides a powerful blockchain framework.

• Way to deploy a new chaincode without creating a new image.

• Hybrid consensus, fast, adjustable level of trust.

31

Talk with us

•Our leader:Fernando Luis Vázquez Cao [email protected]

•Me:Siriwat [email protected]

32

trading derivatives on hyperledger

Technology