Page Comparison

...

1. 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.
2. 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).
3. 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 

   Mathinline
   host 7bf7a548-f937-390d-b7ee-64c4940fe12e body \text{score}(b) = \sum_{b^\prime \in DAG(b)} \text{pca}(b^\prime) + \text{pce}(b^\prime)

   , 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 

   Mathinline
   host 7bf7a548-f937-390d-b7ee-64c4940fe12e body \text{pce}(b) = f \cdot \sum_{b^\prime \in \text{ack}(b)} \text{pca}(b^\prime) + \text{pce}(b^\prime)

   . 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.