Lido on Ethereum: Call for Relay Providers

[Izzy]

Thank you Ben for the heads up and taking steps for safe rollover.

The Relay Maintenance Committee will proceed with removing the Bloxroute Ethical relay from the vetted MEV Boost relay list in the coming days.

[thegostep]

Hi, I’m Stephane, founder of Frontier Research.

Frontier Research is an independent research and advisory group formed to bridge the gap between fundamental research and commercial products. We build upon our expertise in MEV and blockchains to pull the future of crypto into reality.

I recently shared our manifesto, which you can read here to understand our ethos better:

Stephane

Following on from the Faith Builder we are excited to announce our next adventure in the Transaction Supply Network is a mev-boost relay with the goal of improving relay diversity and innovating in this design space.

Our relay is currently in open beta and we would love to onboard Lido node operators to help test our relay on goerli and mainnet. We are experimenting with different deployments in order to maximize block value and minimize missed slots.

https://blockspace.frontier.tech
https://goerli-blockspace.frontier.tech

We look forward to presenting our relay at the upcoming Node Operators Community call on Tuesday 29 Aug.

[ldelisle_blocknative]

After considerable internal debate and in consultation with our Board of Directors, effective Wednesday, September 27, 2023 8am PST Blocknative will suspend the Blocknative MEV-Boost Relay and associated Ethereum Block Builders.

The Blocknative Relay Data API will remain available for data downloads until October 4, 2023.

We do not anticipate this change disrupting Validators or other network operations. To avoid any error messages after September 27, please modify your configurations as follows:

• The Blocknative Relay will return a 503 error with “no builder bid”.
• Ensure your Validators are connected to multiple MEV-Boost Relays and have local building enabled.
• Remove the Blocknative Relay from your Validator configurations.

We deeply appreciate your partnership and readiness to engage with our Relay over the past year.

[Izzy]

Hey Laurence,

Thank you for the notification. It’s sad to hear that there’s a relay operator leaving the space, especially given blocknative’s efforts to maintain a separate codebase.

I will notify the relay maintenance committee as well to begin the on-chain transaction to remove the relay from the vetted relays list.

Will there be any full archive/snapshot of the Relay Data API data made available anywhere?

[ldelisle_blocknative]

Thank you Izzy!

Regarding the full archive/snapshot: Blocknative has no plan to maintain a full, shareable archive of the Blocknative Relay Data API. We are keeping our Data API instances running until October 4th to allow the community to scrap any data they think is relevant for themselves or future research purposes.

[Izzy]

The Blocknative Relay has been removed from the vetted relays list by the RMC as the relay has been shut down, see: Lido on Ethereum: Call for Relay Providers - #24 by ldelisle_blocknative

[ben_bloxroute]

Hey all, the bloXroute team has shared with you guys a few times about the validator gateway and we had some node operators asking for the green light from Lido to test it out.

Our validator gateway uses two components, a relay-proxy and a BDN hosted gateway. The relay-proxy acts as an additional relay on mev-boost/vouch startup arguments while the BDN gateway is a peer for the consensus and execution layers.

Here is the code for our relay proxy: GitHub - bloXroute-Labs/mev-relay-proxy
Here is the code for our BDN Gateway: GitHub - bloXroute-Labs/gateway
Here are the docs for the validator gateway: Validator Gateway - bloXroute Documentation
Here is more info about the validator gateway: Introducing the Validator Gateway: Boost Your Ethereum Validator Rewards - bloXroute

Please let me know if there is any information you need from us regarding this!

[Izzy]

Hi Ben,

While the RMC is reviewing this, could you please also let us know if the code for the relay proxy and gateway undergone any audits and/or security assessments?

[ben_bloxroute]

We haven’t had any security audits conducted on the BDN gateway or the relay proxy. We do have self hosted options that are open sourced if people would like to review.

[alextes]

Hi hi, Alex from Ultra Sound. We’ve been asked to share the state of an experimental change we’ve made to the relay. We call it “adjustments”. Let me set the context. Given:

• builder A bids against builder B, at relay X. builder A bids 19, builder B bids 21. relay X now has a 21 top bid.
• builder A bids against builder C, at relay Y. builder A bids 18, builder C bids 19, relay Y now has a 19 top bid.

Most relays are “simple”, and when the proposer asks, relay X would offer 21, Y would offer 19, and the proposer would pick the 21 bid. The ultra sound team realized the following. If you see the proposer asking the relays for their best bids as an auction, simply “max-bidding” as a relay is not always optimal. Relay X could, by slightly lowering its bid to 20, still win and keep a fraction of the bid for itself.

