Transaction Fee Mechanism Design with Active Block Producers with Pranav Garimidi | a16z crypto

Transcript

uh all right welcome everyone to today's a16z crypto research seminar uh very happy to introduce our very own pranav garamidi um who's full-time here at a16c crypto he's going to talk about transactionary mechanisms EIP 1559 and other designs and in particular uh how Mev uh changes our understanding of them so yeah thanks Tim yeah so today we'll be presenting some joint work that um are coming with Tim and Miriam I'm also with the research lab and yeah so I'm talking about transaction mechanisms um short we call them tfms with active block producers and so to start off with is an outline kind of start to talk with some informal motivation and definitions just kind of defining what are tfms what do you want from them kind of this biggest section

we make is between passive block producers and active block producers so passive is what you probably think of right now like just or at least with the literature has thought of so far over our block producers only care about transaction fees and block rewards and active is this case that we're living today or I mean they exists and block producers and Searchers and miners kind of all care about some application Level value from the transactions and so from there I'll move on to some more of the formal model and the results kind of exactly how you define your TFM and kind of the main result we have this impossibility result so kind of going through that um and then talking about some kind of approximate Notions of in some compatibility that you can get to kind of get around in possibility and then we'll kind of finish off with some

future directions um so here what are some directions to get around these possibilities and in particular talking about encrypted mempools order flow auctions and Mev burn and kind of how those relate to our model so to start off with um why do you need tfms so right now we have block space as a finite resource and so we'll have some block producer Builder or some party that's trying to put together a block they see this mempool of transactions and then in some way deciding which transactions to get in and still throwing a mechanism and so basically they're going to charge payments to different users and based off those payments kind of decide what are the most really transactions or transaction they want to get in um so here kind of you can see in the bottom we have five different

transactions with the corresponding um dollar amounts those users might value them so like one kind of first thing you might think of is this kind of first price thing where basically every transaction maybe submits their bid that's how much they value the transaction the block producer just picks the highest ones and charges them their bid so here that would be this kind of orange um red and purple transactions or the highest ones and so what are the ideal properties of a TFM and so the first one is coming we wanted and somehow pick the most optimal set of transactions like you know one super trivial thing is like you just look at the mempool pick some random things literally fill up your block and that wouldn't be great um for kind of clear reasons um the second one is that we really want the mechanism to be incentive compatible

for the block producer for the value in whatever we're setting um and so we call this and our paper B pick um and prior Works has been called mic mmic for myopic minor and so they're compatible and this is really kind of an essential property of the TFM if the person the person running your TFM is going to be the block producer and so if they have some incentive to DV8 and kind of all the guarantees you might want um would go away and that wouldn't be great and so kind of a classic mechanism that people think about economics the second price mechanism that kind of really achieved this first goal of like picking up some transactions turns out to not be something Cloud over the block producer right um and the way I see that is basically the block preser can just insert a new transaction kind of um

right below the first highest price and increase our revenue and that's kind of one of the main reasons we don't see this used in practice in blockchains and kind of the the last property we really want is this notion of users having dominant strategies or kind of desk for short um and this basically says that users should have basically some kind of like good ux they should just want to report their true values and the mechanism should be easier for them to use and so here's what kind of the first price auction kind of fails um you know I briefly described before a kind of in the first price auction users want to exactly reason about what's like the smallest bit they can get to still be as like just a bit above the next highest person um to maintain inclusion and so we're going to be trying to aim

for some property of these three things um in our tfms and so one thing I start off with which is kind of what um the current EIP 1559 is built off is this idea of a tipless mechanism and basically the tipless mechanism there's some base three of the protocol sets and then it's a fairly simple rule if my transact if I have higher value for my transaction the base fee I'll just bid the base fee and I'll be included um so here for example if the base three was six we can see that I kind of like these red blue and green transactions have value below six so they don't want to be anything they just fit zero but this yellow and purple transaction um or above the basically it's actually willing to just bid the space fee and get included and so familiar with how 1559 is

designed today you might think this should be some kind of tip on top um and so that's kind of to have some really tight breaking you have to basically set appropriately basically these two mechanisms are equal um but this one just a bit simpler to describe so we're kind of be using tipless mechanism as kind of the focal point of um thinking about what our kind of approximate these significant mechanisms in practice today um and so now to kind of Define a preliminary version of exactly um I'm talking about here so basically there's a space view that's set We're not gonna be worried about how it's set on to the rest of this talk basically every user gets to take it or leave it price effectively if they value the transaction above the second or leave it price then they just um bid that amount

and then kind of the mechanism requires that every included transaction has to burn this fee effectively um right so in our this is the classic like burning rule you might have heard of in 1559 and then because you had this bit of an extra tip on top to break ties and this version the mechanism will say that you have to just break down arbitrarily and so there's some maybe lexiographic ordering you can imagine you have your transactions of course this type of stuff is gamable um but for the purposes of describing decent compatibility Notions we'll kind of ignore that for now and so kind of like um looking exactly at the Notions you want um so for D6 this is kind of easy to see that it's desicc your strategy space is very simple I either pay the base fee or I don't pay the base fee that's all I

