A Candidate Design for a Modernized Penalty System

Governance
1

Hello all,

We just pushed up a design for a revised penalty system to the research repo. The penalty system is the portion of the Oracle DAO duties that detects MEV theft from people that have an invalid fee recipient and penalizes them to make the rETH users (and Smoothing Pool operators) whole. To date it has been designed and implemented but hasn’t been enabled yet, because we’ve never been in love with the spec around it.

This new system proposal simplifies a lot of things and makes it (hopefully) more effective and more transparent than the current system is. I’d like to start a discussion with everyone around it because it comprises a significant change in a fundamental portion of the protocol itself (read: it would require contract changes), and it’s in everyone’s best interests if we know the Rocket Pool community believes that this change should be included in the next update (though admittedly, it’s small enough from an implementation perspective that it could probably be its own update so we can deploy it faster).

I won’t replicate its contents here for brevity, but here’s a TL;DR:

  • The oDAO performs the “cheating check” as usual to detect if theft occurred on a slot (I’d like to make the rules for this a transparent spec with third-party implementations, analogous to the rewards tree spec and treegen)
  • When cheating is detected, the oDAO reports the theft and the amount stolen to the contracts
  • The contracts use the network’s RPL/ETH price to immediately remove 110% of the stolen amount in equivalent RPL from the offending node’s staked RPL
  • The contracts make this up for sale to anyone at a 5% discount of the fair market price, incentivizing arbitrage bots to buy it
  • Upon purchasing, the contracts send the correct amount of ETH to the rETH contract for burns and to the Smoothing Pool (if applicable).

There are many more details (and a fun picture made using PowerPoint, don’t judge me) in the full proposal so please read that first, then come back here and let’s start a discussion around it.

Full proposal here:

Thanks everyone!

2 Likes
2

Why only 110%? I believe more would be safer and only fair.

110% sold at 5% discount leaves a 4.5% that will be sent where?

3

Incentive for an arb bot to quickly make the conversion and I assume account for price action.

4

Despite being sold at a market discount, the 10% tax means that in total, theft of 1 ETH will result in 1.045 ETH being provided to the pool(s); thus, cheating ends up being a net gain for the rETH users and the Smoothing Pool, though minimal. (Admittedly 5% is arbitrary and is left to community discussion).

The extra would be sent to the rETH contract and the Smoothing Pool (if applicable).

1 Like
5

Sure, though the network price (which is what this uses) is updated every 19.2 hours and has a 12-hour TWAP on it so it inherently has some shielding against sudden swings.

6

This is amazing as is. But my uninformed thoughts:

  1. Consider a reasonable hard cap on total penalties per reward period. 100 ETH, 1k ETH, 10k ETH, whatever. This would drastically reduce the risk from a rogue oDAO mass penalizing, with zero effect on any realistic penalty scenarios.
  2. Consider a minimum penalty (like 0.05 ETH) to ensure gas is covered for small thefts
  3. I’m not sure how I feel about allowing SP entrants to opt out of MEV boost. Torn, but if you are morally opposed to MEV boost, it’s kinda weird to be directly benefiting from other people using it.
7

First - thanks for getting us a concrete starting point. Penalties badly needed work and this hits most of my concerns.

I do have 2 big issues…

Allowing Locally Built Blocks

If we allow locally built blocks, we will attract thieves that are able to capture MEV. If they can match a searcher from an MEV relay, they would make about ~6% on 32 ETH, but only feed back about ~4% to rETH holders.

For an 8-ETH minipool with 14% commission

  • an honest operator makes 8*.06+24*.06*.14=0.68 ETH per year, and passes on 24*.06*.86=1.24 ETH per year to rETH holders
  • this dishonest operator would keep all MEV rewards, so they would make (8*.04+24*.04*.14)+.02*32=1.09 ETH per year and pass on 24*.04*.86=0.83 ETH per year
  • The dishonest operator makes 60% more while rETH benefits only 67% as much

The dishonest operator is so successful that I predict if we freely allow locally built blocks, the protocol will be dominated by dishonest operators. This will make rETH underpeform and I suspect eventually kill the protocol entirely.

My suggestion:

  • Require MEV boost, with a small list of allowed relays.
  • Require no locally built blocks.
    • That means that if no relay gets a block built, the NO should simply not propose.
    • This is unfortunate, and a slight loss of profits when relays have issues, but I don’t see another viable method at this time.
Can't a dishonest NO run a searcher and send value to themselves using MEV boost?

Not really. The relay will take the highest bid. If the NO’s bid wins, that means it’s providing more value to rETH than rETH would get without that bid. In short - they’re helping, not stealing.

Relying only on RPL

Right now we support 16+1.6 minipools and 8+2.4 minipools. These start with 17.6/10.4 ETH worth of collateral and will have at least 16/8 ETH worth regardless of RPL price changes.

The proposal here would reduce that collateral to 1.6/2.4 with an option to reduce that to ~0/0 under extreme RPL price depreciation.

As I wrote about in https://github.com/Valdorff/rp-thoughts/tree/main/leb_safety, I judged that under high market conditions 1 in 70 4+2.8 minipools would benefit from stealing each year and that this would result in an ~8% drop on rETH yield. At 2.4 ETH worth of collateral, that would be ~1 in 42. At 1.6 ETH worth of collateral that would be ~1 in 21. Damage to rETH would be devastating in either of these cases if they played out.

Without forced exits, you need to rely on a massive buffer - maybe 30+ ETH worth of RPL across a node, and some amount scaling per minipool on top of that? I think this is a nonstarter.

If we had forced exits, we could do something like:

  • Require 10 ETH worth of RPL across a node
  • If you drop below 10 ETH worth, all of your minipools are force exited; a grace period would probably be ok
  • This would dramatically increase how important it is to “top up” your RPL (though at the node level, with the minipool level staying as is)
  • This would price out small operators

My suggestion:

  • Do write a clear spec that can be checked against for what will be penalized
  • Use RPL penalties first, as that keeps ETH collateral intact
  • Use ETH penalties if they are needed, so that we don’t need massive amounts of RPL
  • Move towards making the penalty programmatic as that becomes possible – either set on chain or (if too gas expensive) challengeable on chain if incorrectly applied

Minor thoughts

Dynamic RPL Discount

The discount should be based on a starting discount and how long the sale has been open; this ensures that we always sell. This relies on at least one bot being “honest” (by which I mean taking the money for itself instead of colluding). That seems safe, especially if we make a bounty for an open source bot with instructions.

Minimum Penalty

As was mentioned - gas could be an issue in selling off small bits of RPL. The easiest solution is to simply enforce a minimum penalty, even when less is stolen. Maybe 0.25 ETH or something?

Settings

The theft tax, starting discount, and discount ramp rate should be pDAO settings so that no SC changes are needed to modify them if necessary.

Alternatives to 'no locally built blocks'
  • We could penalize based off the max bid across all allow-listed relays for that slot
    • This would actually allow vanilla blocks, just at a cost; in a fallback scenario you would simply pay that cost and hope it’s not a lottery block
  • In combination with the above, we could allow appeals
    • The penalty would be instantly applied, but the RPL would be escrowed briefly (eg for 3 days). In this time the user could appeal with evidence. If the evidence is convincing some group (oDAO or otherwise) would be able to remove the penalty. There should be a cost to a lost appeal to avoid griefing.
2 Likes
8

Awesome initiative! This would finally bring RPL’s original vision of being an additional security collateral to practical reality. One big advantage to using it first is of course that damage to rETH can be repaired almost immediately, rather than having to wait for a NO to exit at an indeterminate future time. I must echo Valdorff’s concern though against using it as the only collateral. It seems this cannot be done safely or without a massive increase in minimum RPL collateral, which is unrealistic.

Unfortunately, this could mean reliance on oDAO for assigning ETH penalties until such time Ethereum in-protocol solutions (PBS / MEV-burn) become available. But this not preclude us from implementing the RPL penalty system as a first step and then iterating on ETH penalties (as it’s still an improvement over the status quo, where ETH penalties are only still an implied threat.)

We could look into possible alternatives/mitigations such as:

  • Fraud proofs for cheating blocks (keeper system instead of oDAO)
  • Retroactive appeals (anti-fraud proof for erroneous penalties or pDAO committee - would prefer this over the 3-day escrow @Valdorff as I don’t think a short timespan like that works for either the NO or the oDAO, and longer timespans start to negate the advantage of quick liquidation/repair.)
  • Guardrails for amount of penalties that can be assigned within a certain timespan

