Week 5 & 6: Proof Of Work History

Hello everybody, and welcome back to my blog!

This week will combine the past two weeks of work for my senior project. The fifth week was dedicated to fixing small bugs in the proof of stake section of my coding project as well as refining the graphic user interface that displays the blockchain’s information. The main visual update was a small addition that visualizes the proof of stake consensus method. I have added a visual aid to display that when one has staked a large amount over the staking threshold (the minimum amount of stake to become a validator) they have a relatively higher chance of being picked in the lottery as seen here:

The sixth week begins the bulk of the research portion of this project. I began conceptualizing a new proof algorithm! It is a variation of an algorithm I’ve already discussed. I have decided to call it “Proof of Work History.” This is an algorithm that utilizes the foundations of proof of work while incorporating a sort of trust score for each mining node in the network. One in which, chain validators begin mining to find a proper hash for the block that would allow it to be added to the chain. Then, as these mining nodes contribute to historical block mining success their trust score is increased proportionally to how much work they have done. If these nodes quit mining they would maintain a trust score but it would decay exponentially over time. This trust score would enter them into a weighted lottery similar to the one I have described for the proof of stake algorithm in the past. This could potentially be beneficial because it wouldn’t require a constant cost of electricity in order to still be a trusted validator. A concern I could see with this is if a trusted node were to change owners. Say a wallet had a relatively high associated trust score but stopped mining, how can we maintain that the person remains trustworthy at this time? One potential approach could be making the trust score both device and IP address specific. Say a node were to change Wifi IPs or go offline we could reset its trust score to zero which would not make them significantly worse off than their situation in a common PoW system. I will review this concept with my off-site advisor and continue to refine this algorithm while inventing new ones with the goal of implementing a few of them.