Discussion Draft - Lido on Ethereum Block Proposer Rewards Policy 2.0

Hey everyone, given the coming conclusion of Lido’s slow-rollout period of MEV Boost, this is a draft put together in order to start discussing and then move on to ratification of 2.0 of the Ethereum Block Proposer Rewards policy. There will also be a separate post about the approval of the relays to be used.

The general purpose of the suggested changes is to:

  • Set expectation of full-scale rollout of “PBS lite” via MEV Boost for all Node Operators going forward
  • Define responsibilities of Node Operators in the case of Relay misbehavior, failure, or otherwise unexpected or non-performant functionality (e.g. what happens if relays provide bad bids, bad blocks, don’t unblind timely, etc).
  • Define the responsibilities of Relay Operators towards the Lido Protocol and Node Operators

You can view the full 2.0 draft here and 1.0 of the document (i.e. the currently approved version) here.

Additionally, you can view a “rich diff” version of the proposed changes here (which I suggest as it makes reviewing the changes a lot easier!). Please submit comments, thoughts, and suggestions in the hackmd document, as comments in Github (or PRs), or as a reply below!


Previous discussion can be found here: Discussion Draft for Lido on Ethereum Block Proposer Rewards Policy

10 Likes

Again, very thoughtful and clearly articulated policy update that I think makes a lot of sense - thanks!

Not sure if I overlooked it or wether it is explicitly needed: What is the time frame that node operators are supposed to implement changes in the must-have (and/or allow-lists)?

2 Likes

I think it makes sense for this to be “as soon as possible”. Changes to the lists take some time to take effect and are “broadcasted” before the change takes place due to the governance mechanism around them.

