Lido on Ethereum: Relay Voting Proposal

[crece-el-rio]

@Izzy

What reason would these validators have to re-trust that relay if they are not made whole?

I hear you. I know I’m not making an economic argument in here, which might be naive. I still like my point

Two facts are that there will be bugs and that the reward boost is tempting.

With that, I think that we can make sure we never lose trust by following:

• Take down the server when a high-severity bug is found, so validators switch to local building and don’t miss slots.
• Publishes a post-mortem after every incident.

(from What makes a relay trust-worthy? - Relays - The Flashbots Collective)

If a team fails to do that, I don’t think it should be re-trusted, ever. In the Lido case, I see that as down-grading from must to allow. Currently, I don’t see a way from must to allow to must again.

I think this will change once the relay monitor is operating, because then we can quantify the risk and the reward of every relay. At that time, maybe getting into the must list means having a high score in the monitor, and it’s no longer subjective.

[metachris]

@sambacha

Also, Manifold has run on average the most profitable relay since the merge till 10/22/2022, this is from a 3rd party that will be publishing a rigorous analysis of relay performance:

This is deliberately misleading. Manifold counts regular mempool transactions to the proposer feeRecipient as “additional value provided”, using such transactions to inflate the bid value. In one instance, there was a 170 ETH transaction to the proposer, which Manifold counts towards “being the most profitable relay”, but in reality that value would have been part of any mempool block as well, and other relays wouldn’t have counted that as part of the bid value at all.

There is currently ongoing discussions around the block-scoring mechanism, and full balance diff is a possible option, but it’s disingenuous to claim being the most profit relay while comparing inflated numbers (concentrated in only few blocks too).

@Izzy

I think the license issue is important but murky. Manifold have raised an interesting point re: the CLA that Flashbots has employed and apparent reticence by FB to accept Manifold to contribute upstream directly.

We welcome upstream contributions, but haven’t seen any attempts to do so from Manifold.

More importantly, Manifold claiming the CLA being an issue is a straw-man argument! Our relay is released under the AGPL license, in the hope it’s useful to others, with the simple requirement to make their changes available to the public again. Manifold has chosen to use our codebase but deliberately rejects to simply make their fork public, which would be enough to satisfy the AGPL license requirements.

[paulhauner]

Sigma Prime will use the “must-include” list of relays.

We do not believe that Ethereum should achieve censorship resistance by pressuring validators to potentially expose themselves to the legal risks of other entities on the network. We believe that Ethereum is capable of specifying and implementing novel forms of cryptography which clearly place the responsibility of transacting on those that are transacting, rather than the block-signing “middle-men” (middle-people). This is not evasion of the law, rather ensuring that individuals are solely responsible for their own actions. This is what we will work towards at Sigma Prime.

We fully support node operators that wish to run only non-censoring relays and it is our wish that Lido makes room for these operators, too. We believe that if Lido wishes to engage with operators that have a high degree of moral integrity, then it should also make allowances for those operators to exercise their own moral judgement. We believe that Lido can survive perfectly well in a world where some operators use exclusively non-censoring relays and it would speak volumes to Lido’s credibility to allow those operators the freedom to operate within their own moral framework.

[ldelisle_blocknative]

@paulhauner

We do not believe that Ethereum should achieve censorship resistance by pressuring validators to potentially expose themselves to the legal risks of other entities on the network. We believe that Ethereum is capable of specifying and implementing novel forms of cryptography which clearly place the responsibility of transacting on those that are transacting, rather than the block-signing “middle-men” (middle-people). This is not evasion of the law, rather ensuring that individuals are solely responsible for their own actions. This is what we will work towards at Sigma Prime.

Looking forward to the outcomes of your efforts here. Neutral infrastructure is critical and something we aim to build and your work here will help immensely.

@KimonSh

As additional monitoring capabilities are developed over time, analysis will be undertaken and presented to the DAO to determine whether Lido Node Operators are finding an appropriate equilibrium between network and protocol health, staker rewards, and Operator specific compliance requirements.

One factor worth bringing up is relay diversity. Relay diversity, like client diversity, is critical to the health of the ethereum ecosystem. It is one thing to be connected to multiple relays - but if they all use the same source code you’re vulnerable to invalid and empty blocks. Source code diversity is critical.

