# Can we fix MEV? by Jonah Burian | Devcon SEA

- Speakers: [Jonah Burian](https://streameth.org/speakers/jonah-burian)
- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-09
- Duration: 26:28
- Topics: blockchain, smart contracts, distributed ledger, ethereum, Science & Technology
- Watch: https://streameth.org/watch/yt-69IZIIsanvM
- YouTube: https://www.youtube.com/watch?v=69IZIIsanvM

## Description

MEV is problematic today. The MEV supply chain puts centralizing pressure on Ethereum. There’s also an allocation problem; proposers (not apps or users) earn nearly all MEV, though they’re merely protocol agents. Numerous proposed solutions address this (ePBS, EAs, ETs, FOCIL, BRAID...), each with tradeoffs and assumptions about whether MEV is intrinsic to blockchains or extrinsic & preventable. Research is challenging to enter w/o continuous engagement. I’ll provide an overview of the research.

Speaker(s): Jonah Burian
Skill level: Intermediate
Track: Cryptoeconomics
Keywords: PBS, Consensus Mechanisms, MEV, execution, tickets

Follow us:   / efdevcon  ,   / ethereum  , https://warpcast.com/devcon
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon SEA was held in Bangkok, Thailand on Nov 12 - Nov 15, 2024.
Devcon is organized and presented by the Ethereum Foundation. To find out more, please visit https://ethereum.foundation/

## Transcript

[Music] hi everybody my name is Jonah buan um as he said I'm a researcher and investor at a fund called blockchain Capital um we were actually the first Venture fund focusing on blockchain period started about 11 years ago um so the topic of this talk is ambitious is going to be can we fix me and I'm going to assume some baseline understanding of me in this talk I'm going to assume people are roughly familiar with a sandwich attack roughly familiar Earth proposer Builder separation if that's not you I'm sorry that you're trapped here with me for the next uh 30 minutes um so the layer of the talk is going to be we're going to set up the problem what is the problem with me today as it stands then we're going to say okay well there's a problem what's the root cause and we're going to try to get to the root of where me comes from We're then going to propose two different schools of thought on how to solve the problem finally we're going to talk about all the different subsolutions that each of these schools of thought have presented so problem root cause two schools of thought all the research around it um so without further Ado me as it stands today is a real problem the first problem is there's an allocation problem and what I mean by that is me is value that is extracted from users yet where does the value flow in the current market structure the people that end up with all this value are the proposers so you have value being extracted from users and flowing to proposers who are simply agents of the protocol that's kind of weird you would assume well you would hope maybe the users would get it if not maybe the applications who are generating it if not at least the protocol but the idea that these out of protocol kind of Agents of the protocol are getting all this value that's kind of a weird Market structure and the second problem with M as it stands today is a centralization problem what I mean there is first off there's an oligopoly in the current meev structure about two Builders represent about 85% of all blocks built that's an oligopoly um and the other big problem is there's a incentive to collocate there's a centralization problem that's Geographic um so the idea here is a little bit nuanced I'm happy to talk more about it in the Q&A section but the idea is there's an incentive to propose your block as late as possible you get more meev that way and if the incentive is to PO propos to BL as late as possible you want to be collocated with other proposers to make sure your block is accepted so slowly over time you should accept expect geographical centralization and we're seeing that so that's not so good for the sake of the network we really hope for geographical robustness and yet the current state of me is actually putting pressure to centralize geographically so there's an allocation problem there's a centralization problem it's not looking too good so how do we solve this well to solve any problem we need to understand what is the root cause of the problem right so let's understand the source of me and this next slide is going to be probably the most important slide if you walk away and this is the only slide you understand perfect me originates from a monopoly on the right to propose a block that is the root cause me specifically it's the Monopoly on the ability to include transactions and to order transactions in a slot so every 12 seconds or so in ethereum one proposer gets the right to propose the next block and with that right comes you get to choose all the state transitions that go into that block all the transactions and The Ordering of them so take a classic me example like a sandwich attack what's going on well let's say there's a big buy order the proposer and by the way it's they're now Outsourcing this Ro to the Builder but in concept the proposer is saying I want to put my buy order right before this big buy order my sell order right after put the three of them together and put them somewhere in the block so they've ordered three transactions got their three transactions included and strategically placed in the block right or including and ordering this ability this Monopoly has given the ability to do the sandwich attack so me originates from this Monopoly this is the fundamental place where it comes from so then how do we solve me well there's two schools of thought the first school of thought is me is intrinsic any decentralized system any any blockchain is going to have me in it somewhere it it is going to be exploited there's me somewhere in the system and you can't fix it the other school of thought is no no no m is not an intrinsic property of blockchain it's a function of bad design me is extrinsic you can actually solve it with proper engineering so under the me is intrinsic Camp it's it's something fundamental how do you solve the problem well we said before me originates from a monopoly well sell the Monopoly right so the idea here would be the Monopoly is worth something you can extract a certain amount of value so how much would you be willing to pay for the right to extract value well up to the value you can extract so if you can extract $100 you'd be willing to pay up to $100 to extract $100 so the idea is there's a monopoly in the system we're not going to get rid of it so let's sell it by the protocol selling the meev it gets back the value that's being extracted at the protocol layer and now you can probably solve the allocation problem how well you could redistribute it to users perhaps maybe back to the applications maybe just to token holders by burning it there's different approaches but at least you probably solve the allocation problem and then from the centralization problem of is there centralization in a protocol we have to take each solution and and ask that question it's not clear on the me is extrinsic camp that me is just a function of bad engineering how do you fix it well it comes from a monopoly break the Monopoly right simple idea if me is a function of a monopoly break it So within each school of thought there's been many different ideas that have been proposed and by the way these two schools of thought probably exist on a spectrum so the idea that I'm putting these in two different camps is more stylistic for the purposes of these talks but there's about six big solutions that have been proposed and they kind of roughly fall into these camps and the goal for the rest of the talk is going to be to cover each of these Solutions at a high level to people have a understanding and an intuition of where these ideas are coming from so one quick pit stop before we go and through these six Solutions today's me pipeline in some sense falls into the intrinsic Camp of selling the Monopoly so the way me works today is proposers are not sophisticated enough to kind of exploit these me opportunities so what do proposers do they sell the Monopoly they sell the Monopoly to builders so proposers are holding on to this verely valuable Monopoly they can't use it so they sell it and in turn they effectively get the value associated with this Monopoly the builders are paying that value in an auction process which means that that's why proposers end up with all the values and we talked about the allocation problem at the beginning this is the reason why and the reason the protocol isn't getting the me is that this whole entire proposer Builder separation process is happening outside the protocol so that's a current market structure today so the kind of obvious place to start when you're thinking about how do you fix the meev problem is what if we take the exact same idea of proposer Builder separation and run it in protocol right super simple idea you just at block n you sell the right to block n you run proposer Builder separation and protocol maybe we've solved me unfortunately if you look at the research and I'm not going to get into all the reasons why there is real problems with this from an engineering perspective it's hard to do it also might induce some other weird forms of me there's you might even be able to bypass this protocol it's it probably doesn't solve the problem go on eth Research you can read a million reasons why but the intuition here is that there's this deterministic way of selling the block perhaps you can capture me that way right selling the right to me in Block n at block n doesn't really work but what if we could sell the right to a future block so at block n Maybe we sell the right to a block 32 blocks later so the idea here is execution auctions you sell the right to the Monopoly in advance and having this buffer from an engineering perspective might fix it might fix the problems associated with epbs and Shrine proposer Builder separation that was the previous solution I discussed so the idea here in execution auctions is sell the Monopoly just do it a little bit in advance um I've personally done a lot of research on this put out some blog posts but there's a great formalization of this by mes and Max Resnik and they basically show the the the highle idea is unfortunately you create a real centralization problem here where in kind of selling the blocks in advance you you you don't really fix the centralization problem you may be fixing the allocation problem you may be capturing some M centralization problem isn't fixed and on top of that there's been another school of research about multiblock meev which is the idea that if you have control two block in a row you can extract more me than the sum of the two blocks um that's a very malicious type of me because it leads to some pretty bad centralization problems happy to answer that in a Q&A section and it seems like execution auctions are the most exposed to this type of M so there's some problems here not at dead end necessarily maybe there's some more research here we can fix some of these problems but that's where research kind of stands today so we just discussed a whole school of thought about deterministically selling the Monopoly well and kind of had a dead end so what if we non-deterministically sell the Monopoly and the idea here is there's a couple of ways of selling something you could directly sell it or we can run a lottery for to kind of receive it so under this Lottery intuition there's the idea of execution tickets execution tickets are a effectively a lottery for the right to propose a block so this is another proposed solution I've done a lot of research here and the way the lottery works is there's call it end tickets in existence every block one ticket is selected that ticket whoever got whoever is holding it they get to propose a block their ticket is removed from the circulation a new one sold so at all moments there's end tickets in circulation you have a one overend chance of winning if you're holding a ticket and you basically have a one overend chance until finally you win um so that's the idea you're effectively hosting a monopoly it's non inter terministic this actually helps a lot with multiblock me happy to address that in the Q&A section um does this solve the problem so I did I wrote a research paper with David crapus at the um ethereum foundation and thead Salah who's a fantastic blockchain researcher and financial researcher um what we showed in our paper is unfortunately regarding me capture it doesn't seem like execution tickets are able to really capture capture all the me as a result you can't exactly fix the allocation problem on the centralization side it seems that execution tickets these lottery tickets will probably be concentrated amongst a couple of actors or maybe even just one actor so that kind of oligopoly we spoke about earlier will exist now in another setting for execution ticket holders and that's a whole new actor in The protocol that might cause some problems so unclear if this really fixes anything but again we're discussing the vanilla implementation of execution tickets there's been questions about what happens if we extend the model and maybe we uh sorry extend the idea and maybe have a unbounded number of tickets that was a paper by Kristoff uh and it actually kind of fixes some of the problems so there's probably some more interesting research there I don't have a slide on this but Pascal's in the audience and he's written some other extensions to the model that are also there's there's something in there there's uh there's potential Solutions in there um so the other non-deterministic school of thought is a concept called Rand EAS or random execution auctions it's kind of a blend of execution tickets and execution auctions it was a new idea it was just proposed recently um there's not been tremendous formalization of it my intuition is that it probably Falls prey to the same problem to execution tickets and execution auctions face um I think some research is needed to to really make sure that's correct um but we'll save that for another talk um now the other kind of concept the other school thought this entire four Solutions we just discussed or under the me is intrinsic um it's always going to be there so sell the Monopoly the other school of thought as you guys recall is me is extrinsic this is this is a function of bad engineering so the solution is break the Monopoly how do you break a monopoly well the Monopoly is there's one proposer how do you break it more than one proposer super simple idea that that that's the concept um and within this kind of Paradigm there is two different solutions that have been proposed the first is fossil I'm sure over this past week if you guys been going to sessions you've heard a lot about it but the highlevel idea is we have one proposer and a group of proposers that are allowed to force to include some transactions and by doing this you effectively break the inclusion Monopoly that proposers have today and there some other Downstream effects I'm not going to get too into it but that's the intuition there and what's interesting is that fossil if you look at the research actually works very nicely in tandem with execution auctions or execution tickets you can actually begin fixing some of the problems I discussed earlier by meshing these two approaches together um happy to talk more about this later um but the other big idea is I would say a more extreme version pushing the multi- proposer idea to its logical conclusion of no no no no we're going to have we're not going to have this subcommittee we're going to actually have multiple proposers the idea here is for Block n you have call it I'm choosing a random number you have eight proposers for Block n and every proposer what they do is they choose a subset of transactions to include based on their own local View and then what is block n you merge all the transactions from the eight proposers together and you apply a special sequencing rule to it so by doing so you've actually fixed two things you've broken the inclusion Monopoly and you've broken the sequencing Monopoly now uh an easy question to ask is wait a second why can't we have break into the sequencing Monopoly the entire time right you can always apply a special ordering rule to a block there's no reason that the proposer has like needs to do that and the reason why we can't do that when we don't have censorship resistance is well if a proposer knows their blocks and have a certain sequencing and they don't like the order of a transaction they just won't include it so you can't apply a special sequencing rule to a block without having censorship resistance and that's something that braid or multi- proposer solution gives you so again the idea of braid high level is take a bunch of proposers they all propose some blocks some sorry some transactions to be included into a block merge it all together apply a special ordering rule presumably this should break the sequencing Monopoly and the inclusion Monopoly so there's a bunch of open questions about this solution um the first is and this is a me is intrinsic type of question wait a second I don't think you can break this a monopoly there probably exists hidden in this structure another Monopoly and in braid the proposer that proposes last in some sense they have a monopoly because they see all the other things that will be included so they really know based on what they do the end result of the block so they have some power over sequencing and including not necessarily the full power that today's proposers have but some power and the question becomes can you have simultaneous release where you don't have somebody with the last look open question in the research another question is that there's going to be some exclusive orderflow auctions that are going on how does that affect it another big question is how does the gas limit work when you have multiple proposers that's another um open question so if you take a bird's eye view again and just going back through the talk we began by saying today there's a real problem we have a allocation problem we have a centralization problem this all Spurs from a monopoly and within it we had two kind of ways of solving it let's sell the Monopoly let's break the Monopoly and with each within each of these categories there has been a bunch of different ideas that have been proposed the literature again I don't know which one's the the right one um I think a lot of work needs to be done but I encourage everybody in this crowd to do some research here and one of the reasons why I personally love meev research is that me research is all about how do you break a system how do you break consensus how do you kind of exploit consensus but through this research you end up learning a lot about how consensus works and a lot about how the execution environment works so it is a interesting form of research that really gives deep intuition about how these systems work so I encourage everybody to dig in I kind of baited people by saying can we fix and the answer is I I don't know um there's a bunch of solutions out there um but hopefully I motivated people to do some further digging um so I guess finished a minute early um so I'll leave room for a little bit more [Applause] questions um if I already see a lot of questions in but you can scan the QR code and we'll quickly tackle the questions there's quite a few I'm going to read them out for the audience joining online would inclusion lists or obfuscated encrypted meme me pools be a solution to solving me yeah so this is a a good question um the one of the questions when it comes to encrypted me pools at least is as a proposer do I have to to accept a transaction from the encrypted men poool and if the answer is no then you could only accept unencrypted transactions and propose those and you end up with the same Monopoly if you're forced to accept transactions from the encrypted me pool you could theoretically create side deals where you have people prove what the encryption represents and then the Monopoly comes back there's some ways to circumnavigate it is my point um so it is possible that at a first order attempt encrypted mem pools does solve some of these problems but it is circumnavigate doesn't mean people will do it but as we see people go through crazy lengths to exploit me so would don't surprise me if they do um in Lottery based proposals what determines how many tickets one entity can hold aren't we Reinventing proof of work so it's very funny the uh the proof of work comment is is correct in a lot of ways a lot of writers have written about this but um what's the most amount of tiet someone can hold there there's zero way um maybe use like World ID that you could uh that you could um enforce um a limit of how many tickets you can hold because if you say everyone can hold one ticket create multiple accounts now you can hold 12 tickets right so there's no way of forcing a limit here so one one actor could really have all the tickets and what we showed in that research paper I was talking about before is that that's probably going to happen at least with the vanilla attempt of how um execution tickets are uh proposed um is bra napkin mat I think braid is an interesting idea I think it's definitely worth exploring I mean as we showed in the kind of the presentation breaking the Monopoly is one really interesting way of solving meev doesn't mean that meev is extrinsic it really could be that me is intrinsic and we're kind of going down a false Road and we'll never fix it but the intuition of there's a monopoly have multiple proposers to break it is probably a correct one and there's at least a nugget of Truth there so I definitely think it's worth exploring and related question how does special ordering work in braid um so that's a interesting open research question so the kind of the dominant idea right now is just do a priority ordering where you kind of just rank order transactions in terms of their priority fee um but that's just one idea of an ordering rule there could be many other ordering rules um and that's an open area of research of what ordering rule limits how much me is exploited what captures most me there's a bunch of questions there so um there's future research to be done uh and the other is why can't we just order transactions based on time stamp and why is that not a proper solution it's hard in a decentralized system to guarantee like the that the time stamp is accurate and also if you collude with some other actors you can you can forge a Tim stamp so you're just asking for other games to be played uh isn't it hard for Builders and proposers to bid the right meev value in advance for future block space rights so yeah this is by the way this is a fantastic question so today in the current meev pipeline if you if you think about what Builders are doing is they know expost what transactions they have so when they're bidding for the Monopoly right they they they they they know they know the value of what they hold so they're they're not bidding overe expected value they know exactly the value they have and can make a bid as such in the case of execution auctions when you're bidding for something in advance or execution tickets when you're bidding for something in advance you're you're bidding exante um and you don't you don't know the value of what you're going to get and as a result you have to do an expected value calculation and if you look at the paper that I put out with David day and fad we show that in when you're doing this stuff in expectation there's a lot of weird properties first of all um there's probably more centralization that takes place um because not all actors can do these exante calculations and on top of that certain actors consistently have higher ex anti valuations but only expost do other actors have a higher valuation um you can see that in the the research um and also part of the reason why we can't capture all me is that people are might be risk averse and downweight the meev they will capture because it's an expectation as a result when you pay for this Monopoly right you won't pay the full amount um the next two questions are related um if we want to give me back to users is as SS the only practical solution um and rather than removing me could we uh approach in a different way where the protocol captures some value from from the from the me um I guess I'm going to answer the first question I don't fully get the second question um my guess is this this is a Cella proposer of how applications can capture their own me so application meev capture is by no means um it works together with protocol Mev capture so one nice way of thinking about the Cella proposer is that they're just running PBS on an application like at the application layer and that definitely should capture me but I don't think that is um non-compatible with protocol M capture um I I this this talk was mostly about protocol M capture of how the protocol fixes a problem I'm not as well versed in how applications kind of fixed a problem so I'm not going to comment further but I want to speak and and and be wrong and yeah the second question is down if you yeah so the if the goal of the protocol is to capture 5% of me like it's it's hard to design an approach where like you're able to Target 5% and get it what's most likely going to happen is you try to capture all of it and if you only want to capture a percentage you can rebate some or you could just say that whatever approach is going to happen is probably not going to capture everything so this is an 80% approach but you can't necessarily Target a percentage per se um currently meev is not a priority in the community compared to other topics how can we increase the attention on the topic um actually I don't know if that's true um I mean fossil has been getting a lot of attention recently um execution auctions execution tickets I've seen a lot of writing recently I think that in today's world um interop is probably one of the bigger problems that users are facing and I I think it it makes sense why that's kind of become the priority recently but I I think I think meev has gotten sufficient attention obviously bias I I love working with me researchers so the more the merrier but I think it's getting the attention it deserves the next question is an interesting one but we've run out of time and um he's a good guy he's a good guy yep so give it up this was a really edge of your seat talk [Applause]