Making sense of PBS auctions via compositional game theory

Transcript

foreign hello again hello it's the same people of the last Workshop unfortunately for you so okay um we are now going to talk about uh how we can use compositional Game Theory which for the people that weren't here in the last Workshop is a way of doing Game Theory using basically Lego bricks to make sense of PBS which is proposal Builder separation which is a kind of Hot Topic in ethereum right now okay let me do a recap so what are order flow auctions

okay so um basically as you probably know with the passage to prove us take the infrastructure of ethereum is changing quite a lot um basically in the last years stuff like Med a surfaced uh people got aware of the fact that the order in which you put transactions in a block is really important and valuable and can be used to basically make money or steal money or stuff like that so these created a much more Diversified environment in ethereum and it's not anymore the case that you just you know have a minor that takes the transactions from a mempool and creates a block

now you have what are called proposers that are basically block space providers so these are actors that away or another have the power of having of providing the block space like if you are elected proposer in ethereum you know you can you have the blog space and you can fill it in basically any way you want then there are Searchers and block Builders these are actors that in principle do not have the block space but block space is valuable for them this can be I don't know like Mev Bots bundle Builders basically all the actors that you know can package

transactions into a bundle or into a block and if that block lends it on if that bundle lands in a block they can basically make money out of it so I mean Builders and proposers and Searchers can actually be the same actor but you know conceptually they are really separated roles and now the idea is that proposers have the power of giving away block space and Searchers and block Builders are actually interested in getting this block space to fill it with whatever transactions they want so this created a system where Searchers or Builders actually could bid

for Block space from proposers and then you know they have to make sure that they get the best transactions to populate their blocks so that can actually make money out of this so you have an outflow of money for if you win the block by bidding and then you want to make some money like with Mev or with fees or whatever to actually recoup and the idea of PBS is exactly creating this system where you know uh block proposers can auction this space in a standardized way to builders the cool thing about this whole system is that now the agents that create the transactions which could be the users or order flow providers like Dexys are in a

powerful position because the idea is that if you create a transaction from which a lot of nav could potentially be extracted then you may be interested in saying hey Mr Builder why don't you make me a proposition and I give you the transaction and then you know you get the map out of it so basically the uh idea of order flow options is that in order for auctions the builders not only bid to proposes but they also bid to users so they are kind of saying if you come to me I will give you the best deal I will redistribute some of the

math to you it really depends like there is a constellation of services that are being offered there are various like rpcs popping up privacy preserving rpcs uh you know rpcs that basically guarantee you that if you are not included in the block your transaction is not your bundle is not leaked etc etc etc now the point is it's still quite early um but uh and we already see that with PBS basically uh block space is being auctioned by proposers to builders there are still a lot of ideas around which auction mechanism works best for PBS because when I say

proposers are auction transaction block space to builders what do I mean there are a lot of different types of options that you know you can use uh and in general at the moment with order flow auctions the space is still quite uncoordinated there are a lot of propositions one of the propositions that you know is getting corruption out there is this idea of intent-driven transactions the idea of an intern driven transaction like in a nutshell is that in a standard transaction I just tell you hey I want to call this function from this contract and I want to do this and you the block Builder just take this

thing and put it into a block the idea of an intent-based transaction really unwaverly is I just give you a goal I tell you hey I want to exchange this much from this for this much I don't care which decks you use I don't care how you do it I leave all these details to you and now the idea is that block Builders the more skilled it is the more is able to honor those constraints by you know making a penny on it by basically making money on it um and in general we are still not completely understood how all these things interact with each other so this

is in a nutshell what is going on in PBS land up to now now what are open games on the other hand well you can go back in time and follow this morning's Workshop if you want but if you can't do that I will give you a very fast recap an open game uh open compositional Game Theory is basically a way of doing mechanism design in terms of systems and processes the ideas that we represent mechanisms as open systems so a game is a box like this it observes some stuff so you have some input from the spa from the past that are the observation the game does some strategic decision

and outputs an option that gets forwarded into the future into a context these action this action will have consequences so the game will observe something from the context this is for instance in prisoner dilemma if you play defect or cooperate you are going to get a payoff and then the idea of these wire here that we call the feedback wires that you can redistribute uh these consequences uh into the past yourself so the idea is that you as a game are framed into a context but you as a game are also part of the context for whatever is on the left and on the right