To-date there are two verifiably unique codes, Flashbots and Blocknative’s Dreamboat. For operational redundancy validators should ensure that they have - at a minimum - one relay on Flashbots source code and one on Dreamboat source code hooked up to their MEV-boost.Transparency in this is something we think all validators (and relays) should consider because code diversity ensures operational redundancy.

[randomishwalk]

@ldelisle_blocknative

To-date there are two verifiably unique codes, Flashbots and Blocknative’s Dreamboat. For operational redundancy validators should ensure that they have - at a minimum - one relay on Flashbots source code and one on Dreamboat source code hooked up to their MEV-boost.Transparency in this is something we think all validators (and relays) should consider because code diversity ensures operational redundancy.

Strong agree. Do you think relay codebase diversity should be held up to the same standard as execution and consensus client diversity? Or should we demand more/less of the MEV relay ecosystem (which is quite small and concentrated at the moment)?

[aidan]

Hi everyone, Aidan from ChainSafe here.

The very limited discussion here on the impact of forcing censorship on a significant portion of the network is highly concerning. ChainSafe stands firmly alongside Sigma Prime in recognizing that this is an unnecessary action that does not contribute or align with the open values of the Ethereum community.

For some Node Operators being compliant is a necessity, and we fully support those operators in doing so. For those who have the choice, we urge you to consider the implications of censorship.

We would like to see further discourse on this topic, with the hope that it will lead to a healthy dialogue surrounding censorship at the protocol layer, and foster further options for validators.

[michaelsproul]

I’m also strongly opposed to requiring operators to use censoring relays.

I would prefer there to be no censoring relays whatsoever and for LIDO to require this. Failing that, it should give operators the choice.

@paulhauner

Sigma Prime will use the “must-include” list of relays.

I’ve discussed this internally with Paul and we disagree on how SigP’s validators should be managed, but have agreed to carry divergent opinions. Personally I would prefer SigP to cease functioning as a LIDO node operator than to engage in censorship.

[vsh]

The goal of Lido policy at it is at the moment is to emulate PBS as close as possible. You won’t have an option to censor Flashbots’ blocks in PBS and I think we should want to know how the landscape of MEV block building will end up if we continue as is - while Ethereum still can reconsider.

Having censorship resistance of Ethereum to hang on assumptions that will not hold true post-pbs (“node operators can exclude some block builders they don’t like”) is I think not the right choice.

[Izzy]

Thanks @aidan and @michaelsproul for your input. I’d like to reiterate the objective and thrust of the policy, which is to attempt to implement a mechanism which mirrors enshrined PBS as closely as possible.

In enshrined PBS (based on current designs), the validator (block proposer) will not be able to differentiate between what’s in blocks, thus they will effectively process whatever block pays the highest, with the possible addition of txs via crLists (which can, and should, be implemented in out-of-protocol PBS as well, and I don’t see why something like this wouldn’t be suggested for adoption by Lido at the earliest possibility in keeping with the same principle). This is mimic’d by hooking up a proposer to as many relays (and thus builders) as possible, with the caveat that due to the fact that MEV Boost-based PBS requires trust assumptions between Relays and Proposers there’s a vetting process that otherwise wouldn’t be necessary.

The point of using as many relays as possible is to foster relay and especially builder diversity; it is builder diversity and builder dominance which ultimately ends being the decision maker with regards to whether transactions are censored or not, and for how long.

Using “non-censoring” relays doesn’t actually prevent potential censorship from happening, because “non-censoring” is not “anti-censoring”. e.g. if the best builder 6/10 times is a tx-filtering builder, and that builder is sending blocks to non-filtering relays, then those are the bids that the relay will send and will be proposed.

Until such a time that anti-censorship mechanisms (crLists and/or ideally encrypted transactions) can be made a reality, I think that the best way forward is to test the system “as it will be” so that the right solutions can then be designed and appropriately prioritized. These are failings at the protocol level (both from a design and incentive perspective) – they should be remedied as such.

[dapplion]

I do not believe PBS will ever be added to the Ethereum protocol without crList as mandatory per-requisite. Else the protocol would accept censorship which goes against its core values.

