Proposal: switch to linear voting power to resist attackers

The Max Effective Stake for LEB8s vote has demonstrated that the RP community has the ability organize and reach a productive conclusion to a contentious issue.

Unfortunately, it also highlights the amount of damage that one evil whale can do if they game the quadratic voting power mechanism. Referencing @Valdorff’s comment shown below, a whale with power on the order of a few hundred votes could potentially turn that into a few thousand votes and single-handedly determine the winning outcome of RPIP-8.

https://dao2.rocketpool.net/t/research-rpip-4-upgrades/1046/5

For this reason, I propose that we immediately modify the voting power calculation to make voting power scale linearly with staked RPL. While this would give our benign whales more voting power relative to non-whales, it would also enable them to properly defend the community against an attacker without having to game the system themselves.

While linear voting power may not be an ideal solution for the long term, it can be modified later if/when we have a solution for sybil resistance, etc.

I hope that with enough support for this proposal, we can quickly get it to a snapshot vote and implemented.

5 Likes

I’m supportive of this.

It’s very easy for a whale to register 1 minipool per node and have an enormous amount of voting power in a quadratic system.

1 Like

I understand the reasoning, but will restate my opposition:

  1. Linear makes the centralization of RPL painfully obvious. Maybe 5 individuals would control 30-40% of voting power? With a 15% quorum, a single whale could definitely decide a vote without other support. So it’s broken from the start, you don’t even need malice.
  2. There are plenty of options between square root and linear. Pick any exponent between 0.5 and 1; a nice round number may not be best in this case.
  3. There is a marked amount of Sybiling that would be needed before square root is worse than linear. 2x is not possible, and 10X is definitely impossible in comparison to linear
  4. We just decided this issue a few months ago and we are in the middle of a contentious vote. i would say we should take a few weeks to heal.
  5. A difficult to gauge downside of linear would be how it affects voting behaviors of smaller NOs. I certainly would be less likely to vote if I was considered 1/4000 of some other person, rather than 1/30. So it may trend towards oligarchy and exacerbate the centralizing effects.

Those are my two cents.

maths: exact numbers a bit old

i’ll use this example: Friendly whale Marceau.eth is hacked by unnamed actors and becomes diabolical sybil attacker with 175 minipools.
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 (he only has 175). So maybe he ends up at 1.8x voting power if he Sybils all 175 nodes.
TLDR: a whale can easily increase his/her vote strength relative to other whales in square root; however, this is extremely unlikely to give that whale more power than linear voting because of the structural advantage to small holders.

5 Likes

Very good points, I do appreciate them.

I suppose this is what it boils down to–voting is simply broken. You can change strategies, but in every case there is a serious flaw.

It seems logical to prefer the following scenarios in order of decreasing preference:

  1. Quadratic voting, sybil-proof
  2. Quadratic voting, no apparent bad actors
  3. Linear voting
  4. Quadratic voting with bad actors

Currently, we don’t have a solution for 1, so we get 2 or 4, depending on our luck. Maybe that is a gamble worth taking until proven otherwise. Either way, the process is far from ideal.

Voting power = (Staked RPL)^0.8 is a little awkward to sell, but you may be pleasantly surprised as a compromise if you run the numbers. Also, i agree about our limited options for a somewhat broken system, but we only need some extremely rudimentary sybil resistance- like i think if you could keep our 175 minipool sybil to 40 nodes or less, they would have a smaller share than linear. Since almost all new nodes have 10-15% collateral, a sudden influx of dozens of 150% collateralized nodes should sound alarm bells on the social layer, if anyone takes the time to track such things.
And for now we have a rocket pool team :innocent: to keep us out of trouble.

Reply to @NonFungibleYokem below

I do like the per capita minipool plus linear RPL option. It makes sybiling more expensive for sure, if harder to detect. And it rewards NOs for doing what we want them to do- run minipools- instead of just holding lots of RPL.
But…politically… it may not be the best time to introduce challenging ideas :joy:

1 Like

It might make sense to split the voting weights into 2 tiers then - 1 tier being just a straight linear weigting based on the number of minipools a node has, and the 2nd being based on their effectively staked RPL. How to balance that might make the recent debate seem tame though.

2 Likes

I would like to suggest BrightID and ProofOfHumanity as potential solutions for 1. Maybe this would need another thread (or Discord chat). They seem promising to me as mitigations for the pseudospoofing attacks.

1 Like

Threw out a quick thought in discord about having a weight per minipool.

I also quite like the in-between exponent @epineph has brought up a couple times.

I don’t have bandwidth at the moment, but it’d be great to see x-y scatters showing each individual’s voting power share (0-100%) under a couple of strategies:

  • quadratic (effective_rpl^0.5) - linear
  • quadratic vs erpl^0.8
  • quadratic vs 0.9*(share per erpl^0.8) + 0.1*(share per minipool count)

