Stress Testing the RaiBlocks Network: Part I

Captured from rai.watch during the stress test

Update: See Part II where I achieve a peak 306 TPS.

Introduction

RaiBlocks has been touted as one of the quickest and most-scalable cryptocurrencies on the market, but how do those claims stack up? In my previous article, I explored transaction speeds and found a median transaction speed of 1.7 seconds. Today I will be reviewing my recent experiment, conducted on January, 21st 2018 at approximately 11AM PST, where I rapidly spammed a large quantity of precomputed transactions from an inexpensive virtual private server (VPS) to see how many transactions per second (TPS) the RaiBlocks network could handle.

Preparing For The Stress Test

Custom script generating the PoW for 30k Transactions on an overclocked GTX 1070

Before we get started, let’s go over some quick background of how the network operates. In RaiBlocks, each account has its own blockchain (account-chain) and only the account owner can sign in transactions to their personal account-chain. Each node in the network has a local copy of all the account-chains forming the block-lattice. Like a conventional blockchain, each block in an account-chain contains the hash of the previous block in that chain; if a block’s previous hash isn’t in a node’s local ledger it isn’t seen as a valid block, but is cached for a short period in-case an incoming block makes that block valid. Because of this, there is a natural limit to how quickly a single account-chain can spam the network without a significant portion of the network rejecting many of the transactions, due to the fact that the incoming blocks haven’t fully synced with their local ledger. Therefore, in this test I created 100 accounts and sequentially spammed send transactions from these accounts. Since 99 transactions were spammed before sending the next transaction in an account chain, the network had a better chance at accepting these transactions because the previous transaction had enough time to propagate the network. Throughout this test, I also occasionally republished these past transactions so nodes have a higher chance of receiving them.

The following are the specifications of this experiment:

• 100 Accounts were created and populated with 300xrb (0.0003XRB) each. This required 200 PoW (send and open blocks) computations before the rest of the experiment can be precomputed.
• PoW for the 30,000 transactions (300 transactions per account, each sending 1xrb) were generated on a GTX1070 and took approximately 5 hours to generate.
• The transactions were broadcasted from my Digital Ocean droplet because of its strong internet connection. They were broadcasted as follows: {Account_A_1, Account_B_1, Account_C_1, …, Account_A_2, Account_B_2, Account_C_2, …}

Test Execution

The blocks were broadcasted from a $5/mo VPS because of its high quality internet connection. It should be noted that this experiment was performed on the RaiBlocks MainNet and propagated throughout real nodes across a variety of hardware. This is not a synthetic data center test.

Custom script broadcasting the precomputed blocks

It took the node 907 seconds (about 15 minutes) to broadcast all 30k transactions. The very limited VPS CPU strained during this period; I suspect a more powerful VPS could have processed the transactions faster.

Beginning of stress test (sped up 8x)

Ending of stress test (sped up 40x)

Results

Dashboard for my $5/mo Digital Ocean Droplet that broadcasted the transactions

It took the node approximately 15 minutes to broadcast all the transactions at an average transaction speed of 33TPS. The raiblocks.club 30 minute average counter maxed out at around 16.86TPS; the stress test lasted about 15 minutes, so we can infer that they also observed an average of ~33TPS.

Since there isn’t exactly a global state in a DAG-based cryptocurrency like RaiBlocks, different nodes experience a different transaction rate at different times. Community member Cronoh measured a peak of 120TPS on his local laptop node on a Wi-Fi connection. The peak 2406 transactions per minute on rai.watch results in about an average of 40 transactions per second for the minute it was averaged over.

Each RaiBlocks’ send transaction is about 260 bytes. This means that the 30,000 transactions, that took about 5 hours to compute on a GTX1070, inflated the ledger size by about 7.8MB. If the recipient generates all the corresponding receive transactions, that will add another 7.8MB to the global ledger. When account chain history pruning is released, this test will inflate the ledger by less than 50KB.

My Digital Ocean bandwidth peaked to about 44Mbps during the stress test. If a node had a lower bandwidth limit, the usage would have been spread out more over time and that node would be slightly desynced until it caught up.

Conclusions and Takeaways

In this experiment we showed that the RaiBlocks’ network can handle at least a sustained 33 TPS, while individual nodes were processing a minimum peak of 120 TPS. These results were limitations of this experiment and the node I was publishing from; I am quite confident in the network’s ability to handle a much greater transaction rate. Future work is to perform a multi-node publishing stress test or to find bottlenecks in my current stress test code.

Misconceptions

1. Note that the nodes that crashed or desynced were not due to insufficient CPU or internet bandwidth. Nodes on inexpensive VPSs and <10W computers held up perfectly fine during the stress test. The bursty nature of the UDP transactions may have crashed some routers with poor quality-of-service (QoS) or triggered other poorly configured networks. The Core team is currently working on lessening the bursty traffic generated by the rai_wallet/rai_node software and working on a scheme of data flooding that is more friendly to NAT and routers in general.
2. The transactions were precomputed for many hours on a GPU. The $5/mo VPS simply broadcasted the transactions, it didn’t have to do a PoW computation.
3. The network was not dysfunctional during this time and was not saturated. During this time other people’s normal transactions were processing at normal speeds.

Like stuff like this? Support me at:xrb_1y6fjssau9mhmnprwfxemfnahz759tx7qrdrfz7kbzd4jbkd4mgrurq7tfmf