In searching the discord the first mention I saw from you that include “central” was just a few days ago on July 11th
You missed at least one 
Here is one from July 9th, where I am describing an attack vector that would exist today if the collateral requirement did not exist.
A quick search showed you mentioned “central” over 60 times in the new post, and it was the topic you were most eager to debate in the discord…
I am eager to discuss all of the proposal, but centralisation risk is an important topic, and it has become increasingly clear that the RPIP-49 authors have not fully considered the risks here.
Support for decentralisation is such a key part of what distinguishes RP from other LSTs, so those concerns are front and centre in our proposal, as are the concerns regarding the lack of protection RPIP-49 offers against centralisation of the validator set.
I was surprised to read your post and find such a strong emphasis of “centralization concerns” around rpl.rehab.
Why? I have been very clear about my fears that UARS will lead to centralisation. We are not the first group to raise these fears. I’m not sure why you would be surprised that discussing the centralisation risks of RPIP-49 requires us to use the word “central”.
Your new post shows a drastic shift, from optimism around your proposal to pessimism of the existing proposal
It seems you are mixing up parts 1 and 2 of our post. Part 1 describes why we believe it is the best direction for RP, and we remain optimistic about this approach.
Part 2 of our post describes why we think RPIP-49 would ultimately lead to negative outcomes for RP. We believe RPIP-49 will lead to significant reduction of RPL price and the centralization of the validator set. So yes, we are very pessimistic about RPIP-49, and the apparent lack of risk analysis that has been performed by the RPIP-49 authors has only increased this pessimism.
reductions in staked RPL/downward pressure on price
threatens to the stability/value/security/integrity of the entire governance system
We have already added some research to help quantify the “Will RPIP-49 lead to unstaking” question in the steel man doc. We believe that the rework will lead to RPL being unstaked, leading to additional sell pressure. Nobody would dispute that reducing the cost of the governance token reduces the cost of governance attacks.
Extreme centralization risk of RPIP-49
“extreme centralisation risk” is a quote from NodeSet’s review of the tokenomics, when they highlighted these issues in March. We share their concerns and do not think they were adequately addressed by the proposal authors when first raised. Here are two examples of that from the same thread:
-
Valdorff dismissed the concerns as “pure FUD”. Wander responded with an answer to that question and Valdorff did not comment further in the thread.
-
You responded that ETH-only NOs would not have pDAO votes, and the ability to reduce no_share would be enough to prevent centralised takeover, to which Wander replied:
The centralization concern isn’t for governance, it’s for key-man risk and consequently rETH safety. If Coinbase has 90% of validators, then rETH is essentially cbETH with some extra complexity (risk).
You did not comment further in the thread, so I am not sure if Wander’s explanation of the risks changed your thinking at all here.
The same concern was also raised by other community members around the same time. From @rocknet’s rationale of their concerns about the rework’s effects on decentralisation (context):
If we do this to compete with other more centralized players, we risk becoming an extension of the same players, driving more stake into the most well capitalized, playing into the worst criticisms of proof of stake consensus
A single large staking entity could migrate half of their current natively staked validators and create over 100,000 1.5ETH minipools, lifting over 3,000,000 rETH by themselves. Is that what we want?
In my view, these are valid concerns which have not been addressed. This makes us more vocal about the centralisation risk - if we believed they had been adequately considered by the proposal authors it would not be necessary to raise them now.
how should the DAO go about determining this?
You might be familiar with the Swiss cheese model of risk analysis. The idea is that no single defence mechanism can be 100% effective so we must use multiple layers to improve the overall security. We should use the same approach here.
While there are already some options available (e.g. Gitcoin Passport), it is an open research area which has not been fully solved. The point here is that a) we do not need to design a 100% effective system in order to provide an improvement over RPIP-49, and b) we can innovate and iterate over time as the solution space is further explored. More on this below.
What’s to stop centralized entities from pretending to be solo stakers to attract delegation?
One of Valdorff’s arguments against delegation is that big names would receive too much delegation. In order for this to be true, those entities would need to self-identify. So, if we accept Valdorff’s logic, we conclude that many of the larger entities will have more to gain from self-identifying than pretending to be a home staker, and will therefore self-identify.
As for the large entities who choose not to self-identify, in a permissionless system it is not possible to prevent them from attempting. Their ability to deceive pDAO into delegating to them depends on their ability to bypass the identification methods we implement.
It sounds like a nightmare to have our discord flooded with users seeking out delegations,
Imagine having our discord flooded with messages every time someone deploys a minipool or stakes RPL Yes, that would be annoying, so those messages go in the #events channel.
This is a non-issue. We can just make a channel for delegation requests and warn/ban anyone who requests delegation outside of this channel. Coordinating in discord is already suboptimal compared to the delegation dashboard, expecting a “flood” might be an overestimation.
I see no way to differentiate between the “solo staker” types we really want, and those just pretending in order to acquire delegations to subsidize more validators.
Valdorff has expressed similar sentiments:
Remember that we can only tell centralized entities apart if they wish us to tell them apart.
Have you considered the implications these statements have for no_share as a defence mechanism against centralisation?
It seems your view is that, if centralised entities are >x% of the validator set, pDAO will activate the self-defence mechanism and begin reducing no_share until they leave. In order to know whether centralised entities are >x%, you will need a way to distinguish between them and the home stakers.
When you are evaluating whether pDAO should activate the self-defence mechanism, what criteria will you be using to differentiate between centralised entities and home stakers? Any criteria you come up with should work equally well under our proposal.
Let’s use consistent logic here. If you can distinguish between centralised entities and home stakers in order to make the self-defence decision, we can use your criteria for our proposal. If you cannot distinguish between the two, it would be impossible to know when no_share reduction should be activated, rendering it even more useless as a defence mechanism.
jump through hoops more easily than home stakers could (the previous Aave borrowing/self-delegation approach being one such example)
As I described in my last response to you, the outcome of anyone performing this “attack” is increased validator count, increased rETH rewards, increased buy pressure for RPL, and increased RPL yield for pDAO. If you disagree with my response please say why and we can discuss it, otherwise please stop alluding to it as though it were a valid attack vector. It is misleading.
The explicit goals under the rework is to make Rocket Pool the most attractive venue possible for solo/home staker types. We try to open the tent as wide as possible to allow the largest set of NOs to participate.
When you “open the tent as wide as possible,” it is equally open to both large and small stakers, thanks to the design of UARS. However, large entities can afford to put a lot more ETH through the tent door. It seems you believe that once the tent is wide open, we will see more home stakers than centralized entities. If so, do you have data to support this hypothesis?
Instead of a tent, imagine we have a warehouse. We are opening up the warehouse doors as wide as possible and inviting people to take as much of our product as they can afford. Some people will be scraping together spare cash to afford one or two items, carrying their purchases home by hand. Others will turn up with a Black AMEX and a fleet of rented trucks. If the hope is that the majority of the products will go to the former group, the outcome might be disappointing.
Another defense of the proposal is that enabling growth in the protocol protects it by creating a higher cost to attack it. As knoshua put it: “I can take over a protocol with 2 validators. I can’t take over a protocol with 200k validators”.
Knoshua’s comment ignores a fundamental point. I’ll repeat my reply here. The issue is rate of change over time, not absolute numbers at a single point in time. Let’s say we start on day one with 100% home stakers. Every day, we get x new home stakers, and y new centralised stakers. If x<y, after one year would the percentage of home stakers a) increase, b) decrease, or c) remain the same? Of course the answer is B, and if the rate of change favours centralised entities then over time they will become an increasingly large portion of the validator set. Please think long term here.
I think the proposals you put forward add friction to the system, which stunts growth and deters solo/home-staker types from easily scaling.
Are you accounting for the fact that the first n validators do not require upfront collateral? If so, I find it difficult to see how this adds friction or stunts growth when it is, from the NO’s perspective, functionally equivalent to having no collateral requirement.
For small values of n, home stakers are more likely to have <n validators than large entities. This means that the people we wish to attract the most experience no friction when launching their first n validators, which is exactly the outcome we want.
Under your proposal every node could end up potentially having different: NO_shares, Delegate_shares, Recollateralisation_share, and Extra_rETH_shares
recollateralisation_share would be a global param, as would the ratio between delegate_share/extra_reth_share, but other than that you are correct. And this is a good thing.
It’s what will encourage competition between NOs, which helps rETH APY, and allows pDAO to provide incentives for protocol-aligned stakers.
What is the rETH total commission? How much do NOs earn? How much does your delegated RPL earn? How much is protocol owned? The answer to all the previous questions is “it depends”, and “it depends on tons of moving variables across all of the validators”, and requires participants to be highly aware of pvp dynamics
Did you ask yourself the same questions about RPIP-49? The answers also depend on multiple moving variables.
Q&A for both proposals
What is the total rETH commission?
1kx
- The upper bound is set by max_commission_rate (set by pDAO). The lower bound is a function of the no_share selected by each NO.
- Both of these values can change over time.
RPIP-49:
- It is (node_operator_commission_share + surplus_share + voter_share).
- All of these values can change over time.
How much do NOs earn? (Ignoring variability in ETH staking yield, performance, MEV, etc.)
1kx
- It depends on the NO’s no_share, which they set themselves.
- If max_commission_rate is changed the NO might need to choose a new no_share value.
RPIP-49:
- It depends on the prevailing no_share, which is set globally.
- Understanding the factors which affect no_share requires reading RPIP-46 in its entirety. Some of these factors are:
- node_operator_commission_share, surplus_share, increase_no_share_seal_increment, increase_no_share_seal_count, and allowlisted_controllers MAY be updated by pDAO vote
- node_operator_commission_share and surplus_share, MAY be updated by an address in the allowlisted_controllers array
- The security council SHALL have a limited-use power to increase the node_operator_commission_share by increase_no_share_seal_increment and decrease the surplus_share by the same amount
How much does your delegated RPL earn?
1kx
- It depends on the total amount of RPL staked to that NO, whether that NO is undercollateralized, and the prevailing delegate_share offered by the NO you have delegated to.
RPIP-49
- It depends how much RPL is staked overall, and how much RPL you have staked relative to other NOs, and the prevailing voter_share.
How much is protocol owned?
1kx
- Somewhere between 0% and the upper bound set on protocol-owned RPL purchases.
- It depends on the duration for which NOs were subject to recollateralisation, and the prevailing RPL/ETH price at the time of the recollateralization purchases.
RPIP-49 (I am mapping this question to the buy+lp scenario as it is closest)
- The lower bound is 0% (assuming surplus_share=0).
- The upper bound depends on surplus_share, and the prevailing RPL/ETH price at the time of buy+lp purchases.
As we can see, when we apply your questions to RPIP-49 the answers are also “it depends on prevailing protocol parameters”. I could easily make the argument that delegation settings are simpler to grok than UARS. But fwiw I do not see any value in this argument - “in order to calculate my ROI, I need to know the prevailing protocol parameters” is true for all yield-producing protocols, even Ethereum itself (what’s the APY? Depends how many validators there are). I’d be surprised if anyone could name a single yield-producing protocol where this is not the case.
Ultimately I don’t think anyone should be picking who is right and wrong for Rocket Pool, this goes against the permissionless ethos Ethereum champions and Rocket Pool followed
I agreed when you posted this in Discord, and afaik you never responded further. Please clarify your intent with this statement, because it could be interpreted as a repeated attempt to insinuate our proposal goes against permissionlessness.
Do you mean to imply that a proposal which attempts to be benefit smaller NOs over large ones is “picking who is right and wrong for Rocket Pool”? You have expressed a desire to “subsidise the little guy”. RPIP-42 does too:
This proposal also explicitly tries to benefit the smallest NOs in a few ways, in line with the pDAO charter values of decentralization and prioritizing Ethereum health
Again, let’s use consistent logic. If helping the smaller NOs is a bad thing, then you should oppose both proposals, as both include this as a stated goal.
Questions about RPIP-49
As mentioned above, the centralisation risks of RPIP-49 are one of the main reasons we oppose RPIP-49. To help better understand these risks could you please answer the following questions?
- What criteria would you use to decide whether or not to activate the self-defence mechanism to prevent centralised takeover? i.e. how would you identify centralised entities in order to know whether they are >x% of the validator set?
- If you were unable to identify centralised entities, and therefore unable to know when to use the self-defence mechanism, would it change your opinion of its viability as protection against centralisation?
- Do you have any data which indicates that, once the “tent door” is opened, the majority of stakers will be solo/home staker types?
- Apart from the “reduce the no_share” self-defence mechanism, what provisions does RPIP-49 include to help reduce the likelihood of centralised takeover of the validator set?
- As a NO, how long would you remain with the protocol if no_share was set to 0%?
- It seems you think our proposal will harm permissionlessness. Under our proposal, from whom do you think NOs will need to request permission before launching a validator?
- Related to my questions above, do you believe there is a difference between “no_share that is profitable based on the NO’s break-even point” and “no_share that Valdorff thinks each group will accept according to their level of Ethereum alignment”? If so, which do you think will be the primary motivating factor for the majority of NOs?
- If UARS were to stabilise in the zone where no_share is profitable for centralised entities but nonprofitable for home stakers, and an increasing portion of the new validators were from centralised entities, what mechanisms in RPIP-49 would you use to attempt to reverse this trend?
- Imagine a centralised entity launches a significant number of validators and pDAO decides to begin reducing no_share, as you described here. Onchain activity and social media show a large number of home staker types exiting the protocol, but the centralised entity has not left. In this scenario, which of the following do you personally believe would be the best course of action? a) continue reducing no_share, b) begin increasing no_share, or c) leave no_share unchanged