In the original MicroCash sources there was a multithreaded signing engine which allowed incoming transactions to be processed over many threads (ie CPU cores). This allowed the MicroCash transaction engine to process many times more transactions per second than it otherwise could.
By my estimation using the OpenSSL code this would allow 15000 transactions per second on the fastest single CPU hardware that you can buy right now. Visa state they handle about 1500 transactions per second on average and can theoretically handle 24000 per second globally (source). Using multi-cpu hardware I think the old MicroCash sources may be able to handle somewhere between 30000 and 60000 per second if there was no network limitation.
A major benefit with MicroCash compared to Bitcoin is that each transaction only requires two cryptographic verifications compared to Bitcoin which may require hundreds and further CPU processing. A major problem with Bitcoin is the scalability of its transaction engine, in my estimation Bitcoin would have major network forking with even 20 transactions per second on average. It currently only averages a little over 1 transaction per second (source). The talented Bitcoin developers are aware of this problem but without a major fork and reworking of Bitcoin it is impossible is improve this much. I can easily see many in Bitcoin unwilling to change the old input/output system of Bitcoin and staying on the old fork which would present major branding challenges to Bitcoin.
The problem with MicroCash before was the actual network and message handling wasn’t as multithreaded as well as it could be. Since I am now using a UDP engine for MicroCash I also redesigned the message handling system to be completely multithreaded and multithreaded in such a way to minimize contention for resources. This should mean on a system fast enough the networking limitation should be minimized.
Something often overlooked when talking about transactions per second in the cryptocurrency circles is what that means for a P2P network. P2P networks ARE NOT the most efficient mechanism for communicating, there is a lot of overhead in running a network. There are of course many benefits to a P2P network but bandwidth and network efficiency isn’t one of them. I’ll quickly delve into this but it really deserves another post in itself.
Basically when someone tries to send a transaction in MicroCash they send it to other nodes on the network so they can all process and verify it*. When a node receives a transaction from another node they also have to pass it onto the nodes connected to them. These nodes will then do the same, the nodes they send to will do the same, etc, until the entire network has the transaction. So if you are connected to 10 nodes and one of them sends you a transaction you will then notify 9 other nodes about it. This means if a transaction is 256 bytes, you will send 9 x 256bytes .
Due to timing issues it is also possible those 9 other nodes will send you the same transaction, so in essence you may receive notification about this transaction 10 times and send it out 9 times. If you’re connected to 100 nodes this of course multiplies to receiving it 100 times and sending it 99 times worst case. You can see there is a lot of overhead in running a P2P network. What was originally a 256byte transaction multiplies linearly with the number of nodes you are connected to. Being connected to 100 nodes could mean a ~100x overhead.
There are algorithms to minimize this overhead in P2P, and I will end up using some, but the point remains in simple terms that P2P networking has a lot of overhead and you need to find ways to minimize this if you want to reach the theoretical maximum transaction per second hardware can actually achieve.
*I simplified what actually happens in MicroCash to make this easier to read, in real terms a transaction is not sent from every node but instead a message that a new transaction has arrived