Disintegrating searchers and builders with Qunitus Kilbourn | a16z research talks

Transcript

hi everybody uh so this is going to be the start of kind of uh infra mechanism design week and kind of the seminars we have uh and today we'll kind of be more focused on ethereum and kind of the state of me and kind of various problems with INF layer um that that Community is facing uh and so you know I think we've kind of seen a lot of kind of market dynamics emerge over the past couple years and a lot of kind of debates on various parts of the stack about how we address things like Builder centralization cens resistance uh you know various qus on execution tickets and kind of different ways of doing PBS uh and so to start out uh the week we will have quintis from flash Bots uh who

does is a researcher there and kind of works on various research problems they face and how they address that in different mechanism to try out basically and so he'll be telling us about uh one of their new refund mechanisms and truthful bidding in PBS auction so hand it off the crus cool thanks brov today I will sort of be talking about truth forbidding in PBS bundle auctions and I say sort of because what we want in practice isn't I don't think there's a really like a good theoretical concept for it and I'm just using truth forbidding as like the closest thing I can get um and motivate this is very interesting because it is actually something that is sort of currently live or about to be live um

and is mechanism designed with practical constraints but also mechanism design in the presence of a bunch of other mechanisms influencing what you're trying to do and and uh I think that's interesting and hard so flying through some context many many years ago not that long ago but in crypto quite a long time ago uh before flash Bots existed there were priority gas auctions in ethereum mempool and there were a bunch of problems with these that I don't know when to get into much but like we had congestion in the men pools blocks are full of reverting transactions um and there was s of incentive concerns around the incentives of validators uh or miners at the time and how they affect the network incentives and so in response to this uh was like came the mavg architecture which basically um

introduced this Central actor that did two things one it provided a private channel for uh Searchers and if that term is new to you then I guess you can just think of them as Traders traders to access miners um but also this this um sort of private this U centralized relay that we were running was also monitoring miners to make sure they were not abusing the like trades uh that Searchers were passing on not front running them for example there were some problems with this one was that um because of the sort of trusted relationship that the the relay had with miners we couldn't operate with small miners is cuz they didn't build up sufficient reputation uh to allow us to do this but the larger problem that I

want to talk what that like relevant for today's talk is that this relay was a central centralized choke point and so to move away from this we move to today's architecture which we have instantiated with the me boost and without like giving too many words to this because I I suspect everyone sort of knows how this works we tried to get decentralization here by opening up this API and allowing any Builder uh to sort of participate in this market with some asterisks however we feel that this is not sufficient uh sufficiently decentralized and we think this for a couple of reasons one is that some actors a few actors still have a lot of influence over the market it's not very neutral and that's not what we'd like to have we'd like to have more neutrality um the second is that there is reliance on trusted relationships in this market

if you want to you know effectively trade on chain or or do some more like time and information sensitive things you have to trust some some counterparties and sort of goes counter to the whole uh ethos of the space and so I want to point you guys to two dynamics that will allow us to understand and what's actually happening in the market uh today the first is that the Searchers um participate in a blind pay or bid auction um whereas the block Builders participate in open outcry auctions and on top of that the Searchers must go through block Builders whereas the block Builders don't have to or have few intermediaries to go through and so these the block Builders operate with lower latency in reacting to to other bids and and just general information what this leads to is an

information difference block Ballers fundamentally have access to more information than Searchers in this in this market structure and so what we're seeing in the market is Searchers trying to leverage the structural information advantage of block Builders this happens in two ways one is that searches end up just being block Builders they they integrate and we see this with some of the biggest block Builders today Beav bu in rsync where um the Searcher would just you wouldn't consider the Searcher bidding to the block Builder instead they just forward their their bundle their full bid reporting their true value or whatever to the Builder and they then allow the Builder to respond to other bids in this auction trying to um optimize their price um and take

profit and this is you know more appealing than participating in the blind auction because in the blind auction The Searchers in this position where they have to estimate the minimum amount they have to bid uh and because it's a sort of a probabilistic guess and I guess it always is probabilistic but it's not done with much information there's a good chance that they overpay uh Missing on some revenue or underpay also missing on some Revenue um but just sort of completely missing on the opportunity a similar way of addressing this that's more scalable than just integrating all these Searchers into block Builders um is that Searchers Outsource they bidding two block Builders through like basically handshake deals refund deals and these deals work like this Searchers first give or sear just give a right of first