Local block building
Having conflicted thoughts here (@Valdorff). From the Ethereum network decentralization perspective, I’d applaud being able to build blocks locally at will, but the risk to the RP protocol may be too big. For the benefit of network liveness, I’d prefer it if local blocks would at least still be allowed if no relays offered a bid for that slot. Forcing a NO to not propose a block when they could have is antithetical to Ethereum liveness and as validators we have a duty to fulfill. This is not just about a slight loss of profits.
The idea of compensating the difference with relay max bid seems dangerous. Now local block-proposing becomes an anti-lottery of sorts. (and if this would apply for relay blocks as well - what if only one relay had the ‘lottery block’ and the NO didn’t enable that specific relay?)

Cheating nodes in bad standing
Quote @jcrtp

Upon being flagged for cheating, the node would no longer be eligible for rewards from the Redstone Rewards system. They would no longer receive RPL inflation, and they would no longer be eligible for the Smoothing Pool. If they wanted to continue earning RPL or Smoothing Pool benefits, they would have to exit entirely, make a new node, and start over which would have substantial gas fee consequences.
We leave it to community discussion to determine if this is excessively punitive or justifiable.

I’d prefer if the NO could return to ‘good standing’ by paying off any outstanding debt as registered, beyond what their RPL already covered. Either via a manual transaction, or by automatically redirecting ETH reward distributions and/or exiting minipools, towards paying their debt off first. Once fully paid off, they’d have atoned and be eligible for RPL rewards and the smoothing pool again.

9

If they have all relays on, this would match what I said of covering the difference.

If they have a subset on, we would need to know the subset ahead of time. If they were posted on chain, then we could (a) count it as cheating if they use any other relay and (b) charge the maximum of those relays’ bids as a penalty if they propose locally.

Some serious complexity.

10
  1. The spec should anticipate the ability for future forced exits from the EL. Thus it should specify that cheating nodes (defined as a node with a minipool with two strikes and one infraction) should have all of its minipools force exited from the beacon chain.

    In the interim, until forced exits are permitted, I support banning a cheating node from receiving RPL inflation or participating in the soothing pool.

  2. I agree with using ETH deposits in addition to the RPL bond.

  3. We should explore whether a fraud-proof scheme or zero-knowledge-proof validation could be used instead of a proposal and consensus vote by the oDAO. This would allow any RP NO to report a cheater (similar to how a slasher can report a malicious beacon chain validator). It would be ideal to find a mechanism where the oDAO would not need to search for cheating events or for the oDAO to report these events themselves. Part of the penalty assessment would fund potential NO that discovers and report stolen funds.

  4. It might be helpful to understand the mechanisms of enshrined Proposer Builder Separation (PBS) plans for Ethereum and to align the spec to be compatible with that new design.

11

I really like dynamic penalty sizing, some form of penalizing RPL and replacing the auction mechanism.

I’m worried about:

Reducing Collateral available

Valdorff has already brought this up: The proposal reduces collateral per minipool from 16/8 down to 1.6/2.4. I don’t believe this is enough and I would want to see some analysis to justify this extreme change.

Not Requiring MEV Boost

I understand the team’s concerns around MEV Boost, but I think we should leave it as is: It will become required in the future. This alone may be a deterrent and we don’t gain anything by giving up on it now. I think this may be an instance where kicking the can down the road may have value.

Liquidation Price based on TWAP

The proposal suggests using the current network RPL price to determine the RPL to be removed and the liquidation price. Since this is a time weighted average and potentially up to 19 hours old, it is possible that the spot price is lower, liquidating is not profitable, and the RPL gets stuck. I believe pricing needs to be dynamic in some form.

Regarding the issues mentioned on github:

Three Strike Rule

I agree that this rule has become problematic with withdrawals going live. But this can be addressed by a workaround without contract changes: The oDAO can apply three penalties for the first infraction of a minipool.

Minipool vs Node Level penalties

I don’t see it as a problem in and of itself. Our current system scales collateral linearly with minipools and there is no sybil resistance. As is, it does not help security because we need to be safe against the case where a new node operator does one minipool per node.
We already incentivize splitting up of minipools with increased voting power and more flexibility with unstaking of RPL. This would further increase incentive to do so.
Node level collateral might make sense together with a reworked collateral system like suggested by Valdorff.

oDAO Trust

Definitely agree with this aspect. I think completely giving up on ETH penalties without any replacement sacrifices a lot of security to reduce the trust. I think that’s a bad tradeoff.
I would prefer focusing research and development resources on a solution that can address the problem without it. This might take a little bit more time and could require Cancun features.

Delay of penalties

I don’t see this as a big problem. A sufficient solution to the mev issue has to result in an insignificant amount of stealing going anyway and that would mean that the cost of this delay would be insignificant as well.