okay you can compose games if the types match you can compose them sequentially in this way and you can compose them in parallel composition is a probably a weird word that we call it parallel composition but the idea is that you are just considering two games at the same time but they don't share any input and any output you're just saying these two games are happening at the same time okay now all this stuff has been implemented we have a DSL embedded inasco we will show it to you it's freely available and we used it for you know designing a lot of applications uh around PBS taking protocols token the science and whatnot

okay so what is uh the most like the basic design that we are going to see today the main idea that we are starting from is that this PBS world is probably becoming will become increasingly more complicated at the moment you see block proposers auctioning block space to um block Builders but for instance you can imagine that the block Builder May itself fragment that block space and run uh options to sub Builders to basically smaller players imagine that you are running some kind of Niche service you cannot fill a block by yourself you have a smaller bundle you may have an

interest in participating and now to an action in an auction for a fraction of the block space so the kind of basic design that we are using here is the idea that a player in our design is at the same time an auctioner for all the players below it and a bidder for all the players above it and in this way we can recursively build this kind of complex systems so uh yeah so this is exactly what we want to do we want to use uh these interconnectedness provided by open games to make sense of overflow auctions okay so this is uh the basic building

block that we are going to use we are going to chop up the players in layers uh the idea is that every layer again you can see it uh as a game and these are the internals of the game so what happens is that some inputs from a layer below are coming in these inputs are copied to each one of these blocks each one of these blocks is a player that plays on this layer each one of this Player is taking some decisions depending on the inputs these decisions are all concatenated together basically into a list and they

are forwarded to the next layer then the payee officer would not come in from the layer above this could be for instance um bids in an auction and these are the results of the auction these results are copied to all the players and these players themselves uh I'll show these in the next slide but if you consider a player as at the same time a bidder and an Auctioneer the idea is that here you are bidding you are receiving the result of your auction if you won or not but you're also an Auctioneer so you are you are getting the bids from players at a lower level and now you got to tell

them hey you won or you didn't win so you have this kind of thing and this is by the way uh how you implement this in our DSL we will show the code uh in in a bit but the idea is that you see this thing here probably yeah so this is the code let's zoom in so these two things here are basically these two game here this game again is um taken the inputs and it's not doing anything with it because they are automatically copied to all players but this thing here you see this thing here is taking a

list of feedbacks so these wires for all players and it's concatenating them into a list that spits out here this thing here is doing the opposite is getting the outputs of all players and it's you know concatenating them and routing them into the future these things here are the players again uh each one of these players sees these bunch of inputs um does something this is basically the player I will show this in detail in a second spit some outputs get some returns so the outcomes of the auction when this player is considered as a bidder and spits back in time the

result of the actions for which this player is an Auctioneer now how is a player modeled this is a player an agent in this model so if you see here we are basically taking these inputs and we are copying the same input to all players now the idea is that in this way all players see all the bits also the bits not directed to them but inside the player the first thing that we have is this block that basically filters all the bids coming in by discarding all the bits that are not directed to this player the reason why we model things in

this way is that this is kind of the standard Behavior but now by tweaking this box you can also model asymmetric information now I can tweak this box and basically model a player that for instance can observe the whole order flow and so can observe also bids not directed to itself now these bits are coming in they are filtered now uh basically an action is run on these bids with some auction parameters uh this could be reserve price first price whatever you you care about then what happens is that we are basically storing

who are the winners of this auction and we are you know basically putting this thing here and waiting with it now I will come to why we are also using the outcome of the auction to basically estimate the payoffs okay from this auction this is how much money we are actually making okay and then we have a bidding process that is I have a private valuation of how much my block my my order flow will be worth I'm sending a bid in the future I'm using my bid to estimate my payoffs this is the amount of money I have to spend basically now I get a return I get uh the outcome of my auction

with this I can basically see you know I have to take the of this into account to calculate the payoff especially you know there are some auctions when you only pay when you win so if you don't win this this this payoff will become zero that's why you need this and also you need to know if you want to let to let the players that bid with you if they want because imagine that I am a block Builder and I'm fractionalizing my blog space people are bidding for my blog space but then I don't win the blog then I got to tell them uh sorry no one won because like I didn't get the Block in the end so that's why we need both

