I know this is not really IPFS-related, but I wanted to share with you an idea to mitigate the electric consumption of the Proof of Work mechanism.
But before that, a short reminder: When a miner wants to mine a new block in the blockchain, he uses bruteforce and tries a large quantity of nonces. A nonce is a number that we add to the block’s data during the process of mining. The perfect one is the one that makes the hash of the block begin with a fixed number of zeros. The first miner who finds it can add to himself a reward in the next block of the blockchain.
Ok but what can be optimized here?
Well, the miners do not work hand in hand, and what it implies is that 2 different miners can try for the same nonce separately, resulting in a waste of electric power. I assume that, even if the nonces are chosen randomly, 2 miners trying for the same nonce happens rather often, given the enormous amount of data all the miners of the network process each second.
Ok, now to explain my idea, let’s simplify a little bit. Imagine that there are only 10 miners in the network, identified by a letter ranging from A to J. If we want to be sure that 2 different miners can never try for the same nonce, we can make the miner A try all the nonces ending with ‘0’, the miner B try all the nonces ending with ‘1’, the miner C all the nonces ending with ‘2’, and so on until miner J.
But how can we be sure that the miners follow this separation when mining?
What we can do is use the peerID (or in this example, their letter) of the miners to determine wich nonces they are allowed to mine. Let’s consider the function
getMiningOffset(peerID)→offset. As you can see, it takes in argument the peerID of the miner and returns a positive integer between 0 and 9, the offset. The allowed nonces for the given peerID are all the nonces matching
offset modulo 10.
And if a miner manages to find the correct nonce but it isn’t one of his allowed ones, then his reward is denied by the network, so he has no incentive whatsoever to mine where he is not allowed to.
But what if a new miner arrives in the network?
Indeed there are issues with this naive approach, and adding a new miner is not the only one. It is practically impossible to have a perfectly bijective function with such small codomain.
To circumvent that, the
getMiningOffset function can return values in a very large set (codomain), for example all the positive integers below 137 438 953 472. Why this number? Well, firstly because it is very big and thus it is very unlikely that 2 different peerIDs map to the same offset (collision risk), but also because it is a power of 2, so doing the binary addition is very quick to do. So for instance, the allowed nonces for miner A would be all the nonces matching
getMiningOffset('A') modulo 137 438 953 472.
So what do you think of this idea? Maybe I am completely mistaken and 2 miners trying the same nonce is very uncommon. Anyway thank you for reading!