If we assume that this is the case, then to mirror future PBS LIDO should not add a “must-include” list of relays without some out-of-protocol crList mechanism. Until that time LIDO should mirror the actual Ethereum protocol which allows to not include censoring relays, at the staker’s discretion.

[Izzy]

Practically this doesn’t solve the issue because censoring is driven at the builder level – not the relay level. Currently the reason that OFAC-compliant blocks dominate is because flashbots builders (which are OFAC compliant) are producing the highest-value blocks more often than other builders are. What’s to stop flashbots (or any OFAC-compliant builder) from sending these winning blocks to non-censoring relays and them ending up on chain?

There’s only two ways for this to happen: (a) relays that are not open to external builders and that’s patently net-worse from a builder decentralization perspective, and (b) the relay itself is doing “anti-censorship” checks (i.e. censoring potential censorers) which no relay is doing. If one can find a relay that is doing this and show that they’re effectively doing so and not ending up censoring bids erroneously, then I can see that arguing that allowing for this kind of relay choice is an optimal “censorship resistant” path. Until then, all it does is reduce the relay pool and builder pool with little to no material benefit.

[michaelsproul]

I think a difference of opinion here is whether or not there could exist a censorship-free mev-boost space without crLists. I think “yes”, the current policy implies “no”.

By dictating a must-use relay list, the current policy assumes that censorship is inevitable – “the flashbots builder will just move to a different relay”, “there are no anti-censorship relays”, etc. I do not think this is inevitable at all, and as an example let me offer the case of relayooor.wtf. This is a new relay with a single builder that is non-censorsing (source) and competitive with Flashbots for profitability (source). I would argue that an operator wanting to use a non-censoring list of relays like Relayoor + BloxRoute MaxProfit + Manifold should be allowed to do that, and will end up censoring less transactions than an operator using the must-use relay list (which will fallback to Flashbots most of the time). Not only is the alternate list less censorious, but it could also be more profitable!

I think the main argument in favour of an allow list is that Lido needs to trust the relays not to collude with the operators to steal value? Fair enough. However I don’t think this argument applies to the must-use list. The argument there is more along the lines of “operators must be competitive”, which I think could be achieved through metrics without a must-use list of relays.

I think the chance of an anti-censorship relay emerging before crLists are specced and implemented is also non-zero. It would be trivial to make a relay that only allows blocks with at least one non-compliant transaction (e.g. to Tornado Cash). Builders could just insert one if there were none in the mempool. If I weren’t preoccupied I would be tempted to build this myself.

To summarise; I’m in favour of abolishing the must-use list and allowing all operators to choose their own list of relays. This gives operators the flexibility to adopt new relays as they emerge, or drop ones that are malfunctioning or found to be untrustworthy. It allows operators to favour non-censoring relays if they believe that to be an effective strategy, without a decision being made on their behalf by the Lido DAO.

[Izzy]

I think a difference of opinion here is whether or not there could exist a censorship-free mev-boost space without crLists. I think “yes”, the current policy implies “no”.

I don’t think censorship-free is technically possible without fully encrypted transactions/mempool (or shutterizing them / etc). Even crLists do not guarantee censorship-freeness (e.g. a transaction may be delayed long enough before it’s picked up in the crList as to fail/revert/etc and thus be considered censored). Given that operators are asked to connect to as many of the “must include” relays as possible and given that the best block bid wins out and given that best bids could come from any of the connected relays, it is possible that the same level of actual on-chain censorship in MEV-boost space could exist without crLists as with. Once again – the issue is possible censorship at the builder level, not the relay level. If an operator is connected to all relays and the best builders don’t censor, there won’t be censoring.

“Non-censoring relays” are a misnomer. These relays provide no assurances about whether the blocks that they relay are censorful or not – just that the relay itself doesn’t care. In fact we could have censoring blocks being sent by “non censoring” relays and no one would be the wiser because the tools to assess actual censorship on the network currently do not exist (though some are trying to build them and IMHO I do not see any reason to not support this effort). Using “non censoring” relays and thinking we’ve accomplished something without actually assessing the practical effects and just saying “well, technically it’s probably less censorious” is performative.

