Seed - Literature Review - Inefficiencies in Proof-of-Work (Part 3)
This literature review will focus on the flaws surrounding proof-of-work, how it causes a misalignment of interests in users, the inefficiencies of the mechanism, and explored alternative mechanisms.
Inefficiencies in Proof-of-Work
The next consequences to address are those that stem from the proof-of-work mechanism’s inefficiencies. Proof-of-work forces miners to do duplicate work in a race with each other, each attempting to be the first miner to solve their block. This means multiple miners are validating the same transactions, and then discarding their work once they see a new completed block to mine. Once all the transactions have been validated, but a finished block is still not received from other miners, the mining system has miners keep trying to find a hash for their block that starts with a set amount of zero bits [1][2].
The energy waste of proof-of-work is also a terrible side effect that is required to maintain its security. This artificial work for proof-of-work both throttles the system, as well as wastes processing power doing work whose whole purpose is to simply determine which miner gets the right to determine the current block. The proof-of-work mechanism boils down to simply being a solution to a synchronization problem. The equivalent problem, if written in a threaded software program, would be one where multiple threads want to write to the same buffer while validating what the other threads wrote. The proof-of-work solution is to keep randomly guessing a number, and have the first thread who guesses the correct number being allowed to write to the buffer. The system is secure and reliable at decentralizing block creation, however inefficient in how it goes about these goals.
If we analyze the problem through the lens of a synchronization problem, as mentioned before, we may find different alternatives that may be more efficient. These alternative solutions to the synchronization problem could be letting the threat with the most to lose write to the buffer, which is very similar to proof-of-stake. We can theorize other solutions following this model which do not require the wasteful work, such as letting the last trusted thread nominate the next thread who gets to write. This does away with the energy wastefulness of proof-of-work specifically, however it doesn't address the bottleneck this extra step puts on the system.
What this mechanism causes is a delay between transaction propagation and block propagation. In layman's terms, it means that there is a artificial delay between when a user says “I paid Bob $10”, and from when Bob will see a block that has a transaction notifying them that they received the $10. This delay exists in all competitive mechanisms, not just proof of work, however proof-of-work is the only mechanism that does it in a energy-wasting manner rather than strictly a time wasting manner. This extra step between transaction propagation and block propagation needs to be addressed, as it’s been an accepted requirement for proof-of-work alternatives that remains a bottleneck in all the systems.
[1] Nakamoto, S. (2008). Bitcoin: A peer-to-peer electronic cash system.
[2] Decker, C., & Wattenhofer, R. (2013, September). Information propagation in the bitcoin network. In Peer-to-Peer Computing (P2P), 2013 IEEE Thirteenth International Conference on (pp. 1-10). IEEE.
Thank you for reading! If you have any comments, criticisms or concerns, please leave a comment, or if you enjoyed this analysis please like and follow! Part 4 will come out tomorrow.