Update: See Part II where I achieve a peak 306 TPS.
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.
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:
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.
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.
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.
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.
Like stuff like this? Support me at: