Research: RPIP-4 Upgrades

Hello everyone! RPIP-4, which describes Snapshot voting procedures for the pDAO, was recently voted into effect. Late in the process (during the vote), some concerns with it were raised. Namely, the quadratic voting algorithm described in RPIP-4 is possible for whales to exploit through the relatively nominal cost of making additional nodes to escape the quadratic vote power reduction applied to each node.

Several mitigations have been discussed, such as moving to a linear (1-RPL-1-vote) voting algorithm or requiring a higher (e.g. 66%) majority instead of a simple majority for votes to succeed. Another option is keeping the quadratic algorithm but increasing sybil resistance through other methods like BrightID.

For the unfamiliar, BrightID is a “Proof of Humanity” network which attempts to combat sybil attacks. This is accomplished by requiring an (anonymous) connection with others and penalizing anyone who provides positive connections for duplicate/bot accounts. BID has plenty of flaws and can be exploited relatively easily on a small-scale basis, but as far as I know, it can still reliably prevent large-scale sybil attacks.

I should note that, at least personally, I am not in favor of requiring BrightID, but we could still use it to ensure greater integrity of quadratic voting without requiring it. Some ideas worth exploring are additional vote weight for BID-verified voters, capping the vote weight of non-BID-verified voters, etc.

Even if we don’t require BrightID, using it to influence the signaling vote is a big deal, so we should be aware of its implications in this discussion. Despite the simplicity of BID, it’s likely that a significant bloc of voters will not go through the process to become verified. This naturally creates a division in power between the more engaged and less engaged voters, which is a step away from my personal ideal of a 1-vote-1-person governance structure, but this may be desirable to some – one could argue that those who are willing to go through a small annoyance to gain extra vote power are more deserving of that power. Of course, linear voting would arguably be an even bigger step away from my described ideal, so I’m still in favor of exploring BrightID even though I dislike some implications.

On a technical level, there is already a snapshot strategy which incorporates BrightID (see below), but custom work is needed to implement for Rocket Pool specifically if this is the direction we decide to take. Regardless, I believe it is feasible based on my understanding of Snapshot.


How does the community feel about BrightID or other PoH solutions as a mitigation for quadratic vote gaming?

Does the community have other ideas to improve vote fairness?

Are there other issues with RPIP-4 which we should discuss?

Please also use this thread to discuss this and other potential improvements to RPIP-4.

1 Like

My main issue with brightID etc is that I haven’t yet been convinced that any of these systems aren’t gamble at scale (I should note, there are multiple services that combine these antisybil metrics to try to get something stronger, so my viewpoint isn’t too out there). If these systems are gamable at scale, then giving greater voting power based on them is itself an attack surface – in other words, it could cost less to attack RP b/c you don’t have to defeat as much voting power (due to real users without brightID). I’m not sure what it would take to convince me, but a couple minimum thoughts are that it would need to resist (a) paid farmers, which we’ve seen for things as low-value as Wow, and (b) build up a long history #lindy.

I wish I could think of a better alternative at this time than linear voting, but I haven’t been able to.

1 Like

For context on linear voting’s fairness, the top 10 RPL holders represent ~7.5m of the ~18.7m RPL or ~40%, and the top 18 RPL holders represent a majority of all RPL. Given that some of these addresses are likely controlled by the same entity, linear voting means that the pDAO may be controlled by fewer than 18 entities.

For context on BrightID’s track record, the Ethereum Foundation has used BrightID in conjunction with clr.fund to do quadratic voting for grant distribution, and several other projects use it without issue, too. If it’s gameable at scale, I’d expect that to have already shown up elsewhere, but absence of evidence is also not evidence of absence, of course.

Given this, I prefer an imperfectly sybil resistant quadratic voting, but the top 18 holders may disagree with me :stuck_out_tongue:


On a different topic, clr.fund uses MACI to prevent bribery/collusion, an approach described by VB here: Minimal anti-collusion infrastructure - Applications - Ethereum Research

