MEV Relays: Dumb Pipes or Something More? with Alex Nathan
Ethereum Denver·Mon, Oct 9, 2023, 12:00 AM
Relays are fundamental participants in the current MEV extraction framework, they are responsible for relaying blocks from the block building marketplace to the proposers. However, this role requires more than simply being a dumb pipe facilitating the separation of proposers from builders; their performance and configuration can impact both proposer rewards and network censorship. In this talk, I will provide an in-depth exploration of the operational performance of MEV Relays, including their role and responsibilities in the MEV supply chain. I will also review examples of how different operational performance metrics (such as missed bids, relay latency, and registrations) can affect validator rewards. Lastly, I will discuss the transaction censoring performed by relays in response to OFAC regulations. While in-protocol PBS may eventually eliminate Relays from the MEV supply chain, the on-going impact of their operation should not be ignored. Alex Nathan Infrastructure + Scalability Stage
Transcript
for the delay we had some technical issues thank you for sticking around my name is Alex Nathan I'm a co-founder and head of analytics at metrica and today I'm going to be talking to you about Mev relays if you're not familiar with metrica you can visit our platform we have free dashboards and alerts for the community at 8.michka.com if you like what you hear today you can follow us on Twitter at metrica Co and if you scan this QR code you'll be able to join our Discord so before I get the meat of the presentation just want to say a couple of words about oh so you were trying do you want to try again um yeah before we get into the middle of the presentation I want to say a couple of words about metrica so Majorca is an operational intelligence platform for blockchain networks and we work with a number of leading protocols like ethereum Solana as well as key players and ecosystems like Lido block demons right there and what we do is we help all these different organizations and entities monitor blockchain networks with our analytical tools so we provide them with alerts apis dashboards so they can monitor the performance of the network real time and uh be able to troubleshoot issues uh as fast as possible so uh the agenda for this presentation is the following so we'll start with a quick overview of the mvv supply chain as it is today and talk about the role of relays um that the relays play uh then I'll show you something that we did with a with a grant from Lido on monitoring uh the performance of Mev relays and finally we're going to touch on a somewhat controversial topic which is Alpha compliance and Mev relays so I imagine most of you have seen some version of this slide over the last few months this is what the Mev supply chain looks uh in the post merge world and compared to pre-merge there's a few different new players that emerged so on the left on the left we have the Searchers uh there's about a hundred of them but it's kind of hard to tell precisely and basically what the Searchers do is they scan mempools and they try to find Mev opportunities like front running sandwich attacks and so on and so forth uh so Searchers are very specialized boats and that's all they do once they identify uh the Mev opportunities then they submit bundles of these opportunities to block Builders uh so block Builders as the name suggests all they do is they create blocks that are ready to be committed to The Ledger uh there's about 120 block Builders right now and uh well as you can see there is something in between the block Builders and the validators and that is the relays um there's about no actually there's exactly 11 relays right now and uh as you can see relays are just an intermediary between block Builders and validators but as you can imagine the devil is in the details and relays have to do a lot more than just simply relay blocks alone so how do relays exactly work so relays constantly receive blocks from uh the builders that submit blocks to them and what they have to do is go through all of these blocks and find the one with the uh with the highest Mev reward for the validator uh in addition to that they have to ensure the validity of the block uh that it uh you know the rewards check out that the validator preferences are uh respected and then uh what it has to do is it has to send just the headers of the block to the proposer the validator the reason why it doesn't send the whole block is because otherwise it won't be having proposer Builder separation and uh once a proposer which receives a bunch of uh bids from all the relays it's connected to picks the the final Blog the one with the highest reward then the relay is responsible to propose a block on the validator's behalf now there's also something that I left out of what relays do which is they also well some relays they sensor transactions based on who the sender and the receiver is but we'll get that in a minute so uh relays essentially operate on trust right they're trusted by various uh participants in the supply chain so validators trust the relays will get them the you know as fast as possible valid blocks uh that are profitable and also validators expect that relays will propose the blocks on their behalf we have seen a few cases where relays actually failed to do that um number two uh Builders trust that relays will transfer their bids as fast as possible to the validators so they can be rewarded for their work uh now this is especially important when Builders and relays are not operated by the same entity and finally there is validators uh in ethereum with regular regulatory obligations and they trust that relay is a claim to be compliant are actually compliant so there's a lot of trust going around and our motto is trust but monitor at the same time we cannot blindly trust that relays are doing what they're supposed to do so we came up uh quite recently as I said with this lighter ground with a solution to monitor relays and um uh we went live with these dashboards and alerts last week so uh you can check them out and give us your feedback so there's two sets the solution one is the the dashboards that allow you to monitor the performance of relays in real time and the second one is the set of alerts that will notify you if relays are not doing what they're supposed to be doing so how does the solution work um we use something called they relay monitor this is an open source project by Alex Stokes from the ethereum foundation and what I really monitor does is the following so in every slot it impersonates the proposer of that slot and then connects to all relays and collects Beats from them um in addition to that we've slightly modified the the relay monitor to collect other metrics like the round trip latency for getting the headers on the relays um and in addition to that because latency plays a key role in uh when you're collecting bids we decided to deploy five instances of the relay monitors across the globe so right now we have five relay monitors two in the US One in South America one in Europe and one in the APAC region and we keep pinging all 11 relays collecting bids and other metrics so all of this data ends up in our data Lake which along with our analytical capabilities inspiring our alerts and dashboards so in terms of dashboards we have three dashboards right now on uhmetrica.com for Mev relays the first one is a relay overview dashboard so gives you some key information like which relays are online versus offline uh the total Mev blocks uh in real time as well as a Time series uh bits we collect from relays at total numbers and so on and so forth the second dashboard focuses exclusively on the operational performance of relays and here's some highlights are uh the bits missed so this is a very good indicator of whether a relay is actually online or offline another one very another very important one is the pitfalls so as I mentioned earlier relays are tasks with actually ensuring the validity of blocks so with the relay monitors we simulate what relay should be doing and if we find that something is off then we trigger then we uh log a bit fold um message and then as I mentioned latency is another very interesting metric so because we have five relay monitors deployed we can give you a median latency across all the regions but we also give you the ability to double click on a particular region and see how relays uh perform in different regions and the last dashboard is on economic performance so we look at the reward distribution for different relays just to know what's what's happening at all times in terms of alerts we have currently four alerts and all these alerts have uh Integrations with a variety of channels so we do pager Duty Ops Genie telegram Discord slack and the four relays that we went with were the following so consecutive misbeads missed speed alerts so again this is a very good indicator of whether a relay is online or offline uh the second one is a pitfall uh again checking to see that the the relay is validating blocks properly and actually yesterday we this alert trigger for the first time uh in a while and we found that a couple of uh relays were having trouble processing registrations uh the third one is relay latency uh so we've analyzed the data and we've seen that uh I relay well 99 of bids are sent within 240 milliseconds so if a relay is consensus consistently taking longer than that then we trigger a relay latency alert and finally we have the intended fee recipient alert again not a very common alert but basically what it does is if the relay uh sends a block where the recipient of the Mev rewards doesn't match the preferences of the validator then we trigger this alert and again this one went off for the first time last week with a couple of blocks route relays um so this is the first part of the presentation again uh would love your feedback uh check out our dashboard sign up for alerts and either talk to us offline or uh ask us any questions on this query now for the second part of the presentation I want to talk about offer compliance and relays so one of the core premises of ethereum is that ethereum is credibly neutral which means that ethereum is fair transparent uh impartial so no single entity has control over how the network operates and after the merge well I guess with emerge this changed for the first time because flashbots launched their first Alpha compliant relay and again this means that the relay was censoring transactions based on who the sender and the recipients were and today there's more compliant relay so blocks are blocks route regulated Eden and block native Are all uh compliant relays they're they are censoring transactions but first let's take a step back and talk about what oh is so ofak stands for the office of foreign assets control and basically they are tasked with putting together the sdn list the block persons list and once a person or an entity ends up in that list that means that U.S persons and businesses cannot be facilitating transactions with these businesses or individuals otherwise they're going to be facing fines and the big news here was last August ofak plays tornado cash the famous cryptocurrency mixer on the sdn list so that immediately meant that validators that wanted to be compliant they had to be very careful with including tornado cast transactions in the blocks they were proposing so the the big concern was that suddenly Mev boost was getting a lot of traction I think around December we're getting 90 percent of blocks coming from Mev boost and uh it's not just that mvp boost was getting a lot of momentum is that flash was was extremely dominant The Flash was relay at some point was responsible for 80 plus percent of Mev blocks and uh since then the community has really responded there's been a number of uh initiatives to try and mitigate this problem so flashboats open source their relay and their Builder uh now validators have control over which blocks they accept with the mean bit settings and today we have more non-censoring relays so uh there is seven out of the 11 relays or non-censoring uh so in a lot of all that that big controversy uh we decided to look under the hood and uh ask a question well are there relays that claim to be compliant are they actually compliant and what we found was quite interesting so we analyzed uh some data from uh November 8th to 2022 up until uh February 1st 2023.
so what you can see here is the blue line is all the blocks containing tornado cast transactions from that period of time now the green line is blocks containing tornado cast transactions that have been relayed by MEP relays and then finally the red line is blocks containing tornado cash transactions that have come through supposedly compliant relays and you can see that from November 8th up until the end of the year the end of 2022 well of tornado cast transactions were coming through just fine uh and I think at that point the supposedly compliant relays figured out what was happening and they fixed it but even now you can see in January there's some spikes every now and then with transactions coming through uh if you ask why this happened our hypothesis is that uh on November 8th it happened that uh some more tornado cash addresses were blacklisted and the supposedly compliant relays never picked that up and it took them a month and a half to fix it so uh what are the key takeaways here uh relays have been called down pipes just because they are moving blocks around but clearly they fight they affect many participants in the ecosystem uh and we really think that Builders and validators should monitor the performance of Mev relays because uh the rewards depend on on them but I also want to make a comment about uh Mev boost and censorship in general so we believe that Mev boost is not synonymous to uh censorship and there is a blog post that my team has been working on it's going to come out next week where we actually looked at mempool data to see you know what is can we quantify this censorship and what we found out is that 99.5 percent of tornado cash transactions that are in the mempool end up on chain so there's not a lot of censorship in terms of uh whether a transaction is successful where there is some censorship seems to be in the waiting time how long does the transaction a sensor transaction stay in the mempool and what we found out was that the median uh wait time for regular transactions was eight seconds but for non-offer compliant transactions it was 22 seconds so it is a big difference it is three times more but still the success of a ofak uh non-uh non-compliant of a transaction is not affected so uh next steps if you haven't visited our dashboards already in the past what 20 minutes uh please do you can go to 8.matchca.com Mev um join our Discord you know would love to hear your feedback uh and improve our dashboards and alerts as much as we can as I mentioned we have uh uh a number of blog posts coming up coming out this week and also next week so all our blogs are published at blog.metchka.
com and we also have a booth in devtopia it's further behind us so please stop by and say hi thank you very much [Music]
Automatic transcript — names and jargon may be misspelled.