This is a new relay with a single builder that is non-censoring (source) and competitive with Flashbots for profitability (source). I would argue that an operator wanting to use a non-censoring list of relays like Relayoor + BloxRoute MaxProfit + Manifold should be allowed to do that, and will end up censoring less transactions than an operator using the must-use relay list (which will fallback to Flashbots most of the time).

Relayooor has been contacted since day 1 to sign up to the Lido on Ethereum: Call for Relay Providers and they haven’t. I understand from their side why they probably want to take it slow before taking on the traffic and responsibility that Lido NOs may bring (although obviously there’s no reason to not do slow rollouts at a pace they would be comfortable with), but given that they are an anon relay I think it’s important that they show up here, represent themselves, and put themselves forward.
IMO it is not reasonable for someone else to take on the responsibility and accountability of this given the trust assumptions engendered by how MEV Boost currently works – but actually someone, anyone, can. Anyone can propose an addition to the “allow list” – so if e.g. you want to do that and the DAO signs off on it (which I don’t see an issue with personally given that it’s up to NOs to use) then it could be used, but the onus is on NOs there to (a) do the work and (b) stand by the their choices.

Not only is the alternate list less censorious, but it could also be more profitable!

If all you’re doing is adding/removing flashbots from the configuration, then I don’t get how it would be more profitable, since the most profitable block would be included regardless. At best it would be “as profitable”.

To summarise; I’m in favour of abolishing the must-use list and allowing all operators to choose their own list of relays. This gives operators the flexibility to adopt new relays as they emerge, or drop ones that are malfunctioning or found to be untrustworthy. It allows operators to favour non-censoring relays if they believe that to be an effective strategy, without a decision being made on their behalf by the Lido DAO.

