On-Chain pDAO Replacement

Governance
1

This topic has been bouncing around our Discord and Twitter for a week or so and appears to have strong community support. If you support the direction, have opposition to it or have any questions, here is the place you can be formally heard. We will develop an RPIP and a formal vote out of any discussions here.

A detailed explanation of the idea can be found here.

I won’t repeat the technical details as you can read the above document. But in summary, the on-chain pDAO replacement will replicate our existing pDAO governance system on chain; importantly, removing the team as an executive middle man and making the entire system completely decentralised.

There are many benefits to this approach but the primary drawback is the increase in gas and complexity. That gas increase comes at a minor cost to node operators and the complexity excludes us from using existing governance software.

The dev team feels like this trade off is worth it, given the alternative is to adopt a simpler voting power model which we feel strongly is not the right direction for the protocol. Rocket Pool’s unique governance system is distinct from other DAOs, making governance capture significantly more difficult and giving power to those most aligned with the protocol’s long-term health in mind.

Please offer any criticisms, ideas or ask any questions you have here.

You can signal support or opposition here as a temperature check, but a formal process will follow.

  • I support the described on-chain pDAO model
  • I oppose this approach (please describe why in a comment)

0 voters

1 Like
2

NOTE: There is current discussion to remove the sqrt from the voting power calculation to make it linear. This will not have any major effect on the technical implementation.

For reference, readers may be interested in this initial analysis by @Valdorff and @epineph: Proposal: switch to linear voting power to resist attackers - #10 by Valdorff.

2 Likes
3

@kane can you give some idea of the gas costs? Both to vote and the bump on the various transactions?

4

There’s a lot of factors and it’s difficult to give a very accurate value until it’s implemented properly (have only done proof of concept at this time). But ballpark, each of the actions mentioned will require one extra cold SSTORE which is around 22k gas. And as an educated guess, voting will likely be somewhere in the 50-100k gas area. So at 20 gwei gas, somewhere around 0.001-0.002 ETH for a vote.

5

Looks like a sensible design. Thanks for the research, Kane!

This design, like any on-chain voting mechanism that directly implements proposals, would be vulnerable to vote manipulation (see the infamous Beanstalk hack), so we’ll need to be very sure this kind of attack isn’t possible. I’m sure the auditors will have this in mind, though. Looking forward to seeing the implementation!

This this might be a good opportunity to add some of the extra security features that have been suggested. E.g. time-weighted voting power from my original draft of RPIP-4 and @epineph’s suggestions in this post.

6

I have posted a draft RPIP for consideration: Draft RPIP for On-Chain PDAO by kanewallmann · Pull Request #71 · rocket-pool/RPIPs · GitHub

3 Likes
7

A node operator MUST NOT be able to withdraw RPL if their staked RPL minus locked RPL is lower than the maximum collateral threshold (currently 150%).

If it’s worded that way and in the future we leave the maximum threshold but specify that you can withdraw at e.g. 50% (without locked RPL), we will have drama all over again, if this now means that this RPIP stays at 150% (for when RPL is locked) or if it intented to match with the withdrawal threshold for when no RPL is locked.

Basically, this discussion about RPIP-4 has made it so much harder to write clear RPIPs :frowning:

8

I don’t see any problem. Worst case means if we want to change when you can withdraw, we may need to clarify language in an extra RPIP. The rpip-4 thing is rather unique cuz it’s a bootstrap issue.

But I agree we might be able to say some version of “locked RPL counts towards withdrawal thresholds” that will be more robust to future tweaks

1 Like
9

Reviewed a bit more than half for the moment. Looks good generally. Biggest high level thing is separating spec from implementation (a takeaway from current RPIP-4 tribulations).

Update 2023-09-11: reviewed the rest. One non-negligible design suggestion in there.

Thanks :pray:

1 Like
10

I’m aware that it’s not directly related to the pDAO functionality, but I would like to make an argument for a proper time-lock, especially now that more on-chain functionality is being made available to token holders.

Before some jump in saying: ‘there already is a timelock’, respectfully, I don’t believe there is, unless I’ve completely overlooked it. There is a proposal delay but not a timelock.

I’d define the difference like so: the proposal delay prevents voting on a proposal before the delay expires, this delay comes between on-chain proposal and on-chain voting. A traditional timelock comes into effect post on-chain vote, but prior to on-chain execution.

I think the problem with a proposal delay as opposed to a timelock is that it makes things very awkward for users if there is a malicious proposal.

I’m aware that as per the proposed spec, a bond is required when proposing, so there is a cost to malicious proposals. Still, depending on the potential impact and bond setting, this may still be worthwhile to a griefer, or someone with enough RPL to pass a malicious proposal.

At the time a malicious proposal is waiting out the enforced delay, users of the protocol do not know whether they should react by exiting, because they don’t know yet if the malicious proposal will be voted down. Unless I’m misunderstanding the system, this gives them two options:

  • Exit now, just in case the malicious proposal passes.
  • Wait-and-see, it probably won’t pass after all.

I think both options can have a serious cost to the protocol users (node operators, potentially rETH holders, but I’m unsure if the pDAO can directly impact rETH holders significantly).

EITHER you burn some gas and time exiting in a panic, only for (most likely) nothing bad to happen.

OR you don’t exit, and just kind of hope that the proposer does not have the voting power to pass the proposal in the last block, and immediately execute the proposal in the subsequent block. If this does happen, it may be too late to exit.

It’s maybe worth noting that I believe this dynamic can play out for the oDAO proposals as well, but given the oDAO are considered trusted actors, this falls under: ‘we trust the oDAO, so this is not a problem.’

If I’ve misunderstood anything here, I’m happy to be corrected. Still getting up to speed some here.

1 Like
11

Just thinking about this a little and I think we might be able to have our cake and eat it too here. Could have a very short timelock (eg, 3 days) and then let the security council extend that to a specified longer time (eg, 3 weeks). They could do this if a vote was highly contentious, or if there was a last-minute change in votes, eg.