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 Let try to limit the alleged tendency of Proof of Stake systems to centralise around large holders (and optimise a few other issues as well) below.

1.2 To begin with, we 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 to SQRT [1+ STAKE] - 1. 

1.3 We have introduced an incentive for would-be validators to split their stakes into multiple wallets to, at the limit, recreate a linear relationship between chance of being selected and stake. To counter this, we enforce a uniform Proof of Burn of one unit or some such minor sum to join a validation queue for a chance to be selected.

1.4 Next, we allow would-be validators 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. Selection probability should still be proportional to the size of the transactions undertaken. 

1.5 Now let’s leverage the strengths of PoS and rely on the single central validation queue as much as we can: we enforce a system that swiftly redistributes a validator’s stake if his proposed block is found to contain errors, such as double spending and others. To do so, we ask validators who joined the queue after him to check his block, and only broadcast it once two validators in a row vouch for it. 

1.6 If two validators in a row instead find errors, the block is discarded and all transactions are returned to the mempool. If this happens, the stake posted by the original validator is forfeit to all the subsequent validators who marked his block as faulty, as is the stake of all other validators who incorrectly marked it as good. Mutatis mutandis for validators who incorrectly mark a block as faulty.

1.7 Note how the standard of truth in the system is the votes of the few validators in the queue. No block can circulate unless broadcast by the one queue, and even if a block is broadcast by mistake when still containing errors, there is no recourse short of a hard fork. 

1.8 Now let’s track a journey of a validator along the system.

1.9 First, the would-be validator checks the mempool and, if he likes what he sees, marks as many transactions as he can afford to check, ideally picking those with the highest fees. To join the would-be validators queue, he posts his stake and burns the minimum burn amount.

1.10 Second, once he does all three of these things, he is assigned a number emerging from the product of a) a random number from zero to one, b) one less the square of his stake plus one, and c) the total size of all transactions he marks. We shall call this his checksum. Once joined in this queue, he cannot leave until the selection is finalised, nor can he see what checksum he got, but he can start to check his block if he likes.

1.11 Once the next block has been broadcast from the queue, the checksums of all would-be validators in the queue are computed and the highest checksum wins. The other would-be validators get their stakes back and are free to try again. Our guy is the winner, so.

1.12 Third, he joins the validation queue, and works on his block. Having discarded any faulty or double-spent transactions, he marks his block as ready to broadcast. 

1.13 Next, he is given another such block proposed by another validator two steps prior to check, and marks it as good or bad. Unlike with his own block, here he cannot discard individual transactions, but must either support or reject the entire block as is. Then another block after this.

1.14 By this time, the two new validators having been selected after him should have already checked his bloc. Assuming they both agree its good, that block is broadcast, and our validator gets his stake back and gains his transaction fees. He is free.

1.15 Note how, by being locked in the queue for at least three turns, his stake is prevented from helping more than one validator to win.