Now that RPL-delegated staking is fully unlocked with Houston and we head towards fully on-chain governance, do we have any protection against pDAO takeover?
Since third parties can now easily supply RPL to NOs and benefit from it, it is possible that some malevolent entity can gain 51% of voting power, exploiting a rent-seeking behavior of RPL holders, and using sock puppets to stay invisible.
With the advent of NodeSet Constellation the likelihood of this only increases.
I hope I am missing some pieces of the puzzle, please educate me.
Hmm… The first thing that comes to mind is that the NO is the voting entity, not the RPL holder. So even if I provide RPL for 80 people, I don’t (directly) control the votes. There is, ofc, a reason for those voters to be interested in things that benefit our arrangement. Note that the threat is different if the RPL holder is the NO and others provide ETH since they do control the votes… But they can also cause the ETH to get slashed if they perform badly, so I think the status quo discourages this.
As a result, I see this is as less of a “hostile takeover threat” and more of an “alignment” threat.
The question then becomes “what’s better?” and I lack a good answer. I still think our system gets more alignment than pure token voting style governance, or even proposed dual government style stuff. I think we’ll need to remain vigilant and see if undue influence is cropping up and in what form. Looong term, I hope we can ossify parts of the protocol so they are forever beyond threat… But that requires a trusted stable foundation, so I think we’re quite a ways away.
Here I talk specifically about the situation where a big ETH holder runs RP nodes and hoards voting power by borrowing RPL from markets like Constellation, RocketLend, etc…
Borrowing might not require additional money from an attacker because RPL suppliers on that markets can agree to minipools ETH revenue share in exchange for their provided RPL.
Maybe I’m wrong thinking that NO borrowing RPL (staking from a separate address) for their minipools gains voting power the same as NO who owns (stakes from a node address) their staked RPL?
Ah OK. You’re right but the impact is bounded/mitigated. They still need to provide the ETH bond, which isn’t cheap. Only up to 150% bonded ETH can contribute to vote power. Quadratic scaling helps with concentrated power. With a future bond curve, concentrating will be beneficial for ETH revenue so that I’d encouraged. I think it’d be easy to get more vote power than “deserved” but crushingly expensive to get something like 51%.
I made some math.
Inputs:
- from langers’ announcement:
- 24,560 vp is 25.7% of total current vp
- goal (to initialize on-chain governance) is 50% => 47,782 vp
- current collateral: 475.18 RPL for a LEB8
Output:
- for 47,782+1 vp the required amount of single LEB8 minipools:
47,783/sqrt(475.18) = 2193
- => ETH required:
2193*8 = 17,544
Doesn’t look expensive.
Also I assume here that all of the current NOs are aligned, so it’s the most optimistic numbers. In reality a part of current NOs can be an enemy squad. (notice how many (1956) nodes did not initialize their vp yet)
EDIT: removed a part about uninitialized vp, bc it doesn’t really matter. Attacker controlled nodes can delegate as normal NOs and override their delegator’s vote just when attack begins.
In this scenario, I have to create over 2000 nodes and fool people into joining up with me 2000 times? Presumably this involves different discord accounts for rocketlend chat and paying people to do videocalls with nodeset?
All of this to reduce the cost per node from 10.4 to 8 (a 23% reduction). It’s not nothing, but I think it’s more likely the attacker simply has the 10.4 needed than that they convince folks 2000 times.
As an aside, the math should prolly be twice as much. You did math for if the attacker was already here or could essentially replace validators. If they are making new ones, they must beat out 100% of the existing vote power.
Just to help in your question, NodeSet will not be initializing any vote power in Constellation at all (as of their last call). I think this is somewhat due to the implementation being a bit different than expected.
The original idea, as I recall, was that the node operators would have the vote power, not the RPL delegators, but even that is not going to happen as we stand today. They haven’t said there’s even a medium term goal to enable the operator vote power, so it’ll probably stay that way.
@Valdorff well, my thoughts departed from the idea of permissionless RPL supplier market like one 1kx suggests (if I understand it right). You’re right that both NodeSet and RocketLend are wrong examples.
Okay, so we can simplify math assuming that the attacker have 30% more capital and can afford RPL. => they need 22,807 ETH
If they are making new ones, they must beat out 100% of the existing vote power.
Right. If we super optimistically assume that all current nodes are aligned, initialize and delegate their vp, than the attacker needs 95,564 + 1 vp. => they need 45,614 ETH
Also worth noting that there is an oDAO veto in existence https://rpips.rocketpool.net/RPIPs/RPIP-24#odao-values. This doesn’t prevent takeover wholesale, but limits the power (and thus the motivation). Ie, someone with 51% vote power would remain unable to: change to an upgrade strategy where their personal wallet has full control; drain all currently drainable funds; set commission to 100%; etc.
You made me read RPIPs again 
If I read RPIP-33 correctly on-chain pDAO has a limited scope of actions and cannot upgrade the protocol. That’s very good.
One of the worst actions rouge pDAO can perform is spending a treasury and removing/replacing Security Council. From this section I conclude that oDAO cannot cancel execution of a voted pDAO proposal, and it is unclear to me whether Security Council can prevent this either (likely no).
So it seems the attack likelihood depends on the ability of oDAO to penalize offender and the treasury at stake.
pDAO can’t propose contract upgrades or stop an existing proposal. The security council can’t propose contract upgrades or stop and existing proposal… But the rpl.rehab proposal includes a security council veto. That’s an interesting point that I should add to security considerations.
1 Like