LIP-6

[KeeJef]

Request for comments on design of LIP-5

[jagerman]

Validator ownership

Summary of some discussion on this: Validator quorum "ownership" is a potential problem right now in that if someone gets 7/11 validation spots at some point (and this could happen at any time, so every block you'd get another chance) then they can effectively choose any random number they want for future quorum makeups, and thus could "take control" of all block generation by always putting in a random number that gives themselves 7/11 (or more) of future quorums.

Discussed possible solutions:

• (non-solution) - use entropy from last N (e.g. N=30) blocks to seed the RNG for validator selection. Problem: doesn't solve anything; a 7/11-owned validator quorum just incorporates the entropy from the last 29 blocks.
• Increasing quorum size. This would makes things a little better, but as long as we are targeting around the same ratio of validators (7 of 11) we'd have to push this really high to make the probability low enough. The downside of jacking the size up is that coordination overhead becomes difficult as the number of validators gets large since there are steps ("has everyone committed?") that require communicating a lot of messages, and the bigger the mesh the more likely failures become (and if we go to the p2p layer, the more crap we have to ask everyone to route for us).
• Validator ineligibility for a number of blocks. A rough idea of this: after being a validator in a block, the SN in ineligible to become a validator again until there have been a certain number of other validation spots. So, for example, with 1100 nodes and 11 validators per block, we might have the idea that a node cannot be selected again until for 50 blocks (550 validation spots = 1100/2). In practice this might be more easily implemented as: when selecting validators we have a list of active validators, we randomly select from the first half of the list, and add SNs who have just validated to the tail of the list.
• Multi-block seeding. The idea here would be that rather than using one seed from which we generate 11 validators, we use entropy from each of the last 11 blocks to determine one validator spot. So the block at height [H-11] gives us the seed to select validator 1, block [H-10] gives us the seed for validator 2, etc. up to [H-1] giving us the seed to select validator 11. With this approach, even if someone gains 7/11 control of a quorum, the most they can assure is one single spot in the validator quorum 11 blocks from now. (We can add some other value -- such as the block height -- into the seed to prevent them from getting one spot in each of the next 11 quorums).

[KeeJef]

Yeah i think the best idea is to incorporate the Validator ineligibility and Multi block seeding ideas, this should make it very unlikely for you to have successive majority swarm control

[jagerman]

There is also a bit of a nothing-at-stake problem here for alternate block producers: since they get to pay themselves a block reward out of order, they will always want to push an alternative out. I think we might lessen this by stipulating that the alternative block still has to pay the primary producer the SN reward. Not sure who should get tx fees in such a scenario: if the original producers gets them then there is no incentive to include any txes, but if the alternate producer does then there is still an incentive (albeit smaller) to push an alt block aggressively.

[jagerman]

Another point:

Instead of [H-11], [H-10], ..., [H-1] we should lag these heights, so that the quorum for height H is determined from [H-21], [H-20], ..., [H-11] which is very likely to be entirely (or at least mostly) checkpoint immutable. This also helps with a potential alternate block situation Kee and I discussed where some delay in quorum A (maybe a slow clock or node timeouts) and some very fast quorum B results in two competing blocks going out on the network, B0 that has either Ba or Bb following it. We can leave this resolved for the next quorum, C, but the problem becomes a lot easier to deal with if C doesn't depend on which of Ba or Bb becomes the dominate block. Instead the proposer proposes based on whatever he first received and the quorum validators can sign off on it (even if it is building on what they see as an alternate block). Then once C is done, B0 - Ba - Bc (or possible B0 - Bb - Bc) becomes the resolved chain that everyone moves to.