Changes to the lists, especially before the process can be Easy Tracked (see here Lido on Ethereum: Relay Voting Proposal - #4 by Izzy) will be slow enough that Operators should be able to react timely even if relay lists are configured manually. If eventually the mechanism is Easy Tracked and thus sped up, I anticipate that Lido contributors and/or Node Operators will have developed tooling that allows them to easily reflect necessary changes.

2 Likes

One question about this part

Validators operated by Node Operators participating in the Lido protocol should be configured to produce blocks via the MEV-Boost infrastructure (or equivalent, such as Vouch’s MEV-Service) as detailed in Appendix A.1, by obtaining sealed blocks from the maximum possible number of relays from Lido’s “must-include list” (those used will be determined by each Node Operator based on their own risk and legal assessment) and an optional number of relays from the “allow list”.

It sounds like the must-include list is somewhat elastic. Have there been any cases in the soft rollout period where NOs were unable to include certain relays from the must-include list based on their own legal analysis? Have any NOs expressed concern about relays on the must-include list for the next period?

ChainSafe has been running only non-censored relays during the soft rollout period. We would like to see some more discussion on actually allowing more flexibility for NOs to choose which relays they incorporate including for ethical reasoning and protocol neutrality health due to large influx of censored blocks within the last couple months.

Please also see some comments made about this concern here: Lido on Ethereum: Relay Voting Proposal - #22 by aidan

3 Likes

Hey everyone, following up on the above comment before the Node Operator Community call, here is the general perspective of ChainSafe, which we intend to bring to the conversation:

We find ourselves in a unique position having a protocol team that strives to create neutral software which represents Ethereum protocol ethos, while also being a Lido Node Operator. It’s a position we take seriously and we greatly appreciate the opportunity to have a say in the policies being crafted here because Lido has the ability to make decisions that regulate how node operators operate as the largest collective staking pool on Ethereum. Although the v1 policy was already put in place and the soft rollout period of mev-boost relays on all operators has concluded, the circumstances of the current state of the Ethereum blockchain and the relay voting proposal force us to take a harder stance on not further contributing to protocol censorship, regardless of the failure of protocol incentives to prevent this. This is what is required of a neutral protocol actor and if we have the choice and ability to reduce it, we should. Given that the post-rollout period of mev-boost has ended and we are now to re-confirm or amend this policy, we should re-consider how this policy as-is contributes to the censorship issue which has gotten significantly worse over the period of this implemented policy. Although “non-compliant” transactions currently make up a small portion of overall transactions on-chain, Ethereum’s goal of being a neutral, global settlement layer is still threatened with the possibility of more sanctioned addresses, contracts and interactions at Layer 1.

We should strive to realign policies that take the current state of the network into consideration. This has led us to reconsider some portions of this policy or make it clearer, if misinterpreted, that node operators, present and future, have the ability to make their own choices for which relays are chosen from the relay lists, whilst remaining compliant to policies and without the risk of unfair penalty due to this choice. This includes not always picking the most profitable block from all relays to propose because it comes from a relayer that is known to actively filter. Granted, we understand that Lido is in the business of maximizing staker returns, but it needs to be balanced with protocol health and stewardship. This is the reason why a diverse node operator set was chosen and included protocol teams within it. We respect the decisions of other node operators and their choice to run all must-include relays for maximum rewards and we would like to have a choice in return: to object to it for protocol health. Failures of design/incentive at the protocol level does not justify further contributing to the problem itself for short term profit, especially as stewards of protocol neutrality.

Builder and relayer diversification is important and the lack of anti-censorship + builder choices shows the immaturity of the market at this time. If the argument is true that running non-censored relays doesn’t actually prevent potential censorship because of builder centralization, then why are we running any relays at all until there’s a path to offering more/neutral options? The point being made here is that we have a diverse set of node operators with varying opinions and incentives - most notably those with ethical dilemmas working to solve protocol problems that is being exacerbated until proper PBS exists with censorship-minimizing features such as crLists. We don’t tell node operators how to operate their share and the flexibility we ask for is to allow those node operators who disagree with “must-include” relays to choose not to run all of them. We also ask for clarity that the block proposer rewards policy to reflect reference vs actual block deviations with only the relays that the NO chooses to run, not comparatively to all relays, including the censored ones. It would not be worth the investment to run nodes with selective relays if the selected relays consistently payout less than higher value censoring relays and we are penalized for a large deviation from relays we did not include.

We would like to be compliant with Lido’s policies while respecting protocol neutrality to minimize potential penalties or forced withdrawal from the Lido Node Operator set because of choices we made (or any other operator made) to only run selective relays until better censorship minimizing features are in place.

5 Likes

x-posing here too:

I’ve gathered feedback from Node Operators, other contributor workstreams, and the community and am putting forth an updated proposal for version 2.0 of the Block Proposer Rewards Policy.

As a refresher, the 2.0 proposed updates generally:

  • Set expectation of full-scale rollout of “PBS lite” via MEV Boost for all Node Operators going forward
  • Define responsibilities of Node Operators in the case of Relay misbehavior, failure, or otherwise unexpected or non-performant functionality (e.g. what happens if relays provide bad bids, bad blocks, don’t unblind timely, etc).
  • Define the responsibilities of Relay Operators towards the Lido Protocol and Node Operators

and the newest updated wording:

  • Includes the possibility for Node Operators to employ min-bid
  • Clarifies relay selection & penalties for Node Operators
  • Proposes a more agile way to approach on-chain relay management operations before they can be Easy Tracked

Docs to review:

3 Likes

We like the updated proposal. No issues from this side!

I find the use of “should” confusing. Maybe adopt the same shall/should/may that RFCs use.

" Validators operated by Node Operators participating in the Lido protocol should be configured to produce blocks via the MEV-Boost infrastructure (or equivalent, such as Vouch’s MEV-Service) as detailed in Appendix A.1, by obtaining sealed blocks from the maximum possible number of relays from Lido’s “must-include list” (those used will be determined by each Node Operator based on their own risk and legal assessment) and an optional number of relays from the “allow list”. NOTE: the use of “must” here is effectively “must use some”, not “must use all”."

Is this “should produce blocks via” or “shall produce blocks via”? The vibe I am getting is “shall”, but the language here is far more lenient.

1 Like

Good call out. I’ll try to tune this a bit.

2 Likes

The changes look good to me as well. Thanks, @Izzy

2 Likes

Alright made some final edits based on your suggestion here to change certain instances of “should” to “shall” in section D.5.

As a refresher, the 2.0 proposed updates generally:

  • Set expectation of full-scale rollout of “PBS lite” via MEV Boost for all Node Operators going forward
  • Define responsibilities of Node Operators in the case of Relay misbehavior, failure, or otherwise unexpected or non-performant functionality (e.g. what happens if relays provide bad bids, bad blocks, don’t unblind timely, etc).
  • Define the responsibilities of Relay Operators towards the Lido Protocol and Node Operators
  • Propose to empower the Relay Maintenance Committee to facilitate the maintenance of the vetted relay lists.

Docs to review:

1 Like

The proposal is live on Snapshot!

https://snapshot.org/#/lido-snapshot.eth/proposal/0x7ac2431dc0eddcad4a02ba220a19f451ab6b064a0eaef961ed386dc573722a7f

3 Likes