can do as a user here and so if my value is higher I pay it if it's not I don't and I'll maximize my welfare here um for beat pick because we're burning the entire base fee in this case um we also get to the block producer is basically indifferent between what they put inside of this block kind of whatever they should like whatever transaction they put in they'll get paid the base they have to burn that immediately afterwards um and so here it's actually very important that the block producer only cares about transaction fees in the block reward and we'll see that basically this property of B pick for this mechanism will kind of go away once you move to a rural to the block Reserve actually has a value for transactions inherently kind of separate from the transaction fees and so one thing that's

um not great about this is the welfare so you actually can't make any guarantees that we've selected the optimal set of transactions and this is um in large part because of this arbitrary tiebreaking rule although if you set the base to be too low we get tons of transactions so I'll clear it and we have to do this kind of extra graphic ordering to just like pick the top ones um you can imagine very high value transaction just happened to be at the bottom of ordering and they're great included and then we're not doing great on welfare yeah all right maybe just to clarify the last point I mean so if the base fee is high enough that everybody fits there's no problem yes yeah yeah so it's when the base fee is too low and then some people get in some people get out and

how do you decide this mechanism decides arbitrarily so you don't necessarily have any guarantees you get the best ones yep that's the difference with 1559 right because their people can compete through the tips and so if the tips reflect the values you're actually going to be picking kind of the high value transactions yep okay yeah and so kind of getting to the key part of our work um is that this kind of Misses part of the picture so any of this key thing the block producer only cares about transaction fees isn't true today right on a movie is a big thing and a lot of the value in blocks that it can come from kind of these on eBay transactions um you can see how high kind of like block Builders are bidding in PBS and we'll call you get into this later on The Talk lots of evidence today

basically that the block producer really does care about what exactly these transactions are more so than just how much how many fees they're paying and so basically we're going to kind of try to abstract away defining exact media is um certainly your classical examples of like front running back running liquidations all this type of stuff um and so we're talking about but we can even think about any of these being like other protocol stuff so for example if I make a bet with a friend about the price of something and I'm a block producer maybe I even send tips include certain transactions to make that that come true um off chain right and so we'll basically just assume there is some valuation function that the block producer has over just orderings of transactions or sets of transactions and that'll kind of be sufficient for our

purposes you don't kind of you won't try to get bogged down on like exactly how the study would get extracted or what's like kind of the functional form of that um and so in particular this really messes the notion of bpic and the block producer does have these kind of values for transactions uh it distorts the properties um or distorts their incentives to follow the mechanism as is kind of laid out and so can I ask conceptual question yeah um kennel maybe I shouldn't think of the Mev as a different way of paying the miner like the fears are very direct way of being the miner if I do a transaction

that allows the miner to extract more value or I mean at the end of the day basically tipping the miner uh yeah I think that's the fine way to interpret it um actually that comes up a decent bit um and some of our future stuff but like um yeah I mean you can definitely imagine that uh right so that's also what makes the incentives kind of hard and we'll get into that um of the if I'm a user and I know exactly how much Mev my transaction has I think it's perfectly fine to think of it as a as a fee to the minor um but if I don't know how much maybe my transaction has and it's kind of unclear how to think about it from a user's point of view of maybe their inadvertently taking the minor or maybe they're not and that seems kind of

undesirable um that's actually where a lot of the hardness comes from and if I can add to that I mean so this work is kind of taking no stance on whether Mev is good or bad nor is it taking any stance on who should get it it's really just investigating how the incentive properties break down when you have Mev so yeah exactly um and so kind of like defining it on me when I say block producer it's a pretty vague term um and so today this is like kind of a picture people at Frontier made um and it's like a kind of a whole mess there's all these parties like kind of interacting and like kind of getting transactionary user all the way to be included finally in a block and so the purposes of our talk today will basically just make two

distinctions there is the user themselves and there is the block producer which is everybody else kind of combined to a single party you can assume there's maybe payments happening between them to get to this final evaluation um but we will consider just two types of parties users and the block producer um and so this isn't basically this isn't like super relevant it's like actually understanding the results but if you're kind of confused about what exactly I knew that I'm saying block producers think of this entire red circle it's just one party basically okay uh and so I'm getting into an example of kind of having this active block producer so we saw before when the block Reser only care about transaction fees it seemed like they could probably accept some combination of the red yellow and purple transactions but now imagine the block producer kind of has

this evaluation in their head right so they can just kind of see how much Mev these transactions would generate by doing some simulations or something um and you'll see this kind of producer has value 20 for the right thing 30 for the blue one zero for the yellow one 15 for the green one and two for the purple one and so um I'll get some examples of what they see if Samsung look like uh but you can kind of imagine that if the block producer I really like it's kind of maximize their own value and the theas aren't super high because they're kind of the magnitude of their values are higher than value to the individual users values then I actually just picked this like red blue and green block uh or transactions instead of the the red yellow and purple ones and so I'll

attempt to go back to the tipless mechanism um but now let's assume that the block picture does have their own valuation and so now deciding what gets into the final block is more complicated than just saying what clears the base speed uh finally we're assuming the block producer is basically just going to maximize their own value and so now even transactions have to be a bit strategic now they're going to bid so we saw before that the transactions um from the Easter's point of view have like a very simple uh choice if their value is below the base fee they don't bid if the value is above the base three they just bid the base fee and like that maximize their value but here we see actually these bids are a bit off from the actual values users have because they can kind of just play some games internally of