the outcome of the auction internal and the outcome of my bid to basically let no to the player what happens now in this model you can see that the betting the bidding and the option are unrelated and this model basically you can place a bid before running the auction they are completely independent processes uh I'll get to these in a second uh in this other thing here instead I'm using the outcome of the option to inform my bidding process so in this case I am fractionalizing for instance

my blog space I'm running an option I get some bids in and only then I place a bit Myself by using this information now again uh this is how these blocks are basically implemented again these two things are basically routing as I said this little box here takes inputs and basically filters only the inputs directed to this agent um this thing here is basically combining the returns to the agents and the results of the local auction to inform with feedback agents about what happened and in here what we are doing is we are

getting a bid and we are basically packaging it into a type where the bid is provided with the name of the bidder and stuff like that we are getting the returns and again we are filtering because we are getting the returns for all the players in the level and we are filtering only the ones that we care about and this block here this is the auction again it receives the input runs an auction mechanism and spits out both the expected payoffs and results of the local auction this thing is the bid uh again in this case the bid has no inputs so it's just a bit you're just outputting a bid using

this private valuation that is an exogenous parameter that's why it's represented as a dotted this basically for instance a probability distribution that you give and this is the payoff uh thingy that basically takes all the returns from the agent the value of the bid and determines the payoff in practice things are a bit more complicated than that but this is I think um simplified version of what's going on uh okay so again this is if you basically compare this implementation here with the one where you first run the auction and then place the bid the

only difference is this the only difference is that the bit game actually takes this result auction parameter as an input um and that's the only real difference okay uh so now with this when when we talk about Game Theory and mechanism design there are uh three or four things that you can do the first thing is that you can study them this is what has been done like in the auction literature for ages uh we are not directly uh interested in that I think there is a lot of theory out there a lot of Specialists that you know took care of that

what we are interested in instead are these three things here and in particular the last one so the first thing that you can do with a model like this is searching for equilibria like tell me which strategy is the best with strategy results in an equilibrium the problem is that for everyone familiar with Game Theory you will know that this problem becomes computationally unmanageable very very very quickly especially with complex order flow auctions like good luck at finding equilibria it's very hard uh another thing that I can do is I give you a strategy and you tell me if this strategy is an equilibrium or not so if

some player can do better or not this is computationally much easier to do um but it's still complicated to I mean the idea here is that if you give me a quote unquote good strategy I can tell you if that strategy is an equilibrium but what I'm doing is basically I'm delegating the problem of finding equilibrium strategies to you and if the system is very complicated almost always this Checker will tell you oh there is some profitable deviation this is not the best thing you can do what we are really interested in instead is simulations so in simulations the idea is that you give me the mechanism the game and a strategy and I tell you your

expected outcome the reason why we think this is interesting is because main maybe you are one of the players in in this layer here right maybe you are this guy here at some in some place in the order flow auction food chain you have some idea some rough model of how all their players work you encode this in your model you write this down and then you say okay if I adopt this strategy what is my expected outcome so you can basically use this to simulate how much money you can make by positioning yourself in some way and at

some level of this complicated food chain okay now sure uh the number of agents in this thing is is is funded by variable so you can start with toy models uh and you can you know turn these into a much more complicated system as time goes by basically so the idea is depending on the quality of your information and your computing power you can make this more or less complicated [Music] um I'll show you the the code base in in a second so yeah this is exactly what I

was saying like Market placement is if I for instance I change my auction procedure I remember as a player I bid but I also run an option myself what if I change it from I don't know first price to end price or I plug in a reserve price or something like that uh will I intercept more Aura flow or less I don't know you can simulate this another thing you can do is best path so that is imagine that I have to reserve X block space and I expect to intercept y order flow would it be best for me to bid directly to proposer or to maybe participate through an intermediary into a

fragmented order flow auction I don't know you can simulate it um if you are a user and everything stays the same what should I do should I bid should I place my bids to everyone or only to some players in the order of the food chain in practice this for instance means if I have a transaction do I place it on the public mempool or only on one on flashbus RPC or maybe I want to go through flashbus and manifold at the same time I don't know you can test and and simulate this Okay so yeah we simulate this uh with together with the guys at flashbots uh we

simulated different auction mechanisms in the context of PBS this is basically where this project was started and what we are going to see now is this little example of an order flow auction so what happens here is that there are three users tree Builders and a proposer okay so now the idea is remember that in the idea of order flow auctions is that the Builder bids to the user to get their transaction right so now we have these three users these three users are basically sending this is not really a bid uh they are sending

