On a less centralised Proof of Stake setup

The main idea: set the chance of being selected as a validator proportional to the square root of one’s stake, but allow reward to remain proportional to the stake itself.

0. Posts on this blog are ranked in decreasing order of likeability to myself. This entry was originally posted on 08.01.2025, and the current version may have been updated several times from its original form. 

1.1 Trying to limit the alleged tendency of Proof of Stake systems to centralise around large holders, one could do worse than adopt the following steps.

1.2 First, let one’s probability of being selected as a validator be proportional to the square root of one’s staked sum instead of the staked sum itself. To avoid the issue of numbers lower than one having squares larger than themselves, set the actual function SQRT [1+ STAKE] - 1. 

1.21 We have now introduced an incentive for stakers to split their stakes into multiple wallets to, at the limit, recreate a linear relationship between chance of being selected and stake. We deal with this in 1.4, but in the meantime,

1.22 Second, allow stakers to validate less than the total reserve of outstanding transactions (there's no block size limit) to facilitate the participation of validators with lesser compute. Normalise the size of the transcations pool that all stakers bid on against the highest such bid, so that each staker is asignea number between zero and one. 

1.23 Third, multiply this number with the pseudo-square of the stake as per 1.2, and you have each stakers portability of being selected (well, e direct correlate of).

1.4 Fourth, let the reward for the successful creation of a block be proportional to the staked sum, not its pseudo-square. Assume no new coin creation with the block, and all reward being tied to transaction fees. Before a validator is selected, calculate the ratio of all transaction fees in the block / blocks to the highest stake. Apply this same ratio to the winning stake as a reward, returning what fees are left unused due to a lower-than-maximum stake happening to be selected to the original wallets. 

1.6 Fifth, make sure that the staked sum can and will be lost if any errors (double spending, etc) are found in the block by two subsequent validators (precisely speaking, you need to ask as many subsequent validators as required to have two in a row agree that the block is good or bad). 

1.61 If your block is found to contain errors, your stake is forfeit to the validators who found out. If you incorrectly mark a previous block as in error, your stake is forfeit to them. Assuming you get the two OKs, the block is broadcast. The network is still free to adopt it or not for probabilistic finality or, alternatively, you could have immediate finality and no forks by increasing the number of required OKs from two to more (feasible if block time is low). Note how the requirement to have two more validators mark your block serves as a time lock that prevents you from staking the same sum in all blocks, among else.

1.7 So, here’s the generic steps a validator would have to follow, once selected from the pool of stakers. Start by checking the previous two blocks waiting for release for errors. If none are found, and assuming the validator prior also found it to be fine, the first block is broadcast (the second will wait for the next validator to check as well). The reward and stake are included in the block. Only now you can check your own block. Once satisfied, join the queue. If the next validators find your block to be fine, it will be broadcast containing your stake and reward. If any errors are found, the transactions are returned to the pool and your stake is allocated to the next validator.