Hey folks,
A bit of news from our neck of the woods, tonight in testing we achieved in excess of 2000 transactions per second processing which is generally considered to be "VISA scale" (we achieved 2,400 to be more specific).
Over the past 6 months or so, there have been many developers that have publicly announced that their platforms can scale to handle x thousands of transactions. However, I'm yet to see any evidence of any crypto-platform achieving a few 100 outside of "perfect lab conditions", let alone a few thousand. Some of the platforms attempt to scale vertically to achieve the transaction throughput claimed, but these platforms require things like super-nodes in the network, with the power of a small super-computer (and the bandwidth to match) in order to achieve it.
In my opinion, all of these claims are bogus until evidence can be shown of said platform achieving anything close to VISA scale in the wild. That is the true test, with participants in different locations, with fast, slow and in-between nodes taking part. Super computer nodes do not count!
When I started the eMunie project, VISA scale was one of the many goals I set, and today we are a real step closer to being there. First a little brief on why we can do this (more information on this stuff will be available as soon as I can find some time between coding and testing to write it up).
The eMunie ledger can be partitioned into 1024 partitions, with nodes in the network supporting 1 or more partitions depending on the performance they have available. Fast nodes might support all of the partitions, very slow nodes may only support a few, but between them all partitions are present in the network multiple times providing redundancy.
Partitions contain channels which are owned by wallet holders, and contain the transactions for a particular "channel key". A partition may have millions of channels as the network grows, but most of the time, a large quantity of those channels will be inactive (not receiving or sending transactions), so a single partition of n channels needs only a finite amount of processing power managing it at any one moment in time.
Even the slowest of commodity hardware we have tested can process 100-150 transactions per second with ease, thus that is the baseline sustained performance metric for a partition.
This evening it was decided that we should finally test to see what is the burst limit of a single partition. We have been testing for quite some time with various loads between 50-200 transactions per second, but we've never actually pushed the envelope to see where it maxes out.
After some organization of testers, and the logistics of getting everyone ready to hit the network with a large amount of spam transactions for a short period, we let rip. The network produced over 4000 transactions in under 10 seconds, all directed toward a single partition, with a peak of ~2,400 tx/s....the network size, 12 nodes of varying configuration in various locations around the globe.
With sustained performance of ~150 tx/s per partition easily achieved, burst performance per partition of 2000+ and 1024 partitions, even if cumulative performance of all partitions is not a linear increase, I'd like to think we have enough performance capacity to deal with anything the network has thrown at it.
Here is a short video with a voice over, of that test taking place.
https://www.youtube.com/watch?v=n0YpFfgwudAYou can see the transactions leave from 2 of the 7 designated spamming nodes(in the command consoles), with the monitor displaying the total transactions seen in the network at any moment in time. The monitor updates every 10 seconds and you can clearly see the effect of network latency as all the transactions arrive at that node over the course of a few seconds.
Some of the slower nodes of course struggled a little for 20 seconds or so to catch up, with the faster nodes taking up the slack. All the transactions presented in the burst were processed by the network, all nodes had them within about 30 seconds (even the slowest) and these funds were available to be re-spent a few seconds later.