We’ve been running this experiment for some weeks now. Some points / questions that have come up:

• the impact so far is rather small. in feb ultra sound delivered 9,607 ETH in bids, and reduced bids by 55 ETH or 0.57%. March 6,266 delivered, 20 reduced or 0.32%. until last week, ultra sound has kept $0 for itself and returned 100% of superfluous bid value to builders.
• the ultra sound relay always provides the highest bid a proposer can possibly get, otherwise it simply loses the auction. as long as a proposer is connected to multiple competitive relays, this stays true.
• in practice the advantage one relay has over another is often latency based. it is possible one relay can no longer get a better bid to a proposer before the proposer’s deadline, whilst another can. the amount the bid appreciates in those milliseconds is value the relay adds and can capture. it would be impossible to receive the better bid if the relay wasn’t around or hadn’t invested in being fast.
• relays cost money to run , we currently don’t charge proposers or builders. the more you charge proposer, and especially builders, the more attractive you make it for them to run their own.
• if a builder runs their own relay, adjusting bids as outlined above becomes a no-brainer, and neutral relays which try to contribute to proposer-builder separation would go unused.
• relays have been in talks with various parties for months, including Lido! to see where relays could get funding. the ultra sound team is rather proud to say they may have found a way to fund themselves which asks neither builders or proposers to pay for their services and keep supporting Ethereum censorship resistance, the relay ecosystem, the ultra sound website, and maybe even based sequencing.

Happy to answer questions if anybody has them, you can also find me on TG as Telegram: Contact @smilingalex.

[Izzy]

Hey Alex, thank you for providing this info here!

the impact so far is rather small. in feb ultra sound delivered 9,607 ETH in bids, and reduced bids by 55 ETH or 0.57%. March 6,266 delivered, 20 reduced or 0.32%. until last week, ultra sound has kept $0 for itself and returned 100% of superfluous bid value to builders.

Is it possible to specify how much of this specifically relates to the Lido protocol EL rewards vault (0x388C818CA8B9251b393131C08a736A67ccB19297)?

What are your plans with regards to when the delta (superfluous bid value) will begin to be split between the relay and builders, and how are you thinking of determining the split?

Additionally, for the community, I’d like to provide this resource from the ultrasound github for community members who may be wishing to dig into more details on this mechanism.

In general, I understand the need for relays to find ways to sustain their operations, and in principle this mechanism should not result in proposers receiving materially less payouts than they would otherwise (i.e. a builder could be “minimizing” their best bid continuously as to not overpay, but not all builders are able to do this as quickly as necessarily and “offloading” this work to a relay is both more effective and efficient (if the relay does its job properly)). In essence, it represents builders paying relays which have better latency a fee to utilize an “overbid minimization service”, so as long as it’s open, fair, and transparent, it can be benign.

That said, IMO there are a few important considerations here:

1. this service should be available to any and all builders who wish to use it, and no “special terms” should be afforded to sub-sets of builders
2. the service should be public and transparent in the sense that bids are adjusted based on public info, and not private info (i.e. the “original” and the “adjusted bid” should both be available, which it seems that they are via your data API).
3. we must be cognizant of the possible centralizing effect here whereby if only a single relay offers this mechanism or does it way better than others, then builders will prefer this relay (or exclusive send their flow to this relay) which may lead to cartelization or relay monopoly (it doesn’t seem to be the case here, and if so there are things the protocol could do to shield itself, so it’s more-so something that needs to be monitored in case adjustment is needed)

In general, the world of PBS and relays moves really quickly, and can be difficult to follow, so it’s highly appreciated if and when relays make substantial operational changes (such as this) they are communicated to the DAO & community timely.

From a DAO and protocol perspective, I believe it’s important for stakers, the DAO, and the community to be able to easily discern when this happens, how often it happens, and how much total value has been “alternatively routed” in this fashion, so I will be working with the RMC and DAO contributors to see if/how this can be reflected in public tooling, such as the fees monitoring dashboard.

[kubi]

Hey everyone,

I am Kubi from Gattaca / Titan. We’re excited to announce the launch of Titan Relay on Ethereum mainnet.

We first introduced our relay a few months ago during a Lido NOCC (which can be viewed here: https://www.youtube.com/watch?v=1rv2JIZJg7I).

Since then, we’ve conducted extensive testing on Holesky alongside numerous node operators, including DVT, and have been operating live on mainnet for the past few weeks.

As one of the leading block builders on Ethereum, we’ve established a reputation for delivering highly performant infrastructure - and the majority of active searchers, institutional trading firms, wallets, OFAs, and other mainnet block-space consumers rely on us for their bundle and transaction processing.

Our relay features a completely new codebase developed in Rust, designed for optimal performance and reliability. It has several new features, such as geo-distribution (currently live in four locations: Ashburn (US East), Frankfurt (EU Central), Singapore (Asia Southeast), and Tokyo (Asia Northeast)) to better serve under-represented regions, alongside Optimistic V2 for enhanced latency and optimized block propagation, among others.

With this new codebase, we also underwent a security audit conducted by Spearbit, with Alex Stokes (EF) and Matthias Seitz (Reth, Foundry, ethers-rs) as lead security researchers.

• Publicly available: YES
• Publicly listed & maintained: YES
• Open source: YES
• Transparent about transaction or address filtering policies: YES
  We offer configurations that either include address filtering based on the OFAC list (censoring) or do not (non-censoring).

Links:

• Mainnet:

  • Non-censoring:
    https://0x8c4ed5e24fe5c6ae21018437bde147693f68cda427cd1122cf20819c30eda7ed74f72dece09bb313f2a1855595ab677d@titanrelay.xyz/
  • Censoring:
    https://0x8c4ed5e24fe5c6ae21018437bde147693f68cda427cd1122cf20819c30eda7ed74f72dece09bb313f2a1855595ab677d@censoring.titanrelay.xyz

• Holesky: https://0xaa58208899c6105603b74396734a6263cc7d947f444f396a90f7b7d3e65d102aec7e5e5291b27e08d02c50a050825c2f@holesky.titanrelay.xyz/

[alextes]

Is it possible to specify how much of this specifically relates to the Lido protocol EL rewards vault (0x388C818CA8B9251b393131C08a736A67ccB19297)?

Keep in mind this is still a developing experiment. Variance for this numbers is high.
Feb: 3213 ETH paid, 27.3 ETH improved / captured delta (0.85%)
Mar: 3386 ETH paid, 12.6 ETH improved / captured delta (0.37%)

Plans for what ultra sound earns with these bid improvements is:

1. pay builders to incentivize them to do this with us at all
2. contribute to the non-censoring relay / PBS ecosystem
3. reward ourselves for the endless hours the team has invested

As to the precise split, I’d say we don’t have strong opinions. Ongoing conversation with the builders.

RE important considerations:

1. the feature is open to all right now.
2. it is. we openly share our bits with all who ask as long as they’re not relay performance bits.
3. agree. it is easy to stay decentralized if it is rewarded. inverse is also true.

on all the rest!

[kubi]

Just a quick note regarding the builder onboarding process: We’re inviting all block builders to reach out for whitelisting and start submitting blocks to the Titan Relay. Our whitelist isn’t restricted to a specific group of preferred builders; its purpose is to ensure smooth onboarding, prevent unexpected loads, and establish communication with submitting builders. We aim to transition to fully permissionless block submissions once we’ve gained more confidence in load management, currently targeting the beginning of June.

[kubi]

Titan Relay Update

Hi everyone,

Here are a few updates regarding the Titan Relay:

• Permissionless Block Submissions: We enabled permissionless block submissions a few months ago. You can find more information here: https://x.com/titanrelayxyz/status/1814297124651081738

• Mainnet URLs Update: The official mainnet URLs have been updated as follows:

  • Mainnet Global (non-filtering):
    https://0x8c4ed5e24fe5c6ae21018437bde147693f68cda427cd1122cf20819c30eda7ed74f72dece09bb313f2a1855595ab677d@global.titanrelay.xyz

  • Mainnet Regional (filtering):
    https://0x8c4ed5e24fe5c6ae21018437bde147693f68cda427cd1122cf20819c30eda7ed74f72dece09bb313f2a1855595ab677d@regional.titanrelay.xyz

For more details, please refer to our documentation: https://docs.titanrelay.xyz/

[Izzy]

Just cross-linking an update from the RMC proposing to:

• deprecate the Eden Network relay
• add the Titan Relays (Global and Regional) to the “may use” list

[sambacha]

Would also like for consideration Proposal: Inclusion of SecureRPC.com MEV Relay as a Mandatory Relay in Lido's MEV Relay List - #6 by sambacha

Having a relay that is not a builder is important for the diversity of the relay operator set.