Z-DAG: A Practical Performance Analysis
Zachary ColeWhiteblock, Inc.
zak@whiteblock.io

Nathaniel Blakely
Whiteblock, Inc.
nate@whiteblock.io

Abstract— The following document outlines a performancebenchmarking analysis of Syscoin’s Z-DAG implementation.
This paper describes the testing methodologies employed by theWhiteblock team within these initiatives and presents the resultsof these efforts. All tests were conducted on the Whiteblock
Genesis blockchain testing platform. Each test series wasengineered to observe the effects of various environmental
conditions on application performance, specifically in regard tocapabilities concerning transactional throughput which consistently presented in the range of 14,000 - 30,000 transactions persecond (TPS) in an environment which emulated high degrees ofactivity under realistic Wide Area Network (WAN) conditions.
While results are substantially higher in comparison to thoseachieved by alternative contemporary blockchain systems, it isimportant to note that these tests were designed only to observe
the practical performance of Syscoin’s Z-DAG implementationand not the Syscoin platform as a whole. As such, theseresults should only be considered to reflect the capabilities ofsaid implementation and may not be indicative of the holistic
performance of the platform itself.

I. INTRODUCTION
Inspired by Satoshi Nakamoto’s novel concept of a Bitcoin
snack [1], the Syscoin platform is an early Litecoin fork
which provides an additional masternode system (similar tothat presented by Dash) in order to provide an asset layer
suitable for implementation within Proof-Of-Sale systems.
Although it is a mature client which was first presented in2014[2], additional features have been continually developedand introduced with the latest version presenting the Z-DAG
implementation analyzed within this report.
The Zero-Confirmation Directed Acyclic Graph (Z-DAG)
implementation intends to achieve higher degrees of transactional throughput by providing near instant settlement
in a manner that substantially reduces the costly overhead
associated with Bitcoin’s transactional confirmation processes[3]. Most blockchain systems are able to provide such
performance at the cost of security which often consecutively
presents some degree of vulnerability and the potential to
execute double-spending attacks. This issue appears to beadequately accounted for within the Z-DAG implementation
which eliminates the possibility to engage in such attacks
through its mechanism to flag any potentially questionabletransactions and defer further validation to Proof-of-Work(PoW). Syscoin is merge-mined with Bitcoin, a function
which allows for the mining of more than one cryptoasset
without the need for additional proof-of-work. [4]. This twotiered consensus mechanism probablistically allows for realtime settlements which enable a significantly higher degree oftransactional throughput without sacrificing the robust security

Daniel Choi
Whiteblock, Inc.
daniel@whiteblock.io

provided by PoW consensus [4].
The intent of these tests was to validate Z-DAG performance in regard to transactional throughput under a variety ofenvironmental and network conditions that generally inhibit
the capabilities of most blockchain systems. It is important tonote, however, that these test initiatives were focused entirelyon the practical performance of this implementation and do
not account for any additional analysis pertaining to thesecurity of the Syscoin platform as a whole.

II. M ETHODOLOGY
A. Testing Methodology
Each test case was designed [5] to observe the effectsof particular environmental conditions on the performanceof the Z-DAG implementation. This iterative process of
isolating particular variables within a highly controlledenvironment ensured the results were repeatable, objective,and deterministic.
After defining the primary metrics of interest, a list ofperformance-impacting variables was identified and a baseline
profile for performance was established to act as a control inorder to provide a point of reference for future test results.
This baseline profile can be referenced in Table II and wasestablished by running the tests in an environment free ofadditional network conditions and impairments.
Within consecutive tests, a new network environment andblockchain was provisioned for each test series. Every test
was conducted within an identical and controlled environment
where the specified topology provided the same constantperformance with the exception of the variables beingobserved.
In order to ensure the integrity of the resulting data, eachtest series environment consisted of a newly deployed network,
an appropriate amount of nodes which were properly peered
with one another, and one dedicated master node whichminted the Genesis block. The role of each node was specified
as either asset sender or receiver. Assets were then evenly
distributed among sender nodes according to the demands ofeach test case.
Upon the completion of each test, average test start time,
average total time, amount of assets processed in receiver’s
array, percentage completed, and average throughput wereobserved and documented for reference.

III. T ESTS
A. System Specifications
These testing initiatives were conducted on the Whiteblock
testing platform [6], a cloud-based infrastructure engineered
specifically for blockchain testing. The system specifications
for these particular tests were configured to ensure anoptimal run-time environment according to the requirementsof the Syscoin client. The following table outlines thesespecifications.
Item
Operating System
Syscoin Core Version
Whiteblock Genesis Version
Whiteblock Syscoin Library Version
CPU Platform
Base Frequency (GHz)All-Core Turbo Freq (GHz)
Single-Core Max Turbo Freq (GHz)vCPUs
RAMStorage
Max Number of Nodes in Network

Description
Ubuntu 18.04 LTS
4.0.0.0-80da881
Diet-v1.1-stable
v.3.1
Intel Xeon Skylake Processor
22.7
3.5
3410GB SSD
30

TABLE IS YSTEM S PECIFICATIONS