This causes way too many possible issues due to trust assumptions and moves away from the goal: get as close to enshrined PBS as possible, so we can actually figure out what that’s going to do to the network. Right now reactions re: “look how censored the network is” are hyperbolic and basically wrong (see some work Rated has started doing on https://twitter.com/eliasimos/status/1580272373516812288?s=20) .

It allows operators to favour non-censoring relays if they believe that to be an effective strategy, without a decision being made on their behalf by the Lido DAO.

A protocol like Lido needs to be able to strike a balance between doing what’s best for stakers (which includes not making the underlying network worse), managing those risks, giving NOs enough leeway to operate the way they need to given legal realities and their organizational ethos (which I honestly believe this policy allows for), and operate within the technical limitations of the underlying protocol. If e.g. triggerable exits existed on Ethereum (or even just plain withdrawals), where stake could be reallocated between NOs more easily, I can definitely see empowering NOs to make these decisions on their own because then the protocol has recourse if the decisions the NO makes end up being bad. However, in the current system, this is not possible, so the policy has to account for that.

[sabrychiaa]

Hi everyone, there will be a community call and discussion about the topic next week. Updates on the community call will be posted in (Lido Node Operator Community Call)

[vsh]

Very happy to see you here. What do I think:

As long as Lido pushes for an open market for block builders, there’s no way the most profitable builder (which is currently Flashbots who happen to censor txs interacting with OFAC-ed txs) is pushed out of it. If they make most expensive blocks 80% of the time and the market is open, 80% of blocks will be censored. Right now Flashbots builder only works through Flashbots relay but it doesn’t have to - and it’s not even required for them to reconsider that, relays can proxy each other if they want to. Removing flashbots relay while maintaining a somewhat open market is not likely to change a thing, it would be just a gesture.

I am against Lido closing market for blocks. That’s the power that Lido should not have in the first place and the ability to have it happened upon Lido bc the block market design is not completely trustless - and I don’t want Lido to make steps in that direction unless the situation is absolutely dire which I don’t think it is now.

The potential viable policy for Lido would be “operators just decide for themselves we don’t care” but I think it would lead to much less usage of less known relays and non-censoring relays in Lido. And I think that relay diversity is the one of the most important long-term challenges for Ethereum. On the balance, I don’t like that option compared to what we have now.

[michaelsproul]

@Izzy

In fact we could have censoring blocks being sent by “non censoring” relays and no one would be the wiser because the tools to assess actual censorship on the network currently do not exist

I think some of the existing tools do actually give us an indication of censorship, in particular tornado-warning.info shows how many censored transactions are included per relay. We can also see from mevboost.pics that the builder-relay affinity at the moment is very strong, with very little crossover. I think we can exploit this, at least temporarily, to gain stronger anit-censorship properties. I am against presupposing that builder migration and censorship are inevitable, and I would at least like us to try the non-censoring relay approach and see what happens. There’s inertia and hidden information that may cause builders to behave differently than we expect from a naive model of their incentives.

@Izzy

given that they are an anon relay I think it’s important that they show up here, represent themselves, and put themselves forward.

@Izzy

Anyone can propose an addition to the “allow list” – so if e.g. you want to do that and the DAO signs off on it

I think the chances of good anon relays existing are quite high, and they may not want to doxx themselves to participate in Lido governance. I’ll look into championing Relayooor so they can join the allow list while retaining their anonymity, thanks.

@Izzy

If all you’re doing is adding/removing flashbots from the configuration, then I don’t get how it would be more profitable, since the most profitable block would be included regardless.

I mean removing Flashbots and adding Relayooor, as Relayooor isn’t part of the allow list currently so its blocks are not being considered.

@Izzy

This causes way too many possible issues due to trust assumptions and moves away from the goal: get as close to enshrined PBS as possible, so we can actually figure out what that’s going to do to the network.

@Izzy

In enshrined PBS (based on current designs), the validator (block proposer) will not be able to differentiate between what’s in blocks, thus they will effectively process whatever block pays the highest, with the possible addition of txs via crLists

@vsh

As long as Lido pushes for an open market for block builders, there’s no way the most profitable builder (which is currently Flashbots who happen to censor txs interacting with OFAC-ed txs) is pushed out of it.

@vsh

I am against Lido closing market for blocks. That’s the power that Lido should not have in the first place and the ability to have it happened upon Lido bc the block market design is not completely trustless

I did some more reading about the current PBS designs and I think there are few points worth highlighting:

• In almost all current PBS designs proposers are still free to choose a bid other than the highest paying one. This means they retain the freedom to avoid censoring builders if they are willing to forego some profits. The only PBS design that forces the proposer to take the max bid is Francesco’s MEV-smoothing design, which acknowledges in the last section that censorship resistance is harder when profit-maximising is enforced (and needs to be handled via another mechanism).

• There is a conflict between Lido’s desire to support open block markets, and its desire to prevent MEV hiding. If it were the case that enshrined PBS required proposers to choose the highest paying block no matter what, then Lido would be unable to blacklist builders that are suspected of hiding MEV. However, this is a moot point because enforced max bids probably implies MEV smoothing, which would disincentive MEV hiding, as all the builders would need to collude to artificially lower the highest bid. I don’t think it is possible to simulate this dynamic in the current system because there’s no max bid enforcement, and the current must-use+allow list system is a poor approximation because it excludes some builders. I think the closest approximation would be requiring operators to use all known relays under the sun, but this would come with the significant downside of reduced censorship resistance, as Francesco notes in his post.

  In the other case where max bids are not enforced in enshrined PBS, the situation is much more similar to what I’m proposing: the block proposers are free to choose bids in whichever way they want and may altruistically forego profits if they wish. I think we can simulate this today by giving operators free choice over the relays they use. This also has the advantage of improved censorship resistance because of the reasons stated earlier in my post (builder-relay affinity, interia/loyalty/etc).

@vsh

The potential viable policy for Lido would be “operators just decide for themselves we don’t care” but I think it would lead to much less usage of less known relays and non-censoring relays in Lido.

I would be in favour of this. IMO word of mouth and reputation can move faster than DAO governance adding to the allow list, and the anarchic approach to relays gives better censorship resistance + a closer emulation

Finally, it seems that enshrined PBS or mev-boost inclusion lists are still at least a few months off, based on the current state of research (Barnabé). So making a good decision in the interim is not inconsequential. Currently I like the sound of the forward inclusion lists, which socialise the cost of censorship-resistance over the whole network, which as noted in that post also can’t be simulated using mev-boost.

[Izzy]

@michaelsproul

I think some of the existing tools do actually give us an indication of censorship, in particular tornado-warning.info shows how many censored transactions are included per relay.

It’s useful but somewhat limited in that it only tells us information in the context of singular relays. This data doesn’t tell us anything about “once submitted how likely is it that X transaction will censored for Y blocks before it lands on the chain”, nor do we know how many other builders were vying for the slot at the time, what the value of those bids were, if the bids were censorious or not, and which of the relays the proposer was connected to.

Inclusion per relays unfortunately doesn’t tell us a lot about the “winningness” of bids that would (or wouldn’t) include potentially censorable txs if someone was using all relays (e.g. in an enshrined PBS-alike setting).

@michaelsproul

We can also see from mevboost.pics that the builder-relay affinity at the moment is very strong, with very little crossover. I think we can exploit this, at least temporarily, to gain stronger anit-censorship properties. I am against presupposing that builder migration and censorship are inevitable, and I would at least like us to try the non-censoring relay approach and see what happens. There’s inertia and hidden information that may cause builders to behave differently than we expect from a naive model of their incentives.

One could argue that builder-relay affinity is strong because there’s little reason for the builders in question to need to seek new relays. Once that reason exists (i.e. the relays that send their blocks won’t have enough connections to possible proposers), then you create a reason for builders who previously didn’t see a reason to send bids to additional relays to now start to.
I’m claiming that this would happen eventually anyway, but I’m also saying that if you try to stifle successful builders via relays you’ll make it happen faster. You’re claiming that it’s worth trying because it may not happen at all – however if it happens you’re now in a potentially worse situation, earlier than you would be in the other scenario, with fewer tools to combat it.

@michaelsproul

I think the chances of good anon relays existing are quite high, and they may not want to doxx themselves to participate in Lido governance. I’ll look into championing Relayooor so they can join the allow list while retaining their anonymity, thanks.

I didn’t mention anything about them doxxing themselves – but if the relays themselves don’t come and say “hey – we’re here, this is what we stand for, this is how we will strive to ensure good operations and performance, here is our history of performance, despite being anon this is what we think makes us trustworthy, etc, use us!”, then I see little reason for an NO to use them and I see a few reasons why DAO members and stakers would be suspicious of an NO all of a sudden using such a relay.

@michaelsproul

• In almost all current PBS designs proposers are still free to choose a bid other than the highest paying one. This means they retain the freedom to avoid censoring builders if they are willing to forego some profits. The only PBS design that forces the proposer to take the max bid is Francesco’s MEV-smoothing design, which acknowledges in the last section that censorship resistance is harder when profit-maximising is enforced (and needs to be handled via another mechanism).

I’ve seen those designs included as a possibility (i.e. “here are all the ways that this COULD be done”) but not as a likely choice. Efforts seem to be geared towards the max-bid design (hence the additional designs and research on crLists and MEV smoothing, which otherwise aren’t as necessary). Designs like where the proposer is more than a “dumb pipe” have potentially ruinous implications w.r.t. censorship resistance. It basically opens the door for things like censorship-at-the-proposer level which is not desirable.

@michaelsproul

There is a conflict between Lido’s desire to support open block markets, and its desire to prevent MEV hiding. If it were the case that enshrined PBS required proposers to choose the highest paying block no matter what, then Lido would be unable to blacklist builders that are suspected of hiding MEV. However, this is a moot point because enforced max bids probably implies MEV smoothing, which would disincentive MEV hiding, as all the builders would need to collude to artificially lower the highest bid. I don’t think it is possible to simulate this dynamic in the current system because there’s no max bid enforcement, and the current must-use+allow list system is a poor approximation because it excludes some builders. I think the closest approximation would be requiring operators to use all known relays under the sun, but this would come with the significant downside of reduced censorship resistance, as Francesco notes in his post.

I don’t really see the conflict. In open markets a builder that hides MEV should lose out to builders that don’t, provided that proposers are connecting to as many builders as possible. This is of course seriously harmed by builder centralization (which means there may be wide differences in bid margin between builders and thus allowing the dominant builder to still do this, or increases chance of collusion and cartelization of bids), which is why relay and builder diversity at this stage is crucial; but these same problems apply to enshrined PBS as you explain, so it’s a wider protocol design issue, not a Lido issue.

@michaelsproul

I would be in favour of this. IMO word of mouth and reputation can move faster than DAO governance adding to the allow list, and the anarchic approach to relays gives better censorship resistance + a closer emulation

Once relay management can be done via the Easy-Track mechanism (~within 1-2 months) a relay could be added to the allow list in a matter of days. Regardless, right now the issue is not existence of additional relays but their reluctance to participate in the process (even as anon). If we are saying that the vetting / trust-building here isn’t as important as the potential censorship-resistance that we gain by giving NO’s more flexibility re: relay choice, then we also need to be more specific (and strict, IMO) about what the repercussions are for an NO that makes this choice on their own but where potentially negative consequences affect the protocol and stakers.

[vsh]

One of the core issues with anarchy on node operator level is that node operator is, logically, now responsible for the performance of the relays they choose and any problems on relay level (like the recent ones with bloxroute or manifold) are theirs to sort out. Power equals responsibility. Now Lido acts as a powerful negotiator who deals with relays having issues.

The other core issue is I think you overestimate the amount of effort average NO will put into sourcing and vetting relays. In my opinion many of NOs will just settle for a couple reliable ones which will be pretty bad for relay and builder diversity.

[michaelsproul]

Sorry that I can’t make the call tonight, I’ve been ill today and can’t do the 12am time slot.

Here’s a quick dump of my latest thoughts.

@Izzy

you create a reason for builders who previously didn’t see a reason to send bids to additional relays to now start to.
I’m claiming that this would happen eventually anyway, but I’m also saying that if you try to stifle successful builders via relays you’ll make it happen faster.

I would expect the majority of Lido operators to still follow the greedy strategy. Only a subset would likely follow the non-censoring relay strategy. The dominance of Flashbots network-wide (including outside Lido) suggests that non-censoring validators would be in the minority and may not trigger builder migration. Some relays (Relayooor) also don’t accept new builders, and this could be a good thing (closer to enshrined PBS).

@Izzy

Efforts seem to be geared towards the max-bid design (hence the additional designs and research on crLists and MEV smoothing, which otherwise aren’t as necessary). Designs like where the proposer is more than a “dumb pipe” have potentially ruinous implications w.r.t. censorship resistance. It basically opens the door for things like censorship-at-the-proposer level which is not desirable.

Francesco gave the impression that MEV-smoothing and enforced max bid were unlikely when I asked about it (both are absent from Barnabe’s recent writeup). However I think it’s too early to know which way it will go. One of the main issues with enforcing the max bid is that it increases complexity and introduces a new latency assumption: the attesters have to receive all of the bids by some deadline and come to consensus on which is maximal, else block production fails for that slot. Regardless, the inclusion lists (or proposer prefixes/suffixes) are essential for censorship resistance in all MEV designs.

---

Suggestions of actionable changes that could be acceptable compromises:

Prop 1: Rename “must-include” to “should-include” for clarity

Prop 2A: Make no other changes to the policy. Introduce Relayooor to the allow list via DAO governance.

Prop 2B: Abolish the allow list. Remove the indemnity provided to operators for running relays other than the ones listed on the “should-include” list. Other relays can be used by operators at their own risk.

Both 2A and 2B would allow interested operators to run Relayooor + BloxRoute + Manifold without being in violation of the policy. The impact on rewards should be minimal due to Relayooor’s profitability. BloxRoute and Manifold provide diversity. Relay malfunctions may be dealt with by the fallbacks built into clients/mev-boost, or failing that, manual intervention.

My current preference would be for 1A + 2B.

[dapplion]

Some post-call points:

• I agree with Hasu points that relayer + builder diversity (i.e. running all competent) is the longer term solution to these problems.
• In such a perfect market, non-filtered block = most profitable block. However, currently that’s not the case
• To correct this deviation, some compromise must be made. @michaelsproul points address it. Else I propose
  • Prop 2C: LIDO can allow a fraction of validators to run an “ethical” list, while the majority runs a “greedy” list. With this arrangement LIDO can both compete and appease community concerns.