In a nutshell, MACI uses zk proofs to keep votes private forever while still creating a provably correct outcome. MACI is only relevant for on-chain voting, but I’ve also seen discussion about improving RP’s vote integrity by only revealing votes after the poll is closed. While this is appealing since some voters prefer as much privacy as possible, this comes with the trade-off that one can’t see how their delegate’s vote was counted until the poll closes. However, delegation is optional and impermanent, and it’s frictionless to vote against your chosen delegate, so it’s unclear how much of an issue this is.


Including the above, here’s the topics I’ve seen discussed so far:

  • sybil-resistance vs linear voting
  • 2/3 majority vs simple majority
  • hidden votes vs open votes

Why would you consider moving to a linear voting algorithm? Are you thinking whales would create many mini RPL accounts that are smaller than the average node operator has? Unless they are able to vote with less RPL than the average NO, then keeping it quadratic seems to benefit smaller NOs more.

I am supportive of a higher majority. I think having ~40% opposition should not qualify a proposal to pass.

I don’t know about BrightID but at least it sounds like it doesn’t require personal information. In general I think we should not penalize users that wish to remain anonymous, maybe BrightID would qualify but I am not sure. It does sound like it would make contributing to governance harder since it’s another hoop to step through.

I wonder how many NOs are actively participating in voting or even set a voting delegate.

The issue with gamable quadratic isn’t whales vs minnows, it’s good whales vs evil whales. The whales willing to game the system will have faaaar more voting power (we did the math with one whale and found that it would have cost them a few hundred dollars to more than 10x their voting power by splitting across nodes).

I see, I did not think about that. One of the biggest node operators is already split into two nodes and so gets (0.5^2 + 0.5^2) = 1.41 => 41% more governance power as it stands. The amount of extra power you get compared to keeping all your RPL in one node scales with ~ sqrt(number of nodes) which is high. So to get 10x voting power you need to split to 100 nodes.

That is a big incentive.

Yes, this is a big incentive and we should therefore expect this behavior.

To address other points brought up:

  • BrightID does not require identity information. The fastest way to become verified is to appear on a video call for a few minutes, but no identity information is exchanged and these calls are (supposedly) not recorded. Alternatively, verification is given after enough time and connections with other high-scored users. Verification may also be removed if your score is too low. Users cannot see their own score.
  • BrightID is easier to exploit at small scale, so it’s unlikely that it would completely prevent motivated small-scale attacks (10x node counts). Where I believe it becomes more useful is on larger scales (e.g. 100x node counts), since attackers have to find individuals to farm the system.

One way to analyze the difference between linear voting and BrightID is to make some guesses as to the time and monetary costs of a single sybil node. We can reasonably assume just a few hours and no monetary cost for the first ~10 sybil nodes, but after that, the costs ramp up as attackers need to coordinate across many individuals.

I’ve had some experience with BrightID, but I’m not an expert. It would be helpful to have someone from BrightID discuss the limitations of the system and how they apply to our situation.

Also, @Valdorff do you mind sharing the other services you mentioned?

This isn’t something I’ve done much diving into, but I’ve come across these two:

https://github.com/joshmike2301/Gitcoin-Passport-introduction-/blob/main/Gitcoin%20Passport%20introduction%20.pdf

https://cointelegraph.com/press-releases/how-snapshot-and-orange-are-making-crypto-more-democratic-with-reputation-based-voting

I believe Gitcoin passport is just an API for connecting to other various services, since BrightID is included alongside Twitter, GitHub, etc. Not sure if it’s usable outside of Gitcoin itself.

https://passport.gitcoin.co


Seems Orange Protocol also uses with BrightID alongside other data sources to create an aggregate reputation.


Another service I found which appears to compete with BrightID directly is simply called Proof of Humanity.

FWIW, I feel linear (infinite sybil resistance) and square root (enhanced equality) voting are so divergent that it may be difficult to reach consensus on one vs the other. I just wanted to pipe in that if you see square root voting as RPL^0.5, and linear voting as RPL^1, you have infinite middle grounds with exponents of 0.5001-0.9999. For comparison’s sake, I made a few arbitrary