1) Control Group:
Case A
3024339250
110

Case B-Case C-TABLE II
C ONTROL G ROUP

2) Network Latency:
The purpose of this test was to determine how theSyscoin network would react to varying degrees of latency.
Latency is the amount of time it takes for a node to transmit
a message across the network to another node. This timing
is critical to performance and security as high latency canpresent adverse effects, such as race conditions, which canpresent attack vectors within most blockchain systems, andresult in suboptimal performance[7], as demonstrated in thistest series where increasing round trip latency resulted in thesubstantial degradation of total transactional throughput.

Case B
3024339250
11100

Case C3024339250
11150

TABLE IIIN ETWORK L ATENCY3) Number of Assets:
In Syscoin, an asset transfer is logically equivalent toa transaction, therefore an increase in the number of assets
consecutively increases the number of transactions within thenetwork. This increase also results in additional overhead
which can further degrade performance and effect the numberof transactions which the network can successfully process,which is demonstrable with this test series where an increasing
amount of asset transfers within the network resulted intransactions dropping from the memory buffer. For this testseries, varying degrees of traffic volume was applied within
the network in order to measure this effect on performance.
Case A
30243
3212501124

Total Nodes
Master NodesSending Nodes
Receiving Nodes# of Assets
Tx per Assets
Waiting Period (s)Network Latency (ms)B. Test Conditions & Topology

Total Nodes
Master NodesSending Nodes
Receiving Nodes# of Assets
Tx per Assets
Waiting Period (s)Network Latency (ms)Case A30
24339250
1150

Total Nodes
Master NodesSending Nodes
Receiving Nodes# of Assets
Tx per Assets
Waiting Period (s)Network Latency (ms)Case B30
2433302501124

Case C30
243339250
1124

TABLE IV
N UMBER OF A SSETS G ROUP4) Number of Nodes:
In this test series, the total number of masternodes was
manipulated in order to observe the effects of this varianceon total throughput. The number of nodes in the network
has a direct effect on the propagation of the transactions
where a higher population of healthy nodes should result ingreater propagation times. A base amount of network latency
was also included in these tests to ensure the results wereindicative of real-world performance.
Total Nodes
Master NodesSending Nodes
Receiving Nodes# of Assets
Tx per Assets
Waiting Period (s)Network Latency (ms)Case A
10433
9250
1124
TABLE VT OTAL N ODES

Case B
1593
3
9250
1124

Case C
2014339250
11245) Doubled Latency on a Percentage of Nodes:
The ability for a network to optimally perform under thepresence of disparate nodes which exhibit higher degrees of
network latency is necessary in order to ensure the long-term
health of the supporting application layer. Performance canbe substantially affected by high degrees of latency, even
if only experienced by a minority of the nodes within anetwork. This test was designed to analyze Z-DAG’s ability
to effectively handle communications and messaging whenvarious portions of the nodes within the network experienced
high degrees of latency. In this test series, twice the amountof the average network latency was applied to a percentage
of nodes in order to observe how these conditions affectedperformance.

Total Nodes
Master NodesSending Nodes
Receiving Nodes# of Assets
Tx per Assets
Waiting Period (s)Network Latency (ms)Nodes with Double Latency (%)

Case A30
24339250
11240

Case B3024339250
112410Case C30
24339250
112420TABLE VI
D OUBLE L ATENCY ON A P ERCENTAGE OF N ODES

Fig. 1.

Effects of Latency on TPS

As demonstrated in the previous tests, network latency
had the most significant impact on performance. A large
amount of latency between nodes resulted in a longer periodof time for transactions to propagate throughout the networkand receive confirmation. This reduced the rate at which thenetwork could process these transactions in a secure manner.
The results in Fig. 1. indicate that the test failed to complete
when network latency was >150ms between each node. It is
important to note that this is a very high degree of latency
that may not be commonly experienced in a live production
network, however, even in this case, it would likely onlyoccur within a smaller percentage of nodes in the network.

IV. RESULTS
A. Control
C. Number of Assets
Parameters
Asset sends per block
Avg tx per second
High % tx completion
Low % tx completion
Minimum completion %Total time average
Total assets

Series A
250
145,542.92
0.67
0.67
97
16138
9Series B
250
111,619.33
0.67
0.67
97
20313
9

Series C
250
114,572.75
0.67
0.67
97
19832
9TABLE VII
C ONTROL G ROUP R ESULTS

Series A
250
45,440.54
1197
117,112.66
21

Series B
250
46,843.70
1197
173,328
30

Series C
250
60,158.00
1197
163,221.66
39

TABLE IXN UMBER OF A SSETS G ROUP R ESULTS

B. Network Latency
Parameters
Asset sends per block
Avg tx per second
High % tx completion
Low % tx completion
Minimum completion %Total time average
Total assets

Parameters
Asset sends per block
Avg tx per second
High % tx completion
Low % tx completion
Minimum completion %Total time average
Total assets

Series A
250
15328.43
1
197
151,204.66
9

Series B
250
8676.771.07
0.88
97269,367
9TABLE VIIIN ETWORK L ATENCY G ROUP R ESULTS

