Allow minipool deposits while under "min" RPL

Draft RPIP: https://github.com/Valdorff/RPIPs/blob/deposits_under_minimum/RPIPs/RPIP-draft.md

Excerpt cuz it’s smol enough that summarizing further doesn’t make sense.

Why 110%?

I’m not really married to 110%, just looking for more than 100% so RP gets a benefit vs sybiliing while not being so high that people opt to sybil.

Sybiling costs: I looked at a recent node set up at 23 gwei (except one transaction at 13 gwei) and they spent 0.045 ETH (not counting minipool deposit). It’s also got soft “costs” like needing to protect more keys properly and additional complexity to run the nodes.

So then the question would be .24 vs .04 + soft costs This is about 2% of the investment for an LEB8. I think for one pool, we’d see essentially no sybils taking on the complexity. At scale, say 10 minipools, now we’re comparing .24*10 = 2.4 vs 0.04 + soft costs – here sybiling seems much more likely. Essentially, we’re soft-cost dominated. I suspect there’s only a modest difference in behavior between 110% and 105%. I do think we shake off a lot more sybils around 102% or 101%… but I don’t really think it’s worth pushing for that extreme.

Like I said – quite willing to change if there’s a community preference.

7 Likes

I think making a new node in this scenario is much better than using this new feature with 110% requirement or even 100%. When someone is under the minimum and uses this, they end up below the minimum still so they won’t earn RPL rewards unless the price recovers. If they make a new node instead, they will earn rewards on the new node if price just stays flat.

A new node has more advantages in general: more voting power, less friction to withdraw staked RPL below 150%, potential of future airdrops, …

The main thing stopping people from doing it is lack of a proper UI for it.

6 Likes

I love this idea. I think stick at 100%. I think RP gets enough benefits at 100% (better rewards distribution, less governance sybil, overall more users likely to stake, less loss to gas fees) and it’s just cleaner and more attractive for a user. Some may sybil regardless, but I bet it’s honestly not worth the headache of balancing multiple nodes for most individuals for 0.02E per month IF ratio doesn’t rise. Since the major uses of RPL currently are 10% entrance ticket and quadratic governance, 100% preserves it.

Sybil scenario, simplified

Node operator has 1 minipool at 5% collateral and wants to add another at minimum 10%.

Single node scenario: 0% rewards if ratio increases less than 33%, after that 100% rewards.

Sybil variant: 0% rewards if ratio goes down, 66% rewards if RPL rises up to 100%, 100% if ratio greater than 100%.

It’s not clear to me that sybil is better for rewards in any universal sense, particularly when accounting for gas fees; it would need a fairly specific prediction of price action.

3 Likes

This is true but double-edged. They do need it to rise further to get full rewards on all of their RPL.

1 Like

This should be quite worthwhile at 100% of normal requirements, in most cases the alternative is not sybil nodes but people simply not creating more minipools at all, removing barriers to more capacity is benefit enough for the protocol.

3 Likes

Cool – I think the community consensus is clear that 100% (ie, the same amount as on a fresh node) is better than 110%. Updated the draft RPIP. Will PR that then sentiment poll.

1 Like

This leads us to a conclusion that NOs would still have incentives to create a new node instead. If they create a new node, they would get the RPL rewards for the newly created minipool, but if they follow this new procedure to keep only their current node they won’t get any RPL rewards. Is it worth the change if the incentives for sybil would still be there?

1 Like

With the 100% setting, I think we’re at a place where this is strictly directionally helpful. If someone isn’t making more minis due to inconvenience, this solves that. It won’t solve cases where they want to maximize immediate RPL yield (though note that there’s no guarantee splitting is the best RPL yield long term) or maximize voting power. I think we’ll need different tools there (like perhaps slightly greater capital efficiency for monolithic nodes with megapools and node-level collateral).

2 Likes

Sentiment poll time (note that we’ve changed from 110% to 100% from the original post):

  • Support moving to vote
  • Oppose moving to vote
  • Undecided
0 voters
1 Like

On a second thought I think this feature may be harmful for Ethereum, because it grants easier access to 51% attack. With minimum RPL requirement an attacker needs 30% more money to attack with LEB8 and 70%(?) more money with LEB4 (It’s a guess, based on idea of 10% borrowed).

You may say that RP has pledged to self-limit, that’s true, but there are many RP alternatives so an attacker can employ as much as possible validators from every one to achieve their goal. Why let them make it easier?

1 Like

Are you replying to the correct topic? This is mostly a convenience thing to allow someone to deposit 8 ETH + 2.4 ETH-worth-of-RPL to start a minipool even if under the minimum. They can already do this by making a new node. I don’t think this has any impact on attack scenarios and only applies to real world users that want the convenience of keeping a single node.

1 Like

Oh, so it still requires all RPL necessary for all minipools to be at 10%? I see. I was unable to figure it out from that picture and a conversation, and a link to a draft is broken.

UPD: I got it now. +1 minipool with all RPL required. Right. Excuse me :slight_smile:

1 Like

Sorry about the broken link.

Draft: RPIP-28: Deposits Under the Minimum
PR to finalize: Finalize_rpip28 by Valdorff · Pull Request #95 · rocket-pool/RPIPs · GitHub

I support this change. It is a good way to remove a barrier to new minipool creation. While the anti-sybil impact might not be as big as hoped, as Val says, it is directionally right.

1 Like

Yep good idea. Fewer barriers to more minipools and RPL staked

1 Like

No more action on this important subject?

1 Like

Should be coming to vote soon. Just has steps to finalize and go live, and it’s moved forward by folks like me doing this in their spare time.

1 Like

I appreciate that. You always make sophisticated considerations and if you had full time to do so, RPL will benefit much more

1 Like

I think this is a bad idea - it creates code complexity while avoiding the underlying issue that RPL is a bad choice for the bond

I’m voting in favor of this proposal-

Given that it is trivial to create a new node and a new minipool with the same parameters, I don’t see why would want to punish honest node operators and prevent them from doing so, forcing them to sybil for the same deal.

1 Like