Parallelizing a POS process
I’ve been thinking about different variations of the POS consensus mechanism, and how to improve its speed without compromising security and distributed nature of it. Below is the description of my idea of parallelized POS. I am looking for feedback and potential partners to implement something like this.
Normally, every time new block is minted it’s hash is generated and this hash is added to the next block. For a POS process to work well 50–100 nodes are pretty much all you need. My idea is to have multiple tracks, each with 50–100 nodes running POS process in parallel with hashing technique to tie it all together. The number of Tracks will be controlled by the amount of transactions system needs to process and by the number of nodes participating in the POS process.
What if we have a process where multiple blocks are minted in parallel by different groups of nodes. Let’s call them Tracks. Every specified time interval (I think we can mint a new block at least every minute maybe much faster) each Track would mint a new block and generate its hash. All blocks minted at the same hight of the chain would be called Level in the hight of the chain. Then all the hashes from the blocks on one level would be put into a Level Admin block to generate a Level’s hash. This Level hash will be put into all blocks on next Level. The number of tracks on each level could be controlled programmatically, it could expand every time there are more transactions to be processed and contract when the number of transactions has decreased. The Level block, in addition to the hashes of all the data blocks on its level, could hold additional information such as a number of blocks in the current level and a number of tracks initiated for the next level. A mechanism could be created that would specify what transactions would be verified by each Track. Each group of nodes will know what transactions to listen to. There are many ways to do that, for instance, a numerical value could be calculated for each transaction with values between 0 and 100 and if the system has to allocate transactions between 10 tracks, then the rules would be published that nodes in the first Track will be required to process transactions with numerical values between 0 and 10 and so on for other 9 Tracks.
Here’s the back of the envelope calculation. if such system could work, and if the POS process is set up for each track to produce a block every 30 seconds, and the size of the block is set to 2 mb (it could be much higher btw). That means we could have throughput of about 100–133 transactions per second (assuming average transaction is about 500 bites). In theory number of tracks system could support could be very high, with 100 tracks it would put the system above 10,000 tps, and we can go to 1000 or 5000 tracks. If the Level Admin Block is also 2mb that block couldn’t hold over 7000 hash strings plus all the additional data. If need be this particular block could be bigger but at 7000 tracks system would be able to process over 700,000 tps which should be more than enough for any general purpose blockchain.
Here comes a disclaimer, I am not a scientist, I am new to blockchain and cryptocurrencies, I am just reading and trying to learn as much as I can just like everybody else. If any of this makes sense or not, please comment or get in touch with me. This may be an obvious or silly proposition, any feedback would be appreciated.
