Lido on Ethereum: Call for Relay Providers

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.

3 Likes

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:

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.

12 Likes

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. :saluting_face:

2 Likes

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?

2 Likes

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.

1 Like

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

3 Likes

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!

5 Likes

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?

1 Like

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.

2 Likes

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 :sweat_smile:, 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.

3 Likes

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.

2 Likes

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 :white_check_mark:
  • Publicly listed & maintained: YES :white_check_mark:
  • Open source: YES :white_check_mark:
  • Transparent about transaction or address filtering policies: YES :white_check_mark:
    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/

6 Likes

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.

:+1: on all the rest!

2 Likes

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.

6 Likes

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/

3 Likes

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