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.