Definitions
  1. Inequality index (IEI): the ratio of a given NO voting power to the minimum viable NO, or how many normal humans are equal to thomasG. IEI = whaleRPL^x/minimumRPL^x, where x is the exponent.
  2. Sybil resistance index [2] (SRI2): the number of sybil nodes needed to double the voting power; this does not change with RPL amount.
    2 < #SYBIL ((RPL/#SYBIL)^x)/(RPL^x); where x is the exponent, #SYBIL is the number of equal sized nodes, RPL is the NO RPL holdings). There is certainly a way to simplify this (for instance, RPL is not needed, but it’s being added for clarity; also something something quadratic formula)
  3. Minimum viable NO: a NO with 1 minipool at 10% collateral (89 RPL at 0.018 ratio)
  4. Dolphin: a midlevel NO with 10 minipools at 30% RPL (2667 RPL)
  5. Whale: a huge staker with 840 minipools and 150% RPL (1,120,000 RPL)

Results:

inequality index for dolphin- higher is more unequal

0.5: 5.5
0.6: 7.7
0.7: 10.8
0.8: 15.2
0.9: 21.3
1: 30

inequality index for whale-higher is more unequal

0.5: 112
0.6: 288
0.7: 741
0.8: 1904
0.9: 4896
1: 12584

sybil resistance index (2)- higher is more resistant

0.5: 4
0.6: 6
0.7: 10
0.8: 32
0.9: 1024
1: infinite

Discussion: Compared to linear, you can get essentially infinite sybil resistance with substantially reduced inequality with an exponent of 0.9, so IMO there is no reason to consider linear. However, I would argue an exponent of 0.7 is my sweet spot that requires at least 10 equal sized nodes to double voting power, so is essentially sybil resistant to all but big players who are easier to track- even on these it significantly reduces the risk of huge fluctuations in voting strength (ie requiring 2160 sybil nodes as opposed to 100 under current voting to get 10x increase voting strength).

Other potential solution to deal with both issues:
  1. Give a voting power bonus that is separate from their RPL for every node that uses bright ID or other sybil resistance mechanism, but don’t require it (5-20 +(RPL^0.5)). Anyone can choose to use it for the extra benefit, or not; the relative benefit would be higher for smaller stakers. This decreases inequality while increasing sybil resistance

Sorry for the wordiness, and any math errors, but still feeling merge hangover…

3 Likes

Very interesting!

What I’m seeing you propose here is two knobs:

  • Exponent: this let’s us increase friction (aka sybil cost) at the cost of increasing inequality index. I love this knob and would want to do some math ok a real case to help think of what number I like.
  • Vote power for 3rd party sybil resistance thing. I think I actually like this more as a multiplicative factor though… If we trust it 100% and it’s convenient, then this factor can be massive (and w can safely move our exponent closer to 0.5). If our trust is quite limited, this factor can be only a little above 1.0.
2 Likes

So my argument for additive instead of multiplicative (if I understand them correctly):

  1. you can conceivably set additive to more than 100% of a small NO’s share- thus boosting (relative to the whole pie) small NOs much more than multiplicative (which would boost whales equally).
  2. it gives very minimal benefit to a whale separating into 2 or 4 or 8 nodes (ie getting their spouse, cousin, daughter, and friend to get a BrightID account)

The drawback of additive:

  1. it encourages players with a few minipools to separate into a few nodes (ie low value sybil action), which I’m not too worried about (and I would argue is mildly beneficial for the Ethereum ecosystem).
  2. there’s no real benefit to whales to encourage them to enroll in whatever Sybil resistance mechanism we pick

So essentially I would argue a two pronged approach:

  1. reduce equality but significantly increase Sybil resistance by increasing the exponent (to some number TBD, likely 0.6-0.8)
  2. increase one-person-one-vote-ness by adding a (substantial) base premium to every node that is Sybil resistance verified. When we trust Sybil resistance more this premium can rise.
1 Like

I think a key difference between where I’m coming from is that I do NOT view 1-person-1-vote as a desirable outcome. I do think investment should be valued, so for me getting to quadratic is the long-term goal. Note that the community did loosely vote in https://dao2.rocketpool.net/t/snapshot-voting-poll/761 for quadratic and not for cube root (which would be closer to 1-person-1-vote.

