The Whiteblock team has released the results of our 8-month research initiative which aimed to analyze the performance and transactional throughput of Syscoin’s Z-DAG implementation.
We utilized Whiteblock’s proprietary testing software (of which the open source version can be found here) and each test was designed to observe the effects of various environmental conditions on application performance with a focus on identifying maximum viable transactional throughput (read: wth is the tps??!). It’s important to disclose, however, that we only analyzed the Z-DAG implementation in particular and didn’t test the entire Syscoin platform or security, so take that as you will and lets’ dive in.
Bird’s Eye View
For those unfamiliar, Syscoin is an early Litecoin fork that employs an additional masternode system to provide an asset layer suitable for implementation in point-of-sale systems. Traditionally, blockchain confirmations are intended to ensure a certain degree of security so that transactions are protected against double spending. This confirmation system usually makes for lousy transactions speeds however… blockchain is not known for super fast and secure transaction speeds (that’s just the promise!).
Z-DAG is Syscoin’s innovative solution to the blockchain scalability problem whereby transactions per second (TPS) are bottlenecked by transaction confirmation times.
Syscoin’s zero-confirmation directed acyclic graph (Z-DAG) is a proposed solution to circumvent the throttled transaction throughput that’s often observed in other blockchain technologies — Bitcoin‘s lightning network is another proposed solution to this issue. Z-DAG uses the Syscoin masternode network as a high-throughput relay network to confirm the transaction in the background.
Tests, Methods, More Tests
We ran a series of tests designed to observe the effects of particular environmental conditions on Z-DAG performance. The iterative testing process we use isolates particular variables so that results are repeatable, objective and deterministic. For an in-depth look, check out our report.
Our methodology includes setting up a new network environment and provisioning a new blockchain for each test series. Every single test was conducted within an identical and controlled environment. Each test series environment also consisted of a newly deployed network. Simply, we painstakingly restarted a new network and new blockchain for every single test we ran to make sure conditions were stable.
We identified a baseline profile control group by running the tests in an environment free of any network impairments and conditions. Using this profile we were able to identify the performance-impacting variables such as — Total Nodes, Master Nodes, Sending Nodes, Receiving Nodes, and more.
With those variables in mind we ran a series of isolated tests. We tested network latency, varying amount of assets, varying amount of nodes, and hyper increased latency on a percentage of nodes.
You can find the full test results in the actual report but here are some interesting highlights. As expected network latency had a strong impact on performance, a large amount of latency between nodes resulted slowed propagation times. This reduced the rate at which the network could process transactions in a secure manner. With latency we noted an average TPS of 15,328.43 (50ms of latency) and 8676.77 (100ms of latency) respectively. Interestingly, at 150ms of latency the test failed to complete, though to be fair 150ms of latency is high and may not be commonly experienced in a live production network. Without any network conditions (zero! Perfect weather smooth sailing!) at all we saw tps ranges from 111,619 — 145,542.
Shilling and Meaning
These results are not conclusive in that it does not accurately depict or it’s impossible to deduct from these tests whether the Syscoin platform as a whole can deliver TPS at the rates subscribed above. Rather, it’s a performance test on the isolated Z-DAG system and we have yet to benchmark or audit the security of the Syscoin platform as a whole. An easy comparison to make would be testing a car’s engine and seeing that it runs exceedingly well… it would be unscientific and incorrect to deduce from engine performance that the car as a whole would go very fast without testing everything else in the car regarding the car speed as a whole.
This being said, the Z-DAG test results are promising, and we are excited to continue our partnership with the Syscoin team to help ensure the development of this technology and would love to see how this implementation affects the platform at large in the future. This is just a disclaimer, but if the Z-DAG is properly implemented, we can assume that the system itself will reflect similar TPS within the next version of Syscoin.