um basically information just saying hey I have a transaction that is worth this much these Builders here will run a trivial option so they will just not uh name any winner because that's just the information that guest is closed but based on this information they will themselves Place bids to proposers and to users so they can say okay user one says air transaction that is worth this much map Builder 2 says okay I am interested in this transaction I'm bidding for this transaction at the same time they have to send a bid to proposer because they have to ensure that they

get the block space and you already see that this is not easy at all because basically you have to take care of two auctions at the same time you have to take care of securing the order flow on one hand and securing the block space on the other what happens is for instance you get the block space but you don't get the transactions or what if you get a transactions and you don't get the block space uh so yeah this is the forward flow as I was saying the red one and the blue one is the backward flows so the idea here is that uh user gives you information you place a bet to proposer and to users now users and proposers

basically up to the side which bid they have to accept or not these are trivial bidders they don't have anyone to bid to after them this is the kind of top of the food chain here so basically the output is just like get spiked back and now proposal replies okay like Builder one one for instance and user one says okay Builder two one whatever and that is information is routed back to the end users now the cool thing is that in our framework you have this tricked that when two boxes have the same name you can basically sum their payoffs this means that

what user to gains here it also gains here this allows user 2 to think strategically forward in the future because user 2 doesn't really get um user 2 at this stage doesn't really know um how much money it will make from the offer of Builders but it knows that in the future it will know and so since the payoffs of user 2 in the past and user two in the future are connected and same from user one and for user three you can have an organic game basically so the idea is that these players and these players are

actually the same players but at different stages of the game they have to take different kind of decisions and run different kind of processes uh yeah and I think now we can basically show uh the code that we have yeah okay so let's show a little the demo uh I understand this is hard uh but yeah the model is here for you and we're here for you we made the model so yeah hopefully this will shed some light yeah okay so so uh these are this is files called components and basically in here we are just defining all the components in those big pictures that we were showing so yeah for instance all

these go up one second so this routing sub games are basically games with no strategic content that see like all the bits and and filter them so for instance you see this routing agent rushing pause feedback about weird names it sees all the returns for all the players in a level it gets the player name and it spits out only the returns directed to the player so this is like kind of the filtering piping infrastructure the plumbing that makes things work here we have auction mechanism this was the a box in our model um and the idea is that you pass the

auction function as an exogenous parameter so basically this thing will take the inputs of all directed to the agents input agent name it will run the option function and it will spit an outcome with this sure they are not predefined so that's exactly the nice thing this this thing and this thing here will have a type A nascal type and now an auction function can be any function you want with that type signature you have them exactly so the idea is that in this way

once you have a bunch of possible options you can swap them on the Fly exactly yes uh so if we go uh go all the way down I mean this yeah okay wait sorry so this is uh what we call agent exogenous this is basically kind of uh the basic agent um again you can basically see that it does some routing it runs the auction here then it determines the action results uh for the agents in the level before so these These are you are getting basically the bids and now you are determining getting also your outcome in your auction where you were

the bidder if your bidders won or not then you place a bid yourself here and then there is some more routing here at the end I know that it's quite complicated to basically looking look at it right now in this way it's just like a dumpster Fire Mountain of ugly code uh but yeah this is basically just the diagram that you saw before in the pictures like in in our DSL again this is the endogenous agent this is the one that is actually using the auction information to place the bidding uh again also in in this case basically all the quote

unquote relevant stuff all the meat of the model is passed as um out is passed as exogenous functions so for instance you are giving an auction function but you're also giving these update estimates that is a function that tells you how you have to use the auction results to update your evaluation and your bits so all these things can basically be developed separately and plugged in and swapped depending on you know what kind of simulation you want to do so yeah and we also have examples for it yeah so yeah so I think yeah if you go all the way down I think there isn't uh we are the

yes yeah in year we basically Define f in here we basically Define the Builders of for order flow auctions I think we also have an order flow auction.hs file yeah where basically we use all these building blocks to um should I go there yeah let's see what's there so yeah in this thing you see we have the layer so this is layer one where you have name one name two name three that will be the names of the players the user submit transaction is the sub game where the user has to strategically decide to which of the three Builders they want to reveal the value of their