thinking will the block producer have some value maybe willing to be subsidized part of the difference between my bid and the actual base view so for example the spread transaction like you know Underwood by a dollar because maybe they have some including that the block producer has some value for the transaction and is willing to subsidize kind of a difference of two between the base fee and they have value three so actually they were right um this blue transaction you know they've had zero uh and they still get included and you see here where before kind of having this yellow transaction being included was optimal here the yellow guy might have um trying to undergrad by a bit and hope the lockers are at some value and to be as they've been under the base fee I was 16 bit five instead and the Blockbuster

ends up having zero value they're just not going to include the yellow transaction and instead uh the purple transaction who is at least paying the base fee will get included walk resources don't really care it'll like burn that anyways um like kind of a lot more tricky with reasoning about how much you should bid trying to reinforce this point if you kind of just shift around the block produced evaluation by a bit and we see the users have the exact same values and the exact same bids that the allocation still changes and so you know in this case now you know the right transaction there's still high value from the log features basically included um but here the yellow in this case the yellow transaction was correct the blockers are at high value or some value for them and so even though they under bid the base fee by one you know the

block research when we subsidize that and they're fine and so we can kind of just see to kind of like emphasize the point um that getting D6 is much harder in the setting because they usually have to reason about the block producer and their own values transactions which can make things more complicated and to kind of have to redefine this mechanism in this world um to kind of that like includes this notion of they're allowed to under bid and still get included uh we'll say that basically every included transaction pays the minimum of their bid and the base fee right so they made it under the base fee they can still get included if the block producer is going to subsidize them which was not the case in the previous version and now basically just um the the block features required to just still burn that basically for the

transaction to include and we're still going to do some basically arbitrary tie breaking between transactions and block Builder and the Vlog producer is indifferent between and so um the form we see why it's not desec right so you kind of saw this um in the picture but basically you just have to reason about um you know do I want to under a bit the base fee because the block producer has a very high value uh and so there's your dominant strategy there and if you try to fix this by saying okay block producers you're only allowed to include transactions that are above the Obesity then that would fix a decent problem because you'd be back in this world or uses either bidding zero or just the base V but now we kind of break B pick um because the block creatures aren't

kind of incentivized to exactly follow this mechanism um and you can imagine that maybe you get something like uh so we're not touching about this formally but like some like option agreements or something um where users still have to kind of play these games and they might like form side contracts for the Builder to kind of get around having the space fee um be set and so this kind of motivates the question like also kind of this classic thing um the Civil mechanism that was deep thick and D sick in the role where block producers are passive and have zero value for transactions apart from transaction fees um in this new world where we have active block producers can be still designed on tfms I have some of these good properties I don't know maybe it's worth mentioning that the last slide applies to verbatim

to eip-5059 yeah exactly uh yeah so um yeah so the small bit of tipping that you had on top of 1559 doesn't let you get around any of these problems um you still have the exact same thing and people might want to under bid the base fee and then I'm kind of Reason about all the same types of problems we saw just with this more simple tipless mechanism and so kind of now getting into like the formal model of kind of thinking about our agents and um so basically we'll say that we have these users the each option transaction T they have this private valuation DT for inclusion and so this is like a very simple um part of our model and then the real world you might imagine that like users might think about how to craft their transactions um to kind of have less Med and like

kind of play some tricks around this um for here we'll just assume the transactions are just given and users just have a very simple value for inclusion so they won't care if they're the front of the block or the back of the block they won't care about if they were sandwiched or not um it's like it's a very simple if their transaction was included they have this value if it's not they have zero value and so then we'll basically just Define a block b as basically just finite order lists of these transactions and some other transactions so maybe the block producer might put in they're coming from other sources or whatever have you and so we'll define a blog producer BP as basically saying they get the final choice of choosing a block which means choosing what transactions get in the final block along with their ordering

along with inserting their own transactions all the time classic kind of Med stuff and so we'll basically capture this by saying they have this valuation function vbp and there's some feasible set of blocks you can imagine that being some block size for example like um there's only K transactions that can fit in the block um but it's more of a general thing um the exact way the feasible block structure looks doesn't particularly matter the main important thing is that what blocks are feasible it's not a function of bids the only function of the actual transactions themselves uh yeah and so basically if you can think of this valuation function the DVP as the value of the block we assure the Mev valued that the block producer can take

from certain sets of transactions and so finally kind of the objective we're going for is to maximize overall welfare um so the welfare of a Block B is this block resource value for that Block B plus the sum of basically the inclusion values of users you got included in that block it might be some debate or whether or not you want to include the block user's value here but for anything we're doing it doesn't matter the results actually hold since there are mainly possibility results the results actually go through equally well if you just assume the welfare is just for users instead so you can kind of think it's interchangeably depending on your context and so to give some flavor of what these block booster valuation functions vbp might look like kind of the simplest case is this passive one which is what hasn't started in the past so this is