Series C-Contrary to our hypothesis, an increase in the number ofassets had a positive correlation with transactional throughput,as demonstrated in Table IX. This is accounted for because theSyscoin client is optimized for higher degrees of transactions.
Some of these optimizations include the parallelization oftransaction verification and disabling of Nagle’s Algorithm,
however, further analysis should be conducted in order toobjectively determine the cause of these results.

D. Number of Nodes
Parameters
Asset sends per block
Avg tx per second
High % tx completion
Low % tx completion
Minimum completion %Total time average
Total assets

Series A
250
38,387.39
119758,985
9Series B
250
34,524.72
119766,894.33
9Series C
250
27,570.61
0.96
0.85
9788,427.66
9TABLE X
N UMBER OF N ODES G ROUP R ESULTS

A higher population of nodes within the network reduces
total throughput since transactional payloads may experience
an increase in the average number of network hops in orderto reach the receivers. Syscoin compensates for this throughits implementation of a broadcast-then-verify method ofannouncing transactions. Assuming this implementation isoptimal (i.e. the Syscoin client broadcast its messages in0 ns), there is still the delay from increased network hops.
Which can be expressed as:hopsXlink(n − 1) + logic(n)

(1)

n=1

ACKNOWLEDGMENT
A number of different people contributed to this research.
We would like to thank Jagdeep Sidhu from Blockchain
Foundry, Qi Trey Zhong of USC, Eric Lim from theWhiteblock team, and Trenton Van Epps from the Ethereumcommunity.
R EFERENCES

Where link presents the time it takes to send a transaction
over link n and logic presents the time it takes for node n toprocess and relay the transaction to its peers.
E. Double Latency on % of Nodes
Parameters
Asset sends per block
Avg tx per second
High % tx completion
Low % tx completion
Minimum completion %Total time average
Total assets
Percentage of Nodes

Higher throughput was observed with an increase in
the number of assets sent to other nodes in the network,
demonstrating the network’s ability to adapt to a higher
volume of network traffic and activity. This can be partiallyattributed to Syscoin’s ability to use multithreading in theprocess of verifying transactions by allowing workloads tobe effectively distributed among available resources.
Contrary to our initial hypothesis, an increase in the numberof nodes resulted in a fairly low performance cost. This canbe due in part to the propagation times between sending
and receiving nodes, however, it is recommended that amore substantial analysis be conducted in order to derive
an objective conclusion.
Overall, the Z-DAG implementation provided a higher
amount of transactional throughput without sacrificing asignificant degree of resilience and reliability to adversenetwork effects.

Series A
25027129.98
119784107
90%

Series B
25029359.55
119778109.33
910%

Series C
25028574.82
119780540.33
920%

TABLE XID OUBLE L ATENCY G ROUP R ESULTS

A minority of nodes experiencing suboptimal network
conditions does not seem to present a significant performancebottleneck within the Syscoin network. This indicates theresiliance of the Sycoin client when presented a substantial
degree of suboptimal nodes in the network, however, further
analysis should be conducted in order to objectively identifythe specific limitations of this tolerance threshold.
V. CONCLUSIONS
Syscoin’s Z-DAG is significantly impacted by the effects oflatency on the network, as demonstrated by results B, however,this isn’t unexpected within any asynchronous distributed
system. It is worth noting that the network was able tocompensate for high degrees of latency when these conditions
are limited to a minor population of nodes within the network.

[1] Bitcoin Talk Forum. Internet: https://bitcointalk.org/index.php?topic=423.0, Retrieved on Jan. 30, 2019[2] Bitcoin Talk Forum. Internet: https://bitcointalk.org/index.php?topic=587080.0, Retrieved on Jan. 30, 2019[3] Quan-Lin Li, Jing-Yu Ma and Yan-Xia Chang, “Blockchain Queueing
Theory," arXiv preprint arXiv:1808.01795, 2018.
[4] Judmayer A., Zamyatin A., Stifter N., Voyiatzis A.G., Weippl E.
(2017) Merged Mining: Curse or Cure?. In: Garcia-Alfaro J., NavarroArribas G., Hartenstein H., Herrera-Joancomartí J. (eds) Data Privacy
Management, Cryptocurrencies and Blockchain Technology. DPM 2017,CBT 2017. Lecture Notes in Computer Science, vol 10436. Springer,Cham[5] Syscoin Whitepaper. Internet: https://www.syscoin.org/assets/whitepaper.pdf, Retrieved on Feb. 13, 2019[6] Whiteblock GitHub Repo. Internet: https://github.com/
Whiteblock/syscoin_test, Retrieved on Mar. 3, 2019[7] Whiteblock Website. Internet: https://www.whiteblock.io/,
Retrieved on Mar. 10, 2019[8] Q. T. Zhong, Z. Cole, “Analyzing the Effects of Network Latency on
Blockchain Performance and Security Using the Whiteblock Testing
Platform," Internet. https://www.whiteblock.io/library/
analyzing-effects-network.pdf, Retrieved on Mar. 12,2019.