Trading derivatives on a decentralized system aims for high availability (HA) and disaster recovery (DR). Both HA and DR can be met by incorporating a blockchain and a container technology. The Hyperledger is a blockchain framework aims for a cross-industry open standard with the freely customizable plugins, smart contract, and the data payload. Those features exposes us the easy ways to implement our trading platform on a blockchain. The Docker was brought to handle each specific Hyperledger chain internally. Also, hovering the whole Hyperledger nodes with containers reduce our time in building infrastructure, and much easier to be deployed on the production environment. This presentation will show how we integrate the Hyperledger and the Docker container for our derivatives trading project, and the issues that we are focusing on. Additionally, the talk partially includes the performance evaluation results under different configurations. This talk was delivered at LinuxCon Japan 2016 by Siriwat Kasamwattanarote, Thierry Gibralta, Vsevolod Yugov, Shibo Lin, Hideaki Takei, and Fernando Vazquez

1. 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

2. 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 Takei
2

3. Agenda
• What are we doing?
• Trading derivatives
• Hyperledger with container technology.
• Our design
• Performance evaluation
• Next challenges
• Key takeaways
3

4. A little more about us
4

5. 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 and
other 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
Price
Make profit?
5
Call
Put
Maturitytime

6. Trading Derivatives (2)
• Traditional platform
Client FX trader
(broker)
Order
Trading platform
Order
Back office
SQL Transaction
Problems
6

7. The new approach
7

8. 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

9. 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.
9
Ref: https://www.hyperledger.org

10. Container
• Docker is a kind of containerization platform.
• No guest OS.
• Only bin/lib/app.
• We all know : )
Ref: https://www.docker.com
10

11. + =
• 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
Distributed
trading platform
Order
11
Client
Order
Order
Client

12. Our design
12

13. 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

14. 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

15. 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

16. 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

17. Deployment example
• 1 host machine
• 1 Client
• 1 Validator node
Trusted domain
RESTAPI
17
Client Validator
Host machine
V1

18. Deployment example (2)
• 1 host machine
• 2 Clients
• 1 Validator node
Trusted domain
18
Client 2
Validator
Client 1
RESTAPI
Host machine
V1

19. Deployment example (3)
• 1 host machine
• 3 Clients
• 3 Validator nodes
• 1 Non-validator node
Trusted domain
19
Client 2
Validators
Client 1
Client 3
RESTAPI
V4
V3
V2
N1
Host machine

20. Deployment example (4)
• 4 machines
• 3 Clients
• 3 Validator nodes
• 1 Non-validator nodes
• each!
20
Client 2
Client 1
Client 3
RESTAPI
V
V
V
N
Host machine 3
Trusted domain
Client 2
Client 1
Client 3
RESTAPI
V
V
V
N
Host machine 1
Client 2
Client 1
Client 3
RESTAPI
N
V
V
V
Host machine 2
Client 2
Client 1
Client 3
RESTAPI
N
V
V
V
Host machine 4

21. Performance evaluation
21

22. 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
RESTAPI
V
V
V
N
Host machine
= Avg( ) = Avg(Diff( ))

23. 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.

24. Overall result* (2)
• Noops vs. PBFT
CPU
Storage
Memory
Latency
Discrepancy
Throughput
Consensus algorithms comparison
PBFT NOOPS
24*Higher is better, comparing relatively to PBFT.

25. 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
Transaction/day(million)
Number of nodes
Throughput
2.92 M 2.91 M
25
Trusted domain
RESTAPI
Client Validator
Host machine
V1
Number of node
defines number of machine.

26. • 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
Transaction/day(million)
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, 4 V nodes, 1 N nodes, 2 Clients, each
4 machines, 3 V nodes, 1 N nodes, 3 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
RESTAPI
V
V
V
N
Host machine 3
Trusted domain
Client 2
Client 1
Client 3
RESTAPI
V
V
V
N
Host machine 1
Client 2
Client 1
Client 3
RESTAPI
N
V
V
V
Host machine 2
Client 2
Client 1
Client 3
RESTAPI
N
V
V
V
Host machine 4
V = validator
N = non-validator

27. 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
RESTAPI
Client Validator
Host machine
V1
Trusted domain
RESTAPI
Client Non-Validator
Host machine
N1 V1
Validator
Recommended!

28. Next challenges
28

29. Hyperledger side
1. Backup / Recovery
2. 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

30. Docker side
1. Image is quite big
2. Make Docker image smaller
3. Might need runC/containerd runC
30

31. 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

32. Talk with us
•Our leader:
Fernando Luis Vázquez Cao
fernando.vazquez@sbibits.com
•Me:
Siriwat Kasamwattanarote
siriwat.k@sbibits.com
32