VRF Lottery-selected Principal Representatives

I apologize if this has been discussed in the past. I did some searching but haven't found anything.

I'm curious if there's ever been any consideration for replacing the nomination-weight elected principal representative system with one using a VRF over a period of "time" (maybe called a "term period"?). I can't think of many negative effects that this would have, and can think of many positives, including:

  • Leaders would no longer be known long in advance. They'd only be known during the term, after which new leaders would be randomly selected. If a short-enough term period is used (less than a day), it would make it very difficult to corrupt enough of the current leaders to execute an attack.
  • Every node (that has opted-in) could have the chance to participate in consensus, not just those with >=0.1%.
  • Users would no longer need to nominate representatives. As simple as it sounds, I believe this is one of Nano's current struggles. Too many users don't change their representatives, and as more and more casual users come, this could get worse.
  • Nano left on exchanges would no longer give the exchanges any additional power.

Would love to hear thoughts on this and the expected difficulty to implement a lottery VRF.

1 Like

It's possible one would work but with both of these they need a limiter besides simply being a network participant otherwise its not sybil resistant.

The main thing is the algorithm isn't our bottleneck. Simple code level improvements will give us enough gains so we don't need anything more complicated for a while.

2 Likes

It's possible one would work but with both of these they need a limiter besides simply being a network participant otherwise its not sybil resistant.

Ah yes, good point. I guess rep nomination provides sybil resistance in the same way a traditional PoS system would.

Could a much lower Principal Rep threshold (something like >=0.01%) combined with a VRF lottery be successful?

The main thing is the algorithm isn't our bottleneck. Simple code level improvements will give us enough gains so we don't need anything more complicated for a while.

Also, are you saying here that adding a VRF lottery and/or representative term periods would be an overly complex feature to add?

To elaborate: could it be feasible to have a pool of representatives eligible for principal representation (qualified through >=0.01% total nomination weight), but give representatives within that pool equal chance at winning the VRF lottery for any given term period, and also give them equal voting power?

edit: 0.01% may be too extreme, but maybe something like 0.05%

Making a change is more complex than not making a change, yes. And since this isn't our bottleneck and doesn't seem like it will be for a long time, it's not something we're looking at right now.

Fair enough, thanks for the responses to the idea though!

This isn't the definition of leader as it's used with consensus algorithm. A leader is someone wholly responsible for determining consensus at a point in time until their term is complete. This is not how representatives are used in nano.

The issues I see with VRFs is that they don't have an entropy source, at least not in a decentralized way. If there's no entropy source, once a bad actor becomes leader they can produce an output that names themselves leaders again.

PoW chains do have true leader selection. They are not vulnerable to these bad-actor cycles because the leader selection is based on entropy.

5 Likes

@clemahieu thanks for responding again, and sorry to keep bugging you on this, but I can't get it out of my head.

This isn't the definition of leader as it's used with consensus algorithm. A leader is someone wholly responsible for determining consensus at a point in time until their term is complete. This is not how representatives are used in nano.

Yeah poor terminology on my part.

The issues I see with VRFs is that they don't have an entropy source, at least not in a decentralized way. If there's no entropy source, once a bad actor becomes leader they can produce an output that names themselves leaders again.

PoW chains do have true leader selection. They are not vulnerable to these bad-actor cycles because the leader selection is based on entropy.

I understand the concern with lack of entropy, but I'm curious what you think of projects like Alogrand, Cardano, Polkadot, and several others using VRF leader selection. I do find it interesting that the Polkadot documentation specifically mentions that computers are deterministic in nature and lack entropy, and that real-world entropy isn't suitable for application to blockchain technologies, but doesn't elaborate on how they introduce entropy for their VRF implementation.

I'm admittedly lacking in knowledge on VRFs, but see it potentially being very useful as a method of limiting and randomizing consensus participants over larger periods of time.

One more thought.

What if rather than reps running a VRF to determine their own election result, they ran a VRF to select one (or very few) OTHER reps for the next term, are not allowed/capable of voting for themself, and the top N candidate reps with the most election votes are elected for the next term?

I'm aware this potentially could be susceptible to sybil attacks, but then again, if you limit the number of election votes by each rep to one or very few, then a sybil attack might be pretty hard to pull off considering that election votes are limited.

This just came to me so I haven't fully thought it through. Might have some major flaws :smile:

You are basically reducing the number of valid signatures each round for each block for a potential 7k blocks a second... which might make the network faster but more vulnerable.

There was a minimum of Ӿ256 of weight to be able to be a rep:

node.weight (vote_a->account) > rai::Mxrb_ratio * 256

If you are concerned the network is "too decentralized" and needs everyone's vote.
I couldn't find the modern equivalent of the piece of code, so sorry for the rai references.

You are basically reducing the number of valid signatures each round for each block for a potential 7k blocks a second... which might make the network faster but more vulnerable.

I'm not sure I follow. How/why would this proposal reduce the number of valid signatures?

There was a minimum of Ӿ256 of weight to be able to be a rep:

Yeah like Colin said, there still needs to be a nomination process and minimum threshold for PR qualification to provide sybil resistance, but you could have a lower threshold and bigger pool of qualified PRs, and use VRF to choose a random subset of them for a term period.

If you are concerned the network is "too decentralized" and needs everyone's vote.

The opposite, actually. I'm concerned that Nano isn't quite decentralized enough, primarily on the censorship side of the equation. The move to 67% quorum threshold helps secure Nano against double-spend/"51%" attacks, but leaves it more susceptible to 33% censorship attacks.

I know that Nano's decentralization will improve over time, but the fact that right now it would literally take two entities conspiring for a censorship attack to succeed is a valid concern.

1 Like

The problem is that this change:

didn't update the defaults.
it HARDCODED the value, you can't change the parameter because it got deleted.
If the attack happens all node operators would have to do was change the TOML or the node commandline and it would start working again... now they have to recompile the whole thing with a different constant value...

I think a proper implementation of the default and restoring the configuration option would be great.
(also this is related but could be its own thread)