execution to block Builders meaning that they send their Bund their transaction to this block Builder and allow that block Builder to use that within their block and their block uniquely um and assuming the block Builder wins they will then share back some of this profit back to the sender of of this order flow and this is sort of like reminiscent of Revelation principle we sort of kind of approximating a a second price auction here of ECG where the the Searchers paying the minimum amount they would have to obviously that's not exactly what happens but that's roughly what we're heading towards and if the Builder thinks they won't win the block there's the sort this fail safe mechanism where the Builder will then broadcast the transactions to other block Builders to try to preserve the the chance of inclusion for the searches so they don't

find face such a sharp inclusion versus Revenue maximizing tradeoff I would say this and several other Dynamics MV Market you could like phrase as U the market sort of discovering the Revelation PR principle like you know the market approximating some sort of mechanism that um does a lot of the the complexity that we would imagine mechanism we designed from scratch would be doing so in this market regime how can a decentralized builder compete how can we introduce a decentralized builder our first step into doing this is implementing a programmatic refund rule in a te block Builder the te aspect is not like relevant to today's talk at all um but that's like the sort of first step in the decentralized direction how do we do this because block building is such a latency sensitive activity where

like tens of milliseconds matter we um calculate refunds after the fact so you can do like more computationally heavy refund calculations um after blocks have been submitted we do like smart multiplexing which is what I was describing earlier where there's a fallback mechanism if you don't think you're going to win the block you can broadcast some bundles and importantly these bundles these bids don't have to be the same ones that were submitted to this um refunding te Builder and then okay not an important topic but we aim to like this is not the final architecture now the question I want to get to today is how do we Define the refund rule how do we Define in effect the payment rule for this programmatic block Builder to be competitive in this in this market for this uh decentralized block Builder so what do we need from

the from the refund Rule and this is where I would love to be able to State some like specific formal property but in reality what we want is we wanted to be competitive you know and competitive in this market with with refund rules and all these like weird micr structure dynamics that I I I haven't mentioned broadly what this means is that we want to incentivize Searchers to give the first R of execution to this decentralized refund Builder more specifically this is not as strong as we need but at least what we would need is we would need to yield higher returns than participating in this blind auction where the Searcher tries to you know get the first price right and broadcast their bundle to to all the boulders this is not enough because you also need to compete with the builders doing the centralized deals um and really what

this comes down to I sort of postulate is improving this uh this tradeoff that Searchers find between maximizing their revenue given that they're included and improving their chance of inclusion right like in a in a in a first price auction you have this problem where if If you bid too low your chance of not being included is is much higher but if you do get included Your revenue is higher in this case it's like a much more complicated situation where you where submitting to the um refund Builder um means that there's a chance that you both underbid and that you um that the sort of the fail safe multiplexing mechanism doesn't do its job well enough but at the same time there's um a chance of higher Revenue but gu a lot of talk let me like get to

the actual rule that we've um implemented we assume we receive some fixed set of transactions in reality these come arrive over time and that plays an important role but for now we just assume they're fixed and there's some optimal block that we build deterministically from these transactions then there's some value associated with this block which is just the the sum of all the payments the of the bids in that block then we Define the payment of a an identity I we do this by identities because some Searchers might want to label multiple bundles as as their own and they don't want to sort of have their own bundles conflicting with each other and yeah this is this is this ends up being tied to the block that's that's built because the location of the bundle in the block is uh determines also the value of the

opportunity a relatively important quantity is this marginal contribution and now this should remind you of the vcg rule where we say this Define this modal contribution is basically the additional value that we can get with with you compared to the best block we can build without this identity with the additional condition that we bound this contribution by the payment made by the bundle and the reason we do this is because we don't want to end up in a situation where we end up in net paying uh a Searcher for sending their flow we also we just want to be reducing their bids to the minimum possible we don't want to be compensating them for positive externalities then C is the amount that the this Builder has to pay to the

proposer to win the block um obviously there's actually this actually relates to which bundles you receive because those bundles might be sent across multiple block Builders but for now we just take it at some exogenous variable and then the actual rule is relatively simple the important thing to consider here is like these two cases and what we're saying is like look if we have enough value if the Block's value is so much larger than you have to pay to the proposer and we have that much um Revenue to to share out then this term is much larger than that and this denominator cancels with the the sum of contributions and everyone just gets refunded their contribution however if we don't have enough Revenue to refund everyone um