where just the valuation function From the Block producer is just zero for any block where they don't have any of the value traditional settings right so far uh maybe the next most natural is this additive case and so you can assume this block producer has this value um new t for every transaction T and there's some funny block is just the sum of the mutes that um our transactions get into the block and so here you can kind of like if you have independent me the opportunities you know different amm trades on different pools the block position get value from um and so since it's not really affecting each other the block producer can effectively just add their value across all of those opportunities and get value from that and the last thing that you might think of um that's still fairly simple is a

single-minded case um so here we can imagine or a set of all possible blocks there's some partition of the Box in this s and blocks not an s and you can imagine so here uses some constant um if there's some like liquidation opportunity and so you maybe need some combination of like two or three transactions to make this liquidation go through and that's all I care about is a block producer I don't want to do anything else and kind of like any side of the blocks the capture those two or three transactions I had this constant value for any blocks that don't contain all these transactions I have zero value for I have no other remedy in that block um and so these are kind of just some things to keep in mind um for the purposes of this talk basically everything will go through we

just additive case to kind of just um in your your mind whenever I describe the sorry a blog post evaluation um just think of it as being additive and so to define the TFM there's two main parts that actually get defined that's kind of part of the protocol and these are the payment and the burning rules and so the payment rule is just as function P that specifies um is a non-negative payment on this PT of B and this bold B is kind of the um sort of bids in the block or bids by all the users for their transactions and so we'll kind of say you know you're going to charge this piece of T um if your transaction T is included in the block and then so the payment rule is actually defined for each individual separate

transaction and then the burning rule is kind of a more aggregate thing basically it says it's a function Q where you'll have this non-negative burn um Q of B that's so the function of the block as a function of all the bids and so this is what the block feature has to pay so if the block producer gets this Vector of bids and they pick this Block B they'll have to pay this Burning rule except by the protocol they can't modify this and so again like kind of stressing the block producer cannot affect the payment or the burning rules all the payment rules are kind of divine in the protocol is coming to the block producer and the burning rules here with Walkers are asked to pay to the protocol um you can imagine so the token holders if it's the Visionary sense um yeah so basically these two are kind

of what quarterly behind the protocol and then the third part of it tfem is allocation rule and this is basically just a function to specifies you know kind of as a function of the bids by the users and the block producers evaluation it tells you what block will actually get chosen and so this one isn't actually firmly coded in the protocol it's up to the block producer to be running the allocation rule as a function of the payment and the burning rules and so well basically you have to like Define tfms where it's in the block producer's interest to follow the allocation rule um kind of asset so the allocation rule cannot should be independent of the distribution of user valuations so I mean you're allowed to take in this

Vector of bids so in that case it can be a function of the distribution of user valuations much about understood the question correctly okay uh so this is their realized bits yeah yeah so yeah so yeah these are the realized bids so if it was um a D6 mechanism this will be their actual values so that would be fine um we'll see that getting the same mechanism is going to be hard in this case um but like insofar as users report um business function of their values then the allocation can depend on the user's values themselves yeah so everything is prior free in the model the whole the whole model is prior free the whole paper is prior free maybe one of the comments because I

think I feel like there's a really subtle point on this slide actually if people are thinking about how eip-559 is usually described but normally you think about like money coming in from the users some of it gets sort of goes to the Black producer some of it gets burned and goes to the holders that's not exactly what this formulas and translates to so here you think about the Black producer being like almost like a bank in the Middle where they take payments from the users and then they're responsible for doing a bunch of burning themselves and in particular this opens the possibility that the my the Black producer may burn more than the payments they got from the users which is not what people are used to thinking about and that ties back to your picture where you talked about subsidizing right so that's what gives

the block producer the ability to subsidize base fee Burns to the to the users that just means P does not cover Q that's what the subsidy means yeah yeah so the advice there no subscript on Queue like for transaction like can I not specify different burn amount per transaction no so so that's kind of the point but Trend the burn isn't specified per transaction the burnt specified is the function of the block so kind of the the change you can imagine is users submit their bids with their transactions the block producer picks the final block and so by picking that final block kind of they'll Define um that sort now all the payments I'm burning is decided and so every user get individual payment they have to pay to the block producer but this Burning rule

specifies what the block producer has to pay to the protocol in some sense or just kind of burn or do something and so there's no like so you can imagine that like you might have um in the way you define the burning rule you can imagine some like additive burning rule or something where you do say like you know this queue of um you know Q is equal to the sum of like qts of everything but in general that's not necessary we're kind of just defining a generic burning rule that could ever function of the blocks and the bids that you want yeah and the point is impossibility results so we're giving the mechanism even more power right they they can do burning per transaction if they want or they can do something more complicated but it's not going to help you with the impossibility result so yeah

yeah um and so for defining DC basically we'll say a user's utility is defined as the value they have for inclusion um times this XT so basically x t will equal one if transaction was included and here I'm hiding some arguments about exactly what block is produced and other user's bids and everything basically you can think of each utility is there value for if they're included it's their value for being included minus how much they're charged if they're not included the payment will be zero X will be zero and so basically zero utility for not being included and we'll say the TFM is DC if every user has a bidding strategy that is independent of others bids and the blocker's evaluation and the bit is basically only a function

