Captured from during the stress test rai.watch Update: See where I achieve a peak 306 TPS. Part II 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 , 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. my previous article 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 (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 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. blockchain network 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 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. raiblocks.club 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 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. peak of 120TPS 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 Note that the nodes that crashed or desynced were . 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. not due to insufficient CPU or internet bandwidth 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. . During this time other people’s normal transactions were processing at normal speeds. The network was not dysfunctional during this time and was not saturated Like stuff like this? Support me at:xrb_1y6fjssau9mhmnprwfxemfnahz759tx7qrdrfz7kbzd4jbkd4mgrurq7tfmf

Chain

Too Long; Didn't Read

Discover Saakuru: Web3 Mass-Adoption with 0-FEES

Stress Testing the RaiBlocks Network: Part I

Too Long; Didn't Read

Coin Mentioned

Brian Pugh

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Stress Testing the RaiBlocks Network: Part I

Too Long; Didn't Read

Coin Mentioned

Brian Pugh

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES