mev-boost community call #1 recap

--- tags: mev-boost-community-call --- # mev-boost community call #1 recap Recording: [https://www.youtube.com/watch?v=oxb_-4z1Sr8](https://www.youtube.com/watch?v=oxb_-4z1Sr8) # Summary - Sepolia Capella hard fork went well with Goerli coming up a few days after the call. - Ultrasound Optimistic Relay running smoothly on Goerli and preparing for mainnet launch. Still some questions around upstreaming the changes into Flashbots MEV-Boost relay repository. Some builders and relays have expressed concern around added operational overhead of running in OR mode. - Relay sustainability is an open question. Want to make sure that running the relay is accessible and sustainable while enshrined PBS research and development is in progress. # Capella ### Sepolia recap First topic is the upcoming hard fork readiness for Capella. Sepolia hard fork went pretty well. (Chris from Flashbots gives an update on their side). Went well, on relay repo main branch everything is working and MEV-Boost has an alpha release. Had an issue setting the correct Shanghai override, so everything only worked a few hours later. But all is in order after config issues were fixed and everything is working fine. Investigating updating to the newest Geth version. Goerli coming up in a few days from the call. If using Flashbots relay, there are docs / resources to see which code / releases to use. ### Block validation On testnets the Flashbots builder codebase is being used as the builder and for validation. Builder repository is for sure working and so can run it as block validation. Generally discussing whether Flashbots want to maintain both repositories and considering consolidating to simplify the maintenance. As of the call, need Prysm fork for `getWithdrawals()` endpoint so that the relay can verify withdrawals. Overall, code is pretty ready to go. For relay operators, the TLDR is to make sure they’re prepared. Can reach out to Flashbots to help with this. ### Testing and comms Some thoughts about how to test upgrade operation. On the relay front, relays will know quickly if stuff stops working at the fork. Usually relays also have some website or status page too. Regarding best way to communicate with relays, suggest using eth r&d discord channel as well as the relay channel on Flashbots discord that is monitored / active. Block construction eth r&d channel is one that relays are aware of as well. Can consider a mailing list for critical issues with relays — a way to get important info in front of everyone. Can make one and make it opt-in for people to subscribe. # Optimistic Relay ### Progress update Lots of progress since last call. At a high level, what is optimistic relaying (OR) about? It’s a change to relays where instead of validating bid / block submissions as they come in and only marking as eligible to win the auction after this validation, the relay defers validation until later. This significantly improves block submission latency. Getting close to launching in production / mainnet after running on Goerli smoothly. Have been in contact with a few builders interested in piloting. Have a builder onboarding doc and a broader roadmap for how OR fits in broader enshrined PBS (ePBS). Been trying to dramatically reduce count of simulation errors on relay. Found edge cases in infrastructure that lead to simulation errors. For example, artificial constraint on block size where valid blocks were considered invalid due to their size. Hope is for this to improve liveness of Ethereum where less blocks are stopped from landing on chain due to such errors. A long tail of edge cases (10 or so) fixing or already fixed, with some of the fixes being turned into PRs for upstreaming into the Flashbots relay repo. Also finding edge cases on builder side causing issues with blocks when they are created. Ultrasound did the work to go through every single error on builder side and told the builders about them. If you’re a builder that Justin did not approach, they request to reach out to talk about producing invalid blocks. Again, idea is that this should help the entire ecosystem. This work is part of OR operation where the relay doesn’t want any simulation errors at all. In case errors do happen in operation from block building side, they will be caught early and lead to a demotion by the relay. But if a given bid error does lead to a missed slot, it will lead to a public announcement from Ultrasound, who are committed to transparency. Have been observing progress with error fixing. On Goerli Ultrasound hasn’t run into issues with several days worth of blocks without simulation errors as of the time of the call. ### Upstreaming OR changes into Flashbots repository There has been thinking and discussion around upstreaming changes to simulation fixes which seem relevant. Ultrasound team will follow up with PRs. On the broader scale, similar thinking and discussion has been happening around upstreaming the whole OR into mainstream FB relay code. Had some discussion during last call whether this is a good idea. (Justin from EF / Ultrasound) provides some thoughts on OR adoption. One example data point is shown from a dashboard on the [rated.network builder page](https://www.rated.network/builders?network=mainnet&timeWindow=1d&page=1). For every builder, the dashboard shows the relay distribution with builders connected to many relays. One point that stands out is the Bloxroute relay where the distribution row is very different from other rows. Bloxroute builder blocks are being won by their own relay with a 96.6% rate, which Justin suggests is a sign of vertical integration. Specifically, the relay might not be simulating blocks that come from own builder, effectively running in optimistic relaying mode. So, based on this Justin suggests that once one optimistic relay gets set up, the landscape will change significantly. The idea is that once OR is activated, Ultrasound relay will be winning all the auctions, becoming a sort of forcing function for ecosystem to move to optimistic relaying. Back to the topic of upstreaming, this suggests that perhaps it’s a good idea to merge in this logic into the Flashbots repo. (Phil from Flashbots chimes in). Phil’s concern is on the market structure side. Since view FB role as standard setting, have to think through all the possible effects. Key vector that Phil is thinking about is centralization. Namely, capital requirements and possibly opening up new games. Just starting thinking about this, but if concerns can be mitigated and resolved, not against it. Generally thinks that there are deeper questions around collateral + latency. Also thinking about this in the context of the long-term dream for MEV-boost to move to a relay-less system. Since don’t think there should be any central parties, one question is whether OR requires/produces any changes that remove flexibility of removing this. (Justin’s partial response) By default, builders don’t need collateral and are not running in OR mode. Thinking of OR mode as a sort of ultra-high priority queue in addition to the high / low queues. Some “mitigations” are keeping it opt-in and capping collateral to 1ETH, which is sufficient to capture most blocks. In the case of a block with > 1 ETH value, it gets simulated in the standard way. Additional point on OR is that it’s bad for censoring relays, especially with OR V2 where you’re saving an extra 100ms which removes the censorship opportunity. Also want to push towards removing the relay. From the EF research perspective want to achieve this through ePBS, and see OR as steps towards ePBS. Think of OR as partial removing of relaying: - v1 is removing simulation - v2 is removing data / verifying availability of data - v3 is removing relay from the critical path on the networking layer. The idea is such that it doesn’t even include the relay. The relay is only the DA oracle. - Finally with ePBS the custodian is the beacon chain itself and the DA oracle is a trustless committee. Therefore, see OR as accelerationist towards ePBS. ### Dashboard from Ultrasound Ultrasound team also deployed some new dashboard with insights. These include a relay censorship dashboard, a lido operator censorship dashboard, and a builder censorship dashboard that tracks things like how many pubkeys each builder has, how many censor, and how many transactions suffer a delay from censorship. Find that impact is very low and now have the data to show it. Data collection wise, the censorship “delay” is calculated using mempool data. The Ultrasound code looks at when a transaction is first seen in the mempool in 3 geographies (Asia, US, and EU), then looks at when it’s confirmed and takes the delta between the timestamps. Phil suggests that the delay is better computed in blocks, basically figuring out when it should have been included but did not. All in all, the Ultrasound team has built up a DB with metadata for each block, tracking the proposer, builder, which relays relayed the block, mempool data, etc. Encourages anyone interested in doing some analysis / research to reach out to get access to DB. ### Relay operational concerns on OR Some relays expressed concerns around upstreaming the changes, but from a perspective of having to deal with more complexities of operating of a relay. For example, there are some concerns with OR having to manage the collateral and the legal implications of receiving funds from builders. (Folks from Aestus relay chime in). Think that it’s inevitable, and generally behind it because think that the cost of running a relay will be greatly reduced due to less simulation load. On the cons side, think that it does put the relay into a little of a bind. Also think that need to have tight relationships between builders and relays to navigate some of the complexities. Phil chimes in to mention that Flashbots can help refine data, put up more dashboards, collaborate. Also suggests thinking more around requirements for operating the relay. From Ultrasound perspective, they’ve been talking to a lot of builders and have been seeing lots of excitement. The one exception has been a single builder that has told that from their perspective this would create more accounting and complexity, primarily around collateral. They anticipate needing to draft contracts to send money as collateral due to legal restrictions. From a relay POV, Ultrasound does not want to setup contracts. Related to the earlier point on requirements of operating a relay and what it takes to do it, Phil thinks that we really don’t want to make it hard for a bunch of dudes on internet to start a relay. Ultrasound mentions being happy to be a custodian for other relays and is also happy to provide collateral for builders using own funds. The reason here is that they trust most builders and believe reputation is worth more than 1ETH. In case of issues, think that builders would be more than happy to make the proposer whole, i.e. if or when a bad block happens, the builder can directly reimburse the fee recipient. In conclusion, this issue comes down to jurisdiction and what it means to be a custodian of funds. Alex Obadia from Flashbots raises a question on the topic of going towards ePBS and at which point you would no longer have an enshrined escrow. Mike responds that would need the escrow in all versions of OR towards ePBS. In a scenario where a builder wins with header but doesn't publish the block on time, the proposer will still miss the slot. Looking ahead to ePBS, the beacon chain would be holding the collateral. Potuz brings up concerns around the builder bidding a high amount and around having a system where a builder can eclipse a block. # Relay Sustainability While working towards eEBS, the reality is that the MEV-Boost setup will be around. How to make sure that operating a relay is sustainable and that enough funding is available so that running relays is possible? The goal is to make sure that relay operators manage to sustain operation and not think it’s not worth their time. Justin provides an assessment of cost of this public good. Estimates about $100k per year per relay of operational cost. Conservatively estimating ePBS taking 3-5 years to get completed, that’s about $5 million for all relays (~10 as of now), which in grand scheme of things, is not a lot of public goods funding. Also can see that relays already have funders, for example Flashbots funding own relay, so is Ultrasound, Agnostic with Gnosis having a large treasury, etc. Don’t think that there is a public goods funding problem here and that the amount is pretty small for this space. Regarding thoughts on charging for relay services, e.g. API access, and running as a typical business, Justin thinks this is very difficult given a race to zero in terms of fees. Essentially if a relay start charging, they’re likely to lose builders, which means they’ll be less interested in charging. It’s also just hard to compete against a relay that doesn’t want to charge. If someone doesn’t charge, the ceiling is almost zero. Operationally, going through the processes as financial institution is a lot of work, for example dealing with KYC for funds from random builders, etc. In addition, engineering work doesn’t seem like it’s worth it. Highlights that the Ultrasound project is about building public goods. Phil agrees with some and thinks that it’s easier to upstream a public good then a business, but that it’s still worth asking “can we do better?”. For example, what if a new team wants to come in but just doesn’t have the means. Running a relay is a lot of work. It’s a lot of devops work, it’s distracting, expensive, politically complex in having to present positions, etc. Perhaps it’s possible to reduce the barriers and the burden to get started. Aestus mentions looking for funding but getting rejected. Difficult to navigate given that the role of the relay is being as neutral as possible. Builders are keen to pay, but as a relay don’t want to compromise. Phil mentions that it’s possible to imagine a world where there is some sort of MEV-Boost foundation to build funding rails, distribute capital, and generally coordinate more. On the topic of builder side channels, they are still very attractive and making relay operation sustainable doesn’t solve the problem. Just maybe makes more attractive to enter and cover base cost.