Given quadratic as an ultimate goal, I think multiplicative lets us move towards quadratic in the long run by encouraging all members a similar amount (as you say, if it’s additive, we are heavily incentivizing small holders and almost not incentivizing whales at all).

This is the 1st solution to the „quadratic voting is gameable“ problem that I don’t hate. :wink:

Simply going linear feels like a solution that is worse than the problem to me. All the focus on possible attacks by „evil whales“ and gameability is interesting and might be very relevant if we were talking about on-chain governance, but snapshot isn’t that. A malicious vote which would hurt the protocol would simply be ignored by the Guardian, right? That means it is very questionable if someone would even try such an attack in the first place. Even if it is easy to do, it is still an inconvenience. Switching to linear voting on the other hand just means giving whales more voting power for free. That’s a problem because big and small NOs might have different opinions on what is best for the protocol (and themselves of course). For example the two big new redstone features (smoothie pool, the reduced gas cost reward system) were very important changes for small NOs, but not so much for whales - who might have spent dev resources differently, if it was only up to them. What I’m trying to say is, that we should not forget to think about what good whales having too much power could lead to.

Ethereum will only stay decentralized if node operation stays decentralized. That’s why Rocketpool should give small operators a (not so small) voice in its evolution.

That’s why I like the idea of the additive base premium for Sybil restistance verified NOs.

@Valdorff : I agree that a bigger investment should be valued, but then we should also think about other forms of investment than money. What about invested time or contributed knowledge? I would be in favor of a similar voting premium for rocket scientist for example. But this probably comes with it’s own can of worms…

I think the social layer is an appropriate way for community members that contribute to have an outsized voice (including rocket scientists). They sway more votes either directly via delegation or indirectly by voicing opinions here and on discord that many people trust.

I think adding direct voting power based contributions is more complexity/subjectivity than it’s worth.

People have been concerned about gameability of the current system when it comes to things like voting on a pDAO guardian multisig. If it is an issue that limits us in what we can do, it is worth fixing.

I feel this.
So i’ll use this example: Marceau.eth as diabolical sybil attacker.
Under 1/2 square root, he has 237 of 27,803 or 0.85% of the vote
Under linear, he has 0.38M of 5.6M RPL or 6.7% of the vote
In order to get equal voting power (6.7% or 7.8x) under 1/2 square root, he needs 62 sybil accounts. in order to get twice as much voting power under 1/2 square root (13.4% of voting power), he’ll need about 250 sybil nodes.
So 1/2 square root is technically not sybil resistant- but it will take a looooot of sybiling to be a worse problem than linear with a malicious whale.

But i also feel that going to strict one-node-one-vote takes away a sizeable benefit of owning RPL, particularly as large owners are Rocket Pool aligned. Hence my compromise.

Remember that this sybiling is pretty cheap. We’ve seen 5 gwei going through very regularly, which would mean around $5 per node (send eth, send rpl, approve rpl_v2 token, register, stake rpl, set withdrawal address). All other startup costs are the same as if you were spread out. So your 250 node case can be executed with a small script and less than $1k.

The other cost is claims. I’ll do that at 20 gwei cuz maybe we can’t time it as much consistently. That would be $5 per node per month, so it would be significant - $750 per period vs just $5 on a single node. That said, rewards build up with no penalty, so not sure this is a terribly strong disincentive to 15.8xing one’s voting power.

Well that’s a fair take. You’d have to have 250 minipools, which marceau.eth does not, but he could get close to doubling his effective voting power.
But with a quorum of 15%, a single operator having 7% or 17% (thomasg) is breaking. So with linear the system is broken from the start. Square root forces significant risks to break the system (generating 62 private keys and keeping them safe, automating voting and other activities, cost of hiding one’s tracks so that accounts appear distinct, actual malicious intent etc).
I guess from my standpoint, linear causes more problems than it solves. i would be swayed on different exponent or another form of sybil resistance.

3 Likes

If anyone is attending DevCon 22, this session looks to be relevant for this topic.