of their private value which maximizes their utility so the key thing here then they can trick in our this model is that their strategy cannot depend on the Block producer's valuation there'll be some like private thing the block booster has but we've kind of seen so far how you might want that to be the case the users might want to know what the blockbridge evaluation will be to know how to bid correctly um but for a mixing to be desync this can't be the case so an example of a D6 mechanism is kind of the second price auction where users always want to be truthfully like if you assume the block producer the auctioneer is just following the protocol as stated then it is dominant strategy to just bid uh your actual value and so I'm getting into bpic so here we call the block booster

utility or BPS which stands for Block producer Surplus and that will basically just be the block produced value for the block plus the sum of their payments in that block minus total burn so you can kind of think of this as your value for the final thing they Select Plus they're like net cash flow of the payments are what they get taken the burning is what they're required to like spend out by the protocol um and so this kind of an alternative integration of Med so kind of back to what Jacob was getting at earlier you can imagine that these nut fees that are being generated or the block user's value is kind of part of like the Nazis and kind of go into this whole thing and so just different interpretation of what any of the actually means and kind of Define be thick then we'll

see a tfmsb pick if its allocation rule chooses the block that maximizes the block which is BPS it's kind of getting back to the earlier point of how I was saying that kind of the allocation rule is in some sense um defined uh by its payment and burning rule if I set the payment rule the burning Rule and the blockages valuation I can actually just solve kind of the maximization of this first equation and that is what the um allocation rule has to be to be beat pick okay in terms of the main result in our paper is that any DC and bpic TFM must have a payment rule of identically being zero so this probably seems weird and sometimes this is saying that the only DC can be picked tfms are the trivial is

a trivial TFM which almost just ignores the user's valuation some recharges them anything and to get some intuition um sort of formally approve this but do some intuition to start off for basically for the TFM to be D6 users must be charged the lowest price they could to still be included imagine that this wasn't the case then users have some incentive to deviate their bid downwards by a bit they would still be included you know maybe um they'd be charged less and they'd increase their utility so to be sick you use First Property but as you kind of seen in the example of hipless mechanism this is very much a function of the BP's valuation right BP has high valuation that can bid lower and be subsidized in some way if they have no value for my transaction I

really should be bidding as I would normally in order to be included and so basically the TFM can't compute the right payments to charge to users to be included because it doesn't have access to this information about the blockages evaluation is and we'll show this kind of forces the TFM to just charge zero payments all the time effectively which as for the intuitive isn't great um but it's the only thing you really can do if you want um DC compute pick and the somewhat strong setting okay so I'll get into the formal proof a bit and so kind of go by contradiction assume there's some TFM that charges uh non-zero payments and then let's fix an additive block producer evaluation uh VPP but this little D be a vector of bids and T star

would be one of the transactions where t-star is included when the bid Vector is the speed and um the block resources evaluation and let's assume they're charged more than zero and so we know that there must be some combination in the Box evaluation and bids where this happens or else our TFM would always be charging zero um so this is where I just picked one by assumption that exists and so kind of by desync this means that the transaction must be included in the block right if the transaction is paying it better be included otherwise they might as well just spit zero and um not be included and then not paid to as a kind of utility um improving deviation and so now let's define the slightly root thing with all this Vector bids B Prime and so this

will basically be the exact same Vector of bids as this bold B except you imagine that the uh use it for transaction distort drops our bit to zero so this B uh minus t star notation means basically every bid that is not t star is the exact same and just bitter P star is dropping their bit to zero and then we'll also Define this capital P as the sum of the original bids uh BT and Q as the amount the the block preser has to burn when they select B and the bid vectors actually just B prime one thing to know if you see this p is capturing the maximum amount of fees the block producer could have been collecting when uh everybody bid this kind of ball D Vector kind of by the same

position if you are forced to pay more than your bid then you have some deviation to bidding zero instead and then getting at least Zero versus negative utility so better be the case that you're never charged more than your bid and so this capital P is basically the maximum sum of bids that for the maximum amount that the block producer could be charging to the individual users and so now we'll consider a modified BP evaluation uh it's called this would be tilde BP or it'll still be additive except basically we'll say for every transaction that was in this original Block B the tilde's value for this transaction is going to be scaled up by this additive P plus Q factor so it'll be really high and so it's kind of the idea of basically

saying V tilde is the same as V except even higher valuation for the transaction that will be included and we'll also kind of look at every other transaction that wasn't in B and we can just set each holder to zero for those transactions so what is the singular 20 it's just the block containing only two yes yeah so I'm abused notation here a bit so it's kind of this is like the MU T constraint to be tilde it's just yeah um if I had a bundle of say like T1 and T2 then B tilde's value for that block of T1 and T2 would be this V tilde of like set T1 plus v tilde have said T2 but I thought they have valuation not just on the set but on the order uh yeah so that's true in uh the formal

yeah so in the general setting it is that they have value on the order so it turns out the distinction doesn't really matter um they could be you can imagine there is um you imagine this valuation function for example not caring about the order so this is just for we think of sets just blocks our sets here well I mean so this is a he's specialized to an added evaluation right which makes the impossible to result only stronger and for an additive evaluation there's no ordering it's just you sum over the yeah it only so for that special type of evaluation it'll only the set manner well so the proof is going to work even if you only have added evaluations yeah so like he says right second bullet fixing additive BP valuation yeah yeah some particularly if it worked for

