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.
-
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.
-
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.
-
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.
-
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.