their contribution we give everyone x% of their of their um of the refund they're supposed to be getting and that's why it's called the flat tax rule because everyone gets taxed sort of similarly okay and then one note I want to include here is that we can't distinguish between uh bundles which were sent uniquely to the refund Builder versus bundles that were sent to multiple block Builders because you can't like really really um because it's so easy to to to access to have a new identity a new pseudonym a new account on chain and you can't really track these things and the reason I mentioned that is because in some other world you might actually want to track this because the contribution of someone who sends flow uniquely to a block Builder is much larger than

someone who sends it to All Because by sending a bundle to all you you raise the bids of competitors as well here comes the point where I sort of try to understand what we're doing relative to some of the more like formal Concepts that exist I think the ideal Cas would be that every Searcher just reports their true value for something being included um and then we do the rest that's not actually the case but let's see what what's actually happening so this is sort of like the payoff for a first price auction assuming that um we're looking at some bid from some biders perspective where they have a value of six for having a bundle included and we're just assuming we're just reducing this to like one sort of a a single item or and just to reason about it more clearly value of six to be

included uh a value of two is a they have to pay obviously in reality you don't know this and you have to estimate it but this is what the payoff would look like so for a second price auction this is what the the payoff looks like as long as you pay more than the minimum amount you have to pay then you get some some flat reward what we're looking at is something in between something that interpolates between these if the Builder has very large margin then um it can basically implement the second price Rule and the red the red lines basically look like the blue so and the reason that this vertical line is moving is that as you effectively refund the the biders more they should bid higher in expectation so the the bid that you have to beat as the highest bidder is is also

grows so as we have more money to refund people the red line approaches the blue and the less we have we eventually we get like in the limit to a first price auction like to the black line so of one thing to point out here that's nice about the incentive properties is that you have no incentive to inflate your bids just like the same argument goes through for the for the second price auction um you can as a bidder overstate your bid state of value higher than your true value but that only helps you in cases or that only makes a difference in cases where um your competitor is bidding higher than your true value as well which means that you're you're bidding at a loss like this you you end up paying in this region which is um you know negative EV for you Our Hope here

or like one of the ways we reason about this and that um makes it seem appealing is that the expected loss of bidding truthfully under the sort of refund rule versus optimally bidding is yet to be formally proven but we think is smaller than in the like first price auction for example right because you bding truthfully you get some some value out of it um and um your sort of like penalty for not Bing less for for I I don't want to get into the the argument too much because it's a we don't have it's formally proven but like that's a a visual intuition at least and then some cave had to put here that this line actually isn't straight it's like slightly curved and the curvature

depends on um how large of a share of the total margin to refund your your bid constitutes so if there's like if if your bundle constitutes the full value of the block then this is um or like almost the full value of the Block it's much more much more steeply curved but it never goes be below the F first Price Line yeah okay there's a counterargument to this which is that really what we're trying to achieve with strategy proofness is that we want to make bidding really simple uh and if that is the goal and that is in fact what's influencing the market dynamics and it's not about just being very profit driven but it's also about having more Simplicity on the on the Searcher side and then this is not a good rule because now the Searcher needs to estimate both

uh how much their competitors are bidding but also how much the different block Builders are bidding and estimate the like the the revenue that's going to be refunded one potential solution to this is to increase the window over which we consider these refunds because it's easier to estimate the margin that or the revenue that the refund Builder is going to generate over a longer time period than it is over a single block however there's a problem here where there's a dilution of refunds issue like I was saying earlier unique bundles like the blue bundle here um represent more value to the refund Builder than bundles that are shared across block Builders the problem is that the refund Builder can't distinguish between the blue and the orange bundle and so instead of refunding the blue bundle the full e one

e that it's contributed uh it it needs to share that refund between the blue and the orange uh Builders and the larger the window if the you know the unique bundles don't appear very frequently the the larger the window the more you dilute this value um so like the degree to which is is a problem depends on the sort of process by which bundles arrive and and um how that's characterized so one problem that we had to deal with in setting up this rule is civil uh and in particular this is one attack that we at first didn't uh anticipate so you can imagine some Searcher valuing an Arbitrage opportunity at like X Plus y but instead of submitting a bundle and

just bidding X Plus y they submit two bundles one bundle that does the Arbitrage only pays X and then some second bundle which if it is included if a is included if the Arbitrage is included pays Y and now what the rule would do without the adjustments that we made is it would consider the contribution of bundle a as being value X Plus y because if you remove a b doesn't pay either but the rule would then also look at bundle B and say oh this guy is contributing y That's great and then effectively refund this Searcher twice for for this value y for bundle B uh and so the way we've addressed this is by just using more compute and so we've defined a new constraint which is a contribution of a