um if the uh ordering did matter for the valuation this would still kind of fit in there and it would still break the impossibility would still hold and then a kiss so you made this point earlier that um users kind of don't know the valuation of like that movie that they create because there might be other users in there that create other value um but in like an additive valuation context it's probably okay to say that the users probably know like the muv that's generating just from their transaction below yeah so I guess this is um okay I was trying to get back to this point later on but I guess I'm thinking more users not throwing down maybe more because they're unsophisticated than more because they know what else is happening of the town of like a classic

more like a mechanism that I'm setting up like I showed my private value I mean I don't really want to like think about what does a block producer care about my transaction like even if it is so additive case you can imagine I'm just a simple user I want to make a trade or something I don't I'm not keeping track of like all the different dexes and like finance and everything I'm just trying to make this trade so like in theory yes like um in other cases it makes a lot of sense that like some party can find out exactly how much I mean your transaction has but we kind of want to see are there mechanisms that don't require this like as a user I didn't just know my own private value for wanting to do this trade and that's all you need to know

and I can just spit that amount and be kind of all off I'm not sure like there actually isn't and it's kind of like the intuition is you actually do need in some sense to like learn your media but like have any hope of getting good mechanisms but to your appointment and I sort of feel like some Searchers could maybe have a better business model if they switch to just kind of telling users about the Mev that they computed for their transactions or you can imagine that being a third-party service where someone tells you right yeah so probably you want to talk about the high level plan a little bit like why you're doing these steps right so you're kind of saying like for all you know the BP wants this transaction really really really badly right that's what you're saying yeah yeah it's kind of the

the high level of poster will be saying you know so kind of have a decent mechanism um a user should have dominant strategy regardless of the BP's evaluation so kind of we're getting I'm going to be getting at is saying that okay um because the user doesn't know the BP's evaluation there are some cases where the BPS evaluation is high enough that they should be paying zero really um and for all of them that could be in that world so if they're not being charged zero um they're sometimes they could deviate and make a profit basically and we're kind of ensure that always has to happen and that's not like driving the impossibility result uh and so kind of the core idea and this claim is that under this new Vector of bids B Prime and this

um BP evaluation via tilde that it's kind of intuitive that under um these things that this block D Prime that's made with this new bit Vector a new BP evaluation the better include every transaction in B and in particular this transaction T star so by D6 basically now that means that t-star should also be included in their original bid Vector this bold B when the block research evaluation this is V tilde and they should be paying zero in this case and so basically we've showed something not exactly what we want but also we want if the block a person said which is B Star which should be quite close to B that then the original payment should have been zero which would have been

contradiction and we'll finally we'll show right now is that actually this B Star is the same as B and so that implies that uh this transaction T Stars payment should have been zero initially kind of contradicting the fact that there was this beat pick DC TFM that ever charged um this non-zero payment to a user and to see that B Star equals B we kind of go through a few steps uh so first off since this TFM was b-picked that means that this original Block B was maximizing the BPS under the valuation bbp and the bid Vector the spool B and by construction of this Vitality BP you can kind of think of it um so basically what we did was we increased the value kind of Point wise

across every transaction in B and we select every transaction outside of B to zero so we kind of know that uh the value of this Block B increases by the uh by at least as much as this block uh B Star based on like how we constructed the speed tilde and then the final point that kind of finishes is that since we know that the payment and burning rules are independent of uh VPP kind of going back to how are they defined remember the payment and burning rules are only going to take his input the block that's chosen and the vector of bids and partially not the valuation function of the block producer and so the dependent boarding rules will be the same whether or not the law creatures evaluation is just a VA VP or what

whether it's this be tilde uh the utility BP and so since under Matilda they're blocked their value for B is so higher than all the other blocks and it's the same payments that means they're not cash flows they're the same under Matilda as under just normal d uh then basically this B Star must be equal to B and so I'm leaving out some details and there's some tie breaking stuff whether there's multiple blocks of the same value but that can kind of be handled uh separately and it's not the main intuition is that you still get this exact same Block B that you initially had as you do with this new vital evaluation and so this should kind of imply that the original transaction T star really should have been tank zero and not this non-negative amount to um

uh finish off the proof I'll kind of prove this claim that I just stated that kind of uh this this Block B Prime should contain this transaction T star and furthermore every other transaction than b but really only T star is the one that we care about kind of as the first inequality we'll use for any block uh B Prime that's not a super set of B so there's some transaction in B that's not in B Prime then from how we Define the speed tilde we know kind of the speed tilde of B is going to be bigger than the children B prime plus this amount p and Q uh since we kind of stated that for every transaction in B the B told us value was the original values the original value of the

transaction plus this p and Q and then by D6 kind of this idea earlier this capital P being the maximum amount of payments that a block booster could get under a certain bid Vector we know the payments the blockcreaser gets under um this bit under choosing any Block B Prime under the vector of bits B Prime is going to be less than or equal to the payments they would get for choosing B plus this total capital p and then finally since we Define the burning rule as being non-negative uh basically the amount they burned choosing uh choosing B with this bid Vector B Prime is going to be less than the amount they'd have to burn choosing

