Im very excited to be working on implementing my ideas on xpb! After discussing my whitepaper with xpbcreator, weve decided to roll out the implementation in four major phases, one of which wasnt mentioned on the whitepaper. I recommend reading the whitepaper before this post if you want to follow along. The four phases are:
1) Delegated Proof of Stake
2) Subcurrencies
3) Contracts Graded by Creator
4) Contracts Graded by Delegates
In the whitepaper, I clearly spelt out how #2-3 and most of #4 can be implemented. However, one shortcoming of the paper is that I didnt describe how the tradeable contracts can be scored in a trustless way. I put forth some ideas, some mention of miners as information gatherers, but no clear way on how to implement it. Evidently, this is an important part of the system.
There would be some problems with using the proof of work miners as information gatherers. First, it may be difficult to provide a clear incentive for them to actually gather the information. Second, dishonest miners may report the wrong information, with no clear repercussions. It enough dishonest miners provided the wrong information, the contract would be incorrectly graded, and with no recourse. The higher the value of the contract, the greater the incentive to score dishonestly, with no long-term repercussions as the miners are all anonymous. Theres also the potential for a hashing power attack: even if 90% of future blocks have to agree, and most miners are honest, someone would only have to temporarily ramp up hashing power to 9x that of the current networks power for 200 blocks to determine any outcome.
Implementing delegated proof of stake solves these issues. We can now require nearly all of the delegates (say 90%) to agree on the data points before a contract is graded. Each of the delegates can be required to post a bond in order to supply a data point, which they forfeit if the rest of the network disagrees. That bond could also be imposed on proof of work miners, but aside from losing that bond, delegates face the even greater penalty of being voted out of being a delegate if they constantly gather incorrect information. By default, clients can elect to stop voting for a delegate that provided false information. Finally, it would be nearly impossible and financially prohibitive for a dishonest actor to become 90+% of the delegates for the sole task of grading contracts inaccurately. In the case where an attacker gains 10%+ of the delegates and attempts to block consensus, well need to figure out a resolution mechanism (still in the works).
Delegated proof of stake also has the added benefits of securing the network more securely and at a fraction of the cost of proof of work. Some may argue that delegated proof of stake places control of the network in the hands of the few, but the rebuttal is that every single proof of work cryptocurrency already has this problem anyway, and in a worse way. On the coin with the largest market cap, just four mining pools together control 50% of the network. Since the consolidation of power on a network happens regardless, proper rules and incentives can much more effectively deter and prevent dishonest activity on the network. The cost of having a delegate process a block is very cheap, since no proof of work is required. In the case of Pebblecoin, this should also make network propagation times much faster given the slowness of the boulderhash algorithm.
Steps 1-3 are basically already planned out. As xpbcreator said, well roll out a testnet for #1 in two weeks time. There are still a few decisions to be made for #4. One is to fully plan out conflict resolution if delegates - be they honest or dishonest - disagree on data points, or if a malicious client creates a difficult-to-gather data point. Another is to fully flesh out the scraping language that will be required to turn data gathered from web-pages (usually HTML data, but maybe JSON and plain-text as well) into data points to be placed into the blockchain. They key is to be able to use well-known sites, such as Yahoo and ESPN, as data sources, so the scraping language must be flexible, but it must not be too complex so as not to be prohibitive to run.
Any comments on the approach and whitepaper would be very appreciated!