2017-12-22 --- ThresholdSpender High Threshold Invasion
Observations
- An "invasion" simulation starting with 10 threshold validators at 55 and 1 at 300, very quickly results in the 300 taking over; and indeed the population threshold climbing higher and higher.
- Similar to the group of validators with threshold ~55, the population after invasion is very inefficient at consensus, with long unused branches.
Evidence
- The tables below keep track of the mean/standard deviation and the full population descriptions. We see the mean rise very quickly.
- See the visualizations below.
Conclusions, Speculations and Future Work
- Even though it seems to be good for the network to have a small number of validators with high thresholds (c.f. 2017-12-21 notes), this is not a stable population configuration.
- Any population with a small variance in the thresholds will likely be inefficient and the higher the mean threshold the less efficient it will be. However, since high threshold invaders are successful, this seems to indicate that economic pressures are towards inefficient consensus. This provides further evidence that additional constraints in the protocol need to be in place, such as the decay of REV earned by validators proposed by Greg (though the details of this have yet to be worked out).
- Here's a crazy idea. Let's change the fork-choice rule from GHOST to something that more closely resembles proof of work, but where political capital is in place of the work. So the fork that should be built on would be the one with the most political capital in it. Specifically, the way we score a block in this rule is simply , where pca is the political capital attached to the block and pce is the political capital earned by the block. The pce function is defined (recursively) as . Note that proposal blocks have no acknowledgements, and therefore the sum is empty, thus earning no PC. This change could discourage forking because longer chains, with more PC, will always be selected over shorter ones.