B Prime and B Prime uh plus this total Q value and so you can basically do the math and it's a bit uh just algebra and basically you can just kind of combine these three inequalities to get to this final point if there is some Block B Prime that's not a super set of B that the V tilde of this block D would have been bigger than the retailer sorry the the BPS of choosing Block B under evaluation be tilde is going to be bigger than the BPS of choosing this block D Prime under evaluation we told uh and so kind of this show is by bpic this can happen so it must be the case that this Block B Prime chosen under

uh the bid Vector B Prime and the BP valuation B tilde must contain every transaction that's originally included in B it's kind of like the interesting What's Happening Here is that by the way that we kind of spiked the the value that b tilde has for every transaction in B that must be choosing the same transactions effectively to still be maintaining um this will be B pick and we basically just spiked it enough that payments on the burning um don't matter and since the payment's done burning aren't functions of the speed tilde we can do this perfectly fine now that we've shown that things are kind of impossible in this general setting one thing I want to know is having to get around it and one thing that we can do so should have

approximate D6 is kind of getting into my headless Point um earlier if users do know some of their actual value of the popular has for their transaction they can have approximately dominant bidding strategies for certain mechanisms and so in particular we're going to go back to this tipless mechanism so consider the tipless mechanism with the space VR and Define this thing new t as being basically the maximum value the Washington has for any block minus the maximum value over blocks where this transaction is not included and so basically what this is telling you is the block producer's marginal value for this transaction and so in the case where the solution is added this is just a constant right it's

basically just saying um value for the transaction there's no real kind of commentatorial stuff going in the edited case so it's just basically knowing this new T is effective to just knowing the block producer's value for your transaction and so now basically in the formula's idea we were talking about earlier when in the tipless mechanism the amount you want to under bid from the base fee is basically exactly how much value the block user has of your transaction because the amount of value the oxidizes for your transaction is basically the amount the block feature is willing to subsidize your transaction and so this is basically saying that if you have this range on what your immedi value is that bidding outside this range is strictly dominated by bidding inside

this range and so the exact details are super important just the idea that if you have a pretty good grasp from where your MV value is you actually still do have um dominant strategies in certain mechanisms okay so kind of on the downside again um what we kind of showed with the fact that payment rule of zero we still kind of have uh that kind of implies that there is no date significant TFM that has and that can they can guarantee any fractional Optimum welfare and well this seems intuitive it is still a bit tricky to prove uh we still have even though the payment rule is zero there's still the burning rule to kind of incentivize or de-incentivize certain including certain transactions

basically it's like it's not super hard to take a bit of math to show that even though you have the flexibility the burning rule the fact that the payments are zero means that the TFM can't use information um from the bids to decide what to include and so basically if there's a very large difference and what the block booster cares about what the users care about by not allowing the block producer to kind of take this into account um it might end up with very some very sub-optimal blocks in terms of welfare and so we can't really give any welfare guarantees in the setting so kind of going back to our picture um we've shown that in the simple models of a TFM that we're going to get these impossibility results but we've made this big assumption that there is a block booster there's a single Monopoly

party that had total control that goes into a block and didn't really have to anybody they can just hide their valuation and that's fine um in practice there's things we can do uh right so we have encrypted mempools and so we'll kind of talking about how that money is the Watcher's evaluation a bit we have order flow auction so it kind of gets this idea of how how Searchers can have to compete with each other and how demo actually reveal some of the Mev value um to the protocol there's also kind of PBS and Med burn that are more the higher level of saying let's look at the total on the immediate value in these blocks and let's have Builders compete reposers compete and kind of the outcome of those auctions give some information to the TFM they can use um kind of get around some of these impossibility

results I'm just kind of saying this in more words kind of one of the key challenges we've seen is that the TFM doesn't know the Walker's evaluation right and that's kind of the key reason that they couldn't charge prices correctly and that you got these this result of like P has to equal zero for a b picking TFM and you can ask is there any way we can elicit this information to the TFM is there any way that being designing mechanism by adding more parties that can basically give the TFM the info it needs to actually be charging the right prices and to align incentives properly and so one thing that's not quite in distraction mode is the opposite is encrypted mempool so basically says it forces the block producers not actually no the evaluation of individual transactions and then the other thing is Auto Pro

options where you have circles compete and here is we're using the outcome of these Searcher options to get information about transaction level UV and the last thing is Discount PBS MV burn um which I was saying is using the Builder auctions instead to get information about the Block Level media and someone kind of go into um a bit more detail on these two different things so starting off with encrypted mempools basically by not knowing um the contents of a transaction and you're seeing a transaction you can almost think this in our model as changing the block producer's evaluation for transactions from being this deterministic thing they know to being some kind of random distribution so for example if they just saw like hashes the mempool and just have to pick some that's effectively saying they have some like uniform prior almost of the user and different between