I think we know the dao likes the values behind quadratic, so we’re looking for something less gamable that looks “similar”. Could do least squares error, or just eyeball.

If anyone’s interested, the move is probably to grab data from rocketscan and then do excel/sheets/scripting stuff.

Followup is figuring out how much a theoretical whale share can increase via sybiling.

3 Likes

I just wanted to highlight this point, cuz I think it’s great and something I’ve missed at times.

Attacker power as a percentage should be what we protect against, not attacker power vs good whales. Good whales protect us, but so does the overall voting public.

1 Like

Took a little dive into data. I grabbed all current nodes, calculated their relative vote power under a few systems, and the main plot shows cumulative vote power as we include the top x voters.

We essentially know from early signaling that we like the values captured by sqrt(effective_RPL) vote power.

Here we see a few of the options talked about earlier. Linear is totally robust to sybil attacks, but doesn’t capture the desired ethos as much.

Now let’s take a peak at what we look like under sybil attack:


linear/sqrt/^.8 are brought over as references. Then we look at 3 levels of sybil attacking: 1 node per minipool in green, 1 node per 50 minipools in red, 1 node per 10 minipools in purple. Imo, red is very realistic, green isn’t and purple is… probably not?

My take here is that, despite a known sybil vector, we’re probably still better off using quadratic. Yes, this allows particular individuals to increase their vote (especially “bad” whales vs “good” whales), but it is still closer to the desired ethos on the whole (“bad” whales as a function of total vote percentage).

Sybil cost thoughts

For a user with 500 minipools, red would currently cost ~$2k extra to deploy, purple ~$5.5k extra, green ~$56k extra. It would also cost more to do every other action like RPL claims, execution layer claims, etc - RPL claims for a year and a half would be similar to the node deployment cost. There’s also soft costs associated with maintaining a massive number of separate mnemonics, docker containers, etc. One little tweak that comes to mind may be to search for nodes that share a withdrawal address - that would be a red flag that someone is trying to save costs while sybilling. If we found evidence of that, it would be pretty easy to exclude them from votes, or group across their several nodes based on withdrawal address.

2 Likes
Quiet in the forum during ETH Denver, so here goes: I agree, under square root I think there are various small tweaks that can be done to harass would-be sybils with very little effect on actual community members.
  1. definitely agree with evaluating for shared withdrawal address, since the burden of having 500 wallets all getting ETH dust seems a potent deterrent. There will be a few edge cases of two or more NOs (family, friends etc) using a single shared withdrawal address, but i’d bet those are few; would also need to see how SAAS/eigenlayer deals with withdrawal addresses.

  2. one idea that I read somewhere (would give credit if i could remember) but i think would be fairly easy to implement would be weighting based on time since node registration. Something like +20% per year, cap of +100%. This means that the cost for a ‘buy and attack’ sybil would be maybe 50-75% higher once we are a little more mature; so attacks would need to be of the ‘long con’ type (and given the ongoing costs of maintaining hundreds or thousands of wallets, the long con seems unlikely). And it still goes well with our ethos of encouraging settlers, while discouraging our current NOs from sybiling later for more vote power.

  3. increase delegation by small operators: This makes us instantly more sybil resistant by raising the number of likely voters (denominator of any future votes); could make us 3-4x more resistant with minimal downside assuming delegations were reasonable decentralized.

  4. also social layer stuff:
    A) white hat sybil- script to sybil our friendly whales in the event that an attack was felt likely to take place. would take a few weeks to get into place.
    B) get out the vote campaigns. A higher number of small voters can easily raise the cost of an attack.

Also, I don’t recall if this was mentioned before, but the cheapest sybil vector from a RPL perspective (many minimum collateral minipools) requires a huge amount of ETH locked into minipools. this ETH is not at-risk generally (but ODAO could ‘maliciously’ penalize if an attack was perceived), but is another huge opportunity cost for an attacker.

For what it’s worth, here’s my spreadsheet for square root vs linear attack power; the two variables in bright yellow can be edited to simulate different attack vectors. No promises on exact accuracy, but I think it’s right.

Please let me know if you see I’ve unintentionally spilled any personal data.

All this is to say that square root seems fine for now.

2 Likes

@epineph I’m a bit late with this response, but I want to give a little more thanks than just a simple like.

I was weakly in favor of keeping sqrt before, but these calculations effectively convinced me to become strongly in favor of keeping the sqrt calculation. Seeing how much more ETH is required to attempt a sybil attack in sqrt vs a linear vote, I’m convinced that this increases the barriers to attackers.

That said, I think to make this more viable in the long run, we need to return to the time-weighting that you suggested. This was part of my original draft of RPIP-4 but was removed to simplify and accelerate execution. Especially if we’re keep the current sqrt algorithm, we should go through the effort to improve resistance, and I think the time-weight has the greatest immediate effect here.