transaction uh and this will be a strategic decision basically it turns out that the dog there is a dominant strategy here for the user since the user only pays to the winning bidder basically like the best strategy for this kind of model is tell everyone your transactions uh do not worry again in practice we'll see later Things become more difficult when you consider intense where you consider privacy and all this kind of stuff that we are trying to bake in in the model but yeah in this simple model where transactions just have an intrinsic utility that means if my transaction goes in the block I'm gaining this much utility from the fact the only thing you want to do

is maximizing your chances of getting in the block okay so this is the three users basically uh if you go down to Layer Two in here we will basically have the Builder so you will have the Builder the Builder the Builder that will receive the inputs from the users in layer one will do other kind of stuff and they will spit out their outputs to layer three so if you go to layer three you will have the proposal and again the three users that now have to decide which offer they want to accept or not now when you compose everything together

if you go all the way down uh there is something called complete game yeah this one you see in the complete game we are basically just plugging the three layers again see like this spits out outputs one these use this outputs one as an input it spits out output users two output proposers and these are used as inputs in layer three so it's exactly the wiring of the picture we were showing before and now if you go in main uh there is basically the simulation function that allows you to run this monsters yeah sure in yeah I mean in this case we just use

two but in theory um there are ways to scale it to an arbitrary number of users obviously one sad way of doing it is by hand but in theory you could use like template askal or stuff like that to basically generate arbitrarily big chunks of code okay uh but yeah this is basically uh an ergonomicity problem of which we are very aware so this this piece of code is not uh even public yet at the moment is it's really a proof of concept but yeah for sure we have to basically make it easier to use okay so now we have uh a bunch of possible simulations so

the first simulation is scenario symmetric in this scenario basically all Builders have access to all order flow so all users can broadcast their transaction to all Builders and all Builders have action access to the same information so if we run this thing uh already okay you already did it yeah nice you can see this thing spits out some Json that is basically telling here for each Builder how much it costs the Builder and how much the payoff is received unsurprisingly since this is a symmetric case and all Builders have access to the same information they basically run all the

same strategy and they have all the same expected outcome uh just a word of caution uh these games are Bayesian so when I say expected outcome I basically mean expected outcome in the sense of probability distributions so in the end it is true that only one Builder Will made it into the block but then the idea here is that all these Builders can make it into the block with equal probability because they are adopting the same strategy with the same information so that's why they you see the same parameters basically these are estimates probabilistic estimates okay now if we go to uh this one in this simulation here basically you

have that only Builder 3 gets access to the most valuable transactions how did we do that in practice um if we look at the parameters uh I don't know how if you go to scenario exclusive order flow I think yeah in the parameters or a flow limited go okay go here expand this one let's see if we can do that yeah basically in this parameters this is where these things we we are using it to define the action space for the user so if you remember I told you that the best

strategy for the user is telling everyone about their transaction but the point is that the everyone is an object in a space that you have to Define so in this case if we are giving this action space this means that the user at layer 1 sees all three Builders and clearly the best strategy is tell to all free what transaction you are but then we can artificially restrict the action space so in this case if we use this one we are basically modeling a user that only sees the first two Builders the strategy stays the same it says okay I'll tell everyone but we artificially constrained the the

builders that are available so the everyone for this user will be limited in this case when it's exclusive when you pass these parameters here the user in layer 1 only sees one Builder and these princess models the idea of a user going through a particular RPC to which only one Builder has access for instance so if we go all the way back to main to simulation in this case we artificially restricted um basically which Builder sees how sees what how did we do we did with how did we do that one user had some high value transaction we restricted artificially

so that that user only sees build a tree and indeed if we run this you see that Builder one and Builder 2 get zero like they don't get any gain and they don't get any cost because the point is since they see less interesting order flow they cannot place a convincing bet to proposer whereas Builder tree can offer more to proposer and basically win the auction uh and okay so in this other thing we see the opposite now build a tree is only getting access to the lowest value transaction

and indeed if we update that let's see if it works you see now Builder one and Builder 2 profit with equal payoffs and now Builder 3 is beautifully because he only sees like the horrible transactions and you will not be able to compete with the other builders with its offer uh and yeah this last one is basically something else that we encoded where basically we tweaked Builders so that different Builders have different capacities of extracting values from the transaction so the idea is that for the same transaction they get different payoffs and that quantifies like their skill of like exploring the search space