these things they're selecting they have no information on them and so it's kind of forced to pick them and you can imagine that like you know this gets tricky in practice of like block pictures have signals from like various information sources they can kind of mess with having the encrypted mempool kind of like perfectly mudding things so maybe it helps a bit the idea here is kind of by using some encryption techniques that we actually just force the Block cruise evaluation to be of a very specific form and then we do have information over what that form looks like and we can maybe use that to design better mechanisms so this is kind of on one end using some cryptography it's a kind of intentionally Force the block which evaluation to look into a certain to look like a certain functional form kind of on the other end

going back to the more elicitation side is order flow auctions and so as you kind of saw that if a user if you're in this like additive setting and the user knows their marginal on the V value then they can start to bid more intelligently and they can design mechanisms that can kind of get back some of the incentive guarantees that we lost and so one interesting thing is maybe you can use Searchers to do this and that if we I'm going to align some of the details there's lots of proposals how you do this and this isn't comprehensive basically it's kind of like a train of thought that um to be fruitful and is some future work can you prove this if you have some correlation between the valuation of the validator and the user that you can you can find dsicm yeah yeah so like uh yeah so if

you have some guarantee that like the the validator's evaluation function looks a lot like the user's valuation functions um then you're on a better off spot of like kind of the bids you elicit so like in some sense like imagine they're the exact same valuation function actually and so in sometimes like this second B6 look very similar if you're optimizing for like if I have a guaranteed the optimizing for users is also optimizing for the block producer but I mean I think there's definitely some tricky things to work out but you can imagine that um you get beep take with these at the same time because maximizing one is also helping the other and so kind of in these order flow auctions one model you can imagine is you know 10 every transaction that comes I run some second price auction some first price auction

the winner of the auction gets the rights to include that transaction in the final block and so then that clearing price of the auction can serve as a signal for what the MV value was which and then maybe it goes back to the user maybe something else happens lots of various details like most of the incentives but just general line of thought you can use Searchers to kind of get this transaction level and indeed data um that you can use to help the mechanism and so this final thing is kind of combining PBS and MV burn and so instead of looking at the transaction level from the this looks at the Block Level from UV so having Builders compete they give like you know different bids for these are my this is basically my MD value for the entire block as a whole and then at

the TFM notice value I mean V burn says you can um like just burn this and then that can shift the incentives um it's you know there's various things you can do you can imagine maybe sending this total block of movie value back to user somehow the incentives there are pretty messy it's not clear entirely you can do that um but as a trainer thought you can imagine that there's some ways to get her into this total Block Level I mean V value um from having competition at a different level and so kind of in conclusion um the main thing we show is that when there's Mev designing these tfms becomes a lot more complicated and there's kind of fundamental challenges that block producers face here and we've shown that like in the basic TFR model that's kind of what's been studied in the literature so far there's

really not much you can do and they're just trying to just like very strong possibility results to really kind of we need more power um but the upside is today's role is way more complicated than that simple CFM model you know today there's users who submit transactions and Searchers compete with them and then there's Builders and then there's you know proposers like there's this whole thing kind of getting back to the picture I showed earlier that makes it so that something's impossible results aren't um as true in practice today and so it's kind of an area of future work like can we break apart this transaction supply chain more formally and understand how this competition different layers whether it's Searchers or Builders or whoever have you um the kind of breakthrough views and possibility results and get back to having kind of efficient mechanisms align incentives

um yeah that's it yep so the commit reveal type schemes with yeah I like the blog producer doesn't know like the values of the transactions yeah or like the content of the transactions they are kind of like prone to like off-chain communication because now as a user I can tell to The Miner the blog Builder that hey this is my transaction and then please subsidize my transaction fees I will pay you less but you will gain so much because now I told you about this transaction yes and then the user will be incentivized to included and we are now back to the setting where the there's like race to the bottom yes the users so it's definitely true so I guess one thing I kind of awarded throughout this entire talk is talking about this off-chain

agreement or collusion property and to because we're only starting a possibility results this is fine basically even if I remove that condition everything is still quite hard and so it's totally treated like yeah so like kind of getting into this getting towards the positive results we should kind of put these um things back in and I totally agree like in the crypto mempool side it seems tricky of like how do you actually make sure these you don't have these signals whether it's your ribs whatever have you um and so it's like personally I think I'd favor more the order flow auction PBS approach versus the encryption approach because of this type of stuff um but definitely a super open area of mechanism to see if anything can be done there yeah because it's the end of the talk feel free to defer the technical question so the what I was thinking of

this correlation I was thinking of common values because there is some common value that is in this Mev above to use here you use like the Revelation principle yeah value so do you have a sense of uh So when you say common value you mean common value between who between the the users of the um block inclusion and and the validator as well so what I was thinking first when I looked at it I'm like oh why why does the Revelation principle hold and then is that the the validator is just another player yes okay but uh once you start having correlation between the

validator evaluation and the user not exactly the same but I don't think this proof strategy will will will will be you're saying like if there's correlation you can arbitrarily jack up the blood pressure's valuation really high on certain transactions it's like essentially when you're saying that if the the block producer can when it's very valuable for them they can subsidize to zero yeah yeah but for the you if for the user also they have the information that for the user also it's going to be valuable they're not going to be putting it at zero yeah the price so there can be non-trivial yeah yeah that makes sense uh yeah I have to think

about exactly what you can do there um that's something interesting something about [Applause]