There is a pretty big difference between summing over all nodes and summing over nodes with the same delegate. I think using the tree over the entire set for the delegate situation is unnecessary and inefficient. If it works for you guys though, not going to waste my breath here.
Final sentiment poll for RPIP-33 pDAO voting
- Support moving to vote; I think this proposal is great!
- Support moving to vote; I think this is âgood enoughâ
- Undecided; I have a specific question Iâd like clarified in the comments below
- Undecided; other
- Oppose moving to vote; I have a specific issue Iâm mentioning in the comments below
- Oppose moving to vote; other
0
voters
Does the design in the RPIP still reflect whatâs implemented? Specifically wondering about the merkle tree.
We removed implementation specific details from the RPIP per guidance from @Valdorff so the RPIP only describes the desired outcomes and these outcomes match the current implementation. The research doc referred to in the RPIP is a little bit out of date though as we ran into some limitations and made some improvements along the way.
This new document is much more detailed and correctly describes the implementation as it stands today: https://github.com/rocket-pool/rocketpool-research/blob/houston/Protocol%20DAO/pdao-prop-challenge-spec.md
I will submit a PR to update the RPIP to refer to this document instead.
2 Likes
So I hope that someone with more technical know-how can help me make (or dispute) this point, but here goes:
The linked explanation of on-chain voting suggests that because there is a max and min RPL collateral that non-linearly affect voting power, a significantly more complex scheme must be used to account for RPL(price). We have already voted to remove the minimum. I think we should seriously consider removing the maximum before taking this RPIP to completion, and thus completely eliminate RPL price from the calculation of vote power.
- the maximum increases complexity which (i think) makes trade offs for worse UX (ie the separate delegate/voter periods, increased complexity and collateral to propose a vote, need for checkers for fraud proofs, etc).
-
The maximum, after the passage of RPIP 30, actually moves voting power farther away from reward distribution, rather than keeping it closer.
-
The sqrt voting scheme significantly reduces (I would say eliminates) the gamability or attack surfaces of governance if unlimited RPL could be staked for voting. In fact, the addition of vote power over the current maximum acts as increases the vote power denominator and reduces the relative vote power of one major attack vector: sybil nodes. This calculus may have to be evaluated with LEB4, but it seems somewhat unlikely we will allow single LEB4 nodes to exist.
-
Making vote power based on a simple function (sqrt staked RPL) is easy to understand/explain to NOs.
-
(this is more my personal opinion) I think that people who stake RPL over the maximum are expressing a confidence in the protocol and and alignment with our goals, even at the expense of higher yields. I think that should be acknowledged formally by designating more vote power, even if sqrt voting makes the marginal gain small.
To me, this change does not seem controversial. As far as I can tell, the major downside is that it is not the status quo and would require a DAO vote for approval. The potential for single LEB1 or LEB2 nodes with unlimited RPL stake would be a concern, but it seems unlikely we would allow very-low ETH bonded minipools without some sort of bonding curve.
1 Like
Sorry for not replying to this earlier.
This is correct.
I agree that back when we posted the research article, if we thought that was even an option it would have been preferable.
That said, the pDAO replacement has the major benefit of being future-proof. We do not know how the voting system will evolve. The optimistic proving scheme approach provides an incredible amount of flexibility.
1 Like
This RPIP has been moved to Review in preparation for finalisation.
Please provide any last community feedback here.
2 Likes
âIf security.members.quorum percent of members vote in favour of the proposal, it is immediately affected.â
Should be âeffectedâ.
â And some minor ones â
It doesnât look like this PR On-Chain pDAO Replacement - #24 by kane happened?
This is a a link to additional info, so doesnât materially change the spec.
The guardrail on rpl.inflation.interval.rate is weak. An increase of 1e16 takes us from 5% per year to 3900% per year. This is fine for avoiding âinfiniteâ inflation, but is quite extreme. Just checking intent.
For security.proposal.execute.time, it says âHow long a proposal can be executed after its voting period is finishedâ. Does that also consider reaching quorum as the period being finished? My attempt at a read is: no - itâs simply the time when the vote starts + security.proposal.vote.time +security.proposal.execute.time. I think either is fine, but unambiguous would be nice.
1 Like
wrt security.proposal.execute.time, itâs the former. Itâs this way as it reuses the same proposal system as the oDAO which is done this way. If thereâs no strong feelings either way, I will update the RPIP to remove the ambiguity and define it the way itâs currently implemented.
1 Like
@kane has raised that PR now including âaffectedâ - thank you for the reminder.
As you said, the intention was to avoid an infinite inflation (via fat fingers or exploit). We were conscious of not being too restrictive and being overly opinionated. However, i agree that the current value is too lax. What number would be better?
1e15 would allow an instantaneous step to 51%. I think Iâm reading this as how much a single step can do, so that seems plenty generous (and not contentious). Even 1e14 would allow about 4% per vote â that seems about right to me, which probably means it would deserve discussion before getting set that small.
Iâm ok with it being 1e16. I think it already serves an important purpose of being off by likely 3 or 6 orders of magnitude, and there will be review on proposals (else we have all sorts of issues).
1 Like
Voting in favor.
On-chain governance is an important step towards ossification.