Draft Outline for a pDAO proposal on Rules of SP and MEV-Boost

A set of rules will be needed to structure fair and equitable participation in the Smoothing Pool. Based on discussions in the discord and Joe’s suggestion to initiate a DAO forum discussion, I am submitting an initial draft for comment on a set of rules that would be formally developed into an RPIP. Because this is an initial draft, I have attached then as a google doc for more interactive commenting and editing by the community.

Once initial feedback has been received, I will create a second post with the revised version posted directly in this DAO forum.

I welcome input, feedback, constructive criticism, and well-articulated contrarian views.
Draft for Comment SP and MEV-Boost Participation Rules

3 Likes

I’ll reiterate and expand what I said in Discord -
There is (legitimate in my mind) risk of localized disruption in access to relays in which for much of the world the relay appears to be up and working, but the operator is not able to connect and get bids. For example, Flashbots uses Cloudflare for their DDOS protection. Which is understandable. But now there is yet another intermediary in the mix that could present localized connectivity issues (the local CloudFlare point of presence is down) to the operator, or might even outright deny access based on their own risk modeling (CloudFlare often makes vpn users jump through many hoops for access). In such a situation, to avoid penalties, it seems likely that an operator would have to fall back to another relay if available, or simply produce a completely empty block (can be done by turning off all execution layer peers), or if even that is penalizable, avoid producing a block all together (this would require some custom monitoring and scripting).

So, to prevent the latter outcomes, if we really want to impose this as a penalizable requirement for smoothing pool participants, before a real PBS peer-to-peer network is available, there needs to be a broad diversity of relays with a broad diversity of network hosts. Right now, our options are just Flashbots (Cloudflare) and Bloxroute (Amazon), with Blocknative likely coming soon (also Amazon). Otherwise, the risk management node operators might take could lead to counter-productive outcomes.

This proposal does not clarify anywhere what “protocol-provided” MEV-boost compatible relays are, and does not clarify who is able to make that selection. If we decide to enforce a specific relay set, it needs to be decided by the pDAO through a separate proposal.

Regardless, I think section 1 should be thrown out of this proposal for the sake of the decentralization of the entire Ethereum network and the claims to decentralization that Rocket Pool makes to all of its stakeholders. At the least, node operators must be allowed to produce blocks that are independent from centralized relay operators.

Ethereum’s value comes from its decentralization. Do we really think these relay providers will uphold Ethereum’s core values forever? What if they are threatened? Some of them already censor transactions despite no law in place to require that. Our investment into Rocket Pool is predicated on Ethereum’s value, and the same way that client diversity is important for our investment, so is decentralization in terms of block proposal. The same way we have clientdiversity.org today, we will have something like blockproducerdiversity.org in the future. Node operators should be able to choose other relays as they see fit.

I expect most node operators will try to get the most return anyway and will use MEV, in the same way they are incentivized to keep their nodes online. So I do not see a reason to enforce centralization at the Rocket Pool protocol level, and I do not think allowing other relays will have any effect on rETH APR.

The smoothing pool is a different story and is understandable to require certain MEV relays the pool agrees on. Regulate that however you like because node operators that see the need to use a different relay could opt out of the pool.

I would add an amendment to section 7 - If a valdiator’s attestation inclusion is delayed because the subsequent block is missed, that attestation should still be counted because that delay is entirely a consequence of the subsequent block proposer’s failure, not the attesting validator.

1 Like

If a user uses a relay we don’t check, how will we know if they cheated? The premise right now is that we can check their results vs the results the relay reports there should’ve been. We cannot do that for an arbitrary relay, because they don’t all fully share an api. We certainly can’t do that if they build the block themselves, since they could simply hide a transaction to an unknown address they own.

At a high level, why should smoothing pool participants have more guarantees of effective production than rETH holders?

100% agree with this. Rocket Pool’s value is that it is more closely aligned to the values of Ethereum than other staking pools. Forbidding nodes from producing their own blocks moves us further from this alignment. I think until a protocol level PBS solution is implemented this should remain an option. I agree that enforcing relays in the smoothing pool is fine since it is optional.

1 Like

We should not require MEV-boost or approved relays for NOs outside the smoothing pool. This is a hot button issue; we should welcome NOs who are taking a financial hit for ethical or security reasons. Most people will choose max profit, so the effect on rETH will be minimal.
Overall, I think this system is too new and too centralized to impose such draconian penalties; I would phase in penalties in over several months to give more options for NOs and to determine if there are unintended consequences.
I do agree that NOs who are diverting MEV to non-approved addresses should be heavily penalized, and the challenge of rooting out these malicious actors should be our focus.