group defined in like basically the same way but just for a set of identity we uh implement or like uh additionally um constrain the a new refund rule by saying that the refunds for any set of identities cannot exceed the contribution of that set of identities and then what we do is we say okay well and the refund rule that we then Implement is the closest we can get to the original refund rule I I told you guys about um given these constraints um and that is not very scalable but you can do it at the at the sort of transaction arrival rate in in in ethereum it's fine or like the number of transactions per block okay that's

that's it I included a link to our docs cuz this is actually implemented if you if you were curious a bunch of different things to work on I think the most interesting thing here is that there seems to be this kind of Trend in the me market where we have a bunch of different mechanism bunch of different auctions all happening at once and what seems to be the case even if you're looking at relays as well is um that the E economic activity and the way people where people are trying to make decisions ends up moving to where the most information is and so when you have these like multiple auctions put together like the pay your bed auction for Searcher bundles and the block the block auction um the one auction sort of ends up the one mechanism ends up sort of being consumed by the other and

trying to understand how this works um as I think would be really interesting um yes any questions so when a bundle is submitted can anyone else see that the bundle is submitted or is is it just like flash BS that's SE it so the question is when a bundle is submitted can anyone see it the bundle is submitted the answer is no with some caveats you can like indirectly extract some information so like if a block Builder updates its bid in the like open out cry auction then you can maybe like extrapolate some information from that but especially with the with the te Builder the idea is that even flash Bots doesn't know there's some like process that's running and that information's private yeah cuz if that was true then you could

just block someone else is refund by submitting the same bundle that they submitted yeah yeah like griefing them basically there's I don't think there's any such thing as strategy proofness in practice um we don't have independent private values people have incentives to grief each other um yeah it's can you go back to the slide that where you first defined this whole setup like you define the Muse and stuff so one question that I was confused me when you define v of T does that take into account the little bees or that sort of distinct from The Little Bees vft is the sum of the small bees okay all right sounds good then the main question I have is

with respect to little c um because I imagine you do something like where does little C come from I guess in your implementation I'm curious about like you have you have some guess of what the competition's going to be or um so so some guess of what the what's going to be about what little C is going to be yeah so so little C is comes from an like a separate module that we run that monitors the the market takes in information about bullet bids at other relays maybe some other information and then puts out a bid um and then sort of eventually we we end up with a final bid that gets taken by the block Builder and then we know what what

C would be point is at the time that you compute the refund C is known is that right yeah because we do it after to the fact okay so like on the bitter side it's possible you wish you knew see when figuring out your little B but you don't but exactly I have to guess what little C is I guess okay yeah so one thing that sort of I didn't directly mention but that is true for this mechanism is that there are sort of like there a positive feedback loop where once you have um sufficient sort of like Market positioning or like you you consistently capture a margin to redistribute that should have like a positive feedback loop and and uh take you elsewhere but there's a like a strong cold start problem because of that c can you also

go to I think it was your second to last slide where you were talking about um kind of like the uh civil proofness this one so are you yeah so so you mentioned like you said something quick about tractability like are you really like exhausting over all sets of Searchers and is that like is that tractable in practice or like you're using heuristics and it would be interesting to develop good heuristics I'm just curious like the state of that proc great great question okay so couple of things to mention yes we're doing it exhaustively so at first um we thought okay we just do it by identity and allow people to report because there is some incentive to report many bundles under one identity because you don't want them to compete with each other but what we realized was that people also really value being able to have like uh

information about refunds at a bundle level because I want to know how competitive every opportunity was and so what people told us they would do is they would just submit all the Bund on different identities and force us into the worst case here so we just do the worst case computation anyway so we can give us information to people while still allowing them to report things under one identity because then at least we have the identity to associate these bundles now one thing that I would like to spend more time thinking through is the impact of this optimization so there's two reasons you want to think about it one is firstly do we ever hit this constraint in practice uh with you know without someone actually trying to break

the mechanism like is there are there like sufficient positive externalities between bundles or or whatever for that for that to be the case and the second is how does our um how does this approximation actually impact the incentives like if it is the case that naturally we do have these constraints being hit um does that change the micr structure where people now are incentivized to split their bundles into many or to change their bidding Dynamics and I don't have any answers to that but I think that's interesting and it would be it would be great if we can come up with a herotic to do compute this faster and take it to other networks but um I don't know if it's possible sweet thanks [Applause]