I'm not sure this is the right place to post this (if not, could a mod move it?)
I've had this idea of a scaling solution to a crypto currency floating around in my head for the last few days. I propose that this system could easily support 4000 transactions per second. This system would not work well for multi-recipient payments, but would work well for once off transactions (like at a supermarket). For anyone with the time to read this, I'd like to know why exactly this wouldn't work, so I can stop thinking about it and get some sleep
Imagine that that you are a miner. You sort public-keys alphanumerically into 1000 different partitions. Think of each partition as a 'mini-ledger' that contains only transactions of specific public-keys. Suppose a public-key is in mini-ledger-258: this public-key will only be able to make transactions with other public-keys in mini-ledger 258. Suppose this network currently has about 4000 transactions per second. As thousands of transactions come in, all 1000 mini-ledgers grow. At some point, the collective size of all the mini-ledgers will approach 1000mb. The miner also has to append the current calculated balances of each public-key that was involved in a transaction at the end of the mini-ledger. No single transaction can have more than 2 recipients in it (as the list of balances could grow to be too large).
Once this is done, each mini-ledger is partitioned into 10 different pieces and each piece is hashed.
This will result in 1000 (each mini-ledger)*10(for each fragment) = 10 000 different hashes (each hash corresponding to a different mini-ledger-fragment).
These 10 000 hashes are turned into a string and Proof-of-Work is done on this string of 10 000 hashes. A suitable nonce is found and proof-of-work can be considered done. This is considered to be a 'block'. This block can be considered 'ledger-less', since it is mostly made up of only the 10000 indexed hashes. You then broadcast out this block to the network (a small file, maybe a 2 or 3 mb), as well as broadcast out all 10000 signed mini-ledger-fragments individually (1000mb collectively). Instead of a regular blockchain, we have a 'ledger-less' blockchain (each block made of 10 000 hashes) and 10 000 'mini-ledgers-fragments' (that hash to the same hashes in the 'ledger-less' block). Thus the blockchain is decoupled from the actual transactions.
Now imagine you're a full node running a super-computer. You receive this ledger-less block. You verify that the proof of work was done on these 10000 hashes. You now receive one of the mini-ledgers-fragments. This mini-ledger-fragment will be about 0.1mb in size. You confirm that this particular mini-ledger hashes to one of the hashes in the ledger-less block. You then do this for all 9999 other mini-ledgers, only accepting them if they hash to one of the hashes in the ledger-less block. If everything seems to be in order transaction wise and balance wise, you broadcast out to the other nodes.
You can also imagine that there are databases that store all mini-ledger-fragments in them. These databases just service requests for particular mini-ledger-fragments.
As a regular node with average bandwidth, you can easily download the ledger-less blockchain since it is relatively small. Downloading all 10000 mini-ledger-fragments is impossible due to bandwidth issues though. However, getting hold of all 10000 mini-ledger-fragments is not needed. You as a regular-node can choose to only store the history of the ledger-less blockchain as well as a single, or multiple mini-ledgers back to their respective genesis fragments. For instance, if you wish to keep track of mini-ledger-653, you can download back to the genesis fragment. This would be about the same size as downloading a Bitcoin block-chain of equal length. Suppose there are 10000 nodes with 1mb/s lines. Each of these nodes are able to verify individual mini-ledger-fragments if they wish. If they store a particular mini-ledger, they can also verify that the accounts have the correct balances. Therefore an individual node can still verify that certain mini-ledgers are authentic, but need not download all 1000 mini-ledgers. Collectively, regular nodes will have complete copies of all the mini-ledgers in existence. Thus when a miner releases their 'ledger-less' blockchain and 10000 'mini-ledger-fragments' to the network, the regular-nodes will be collectively hunting down and looking for errors in the new proposed ledger-less block. If an error is found in any of the mini-ledgers-fragments, it is broadcast to the network and propagated easily, since the file is 0.1mb in size.
The biggest advantage of this setup is that of error propagation and verification is quick and error checking is easily partitioned. Suppose you are a node that finds a public-key X on mini-ledger-345 that is including a transaction that they do not have funds for. This is an obvious error, but how do we let all other nodes know? This is very easy: you just send out a list of hashes corresponding to the mini-ledger-fragments of interest for pub-key X. If you send out 10 of these hashes, a receiver of these 10 hashes needs to only download the 10 mini-ledger-fragments corresponding to those 10 hashes, verify them on their own copy of the ledger-less-blockchain, then analyze the balances. These 10 hashes would go back at least 10 blocks in the ledgerless blockchain, so the balances you're seeing can be regard as final and conclusive.