For the cheating problem: This is somewhat beyond my knowledge base (will delete if refuted) but can:
  1. a node signal on proposal that they are not using MEV boost (ie, grafiti RP-GL v1.6.3 OPT-OUT)
  2. If that block contains frontrunning/sandwich/arbitrage attacks (which there are bots tracking already) and fee recipient is only receiving 0.015 ETH, it is highly suspicious that the fees are being funnelled elsewhere.
  3. if this happens multiple times for a node operator, it becomes statistically impossible for this to be due to chance.
  4. Layer 0 (#trading) formulates a plan to warn/penalize; presumably some of the fees go to whoever discovers the cheating
  5. because few NOs will choose to opt out, it should be relatively easy to track those who do
3 Likes

The reason the smoothing pool is regulated more with MEV required is that its performance is collective, so any individual NO’s performance depends on everyone else’s in the pool. Outside the smoothing pool, NOs are incentivized to stay online and get the highest returns themselves because their own profitability depends on it. In addition MEV theft is more profitable from the smoothing pool because you get the smoothing pool’s rewards on top of your MEV theft rewards.

Basically, the smoothing pool regulation and uptime checking is how to respond to most of the arguments against having the smoothing pool in the first place: An objective case against the smoothing pool for node operators

Solving the cheating detection problem is not trivial, but we are part of Ethereum, the most decentralized place we can be. In my opinion deciding on a centralized solution is a cop out and not good for the Rocket Pool brand, we can do much better than that. A good start is looking at the fee recipient, which was the plan from the beginning anyway. The idea is that it is easier to collect MEV profits if the fee recipient is correct and harder if not, since we do not expect custom MEV software from node operators to be very efficient. This has been the Rocket Pool team’s reasoning from when MEV boost was decided to be optional.

1 Like

I had thought this as well, but there are arguments about remaining competitive for the rETHers MEV plays a significant part in the overall APR return. If we don’t require NO to seek MEV profits, then we will not have a competitive APR compared to other LSD providers. Not arguing one way or the other but just wanted to point out the fact.

1 Like

I think most NOs will want maximum profit and will be doing MEV. Outside the smoothing pool, NO profit and rETH profit is aligned. On the other hand, it should not be an absolute requirement for NOs.

The same argument you are making could be made for “ethical” relays vs. non-ethical. Sandwiching is super profitable, so why would we even give the option of “ethical” only if it makes us lose out on huge MEV from sandwiching?

One of the challenges of the MEV-boost design is that the block builder, not the proposer, sets the feeRecipient address. A bid payment is included somewhere in the block, and that is the PPV payment to the Proposer (e.g., the minipool). RP needs to cross-compare that simple Ethereum transfer transaction with the bid trace from the API on the MEV-boost relay to verify that it was the top bid.

One of the challenges of the MEV-boost design is that the block builder, not the proposer, sets the feeRecipient address.

I noticed that on the blockchain but was not aware it was a requirement. That does complicate coming up with a decentralized solution for relay verification. I think it would be interesting if we funded community run relays to work on ways to make verification and block building in general more decentralized (whether these could ever be competitive is another question, but I think there still could be some value in trying it out)

I like those ideas, but I don’t think they’re the purview of RP. We’re a small protocol with a tiny war chest that’s seriously overburdened.

This kind of public good work is important (and as you say, very etherean), but I think for RP we need to answer what the best we can do now is with the tools that are available.

Long term, we all want proper PBS.

1 Like

Maybe the question that we should be asking is, “Does RP require its NO to use MEV-Boost?” or “Can an RP nO choose not to run MEV-Boost?” If the latter, then it is possible to steal the MEV for yourself and not send any to the rETHers. By running your own builder no one would ever know that you are stealing.

RP could solve this by running its own third-party relay to ensure that the NO does not extract MEV secretly. Maybe there could be a fair ordering relay, a no-MEV relay added to the list of approved relays.

For each assigned attestation, an SP minipool SHALL receive a late attestation mark for each
attestation made NOT recorded in the slot they were assigned (e.g., attestations with an inclusion
distance of 0). Attestations made one slot or later SHALL NOT be counted.

This is because SP returns are dependent on one thing only - block proposals, If a node can not attest in their assigned 12-second slot, then it can’t propose in the first 4 seconds an assigned slot.

I have problem with this statement.
My minipool sporadically attests to slots with 1-2 optimal inclusion distance. Looking in the logs, attestation was sent in due time. The problem was not the node or minipool, but something else.

Example:
epoch: 147922
slot: #4733516
validator: 331508

Attestation was included in slot #4733520.

Slot start time: 2022-09-19 22:23:35
Slot attestation time: 22:23:38.481
Slot end time: 22:23:43.047

In eth2 log, attestation was sent on time:

2022-09-19 22:23:38.481+00:00 Attestation sent                           attestation="(aggregation_bits: 0b0000000000000000000000000000000000000000000000000000000000000000000000000000000000000001000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, data: (slot: 4733516, index: 13, beacon_block_root: \"ee45b3c6\", source: \"147921:0e69a750\", target: \"147922:86de288
9\"), signature: \"891f1391\")" delay=-519ms336us823ns subnet_id=13

I’m not sure that optimal inclusion distance has any effect on proposals, so why would a node/minipool be penalized for that?

Your inclusion was delayed because the subsequent block was missed. There was no block to put your attestation with the minimal inclusion distance possible. In theory these should affect everyone to roughly the same extent, so the smoothing pool calculation shouldn’t matter. But it is an easy thing to test and account for, especially if your attestations bracketing that one were completed and timely as well.

Wouldn’t that be solved by what the proposal already contains? The following text can be found:

Block proposals where the RP node had registered their proposer bid payment address correctly with the relay but the block did not receive a bid from the relays as evidenced by a bid trace thru the MEV-boost relay API SHALL not receive a penalty. This will also account for periods in which the MEV-boost relay was down.

The key word was “localized”. Ie, it’s possible that a person in one region cannot access a relay (or can only do so with breaking delay). In this case, the API will report that the bid was available, but in practice it wasn’t for the proposer at the time.

I agree with this, and would thus recommend we don’t include more code to handle it. It should be in the noise.

This will affect ONLY minpools that were assigned to the same slot in the epoch. Minipools attesting slots before/after will have distance of zero.

If we can test and account for missing slots after attested one, and if that will not affect participation rate, then I think there is no problem.

I think individual cheating wouldn’t be too hard to detect. The fee recipient will have to be the distributor contract if they aren’t using a builder so you would just need to look for non-mempool transactions included in the block. If those exist then there is some kind of under the table deal going on and a violation has occurred. But as has already been pointed out that would require a fairly sophisticated operation and like the scrub delay just knowing that was being monitored should be enough of a deterrent.

1 Like