for mad and when you run this again you will get different parameters where basically the most skill Builder that is able to extract the most nav will also be able to place the best bit to propose them so yeah this is just a little proof of concept I would say um but that's basically what we did and if we go back to the presentation for a second I also wanted to show you and then we go to questions uh I also wanted to show you future developments so the idea is that now we want to Stitch this together with intents so again the idea of intense and commitments because there are related things is

I tell you what I want so the idea is I tell you what I want and only then for instance I show you my real transaction so a standard example is I tell you maybe by a zero knowledge proof or something similar that my transaction is at least worth this much math you see this you do everything you have to do and only afterwards I show my transaction to you and you have access to the real information so the idea is that again we kind of re-used the same uh kind of block so we have the first round when all the bits

come in and at this stage with the bid you carry the intents you carry information they say okay I care about you know near the type structure will be more difficult you say like I care about this kind of information I care about privacy preservation and stuff like that then the auction is run as usual now basically what happens is that after the auction is run the single user has to decide if they want to provide the actual transactions or not so some actual transactions come in based on whoever won the action you decide who to include and how to bundle

the block basically in here you can also model things like I want to cheat I ensure your first position but I actually don't not putting you first in the bundle or stuff like that after doing that you can choose to reveal the block or not and this informs your payoff this is really interesting because there are there's been recent Publications um in which you know it is shown that for instance there is a difference if the user space before or at inclusion time so for instance what happens is that if you pay at inclusion time you may be incentivated to you know give your intern to everyone and then you get a different kind of office and then

basically you up everyone that is not nice with you and only Reveal Your transactions to a few selected players but then in doing so what happens is that all the other players that basically you know did their calculations supposing that they would have received your transactions are now screwed so with this more complex design that is still not implemented yet we hope that we are able to characterize this kind of very weird and complex interaction uh yeah I think yeah again you can do it with private information or not but it's not really important and yeah I think that's basically it and we are open for questions thank you [Applause]

do we have 10 people questions by the way cool that's it is complexity arbitrarily scalable um have you started developing any

insights about about the the appropriate level of complexity or maybe some systematic way of moving through up through the complexity scale to um you know get better insights essentially uh okay for the second question uh I think this thing is still not scalable in the sense that it is in principle but we are still lacking a lot of ergonomics we are painfully aware of it so there's still a lot of work to do I'm not going to anyone and saying oh yeah this thing is super easy to use absolutely not it's still quite complicated we just think that it's a better architectural choice that you know as more opportunity to scale but it's still a pain in the ass to use

today like that's let's be honest okay um but um wait what was the question about that oh yeah um what we really need to do now is we really want to work very closely with people that are part of the Mev food chain infrastructure because you know we don't run any relayer we don't have any RPC we don't have a MAV product we do not observe directly day to day how this stuff works so there are some assumptions that we made we made these assumptions talking to people and based on you know what we see around but it

would be very very nice uh to work with you know people that are actively involved in this and they are willing to experiment with this kind of stuff I think this is what it's needed the most uh for us at the moment like really interaction with with people that use that are in the math production infrastructure yeah for sure he also asked if we have some insight from our model yet uh yeah I mean there are we have I mean some insights yes for sure um even in this very simple toy model for instance you know it it was really nice to see actively how participating in

different men pools and being able to observe or not observe some stuff would radically change your access to actually block space because of the order flow you can intercept uh yeah we have uh we have some other some some insights uh but yeah we are still like largely playing with this stuff by by ourselves at the moment would you mind just going back to their simulation results simulation simulation results okay yeah and just talking to because you mentioned that those payoffs and the costs are Bayesian results right so you would basically say that in expectation the cost would be 297 and the expected payoff would be 300 yeah exactly but for

the previous result when you simulated I think it was the second run so it was an exclusive order flow number one you would have two um two agents having the same results which is just something that I would wonder how this would work in practice so yeah okay no so it was the second one I think because in this one building is the only one oh exactly so with this I have a question as well so like what does it mean because why would the like this would assume that the Builder number three would not change their um their strategy based on the information that that they know about the other two because in the case when the the first and the second would not bid because they know that there are no interesting transactions uh build a tree

could say I'm paying you only like a marginal cost right because this would then include knowing having full information this is a simulation it's not equilibrium checking so with this strategy it may totally be that Builder 3 could pay much less than 270 exactly Securities or for sure okay but at the moment we are again as I said before now this is a small game and already finding equilibria will be a pain uh so in general the way we expect this to to work in practices I mean we know that Builders and you know all this kind of stuff is not like really strategic they are Bots that basically execute some heuristics that are pre-programmed so

