# The tension between MEV and Censorship Resistance Gadgets by Julian Ma | Devcon SEA

- Speakers: [Julian Ma](https://streameth.org/speakers/julian-ma)
- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-09
- Duration: 24:26
- Topics: Science & Technology
- Watch: https://streameth.org/watch/yt-4OJ1eCtEAVs
- YouTube: https://www.youtube.com/watch?v=4OJ1eCtEAVs

## Description

Although fairly unrelated at first glance, MEV is currently *the* bottleneck for a censorship-resistant Ethereum. This talk will first explore why MEV and censorship resistance are fundamentally counterforces. Then, we will dive into how MEV constrains the design space of censorship-resistant gadgets like Inclusion Lists and Concurrent Block Producers. What does the future of censorship resistance look like for Ethereum?

Speaker(s): Julian Ma
Skill level: Expert
Track: Cryptoeconomics
Keywords: Ethereum Roadmap, Censorship Resistance, Design, MEV, protocol

Follow us: https://twitter.com/efdevcon, https://twitter.com/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

today I'll be presenting the tension between meev and sensitive resistance so as was mentioned it's slightly speculative more speculative than I'm used to this is an idea that we've been trying to formalize a little uh but it's turned out to be quite difficult so let me take you through an introduction and see uh what your thoughts are at the end so for this um session I'd like to frame meev as an aligning values problem m is the maximum value that some extractor can extract from building the block uh and this is some private benefits for this uh actor and the ethereum protol has some other um benefit function which we call the Social benefits and in principle The Ether protocol aims to maximize this social benefits but it's very unaware of anything that happens outside of it so it doesn't know the external state of the world and it fully relies upon this actor the extractor is an agent uh of the protocol sensorship resistance is one of the core values of the social benefit that that ethereum has you can see it has either an um a means to an end so maybe you want to have cens resistance to obtain some other properties uh for example being able to have applications that rely on this sensorship resistance within real time or you could see it as the end goal so have sensorship resistance for the sake of sensorship resistance whatever way you see it the ecosystem needs to align the private benefits which is the m that the extractor can extract with the social benefits which is what we as an ethereum ecosystem want the eer tool to do so here are some observations on sensor ship uh without any normative statements I'd say um so there are three sorts of sensorship that we see uh happening possibly is economic censorship so maybe some attractor wants to censor a transaction because it can get more value uh by by doing so uh an example is multi M that we've seen earlier today uh or the leading example that I wanted to use here is if someone has some loan for example on a and it's um it's it might get liquidated soon they want to send a transaction in order to heal their loan uh but the extractor sensors this transaction because it wants the loan to go bad in order so that it can extract some M from it then there's accidental censorship and this may seem very weird how is a transaction ever accidentally censored but it turns out that this is actually something that we observe uh right now so there are many many messages floating around in a mempool and sometimes Builders just simply Miss transactions for whatever reason that is uh and if we take it to the limit uh builders in principle want to keep their block as light weight as possible so any transaction takes up bandwidth and especially some transactions that are very um very heavy for example blobes take up but lots of bandwidth if you take it more bandwidth it means that your your block takes more time to send to the other uh to the other nodes meaning that you have to send it earlier meaning that you can't delay your block submission as well as you could if you were to play optimal timing games so potentially a builder is is sensoring transactions because it thinks that it may get more value if it doesn't include this transaction but but includes transaction in the future and this is timing games taking it to the limit uh a builder may actually miss its slot uh which means that no transactions in the slots end up on chain and this is obviously censorship and then there's regulatory censorship which is what most people are probably familiar with is there's some government that says these sorts of transactions cannot be included by this actor and where the actor is the extractor who is an agent of the Adan protocol but apparently also has other constraints uh enforced opponents so um given that we observe these sorts of censorship or at least that we know that these theoretically exist the conclusion should be that the values are currently not aligned aligning private and social uh values is something that economists have do been doing for ages uh so there's a lot that we know about this but within ethereum we are relatively constrained in what we can do for example giving um rewards for it is difficult because it means that we have to issue tokens and if you issue tokens it means that possibly there is some delusion uh that could benefit from this so the way that we've been doing it is analogous to regulation kind of uh and this is our value aligning design philosophy we do so by creating rules that constrain how the AER can act within a a certain slot so for the for the framing of this talk we'll use the state transition function as how NV is attracted so GMA is a state transition function it's publicly known the extractor can alter it um and what it says is which transaction sorry which state transitions are valid and which are not so for example you can't put an invalid transaction in a state transition function and obtain a valid State transition s here is the state of the previous block which is also publicly known and T is an ordered list of transactions that the extractor inserts into the state transition function to obtain some S Prime which is the new state the extractor in principle has full control over this T and this is the key part where we'll try to align values by getting more information about T and then making an opinionated choice on what T should be so if we map uh the states that that you could enter into uh which is very high dimensional it contains all of the account and all of the balances into a two-dimensional plane with just private benefits and social benefits you may see that SAR which would be the optimal solution that some extractor uh employs uh should rank very high on private benefits this is clear because um this is the objective function of the extractor there's no objective to maximize social benefits in principle but perhaps there is some social benefit here is relatively low but it could be higher uh the the values don't necessarily have to be underlined the key problem here though is that ethereum doesn't know what the social benefit is and what Which social benefits are possible this is because ethereum has no knowledge about the external states of the world except for the T that was inputed by this extractor and since this extractor doesn't have the same values um it can't really know what the social benefits are so on a high level the idea of the current ways to to increase C resistance is by first of all making this more legible so you could think of for example having multiple inputs into t uh and not necessarily acting up on it uh just making it more legible in the first place so the red part here is some State transitions that are very undesirable from the social benefit uh point of view the orange part is maybe more desirable the green part is good and the dark green part is with ethereum views as the best this slide is supposed to show that uh making things legible doesn't always mean that it's perfect you can see that the dark green parts for example has the same social benefit as some parts above and under it uh yet ethereum the protocol might think that these are better uh purely because it's constrained in the knowledge that it has about the external world one way that we then want to try to align these values is by imposing some constraints so you could think as ethereum saying okay we've seen now some of these um these possible states of the world uh and we for sure do not want you to go into this red and this Orange area and maybe we we're not so careful and we cut off some of the green area as well it's very hard to make constraints that are uh binding at the exact points that we want uh and achieve the right goals and you can see as well that's in this in this very stylized example I must say there's a straight line it's difficult to make uh constraints that are more bounded around for example circles or um that have more nuances uh because if theorum has to remain very neutral so um it it cannot it can only cut off um parts of the p mble states that are obviously bad and cutting us parts of the state that are potentially good in some future would be uh bad for neutrality so now I'll go through some case studies the first one is inclusion lists we have an Erp out for fossil which is Erp 7805 which is our inclusion list design the high uh the high level design philosophy behind inclusion list is that we allow uh the most decentralized sets of participants that has some input into centralized block construction uh and the idea is that the include shouldn't be able to attract any any me so uh we do this because it kind of aligns the private benefits and the social benefits of the inclusionist Creator and of the interian protocol if the inclusionist Creator were able to exract me then it would probably do so and we observe that M leads to some centralization uh and makes it difficult to ensure that we don't have these sorts of economic accidental or regulatory censorship so the goal of inclusion list is to increase the chain neutrality and we do this by having some list of transaction that constrains how the execution payload is created and this gets us at the notion of unability which is one of the main points of the talk unability is um is something that we're trying to explore more uh and it informal definition would be that the inclusion list creates more value for the inclusion list Creator if used as intended it's very related to incen of compatibility but incen of compatibility assumes that you know exactly what point you want to go through and ether protol again has very limited knowledge of the world and it wants to be very neutral so it may it may prefer to be neutral over getting perfect in sense of compatibility it just doesn't want some very obviously dominated things to happen for example using the inclusion list for me extraction and maybe less obviously so using it for pre- confirmations which is that the inclusion list Creator tells someone okay if you're in my inclusion list you're guaranteed to be in the block uh and you should pay me some fee for this we don't want this to happen because we believe that if these sorts of markets pop up then we might go into a similar setting as the MEF boo light markets that we see for blood production uh which would lead to centralization and defeat the goals of censorship resistance so the idea is that inclusionist must be minimally invasive such that the intended constraints are achieved uh otherwise the private benefits of inclusion list May uh differ from the social benefits and if the private benefits of different inclusionist creators differ a lot uh then it will lead to centralization with the Meb like market and a nice example here in my mind is unconditional versus conditional inclusionist unconditional inclusionist states that if uh all transactions from the inclusion list must be included in the block regardless of whether the block is full and conditional inclusion list states that all transactions must be included unless the block is full you may intuitively think that unconditional inclusion list gives you better inclusion guarantees because any trans transaction in the inclusion list must be included within the blook but actually unability gets at an earlier notion of what goes into the inclusion list so if you make inclusionist uh unconditional meaning that they have better inclusion guarantees and for example uh to take the most exch example you could say that this inclusion list must be included at the top of the next block because these transactions were seen earlier perhaps this is some notion of fairness whatever way um you could make this argument that inclusionist transaction should be included at the top of the block and this would mean that creating the inclusionist now becomes very valuable and now there will be a market for outsourcing this uh inclusionist creation which perhaps going to exactly the same person as the one that constructed the blood and so we explicitly want to prevent this uh by making the inclusionist conditional so I I would say that the constraint is maybe more relaxed within conditional but the way that the constraint is created uh is is uh is more likely to gain what we intended as a protocol to achieve if that makes sense and then the second case study would be multiple coner block producers which is a whole topic these days uh the basic idea is that there are multiple block producers producing subblocks simultaneously instead of inclusion list where the inclusionist has created sometime before and I would actually argue that this sometime before is a is a feature and not a bud because precisely uh the arguments that I'll show here is that uh multiple tutor blood producers relies upon some sophisticated parties whereas inclusionist does not Foster the same environment so the goal of multiple concurrent block producers would be to prevent economic censorship the idea is that if we prevent uh transactions that are sensored for some adverse selection reason so transactions uh that need to be very timely uh where there's for example like high frequency trading types of ideas then we can achieve a new set of applications that we haven't been able to realize today an example of M mulp Block producers is mackenstein which is the proposal from barnab and Mike which means that one person creates a top of block and the other person creates the rest of block and another example is braid which is proposed by matnik enco which is a deterministic merger of K chains where each payload is merged deterministically According to some pred ordering rule how this scores on the unability table is is very speculative I say CU we don't know that much about MP blood producers yet but to me it sounds clear that mcbp since it's specifically there for the gain censal resistance for transactions that are very meev sensitive so these are the high frequency trading transactions that may suffer adverse selection if they were put into the inclusion list where it takes a little bit of time for them to get included it would allow any blood producer to attract equally well this is basically one of the designed goals of multiple block producers this means that these partial blocks are a vehicle for me and you can't expect uh a large uh unsophisticated and geographically decentralized set of participants to have competitive private valuations for these property rights of making these partial blocks that carry me similar to how we see now in Mev boost that there are only two Builders who are very good at this there are returns to skill of being um a blood producer in mcbp which means that my marginal benefits of gaining an extra seat in these K consec in these K parallel chains increases with the amount of seats that I already have and there returns to sophistication so it's not easy to build these Bloods even when blood building is constrained it doesn't mean that blood building is simple they definitely still returns to sophistication and there are barriers to entry which we now currently know mainly in the form of private order flow so that's why uh most po block producers in my mind depends on a test of proposer separation and multiple blood producers is very crowd so you can't expect uh decentralized sets of participants who are unsophisticated and willing to uh willing en able I guess to contribute to Central resistance to build partial blocks so we need to ensure that its creators are not also the testers because that would then centralize the tester set if you put some centralizing force on a decentralized set of participants um then the decentralized set of participants will become centralized and it's not that magically the centralized uh property becomes uh get some decentralization properties so that's why a tested proposer unlocked some new block construction pipelines that are currently not possible you could for example allocate the attesting rights to a set of ATT testers uh and allocate building rights to a set of Builders separately so what are some of the consequences of this unability notion well this is I think uh a very fun part to explore and one thing that I've been thinking about a bit is applications consuming consensus information so now assume that we have this uncodable inclusion list meaning that it's very unlikely that it will contain me transaction since it's specifically designed to not be a vehicle over meev it's very unlikely to include Arbitrage transactions therefore so an application who may see this may treat transactions that came via the inclusion list differently from transactions that came in via the main block it may do so because it's it's more confident that transactions from the inclusion list are uninformed and won't uh take their liquidity in general if if you're designing a trading mechan it's important to distinguish between those who are very well informed arbitrageur and those who are not because trading between two parties is is in general zero some especially if it's Arbitrage so if an arbitrager is making money it's at the cost of some other person in the static World Vision so what what you could possibly do is you could use an asymmetric speed bump which is something that's been developed within traditional Finance uh and what it does is it speed bumps certain transactions and it doesn't speed bump others um so the inclusionist has a natural speed bump and again I think this is a feature not bud so what you may say is the inclusionist transactions they are able to take liquidity whereas the transactions From the Block they're able to provide liquidity taking liquidity is the Arbitrage path where um providing liquidity is is not the Arbitrage path unless you look at for example just in time liquidity uh but you could set up the trading rules so that you uh aim specifically for this meaning that liquidity providers would face less um adverse selection meaning that there would be more liquidity low lower trading cost for users seemingly though it seems to be a bit of a paradox it's um if the exchange believes that the inclusion list is uncodable then it's suddenly very valuable to make the inclusion list because now your transactions are treated differently uh so then maybe inclusion list becomes Crow again but then if the inclusionist is Crow The Exchange thinks okay well this is not so valuable anymore I won't act upon it so it seems to be kind of like the the SP man name you know where you're pointing towards each other and expecting the other person um to do something or to remain static I would say though that this is not a paradox uh because the application plays a sequential game and also simultaneous game the application must commit without regret uh to its strategy of um of handling transactions you can't imagine an exchange saying okay if you send me your transaction I have no clue what I'll do with it maybe I'll do this maybe I'll do that so you need some commitments of how the exchange rules are set up and so the The Exchange will only commit to um using such an asymmetric speed bump if it believes that the inclusionist would still be uncodable after its commitment so it must commit Without Regrets so they shouldn't be a paradox even when applications specifically use uncodable inclusion lists we can still have uncodable inclusion lists so some of the um statements that I'd like to leave off with is that if cenal resistance gadgets are incredible then its creators can be decentralized so if there's no other um use case that's better than uh using um the uh censal resistance Gadget specifically what what it's designed then you may ask some of the decentralized participants to create this because it won't centralize the set further if the censor resistance Gadget is cable then its creators will be centralized this is not a centralization is not a feature of Market mechanism although Market mechanisms can change it a little it's mostly a feature of the intrinsic property rights it doesn't matter how you allocate for example building rights uh especially within the ether protocol because there can be secondary markets um it's the fact that building rights are inherently sophisticated and there are inherently barriers to entry so it's not about proposer Builder separation it's about the building rights and finally uncodable sensorship resistance gadgets seem stable uh so potentially there's a whole new set of applications that we can unlock if applications can consume consensus layer information so that was it uh I hope you enjoyed and it's part some conversation uh and I'd be happy to take any questions [Applause] so does inclusionist with an inclusionist committee members making economic sensorship end times more expensive uh this is a property that's not currently in fossil fossil relies on boosting the signal of solo stakers fossils are uh Erp so we made this decision because um putting this uh property that you get an inclusionist committee makes it n times more expensive uh um as protocol complexity we don't think it's warranted at this point because we see a revealed preference of people willing and able to make uh to even take an economic penalty to provide sensorship resistance getting this property though is an easy extension to Fossil um so if it's necessary we could implement it easily um yeah just scan the QR code for anyone who wants to ask any questions and it'll show up uh yeah we have a second question uh which I'm going to read out for the audience joining online how do you achieve unability of ilil is that a property enforced by the spec or achieved through the selection of ilel creators how to select who creates the I yeah so uh the design philosophy behind inclusion list is that you select the most decentralized sets of participants to have input into centralized block construction so unability is not achieved by the selection um because um this is again it's it's achieved not by the market mechanism but it's achieved by the inherent property rights of creating this inclusion list and so what we do is we make the minimally invasive uh way that inclusion list could be structured in order to still attain the Cent resistance properties that we're looking at so specifically in our Erp uh there are three seconds between that the inclusionist last can be committed to and um the block produced so it's difficult to include any transactions like Arbitrage uh because these would be relevant within the the 3 seconds a May face adverse selection if you were to do so secondly there are multiple inclusionist proposers so there's not one inclusionist proposer who has unilateral power over inclusion or or exclusion which is the general definition of me there's no private order flow possible because inclusionists are broadcasted publicly uh and they are only enforced if they are broadcasted publicly um so you can't get any private transactions into the block and most importantly inclusionists don't have any ordering rights so an inclusion this is just a set of transactions inclusion sets I guess uh and it doesn't say anything about the ordering in the block meaning that uh there there's there's no me to be extracted it's the minimally invasive inclusion is possible um the next question is do you think that if we don't uh incentive ILS with some part of the fees it might lead to a scenario where everyone creates empty ILS so um I don't think this is likely uh why I don't think this is likely is uh in for we select 16 validators so if there's we we run some numbers and conservative estimate of solo stakers is 6% uh which means that in 63% of SLS there's at least one solo Staker we currently see that solo stakers and others are are willing to uh take some economic penalty to contribute to censorship resistance we see people locally building blocks and we see people setting a Min bid within meth boost meaning that if the MEF Bo's revenue is lower than some threshold I'll just build my block myself so you see here an economic penalty inclusionists don't impose any economic penalty but they also don't gain you anything given that people are willing to take an economic penalty and inclusionist basically give you zero we expect at least some people willing to participate if only one of the 16 is willing to participate we already get the sensal resistance properties that we're looking at um how can IL be unconditional in the presence of the block gas limit yeah so this is I think just a a semantics question unconditional um could I basically means that the transactions have to be included regardless of uh whether the block is for or not you could make some separated uh gas for it which was proposed in the ER 7547 which is M inclusionist CP where there's just a dedicated amount of gas for the inclusion list and this usually comes with u a somewhere in Block property uh so potentially you could put it at the bottom of the block uh you could also say which is more complicated for the Builder but the transaction just have to be in the block I don't care where they must be in there uh this would force the Builder to reconstruct the block more often and it would be slightly more complicated in principle ILS with unconditional and block ass limits are not mutually exclusive because you up the block a limit to accompany the unconditional I um if I selection does not take fance into account could fil make the max EB increase less effective so actually this makes it more effective if you don't take the balance into your account you you select more people who have lower balance you probably want to select more people who have lower balance for censorship resistance because they are more likely to be unsophisticated maybe geographically diverse you you probably don't want to select coinbase even though they might contribute to the economic uh and The Accidental censorship uh so in my mind uh not taking balance into account makes fos a lot more effective actually wow that was really good talk and really detailed um give