Mijin Project Demonstration Experiment Report - arara › wp-content › uploads › 2016 › 10 ›...
Transcript of Mijin Project Demonstration Experiment Report - arara › wp-content › uploads › 2016 › 10 ›...
Mijin Project
Demonstration Experiment Report
August 28, 2016
ver. 1.1
arara Inc.
Copyright© 2016 arara Inc. i
Table of Contents
Mijin Project .............................................................................................................................................................................. 1
Demonstration Experiment Report ............................................................................................................................................ 1
1 Background and Purpose of the Demonstration Experiment ............................................................................................. 1
2 Result ............................................................................................................................................................................... 1
3 Outline of the Demonstration Experiment ......................................................................................................................... 3
3.1 Period ......................................................................................................................................................................... 3
3.2 Target System ............................................................................................................................................................ 3
3.3 Arara Coin System .................................................................................................................................................... 4
3.3.1 Use Case ................................................................................................................................................................... 4
3.3.2 List of Administrative Functions .............................................................................................................................. 6
3.3.3 List of User Functions .............................................................................................................................................. 6
3.3.4 Screen Transition Diagram ....................................................................................................................................... 7
4 Details of the Demonstration Experiment ......................................................................................................................... 8
4.1 System Configuration ................................................................................................................................................ 8
4.2 Points of the Demonstration Experiment ................................................................................................................. 10
4.3 Advance Preparation................................................................................................................................................ 10
4.4 Demonstration Experimental Method ...................................................................................................................... 11
4.5 Demonstration Experiment Description .................................................................................................................. 12
4.5.1 Summary................................................................................................................................................................. 12
4.5.2 Consistency Confirmation 1 (Transactions to one server for one department/service) .......................................... 13
4.5.3 Consistency Confirmation 2 (Transactions to four servers for one department/service) ........................................ 15
4.5.4 Consistency Confirmation 3 (Rebooting servers) ................................................................................................... 17
4.5.5 Performance Confirmation 1 (Transactions to one department) ............................................................................. 19
4.5.1 Performance Confirmation 2 (Transactions to multiple departments).................................................................... 21
5 Results and Consideration of the Demonstration Experiment ......................................................................................... 23
5.1 Data Consistency ..................................................................................................................................................... 23
5.2 Performance ............................................................................................................................................................. 23
5.2.1 Server Load ............................................................................................................................................................ 23
5.2.2 Transaction Approval Confirmation Processing..................................................................................................... 23
5.2.3 Transaction Performance ........................................................................................................................................ 24
6 Conclusion ..................................................................................................................................................................... 26
Copyright© 2016 arara Inc. ii
Update History
Date Version Update Content
August 28,
2016
1.00 Creation of the first edition
September
28, 2016
1.10 Update of the Result
Copyright© 2016 arara Inc. 1
1 Background and Purpose of the Demonstration Experiment
(1) In 2008, a person named himself Satoshi Nakamoto submitted a paper about Bitcoin, a non-centralized and
distributed virtual currency system called Blockchain, and in 2009, he released the software of Bitcoin on the
Internet and its operation began.
(2) Blockchain has the following characteristics:
(A) A distributed type that synchronizes the same data on arbitrary multiple computers
(B) By binding the transaction data blocks with chains, falsification of data will become very difficult
(C) The mechanism in which any number of nodes can participate regardless of PCs and servers connected to
the Internet is called the public type. The mechanism that designates an administrator and a company
operates as a non-distributed type is called the private type.
(3) Mijin is the software developed as the private type by Tech Bureau, Corp. based on NEM, public type
Blockchain software published as open source for which the development began as the Blockchain 2.0 Project
in January 2014.
(4) The usefulness and cost benefit of the system for sending and receiving currency on a many-to-many basis
have been verified by other companies’ demonstration experiments, but its usefulness for the system in which
high-volume transactions occur on a many-to-one basis, just like our point + plus system, is unknown.
(5) So, the purpose is to help clarify the direction of our services and product development by assuming the
system configuration that is close to the point + plus system, which is our flagship service, conducting the
demonstration experiment, and comprehending the performance, cost, and characteristics of the system.
(6) Regarding many-to-many transactions, a wide variety of methods for using other than currency have been
proposed but what can be done and what cannot be done are obscure; therefore, obtaining the know-how
through this demonstration experiment will be one of the purposes.
References
(1) Satoshi Nakamoto:
https://en.wikipedia.org/wiki/Satoshi_Nakamoto
(2) Bitcoin:
https://en.wikipedia.org/wiki/Bitcoin
(3) Blockchain :
https://en.wikipedia.org/wiki/Blockchain_(database)
(4) Tech Bureau mijin:
http://mijin.io/en/about-mijin
Copyright© 2016 arara Inc. 2
2 Result
Although there are some issues, it is possible to do 3,000 or more transactions per minute without causing
inconsistencies, and it has been verified that the mechanism can make it difficult to falsify data and can prevent data
loss. We also reached the conclusion that it is sufficiently applicable to the systems in which high-volume
transactions occur on a many-to-one basis such as our point + plus. However, as functions other than the functions
that mijin can realize need to be absorbed by peripheral systems, securing their credibility and availability will
become important.
Copyright© 2016 arara Inc. 3
3 Outline of the Demonstration Experiment
3.1 Period
Preparations of the design, development, and set up for the demonstration experiment system
June 21 to August 12, 2016
Conduction of the demonstration experiment
August 15 to 26, 2016
3.2 Target System
We assume the system in which we prepare our own arara coins and our employees can make various kinds of
payments in arara with arara coins (hereafter referred to as the “arara coin system”). Mainly, we assume the payments
in the service of in house cafeteria called Happy Cafeteria and Office FamilyMart.
*There was a proposal to use arara coins as virtual currency that can be used publicly in the future but we did not
consider this in this demonstration experiment.
Copyright© 2016 arara Inc. 4
3.3 arara Coin System
3.3.1 Use Case
The main use cases of the arara coin system are as follows:
The following is the image of a small-scale system. There is one company card and many cards for all employees,
the payment between the cards will be processed by the system.
※ARC=arara coin
Charging to the employee card (Example)
Administrator
800ARC
800ARC
800ARC
Use by the employee (Example)
8ARC
Company Card
Employee Card
Employee A
Employee B
Employee C
Employee Administrator
Company Card Employee Card
The employee makes a payment from the website or smartphone before use.
Copyright© 2016 arara Inc. 5
On the other hand, if the company is large, we will use the following structure to make it possible to control with
respect to each department and to avoid transactional concentration on the company card.
Recharging to the employee card
(Example)
Use by the employee (Example)
8ARC
Employee Departmental Administrator
Department Card Employee Card
The Employee makes a payment from the website or smartphone before use.
Transactions between the department and company will not be done at real time
but be done in a batch as needed.
Overall Administrator
Company Card Departmental 理
門
員
800ARC
800ARC
800ARC
Department Card
Employee Card
Employee A
Employee B
Employee C Department B
10,000ARC
10,000ARC
Administrator
Departmental 管
部
社
800ARC
800ARC
800ARC
Department Card
Employee Card
Employee A
Employee B
Employee C
Department B
Administrator
??ARC
Overall Administrator
Company Card
Copyright© 2016 arara Inc. 6
3.3.2 List of Administrative Functions
#
Function Content
Implementation in the Demonstration Experiment
A1 Multi-Organization Support
Independent processing and management for each office or department can be done
Yes
A2 Card Issuance You can issue cards with a unique number system. No
A3 Expiration Date Expiration date can be set for each card. No
A4 Extension of the Expiration Date
You can extend the expiration date when used, etc. No
A5 Status Change You can change the status of the specific card such as activation/deactivation and expiration date.
No
A6 Recharging Function An organization can send or receive money to/from a specific card.
Yes
A7 Lump-Sum Recharging Function
An organization can send money to multiple specific cards.
Yes
A8 Totalization Function
It can specify the period and display the total of sending/receipt of Mosaic (coins) with respect to each individual card, individual organization, and upper organization.
No
A9 Total Amount Adjustment
You can add coins (Mosaic) when the coins are about to run out.
No
3.3.3 List of User Functions
#
Function Content
Implementation in the Demonstration Experiment
U1 Compatible with Smartphones
You can use it with a smartphone app (iPhone). Yes
U2 Compatible with Smartphones
You can use it with a smartphone app (Android). Yes
U3 Payment You can easily make payments of 100 yen, 200 yen, etc., that you frequently use and you can also make a payment by designating an amount.
Yes
U4 Aggregate Calculation You can refer the amounts of the monthly charge and payment.
No
U5 History You can refer the monthly charge and payment history. Yes
U6 Sending and Receiving of Money Between Employees
You can send and receive Arara coins to/from another employee.
No
Copyright© 2016 arara Inc. 7
3.3.4 Screen Transition Diagram
operation menu payment menu execute payment
login account information
payment history confirm payment
Copyright© 2016 arara Inc. 8
4 Details of the Demonstration Experiment
4.1 System Configuration
The following is the system configuration diagram used in the demonstration experiment.
Figure 4-1. Entire System Configuration Diagram
Table 4-1. arara Coin Server Specification
Location amazon aws Tokyo-ap-northeast-1a
Instance Type t2.medium
CPU 2 cores
Memory 4G
Storage Type SSD gp2
Database PostgreSQL ver9.5
Copyright© 2016 arara Inc. 9
Figure 4-2. arara Mijin Cloud Configuration Diagram 1 (Low latency: RTT average is about 0.5 msec)
Figure 4-3 arara Mijin Cloud Configuration Diagram 2 (High latency: RTT average is about 75 msec)
Copyright© 2016 arara Inc. 10
Table 4-2. arara Mijin Cloud Server Specification
Location amazon aws
Tokyo-ap-northeast-1a
Tokyo-ap-northeast-1b
Singapre-ap-southeast-1a
Singapre-ap-southeast-1b
Instance Type m3.large
CPU 2 cores
Memory 7G *When allocated 7 gigabytes to JavaVM, the process frequently went down; therefore, we set 4 gigabytes
Storage SSD gp2
Table 4-3. Client PC Specification for Mass Data Transaction
Location arara headquarters
CPU Intel Core i3 2 cores 4 threads 3.1
GHz
Memory 12 G
Storage Type HDD (SATA) 7200 rpm
4.2 Points of the Demonstration Experiment
We implemented the demonstration experiment this time by focusing on the following points:
1. Consistency
Whether or not a discrepancy occurs when we do transactions on multiple mijin servers. Whether or not a
discrepancy occurs when servers do not synchronize for a period.
2. Performance
Does it have a processing capability for many transactions to one card at a short period and does it have a
practical processing capability when processing a large amount between multiple departments?
Whether or not a bottleneck occurs between Client → arara coin server and arara coin server → mijin
Cloud.
4.3 Advance Preparation
We made the following preparations in conducting verifications.
Number of Users (Cards) 100,000 users
Number of Departments 1,024 departments
Recharge About 5.6 million transactions
Copyright© 2016 arara Inc. 11
4.4 Demonstration Experimental Method
We conduct the demonstration experiment by installing the test tool (the one separately developed this time) on the
test client and changing the parameter. The parameter is as follows:
Table 4-4. List of Parameter Items
Number of Users (Cards) Fixed in all tests (100,000 users)
Number of Departments Fixed in all tests (1,024 departments)
Client Latency Latency until the test client sends a request for the next transaction
Number of Client Threads The parallel degree that the test client concurrently executes transactions
Server Connection Mode Designate how to connect to multiple mijin servers.
-Department/service fixed mode: The mode to always connect to one server
when the department and service are the same
-Round robin mode: The mode to connect to servers in a sequential order
Network Latency Network latency between servers
For the test, we conduct transactions with the above parameter for about five minutes and acquire the following
data:
Server Load Brief load average
Processing Time Number of transactions processed per minute
arara Coin Server
Processing Time
arara coin server’s processing time. The time from receiving a request to
receiving mijin’s transaction request response (unapproved state)
mijin Processing Time The time from sending a transaction request to mijin to receiving the
response (unapproved state)
Data Capacity Data size (volume of data depends on the number of items) *Implement in
specific test cases
Copyright© 2016 arara Inc. 12
4.5 Demonstration Experiment Description
4.5.1 Summary
Test # Test Content
Confirmation of the Data
Consistency 1
We make payments from 100,000 cards to 1,024 departments. The
connecting mijin server will be fixed for the department and will confirm
the condition where inconsistency is difficult to occur. We randomly select
the cards.
Confirmation of the Data
Consistency 2
We make payments from 100,000 cards to one department. We randomly
select the cards, but we conduct transactions for four consecutive times and
allocate them to four mijin servers to confirm the condition where
inconsistency easily occurs.
Confirmation of the Data
Consistency 3
We reboot several servers under the condition of the Confirmation of the
Data Consistency 2 and, after that, confirm that the data between the servers
will be synchronized.
Performance Confirmation 1 We send a large amount of requests from 100,000 cards to one department.
We randomly select the cards and allocate them to four mijin servers in a
round-robin fashion.
Performance Confirmation 2 We send a large amount of requests from 100,000 cards to 1,024
departments. We randomly select the cards and departments and allocate
them in a round-robin fashion.
Copyright© 2016 arara Inc. 13
4.5.2 Consistency Confirmation 1 (Transactions to one server for one department/service)
4.5.2.1 Content
All four mijin servers have the same data. In other words, three servers will synchronize the data processed by one
server. Therefore, if we conduct multiple transactions from one card to multiple mijin servers in a short time, there is
a concern that we cannot maintain consistency. Therefore, we confirmed that we could maintain consistency with the
configuration in which we made transactions for one card to one server first.
4.5.2.2 System Configuration
Figure 4-4. Request to One Server for One Department/Service
Copyright© 2016 arara Inc. 14
4.5.2.3 Transaction Sequence
Figure 4-5. Transaction Sequence
4.5.2.4 Verification Parameter
Number of Users (Cards) 100,000 users
Number of Departments 1,024 departments
Client Latency 0 msec
Number of Client Threads 1 We set one to check consistency
Server Connection Mode Fixed We fixed the connection servers for
each department/service
Copyright© 2016 arara Inc. 15
4.5.3 Consistency Confirmation 2 (Transactions to four servers for one department/service)
4.5.3.1 Content
All four mijin servers have the same data. In other words, three servers will synchronize the data processed by one
server. Therefore, if we conduct multiple transactions from one card to multiple mijin servers in a short time, there is
a concern that we cannot maintain consistency. Therefore, we confirmed that we could maintain consistency with the
configuration in which we made transactions for one card to four servers first.
4.5.3.2 System Configuration
Figure 4-6. Request to Four Servers for One Department/Service
Copyright© 2016 arara Inc. 16
4.5.3.3 Transaction Sequence
Figure 4-7. Transaction Sequence
4.5.3.4 Verification Parameter
Number of Users (Cards) 100,000 users
Number of Departments 1 department
Client Latency 0 msec
Number of Client Threads 1 We set one to check consistency
Server Connection Mode Round robin Connect in a sequential order
Copyright© 2016 arara Inc. 17
4.5.4 Consistency Confirmation 3 (Rebooting servers)
4.5.4.1 Content
All four mijin servers have the same data. We believe that actively conducting the distributed connection is
preferable in view of the load distribution and performance. However, there may be a case that if one server goes
down, reboots, or recovers, we will not be able to take data consistency between servers and in this case, we need to
manually recover it; therefore, there is a concern about operational load. Therefore, we confirm to maintain
consistency even if one server repeats rebooting.
4.5.4.2 System Configuration
Figure 4-8. Request to Four Servers for Multiple Departments/Services
Copyright© 2016 arara Inc. 18
4.5.4.3 Transaction Sequence
Figure 4-9. Transaction Sequence
4.5.4.4 Verification Parameter
Number of Users (Cards) 100,000 users
Number of Departments 1 department
Client Latency 0 msec
Number of Client Threads 1
Server Connection Mode Round robin Connect in a sequential order
4.5.4.5 Verification Method
While consecutively conducting the above transactions, reboot two of the four servers at fixed intervals. To avoid
mijin from appropriately shutting down, turning off the power would be a good reboot method but we decided to
realize it by force-quiting (kill-KILL) mijin’s process to save time.
Copyright© 2016 arara Inc. 19
4.5.5 Performance Confirmation 1 (Transactions to one department)
4.5.5.1 Content
We considered the possibility of affecting performance in confirming consistency when conducting concentrated
transactions to one card without considering the department and confirmed performance.
4.5.5.2 System Configuration
Figure 4-10. Request to Four Servers for One Department/Service
Copyright© 2016 arara Inc. 20
4.5.5.3 Transaction Sequence
Figure 4-11. Transaction Sequence
4.5.5.4 Verification Parameter
Number of Users (Cards) 100,000 users
Number of Departments 1 department
Client Latency 0 msec
Number of Client Threads 10 We set ten to confirm performance
Server Connection Mode Round robin Connect in a sequential order
Copyright© 2016 arara Inc. 21
4.5.1 Performance Confirmation 2 (Transactions to multiple departments)
4.5.1.1 Content
We confirmed the difference in performance in the case of conducting concentrated transactions to one card
without considering the department and in the case of distributing the transactions to multiple servers.
4.5.1.2 System Configuration
Figure 4-12. Request to Four Servers for One Department/Service
Copyright© 2016 arara Inc. 22
4.5.1.3 Transaction Sequence
Figure 4-13. Transaction Sequence
4.5.1.4 Verification Parameter
Number of Users (Cards) 100,000 users
Number of Departments 1,024 departments
Client Latency 0 msec
Number of Client Threads 10 We set ten to confirm performance
Server Connection Mode Round robin Connect in a sequential order
Copyright© 2016 arara Inc. 23
5 Results and Consideration of the Demonstration Experiment
5.1 Data Consistency
In any of the tests, we could not confirm the case in which consistency collapsed and which could not be approved.
However, because the current mijin always charges a fee (xem) when conducting a transaction using Mosaic (arara
coin) and there were some events where errors occurred due to insufficient xen balance. As we received an answer
from Tech Bureau, Corp. that they just charge fees as a countermeasure against malicious API attacks when placed in
a standard and public environment, and it is possible to set the fee as zero; therefore, we determined that this was not
particularly a problem.
When we conducted Test 4.5.3 Consistency Confirmation 2 (Transactions to four servers for one
department/service), a phenomenon frequently occurred; when the transaction date and time, sender, receiver, and
transaction amount were the same, the result of the transaction will be neutral, an abnormal status because they were
overlapping transactions. We believe that a mechanism to prevent overlapping transactions functioned on the mijin
side when we conducted the same transactions at the same time. We think that we should have conducted tests to do
the transactions by changing the transaction amount in each case.
Regarding fault tolerance, we rebooted at fixed intervals while conducting transactions but we could confirm from
the logs that synchronization normally completed after recovery and the fact that we could confirm past transactions
with the recovered server; therefore, it was not particularly a problem.
5.2 Performance
5.2.1 Server Load
When the network distance between the arara coin server and mijin server was short and latency was small, the
mijin server’s load average did not exceed 2 in any of the tests. Therefore, if it is about 100 transactions per second,
we believe that we can do the processing without any problem.
On the other hand, the AP server side on the arara coin side had a somewhat higher load than that of the mijin
server. We believe the cause was the use of CPU power for calculating hash and signing to create the request data to
mijin.
The runtime error infrequently occurred on the side of the arara coin server. Its cause is still unknown but the
occurrence rate was extremely low; therefore, we believe we can cope with it by retrying.
5.2.2 Transaction Approval Confirmation Processing
Initially, we assumed the approval check in Figure 5 below in all tests, but we found out that the runtime error
occurred on the client side with high probability when conducting the confirmation request for the target transactions
(occurred about 80% of the time). We guess it was the specification to return twenty previous transactions, including
the target transaction. If conducting a check for each transaction, the specification would be to obtain and return the
data for the number of transactions x 20 cases; therefore, processing would become slow due to the logic related to
this condition, which would lead to cause errors. We think this is the future issue.
*As shown above, we conducted all tests under the condition of not carrying out the check.
Copyright© 2016 arara Inc. 24
Figure 5-1. Transaction Sequence
5.2.3 Transaction Performance
Any of the processing was about the same in terms of performance. The performance was about 3,000 transactions
per minute in multiple cards-to-1 department configuration and about 3,800 transactions per minute in multiple cards-
to- multiple department configuration. Considering the test data variation, we think we cannot conclude that the
characteristics of mijin caused the difference.
There is a report that the nominal value is several tens of thousands of transactions per second, and our results this
time were low but the server load in both of the tests was not high. Therefore, we think the cause was the lack of
processing capacity on the client side or insufficient optimization of the number of threads on the side of the arara
coin server. Therefore, there is a possibility of conducting more transactions but we found out that we could do 3,800
transactions per minute and 220,000 transactions per hour in these tests.
Table 5. Transaction Performance (Figure 4-2. arara Mijin Cloud Configuration Diagram 1 (Low latency: RTT average
is about 0.5 msec)
Multiple Cards-to-One
Department
Multiple Cards-to-Multiple
Departments
Number of Transactions (Per minute) About 3,000 transactions About 3,800 transactions
arara API Time (Right after the sequence
2- 4) About 600 msec About 700 msec
mijin Response Time (Sequence 3-4) About 10 msec About 10 msec
mijin Request Delay None None
Approval Time Unmeasurable (Seemed to be completed within several
seconds)
Copyright© 2016 arara Inc. 25
Results of the tests under the environment of high latency were strange. Considering the fact that mijin’s response
time was about five-fold and latency was about 150-fold, we did not think of it as particularly strange. On the other
hand, arara’s API time took as long as about 310 seconds. However, there was no server load at all; therefore, we
assumed that there was a bottleneck somewhere, and we investigated the cause.
In conclusion, the cause was that a mechanism of not putting an excessive load on the mijin server was coded in
the client program sample we used on the arara coin server that NEM development members released and NEM core
client API and accumulation of request cues occurred on the client side (use of SleepFuture).
Under the environment of low latency, it could still process 3,000 requests per minute without delay but under the
environment of high latency, it could not process 3,000 requests per minute and accumulated request cues on the
client side, which seemed to end up with an average processing time of 310 seconds.
We corrected the program to solve this problem and tested again, and we obtained results under the environment of
high latency that were equivalent to the results under the environment of low latency.
Table 6. Transaction Performance (Figure 4-3 arara Mijin Cloud Configuration Diagram 2 (High latency: RTT average
is about 75 msec)
No Program Correction
Multiple Cards-to-One
Department
Multiple Cards-to-Multiple
Departments
Number of Transactions (Per minute) About 3,300 transactions About 3,400 transactions
arara API Time (Right after the sequence
2-4) About 310 sec (Increasing
tendency)
About 310 sec (Increasing
tendency)
mijin Response Time (Sequence 3-4) About 50 msec About 45 msec
mijin Request Delay Yes Yes
Approval Time Unmeasurable (Seemed to be completed within several
minutes)
Table 7. Transaction Performance (Figure 4-3 arara Mijin Cloud Configuration Diagram 2 (High latency: RTT average
is about 75 msec)
With Program Correction
Multiple Cards-to-One
Department
Multiple Cards-to-Multiple
Departments
Number of Transactions (Per minute) Not measured About 3,100 transactions
arara API Time (Right after the sequence
2-4) Not measured About 114 msec
mijin Response Time (Sequence 3-4) Not measured About 108 msec
mijin Request Delay None None
Approval Time Not measured Unmeasurable (Seemed to be
completed within several
minutes)
Copyright© 2016 arara Inc. 26
6 Conclusion
(1) We found that consistency did not collapse according to the method of use, and it could stand against
about 200,000 transactions per hour.
(2) We found out that it was difficult to make falsification and could ensure data integrity due to the
mechanism of data synchronization.
(3) We found out that it had a high level of availability due to the distributed system.
(4) We believe that feasibility of the e-money system is highly possible in terms of consistency and
performance.
(5) Based on the above (1) – (4), the possibility of substantial cost reduction can be expected.