the idea is you can use this thing to simulate how profitable that heuristic is and maybe you want to say okay now let's make a small change in the heuristic do I go better or worse I wouldn't expect to be able to like really do like gradient descent and yeah find an Optimum okay yeah so this will select if they would adapt you based on information okay I mean obviously if you can rent a ton of AWS space and probably things are different but well you can do that and for the other result for the search run I think it was for a second you would have two agents with the same amounts this would just signal that um in your simulation you would expect that

both agents could pursue this strategy but in the end only one of them would require them to do the action right yeah exactly so the idea of the expected outcome is imagine that you say I win like a hundred but only 30 percent of the time is like saying okay now you are waiting that payoff by the probability so I don't want to say something stupid but I think the expected outcome would be 30 in that case so yeah hey could you give some insight into how you think privacy might affect the way players interact with each other like usually who's hiding what from whom and does this benefit certain players more than others and how would you model this

so if we go back to the model I think that there are different ways of modeling private information here one obvious thing is in the definition of a player you can tweak the this box here and this box here and basically this allows you to model for instance an agent that listens to multiple mempools and so it can see more transactions in a way uh when you um when instead you really I mean there are various definitions of private

information here one is this one the other one is what do I know about how other players interact and what other players do so this would basically have to do with this and with the auction parameters so when you model the other players imagine that you have you are a player and you are modeling other players then you have to have some ideas of these two things and obviously the more you know the more precise information you have the more your model will be reliable the third thing if you are thinking about privacy preserving mempools and transactions and stuff like that then we go here that is still highly speculative but the idea is that again I can give you some information like a

lower bound of the Mev that you can extract to from some transaction but then in practice if I decide to commit to show you my transaction that could be much more or actually could be that if you don't honor all the conditions I gave you it's much less if not zero so again it's very difficult to see how granular you want to be with these things because more granularity also means less scalability it will become more difficult to simulate this stuff so yeah we are trying to do trade-offs basically okay yeah two minutes are missing so the last question if you have if not thank you uh like could you explain a bit more

about I guess like the feedback part because I know like for example some of the strategies like it may not just be like over one game but like over a long game like does the feedback just continually like I guess affect the input over and over again because like in the example you gave about privacy right like let's say that you a user sends a transaction and then like the Builder commits to giving them like a certain profit but then the Builder defects and then they do something completely arbitrary does that just affect like the next round kind of and how do you simulate that yeah so basically the way you can simulate it is you have this eye thing here I don't know if I mentioned this in this Workshop or in the previous one but basically there are three main kinds of atomic games that you can use they are

strategic choices that are You observe something you have an action space and you have to pick one thing that you can do and you make a strategic Choice the other one is a deterministic function so you have no strategy you just observe and do and the third one is draw from nature so that is basically used to model random events like flip a coin and stuff like that so if this thing is a deterministic procedure then the user can be sure that there is no strategic Choice involved so you can model for instance a player that cannot censor transactions by saying these are deterministic functions players know this uh there is nothing that they can do and these will be the equivalent of

like modeling uh Builder using I don't know like an fgx or some private and like Enclave of some sort on the other hand if you want to model uh something different you could say okay this is maybe a random function there's a draw from nature and like 30 percent of the time these Builders scams you and again now the user observes the structure of the game and knows that okay I can commit to this player but then I have to know that every time I decide to reveal there is a 30 possibility that I get scammed so again you can basically bake this stuff in into the model it's like uh when you do the stochastic

model like I guess how like this is kind of like how far do you iterate because like in the example you gave her like 30 of the time the Builder like scams you right then the user changes their input and that affects like the next simulation right so like I guess how far can you like iterate until you reach because is that similar to finding equilibria or uh not really like uh basically what you do in this game is you go all the way to the end and then all the hill all the way to the other end so you do all the red and then all the blue these are all the actions and then you have all the payoffs and then you get the expected value for those parameters the way you find equilibrium and stuff like that is by performing small deviations on the

strategy space and basically doing gradient descent but that's why we're focusing on simulations more than on that because that's going to be computationally terrible okay I think we are done but we will be around for more questions outside if you want thank you very much [Applause]