Proposer-Builder Separation, payment for order flows, and centralization with Agostino Capponi

Transcript

Thanks for joining us for the the afternoon session today on focusing on Ethereum. Pleasure to introduce Augustino, he's a professor um at I or at Columbia who's worked on lots of various kind of problems in finance and economics and as of recently has been working on um kind of blockchain stuff. And so yeah, hand off to him to talk about proposer-builder separation and some problems that arise from that and potential solutions. So, thanks. Thank you Barnaby. And um yeah, let me continue along the lines of what uh has been discussed in the morning about the the the MEV and uh new architecture of Ethereum based on the proposer-builder separation mechanism.

So, what I'm going to do is giving an overview of the PBS. I think most of the people here are very familiar with the with this architecture, but just to make sure that we are all on the same page, I will start with a brief recap of how this architecture works. And I will mention what it means uh payment for order flows. And then I would like to propose a game theoretical mechanism to show why and how centralization might arise under this new design. And that's joint work with uh current student Rishi Jain and the former post doc Sven Olafsson.

Okay, so I think the I think we all agree that uh centralization is basically the main principle upon which the blockchain technology has been designed. Uh why do we like decentralization? Because it ensures a lot of nice properties such as resilience against manipulation, censorship, uh settlement finality, avoiding self-managing practices, and so all all these are benefits that can be guaranteed when the system is decentralized. And uh in the traditional like ecosystems that we have seen in in Ethereum but also in Bitcoin earlier. Uh validators are responsible for both proposing and constructing the blocks.

So, what the validators do is they take order flow, they incorporate this order flow into the blocks, and then they validate these blocks and they append them to the chain. And typically the transactions that these validators have access to can be roughly classified into three categories. One is the set of internal transactions. These are transactions that are essentially initiated by the validator themselves. So, they construct this order flow directly. Then there are public transactions, which are essentially transactions that are visible in the order in the public memory pool of the blockchain. So, everybody can have access to them.

And then there are private transactions, which come from private agreements that the validators have with order flow providers. So, they establish direct communication channels, direct contractual relationships, and in exchange for this order flow they might promise something back. Okay? So, these are three type of potential transactions. And if we look at the traditional validation ecosystem before the introduction of the so-called proposer-builder separation mechanism, the idea or the mechanism was the following. We had again these public transactions available in the mempool, and then we had individual searchers or wholesale order flow providers who were who had access to private order flow, and they would take their private

transactions to the validators. So, the validators had access both to public transactions, private transactions, internal transactions that they build themselves, and they would construct the block. So, that's basically the traditional ecosystem. And then there have been a lot of questions, a lot of discussions about, "Okay, this is really a very nice design. On the surface it looks like very well decentralized, but the question is it this is the system really decentralized?" If we look at the economic incentives behind uh construction of blocks. Are these incentives aligned really with the spirit of decentralization? And it And then we think about, okay, what's the compensation mechanism? When we have a system, we have to reward uh these validators for providing these services.

And traditionally, the remuneration system consists of two components. There is a fixed component, which is the which is in the form of newly minted tokens. So, as soon as you provide a service, uh I will give you, for example, new tokens uh in exchange for the service that you're providing. This is also what was happening with Bitcoin, what is still happening with Bitcoin, right? You get newly minted coins every time you mint a block. And then there is the more interesting component, at least from an economic perspective, which is the variable component, the component which depends really on the traffic that we see in the network, which is the so-called transaction fees. And these fees determined by like what transactions are selected and added into the block. What is the

sequence that uh is followed by the transactions that are appended into the block. And uh it depends on many many different factors, including the availability I mean, including the traffic or the congestion that we have in the network. Like, if we have a more congested system, then you have to pay more in order to get your transaction executed. So, the demand is higher, then it means that the fee the variable fee component goes up. And then precisely, this variability is also giving rise to the what is typically referred to as the maximal extractable value, which is I mean, economics is neither is nothing else than a form of rent extraction from validators. Uh so, validators are extracting this rent from other participants in the ecosystem. And these

participants are like could be users, it could be even arbitrageurs. Eventually, they all have to pay a fee to the validators if they want their transactions to be executed. So, the validators have basically complete monopoly over the block content. It's true that they compete according to some auction mechanism in order to decide who is the validator who is uh responsible for appending the block, but ultimately once they're selected for appending the block, they have complete monopoly on what to include into the block, what transactions to include, what orders to choose, uh and which transactions to potentially censor and not include into the block.

And because of that, uh this leads to problems uh including uh centralization, which means that uh validators who have a lot of access to order flow, those who have let's say better uh agreement maybe with order flow providers, so they are better at uh managing and processing the incoming public order flow, they will be able to construct more valuable blocks. As a result, they will increase their fee-based earnings, and uh they will basically end up monopolizing the system in the sense that the high percentage of the blocks will be constructed by these validators. So, now I discussed the standard uh tradi- uh validation system. Now, I want to

mention the so-called proposer-builder separation framework. How does it work? Uh what's the difference with respect to the original ecosystem? Like, as I mentioned, in the traditional world, validators are both proposing and constructing blocks. They bundle together these transactions, package them into a block, they send them through the network. PBS basically has been designed uh in part to solve the centralization problem that um we have observed in the traditional validation ecosystem. And one way to do that, or one the thought process was basically to separate the block production process into a more sophisticated process. So, it's not that validators have to do everything, construct the block, uh validate the block, and propose it, but

instead of doing that, let's like separate the process into three different tasks. Somehow, there are the searchers, the builders, and the proposers. So, the searchers are, in a way, order flow providers. They identify opportunities for um basically MEV extraction from the applications. For example, they could identify a good swap opportunities coming from a CEX DEX arbitrage. So, if there is a misalignment of prices between centralized exchange and decentralized exchange, they identify this transaction and they might send it.

Or, if they see an order which could be front-run, that's a front-running arbitrage opportunity, they identify it, and they they they they they might send this opportunity or this order to another party in the ecosystem which is the builder. So, the builder are basically collecting all these transactions from searchers. They could also construct some of these transactions They could also identify some of these opportunities themselves, but the basic idea is that the searchers are providing the services to the block builders. The block builders are taking out all these great great opportunities for extraction of, again, MEV, and they are adding them into blocks.

So, each builder is basically trying to construct a block which is as valuable as possible including all these arbitrage transactions, and then they will try to get their block executed or added to the chain. So, how do they do that? They have to send this block to the proposer, and the block proposer, basically speaking, is getting offers from all these builders. Each of them trying to have their block finally added to the chain, and then the proposers, typically, they will pick the most valuable block because that's the block that is paying the highest fee, and it will add this block to the chain.

Importantly, the builders have full visibility on the content of transactions. They can see exactly what type of transactions they are adding into their blocks, like whether or not they're arbitrage, front running, or payment transactions, and so on. But, the block proposers do not have visibility on the content of the block. They just get this block from the builders. They see what is the mean depending on how much uh the builder are bidding for the block, they will just take this block and execute it. And that will be shared. Okay, so that's the difference with respect to the previous process.

Now, the question that one should ask is, okay, given that we have this nice design, or it seems like a little bit even complicated at least I took me some time to understand how it it actually works, and I'm not sure that I still understand it completely. But, the basic idea is to see what whether or not there are some incentives which are still not perfectly aligned with what we would like to see, which means a very decentralized ecosystem. So, the builders are filling this block with valid transactions. Again, the role the the internal public and private transactions that I mentioned earlier.

Now, that's the job of the builders to identify them. Then, they are trying to bid in order to get their block executed. So, they are competing in an ascending bid bid first prize auction. And this auction will essentially determine how much the validators are getting if they include a block of this builder into the chain. So, they're basically bidding to get their transaction executed. And the proposers, again, they want to choose the highest bidding block. Uh the the block which bids the highest amount from the auction of these builders. If you want to visualize this in a figure, like compared to the figure that I showed before, now there is an intermediate layer coming from the builders. So, all

these public private internal transactions are essentially collected by the builders. The builders constitute a competitive market, so they are like there are plenty of them. Uh they are all trying to compete to construct valuable blocks. They compete in this auction, the winner of the auction gets the right to be validated and appended to the chain. What questions are we trying to answer in this paper? We're trying to understand, first of all, whether or not the proposer-builder separation framework is indeed achieving the intended objective of guaranteeing a very decentralized ecosystem.

And decentralized means at all layers. And also we want to understand whether like the system is more equitable in the sense that at all layers like validation, building, searchers, we can guarantee that there is some fairness in the process. Let me just mention what are the main findings before I go and develop the model to show how these findings arise. We're basically showing that the idea of guaranteeing more centralized ecosystem is less less centralized ecosystem is actually achieved in terms of the validation layer. So, indeed PBS is reducing centralization among validators.

And especially this is like even more prominently. So, if the builders constitute a very competitive market, if they're very good in order flow acquisition and they're very competitive, then this will actually be beneficial for the decentralization process in the in the blockchain. However, what is happening is that it's PBS is introducing centralization within the builder market. So, it's making the builder market more centralized. So, in a way it's it's decentralizing the validation process, but it's centralizing the building market process. And that's like what are really the main takeaways of this paper.

And that's what I want to show in the model. So, first I would like to I mean I think I have some I mean literally but like to mention some related literature. I think in general there has been some work on understanding whether or not blockchain is centralized or not, especially under the proof of work Bitcoin. Few people here have contributed this literature, including myself. Matthew also has a paper on that. Uh and there's been also some uh recent literature on the economics of PBS, so papers that have tried to document how the proposer-builder separation framework works. If you are interested, I think you can take a look at this paper and I think the list John et al. list should be 2024, not 2014, because there was no PBS in 2014, sorry.

And uh theory is like from Ethereum has also written a nice paper. I think these give a very complete overview. And there are also like papers that look at centralization, and here I want to be careful and actually position a little bit our paper with respect to these existing works. I think there is Malav has a paper, uh I think one of the first paper actually, on the topic. And uh the idea of the paper is uh essentially to show why I mean how centralization can arise in the builder market. I think your paper, if I understand correctly, is more focusing on like wow how integration between builders and searchers has the chance of uh increasing centralization because they will have higher probability of winning in this PBS auction, especially in volatile regimes where there is a lot of volatility. Uh I think in comparison to

this paper, we are more focusing on the builder and validation integration, so we are not really looking at searcher-builder integration. Uh and there is paper by Tim Rough and uh Maryam, uh which is also very closely related to I think your paper uh is focusing on the long-run dynamics. You're thinking more of an ecosystem where builders uh will get a chance to append the blocks, then they will get more share, so they might uh have higher chances of winning later. So the long-run dynamics is that you might end up with a very centralized uh ecosystem. And uh I think finding that uh essentially this result is really driven by heterogeneity in the block-building ability. If block builders have different skills in building blocks, then

uh this leads to more centralization. Whereas, uh if you have maybe less variance in terms of the block building skills, then you will see more decentralization. And I think you are basically focusing mostly on the builder market, right? There is no interaction between order flow providers and builders in this market. There's another paper also by Ambark and which is more empirical. They look at data from the network and they show that there is evidence of centralization, especially among builders and relays. Okay, so now let me describe the model.

So, what I'm going to do is setting up a benchmark model first, which is a very very simple trivial model of Ethereum without PBS, because then I want to compare it with the more interesting model, which is the PBS model, like when we have PBS. So, in the benchmark model, this is again without proposal builder separation. There are M validators. Each of them has a stake. This is exogenous. So, they are basically already they are they are endowed with a certain stake in the system. And the validator is picked by the protocol with a probability which is proportional to its stake. So, if validator has a larger stake, it will have a larger probability of being picked to validate the block.

The value that of the block that is validator are building is basically given by the order flow that is available to this validator, which is X. And only distinction between validators in terms of block building ability. So, how good they are in processing this order flow and building a valuable block. So, different validators might have different skills. We make the assumption that there is an economy of scale. So, if validators validators who have larger stakes, they also are better at building blocks. So, EI and EIB and SI are similarly ordered. So, a larger stake means higher building blocking ability. And then, if you compute the revenue of the validator, this is given

by the probability that they add the block, which is SI over S, times the expected value of the block value. So, how large is the value of the block? So, that's basically. And then, you can see immediately from this result that if you have a more valuable If you have a more uh skilled validator or a validator which has a larger stake, then it will tend to append more block, and by design this will lead to a more centralized ecosystem. Right? It's It's very obvious from just the the the definition. Yeah. What is V at this stage? I see. That's a good question.

So, why do I have the superscript V? Uh It means validator. Yeah, just because later on I will have the builders. So, I just want to distinguish the validator from the builders. That's why we have the superscript V. So, now let me describe the builder market model. So, in this builder market model, there are N builders. They are all characterized The distinction between this builder in terms of building ability, how good they are at building blocks, and uh how much accessibility they have with respect to order flow. And I will explain how this is captured in the model. So, the big building block ability is again captured by the parameter EI. So, that's basically the skills of the validators in processing this order flow.

And this order flow that they process uh in order to build a block consists of two component. One is a common value component X, and the other one is a private value component XI. So, X is the basically the value coming from public order flow. Again, public order flow transaction, and XI is the value coming from private order flow transactions. And then, they process them, and they build the block. So, now the extractable value for the private from the private order flow has this distribution. So, XI is equal to VI. It's It's bit like Bernoulli distribution where XI can take the value either zero or VI with probability 1 - PI, they are not able to extract any

value from the private order flow. With probability PI, they will extract value VI. So, they are able to extract private order flow. And this PI is essentially capturing the exclusive order flow acquisition and the internal searching ability they have. So, all the builders are starting with some access to exclusive order flow, which is denoted by PI zero. So, this means that they already have some Some builders already some private arrangements with Yeah, question. Why this uh Bernoulli variable? Why do I pick a Bernoulli variable and not a more You mean why not a general distribution or Yeah, in principle, I could do that. I

could take a more general distribution. Here, I just want to focus on this parameter PI, which is the probability of building blocks, and show that depending on how good how large is PI, then you will have more or less concentration. I just want to make things a bit easier. I could pick a distribution, but then I would have to maybe instead of saying that PI is capturing the exclusivity of access to order flow, I would have to basically have the distribution on VI capturing this exclusivity of the flow, and maybe I have to rely on some notion of stochastic dominance, for example. But, in principle, it could be me.

I just pick this for simplicity. I want to make the point in the simplest possible way following more an economic type of approach. Uh but, um in general, this can be generalized. It's not really a strong con- a strong constraint. Yeah. Thanks for Yeah. I would have thought PI * VI would have been sort of the relevant quantity here more than PI As far as I the ordering Okay, so it's like PI times VI. Um I mean, I have a big VI but a tiny PI then that doesn't seem Yeah, if you have a big VI but a tiny PI him then you will less you'll

essentially have a very very low block value coming from private order flow, right? The product matters. And the assumption I was sort of surprised that CV given that assumption at all. Yeah, just one point in because in the end what I will do I will maximize the expected value. So, this VI times PI will appear. If you take the expected value of the block, then it will be exactly PI times VI. Okay. Yeah, but it's a good question. These are just random variables for now. Yeah. So, PI is essen- is as I mentioned is um is given by the sum of these two components, the exclusive order flow access that you have like before uh any allocation from the searchers before any allocation from the from the order flow

providers. But then if you manage to get also the flow from the providers, you will increase your PI by an amount which is PI tilde I. So, PI tilde I is this endogenous order flow acquisition coming from your private agreements from from your ability to attract flow from the providers. But you have to basically convince the order flow providers to allocate order flow to you. And the assumption that we make here is that uh uh EI and PI zero are similar in the sense that if you have better building block abilities, then you are also probably more likely to get better access to order flow at least in the in the beginning. So, like the stronger builders are essentially those who have both higher initial value extraction probability but also strong builder

skill building skills. So, the way we model the builders is basically the following. They will have to acquire I mean, they want to extract MEV from the order flow provider. So, in order to convince the order flow provider to get order flow, they will have to offer some uh fee, some rebate to them. Um which basically yields a unit value increase in the value extraction probability. So, if you pay this order flow provider, you give them this rebate alpha I, they will give you more order flow, and this will increase your probability of extracting value from the block. The model is that uh again, we model block building competition as a first-price ascending auction, which would be equivalent to a second-price sealed-bid auction, like uh where value building is the the dominant

strategy, and uh the objective of the builder I is essentially to maximize its revenue, which comes from uh the expected value of the difference between the largest and the second largest bid. So, B with this parenthesis one means the highest bid. Uh these are the um the the order statistics, like of the bids. So, the gap between the first and second bid is exactly the revenue of the builder because he pays the second bid, uh but his block value is the is the is the one coming from the first bid. And of course, this will only be materialized if his bid is the largest, right? If BI is equal to the first order statistic, if he's the one who has bid the highest

value. And he has a cost coming from giving the rebate fee to the order flow provider, so which is alpha times beta delta I. So, that's the the rebate fee that needs to be paid to the order flow provider. So, he has to pick the he has to decide what rebate fee to offer in order to maximize this expected revenue. This is like what uh builders does. The order flow provider in turn needs to decide how much order flow he wants to allocate to the builders. Again, allocating order flow is valuable because it increases the value extraction probability of MEV for the for the builders from PI zero to PI zero plus beta delta I. So, he's increasing his order flow acquisition by this amount. And this I mean, this is the objective function of the order flow provider. So, here we have essentially

the first term is the sum of PI items plus ETA phi items phi tilde I. So, let me explain what this means. Essentially, PI is the probability that the block is included, the probability that the builder I is bidding the highest bid. And alpha I is the fee that will have to be that is that this order flow provider will receive from builder I. So, ETA is capturing the relative importance of the rebate fee compared to the block inclusion probability. So, if I'm an order flow providers, I want to give my order flow to a builder who gives me a highest rebate fee, but

I also care and maybe I care even more that my the builder that I'm selecting will end up being included, will be the one who gets the right to append the block, right? Because if I give my order flow to a builder who pay me a very high rebate fee, but this builder has very little chance to be included, then what's the point, right? I will I'm basically not not not maximizing my revenue. And I have to also want to take into consideration that I want to get to get some diversification among builders. So, that's why I have the term gamma, which is somewhat the risk aversion with respect to concentration.

So, I don't want to allocate my entire order flow to a single builder because then if this builder is not selected, I will get zero. So, that's why I have the sum of PI tilde I square. And then there is another term, which is the capacity concentration in the order flow generation. In the sense that me as an order flow provider, I have limited order flow, so I'm somewhat capacity constrained and I have to be careful in how I allocate this order flow, right? Because it's not that I am any limit it's not that I am an unlimited amount of order flow. I have somewhat a limited amount and therefore I'm somewhat adverse want to be careful about how I allocate it.

So, that's the I got in the other term. And this interplay between gamma and kappa is actually important because you want to both diversify your order flow location, but you also have to take into account that you have some capacity constraints. So, could you elaborate on the uh on the the last term? Like, where does the capacity constraint come from? Where this capacity constraint comes from? Yeah. It comes from the fact that you as an order flow provider, I mean, you are not able to generate an unlimited amount of the flow. You have some limited order flow. So, you have a scarce resource, and you have to decide where to allocate it. But but the model doesn't assume that allocating order flow to one builder prevents me from allocating the same order flow to

another. Yeah. It It does. I'm saying that uh yeah, if you are me, you you you you have order your order flow, you basically have to carefully decide where to allocate it. You cannot send it to So, I can't send duplicate transactions to different builders. That's an assumption. Okay. I mean, in practice, you you can, right? So, it's a How do you enforce this in practice? No, no, I'm saying in practice, you people do send duplicate transactions to different block builders. I'm saying this is a a quirk of the model that that you can't. Yeah, no, that's that's a model assumption. Yeah. Would it cause you a lot of trouble if you did? If I did that? If I would I I I you But I guess it would make your game harder to solve if the order flow provider was submitting

choosing how to send how much of their order flow to send like not just it it wasn't just an exclusive choice. Yeah, I could also choose to send some of my order flow, you know, I send my order flow to SCP, but I also send some along to Titan. The problem is I'm competing with myself then. Yeah. But Yeah. It's a choice I could make because if I have you know, random allocation, I still might want to do that. So, it would just make your model more complicated. I think you can do it. Yeah, that's a good point. So, you are thinking about uh having a somewhat mixed strategy where you you decide what is I'll send this order flow to multiple bidders some probability. Yeah.

That's a good point. Maybe I'll I'll look think about that. Yeah. So and while while we've stopped, could you explain why the exponents are there? I I just I've I missed Could you explain why? Why you have the the square? It's a good point. Uh yeah. To make Okay, it's concave I mean this would be Okay, this is essentially if you If you If you don't like this formula the objective you could say okay, I want to maximize only the first two terms subject to some constraint on the capacity. Right? And then if you relax this constraint on the capacity, you end up with this term kappa over two times the sum of the square. As Malash say, what matters is that the reality is concave.

So like it's a concave uh cost and uh I mean the simplest possible way of introducing concavity is a square. But in principle you could relax you could you could replace it with any concave function. But it comes likely I mean an alternative formulation would be subject to this constraint that the sum of the beta the I's would be equal to some constant. And then you relax the constraint, you end up with this term in the objective function. And that's uh it's a soft form of capacity constraint. You can have a you can have a hard constraint or you can have a soft constraint. This is a soft constraint. What should I think of as an order flow provider in this setting? Am I thinking just of like wallets or what am I think Yeah. Yeah, like wallets exactly that are providing order flow.

Yeah. Kind of like if we want to look at the subgame perfect equilibrium we want to solve for the equilibrium, it's a game which has two stages. So what do we do? The natural solution constant is the subgame perfect Nash equilibrium like two stages. Uh in the first stage the order flow providers uh I say in the first in the first stage the builders will decide uh how much rebate fee to offer to the order flow providers given that all the other builders are also optimally choosing their own allocation. So, that's why you have pi i alpha i star alpha minus i means all the rebate fee offered by the other builders except for i, they have to maximize their objective, and this isn't accounting or internalizing the fact that the order

flow providers will actually take this into account when they decide how much order flow to allocate to each builder. So, they will take into account how much rebate fee they are getting, but also, of course, what's the success probability of the builders. And the I now next step is basically to solve this game. So, we use backward induction, start from the second stage as usual, find the optimal allocation in terms of order the flow, and then we go to the first stage, which is determining what's the rebate fee that will be offered. So, that's what I want to do. I mean, first I want to go back quickly to the original model like without PBS, because again, I want to compare the two what with and without.

Without PBS, again, I mean, it's a very mechanical model. So, the returns per unit stake of validator is given by the profit of validator divided by its own stake, and we can show easily that the return per stake is increasing in the stake share. So, the larger will be the shares the stake share of the validator i, the larger will be the return per unit stake that it will get. And now, if we think along the lines of team uh Pronath and Marian model, and the stake is we don't do that, but if you think about reinvesting the stake over different periods, you will see that the larger validator will become fast will grow faster and faster compared to small validators, and you will end up with with centralization in in validation.

So, that's the idea. And if you want to guarantee decentralization, the only way is this they have the same block building ability. If they have same block building ability, then this will somewhat slow down the the centralization process. But if they have they have heterogeneity, like, for example, like in your paper, then this will end up with with a very centralized system. So, now I want to go to instead the model which is the PBS model, which is the most interesting part here. So, I'm focusing on what's the change in the builder success probability coming from order flow acquisition, right? So, what is how is this defined is is defined as the difference between the probability of

being successful in building the block for builder I if we take into account this order flow allocation from the providers given that the P D is equal to P D L star. So, P D L star is the optimal equilibrium allocation from all the providers minus the probability of being successful in building blocks if there is no order flow acquisition conditioning on P D L D equals to zero. So, essentially this gives what's the what's the what's the change in success probability of the builder if we take into account this allocation from the order flow providers, right?

And this theorem is basically showing precisely what happens and why we end up with centralization in building because if you look at the order flow the equilibrium order flow allocation is such that uh we have that P D L I is larger than P D L star J if P I zero is larger than P G P I zero is larger than P J zero. So, that means that if we have that the initial order flow acquisition of the builders I is larger than the initial order flow acquisition of builder J, then with the order flow allocation this difference this superiority in acquisition in acquisition of order flow will be preserved because P D L I is larger than P D L J star. And also if we look at the

success probability of the builder, again it's such that if you have an advantage initially, you will preserve your advantage. So, you will increase your success probability. So, in this basically is showing that there will be some degree of centralization and the idea is that if you have an initial advantage in parallel order flow, then it means that you will have a larger chance of uh acquiring more of the flow because your success probability once you acquire all the flow will go up. Right?

And as a result, if your success probability will go up, you will basically be selected more from order flow providers, right? Because your flow providers want to allocate order flow to builders which have high success probability. So, you will accept you will uh build more blocks. You will basically have more blocks that are validated and you will acquire even more order flow. So, there is this feedback effect which basically triggers uh builder centralization. So, it all stems from the fact that uh once you have initial advantage and you have access to your order flow market, you will increase your advantage even more.

And by increasing your advantage even more, you will attract more order flow and that will increase your advantage even further and so on. So, there will be eventually this um or this centralization in building. And it also points that basically what PBS is doing because of that is changing the ecosystem from uh a proof of work, which was the previous protocol, to a proof of MEV, right? If you have if you're stronger at MEV extraction, then you will basically get more order flow and therefore you will become even stronger.

So, they're essentially competing on who's stronger at MEV. If we really want to visualize this in a graph, that's basically what is going on, that if you have exclusive access to order flow, uh you will basically build more valuable block, you will be consistently out outbidding the other block builders, so that means that you will get even more order flow provided to you and so on. So, there is in a way the big get bigger phenomena that uh we're observing precisely coming from superiority in initial if you have higher skills at building blocks and you have a higher advantage initially, you will increase your advantage even more until centralizing the entire ecosystem. So here, what just a clarifying question, what do you mean by decentralization in

the dynamic system? Is it that if you have an advantage, you're going to have 100% or in the steady state you're just going to have a equilibrium distribution that will be convex in the initial advantage. You or you will have 100% of the whole market. Yeah, so in the paper we have basically a metric of centralization which is you can be look at the Herfindahl index. If you look at the Herfindahl index of the building the market share of the builders, you will see that it will be going up. Going up, exactly. But the reason why it goes up is because of this result that I've shown now. But it's not going to be a situation where someone owns the whole market.

No, that that's not me. It's just just show that it goes up. Okay. Be if there is a heterogeneity and the more heterogeneity there is, the higher it goes up. I think if you would do this dynamically, if you have like multiple periods and you're allowed to keep this process going further and further, eventually it could end up with a centralized ecosystem where there is just one builder. But in a static one period model, you can only make a point that it will go up. And when you say heterogeneity, are you referring to the fact that different builders have different order flow or you pointing to the internally generated order flow specifically?

Uh no, I'm referring to these two parameters that we have in the model, EI and PI0. So that means that they have different different building blocking abilities which is captured by this parameter EI, skills in processing order flow, and PI0 which is essentially initial access access to exclusive order flow. So if they are heterogeneous in these dimensions. They have different parameters. I think the endogenous flow is really important as well in practice, right? The endogenous flow, yeah. But the endogenous flow will be driven by this exogenous flow, right? The fact that if you are if I mean, that's what the result is showing that if you have an advantage in exclusive order flow acquisition

initially, you will increase your advantage even more. So, the gap between PI and PJ will be larger if PI0 is larger than PJ0. Yeah, that's that's true. Yeah. I have another question. So, just to clarify the the argument like as I understand it's from from the order flow originator's perspective, they basically only care about inclusion. Yeah, and and and the rebate fee that they get. Yeah. Then then how much they care more about one versus the other depends on this parameter the parameter eta that I have in the model. Yeah, this one.

So, they this are PI and plus eta phi this exactly balancing the the inclusion probability versus the rebate fee that they get. And does the Sorry, does the rebate depend on the competitiveness of the builder auction? The rebate alpha i Yeah. Yeah, the alpha i will depend on the Yeah, it will depend on the competitiveness of the builder market. Me, it will be an endogenous quantity which will depend on how many builders there are, how heterogeneous they are in the building and order acquisition abilities and so on.

Wait, so could you elaborate on on the connection? Yeah. So, the idea is that when we solve for the model, uh this alpha i which is the parameter of the order flow providers will be decided based on what is going to be the inclusion probability of the builders. So, if we have a more competitive builder market, then So, if So, if you have a more competitive builder market, then the builders will choose alpha i based on the accessibility based on how much of the flow they will be able to get from the order flow providers. So, if there is let's say only one or me, there is only one order flow providers and there is a very competitive builder market, then maybe the order flow provider will basically

be Sorry, there is a very monopolistic builder market, then they will give the entire flow to this builder, so they will get the rebate fee only from that builder. But, if there is a more competitive builder market, then the rebate fee will be lower. There's like two dynamics, right? Like one is if builders are more competitive competitive with each other, then they are like more commoditized and they all need the order flow more to differentiate themselves more. Yeah. Yeah. But, at the same time they can't like they don't have that much excess value to to bid up because if they bid up too much and they Yeah.

can't pull forward that value to the in the block auction to the proposer. Are are both of those dynamics captured in this in this model? Okay, so one dynamic One is the diversification dynamic, the fact that you want to diversify your order flow among different builders. Yeah. That's one and then and this is more prominently so if you have more heterogeneous a more homogeneous builder market. So, that's one of the dynamics that you mentioned. And what was the other one? No, I so I'm saying from the Yeah. Like this the amount in which a order flow originator gets rebated will depend on I mean, I guess in practice will depend on the degree to which builders are competing with each other for that order

flow, but also the excess value available to the to the block builder. Like if the block builder thinks, I only have, you know, epsilon value to rebate to this guy uh because it's a very competitive market, then they I guess they can't rebate too much. Oh, yeah. I um I guess I can speak to you about this afterwards. Yeah, maybe we can discuss me. Probably means more solid than think it I don't know if this is accounted for what you're saying, but let's discuss uh I think I just I missed something in the model. That's all, yeah. whether or not we should be concerned about centralization in building. We had a discussion with Malice yesterday. I can be the first post of Vitalik was that uh he's not too concerned about centralization in builder as long as there is decentralization in validation.

Uh but of course uh there are also a lot of problems for builder centralization, censorship, preferential treatment uh of use means some provide with the flow provider searches and then others uh maximization of MEV. Me, I think there is also a discussion, okay, how can we actually solve this problem? I mean, there are inclusion list. Well, that's one possi- potential solution, but I think going back to what Malice was saying, it's more treating the symptoms rather than fixing the root cause of the problem. Flashbots, I think has also introduced uh the Suave uh mechanism, which seems to be along the direction of reducing a little bit the problem of building builder centralization. Maybe Quintus can de- definitely say more about it, but let's move on to the next uh slides.

Want to make the final point about, okay, how about decentralization in validation? So far I made the point that there is centralization in building, but can we claim that the system of validation becomes more decentralized? And here I'm thinking, okay, let's look at this uh difference in revenue of validators. So V, again, the sub- subscript distance for validator, that's the difference with the revenue of validator I and the revenue of validator J. This is given but this is the revenue per you- per share, like divided by S, which is the total share of the total uh stake in the system.

This is the difference between the expected profit of validator I minus the expected profit of validator J. So the profit of validator I is basically the expected value of the maximum within the built that the validator I will make and the second highest bid. Because again, if you have a block which is more valuable than the one uh proposed by the builder and the builder will pay the second highest bid, then you will essentially uh take I mean propose your own block, otherwise you will take the block that was proposed by the builder. What we can see here is that if a validator has a largest uh bid the difference between RI and RJ is uh so which is the gap in the revenue of validator I and validator J is decreasing in the block building

ability and the in the initial order acquisition probability. So if you have let's say more and more if you have a more competitive builder market, which means that uh the order acquisition probability and builder the building skills of the builders will be larger, then this will reduce the difference in revenue of two validators. Right? If a more provision builder market is making the revenue of these validators closer and closer to each other, w- how? Because of course if the builders are becoming more competitive, they will construct more valuable block, they will bid a larger value, so the second highest bid will be larger. So that means that in this expected value the difference the expected value of the max minus expected value of the max the max will always be B2 and if the max

is B2, which is the second highest bid, then the difference will be zero. So in a very, very competitive builder market where builders are super sophisticated, super good at acquiring order flow, they will basically make the difference between two revenue of two validator revenue equals to zero. So that basically makes the point that this problem of centralization of validation is being alleviated by a very competitive builder market. Finally, I want to mention a few words about integration of builder and validators. So what incentives do validators have for building? There are two incentives. First, they can enhance the value of their own block, so if these validators are also builders, they can construct more valuable block. Second, they if they become builders, they can also offer this service to other validators, like because now instead of building the

block I mean instead of validating the block, they can also build and deliver this block to other validators. In equilibrium, one could show the following. So, this is an approximate result. It only holds in the regime where gamma, which is the aversion with respect to order flow concentration, is large. So, if we have very large aversion with respect to if we want to diversify more because we are very averse to concentration, then if we, let's say, look at the equilibrium order flow allocation and we look at the leading order term in expansion in the gamma, you will see that the first order is of this form, which is very interpretable because it is basically of the form except for the probability of the builder AI times the expected value of his own block plus the probability that

this builder is not take a validator is not, sorry taken. And in that case, it's which happens probably the one minus SI over S. And in this case, they get a benefit from building for others. Right? Because if they mean they can either get benefit from being selected and not build their own block. If they're not selected, then they are basically acting as builders and they will make their block available to others. So, this value of this order flow allocation is increasing in the validator's stake and share stake share. So, a validator which has a larger share in the system will also have a larger equilibrium order flow which is allocated to him. In in what sense like do they want to be builders? I think

it's instructive to look at this quantity, which is the expected revenue change of a validator from becoming a builder. So, if we think about, okay, if the validator were to become a builder, what's his expected change in revenue? And there are again two components. The first component is coming from the fact that these validators is selected to build a block. In this case, he will have to compete only with second largest bid, right? Because if he's selected, then he has to decide, okay, where should I propose my own block or should I take the block proposed by the winning builder? And the winning builder builder is paying the second highest bid. So, the difference BIB minus bid two is essentially how much additional revenue

would have if he's acting as a builder. With probability 1 minus SI over S, this validator is not selected to build the next block. In this case, it will have basically to compete as a builder in the builder market because he's a builder, but he's a builder validator. And in this case, he will have to outbid the highest builder, right? So, he will have basically to to get a block which is more valuable than the one proposed by the highest bidder. So, that's basically the expected revenue change. And what you can see is that if you have a larger bid one and bid two, then that means that the validators are extracting enough rent from the

competing builder market. So, if you have a large bid, both for um I mean, both the the highest and the second highest bidders are bidding high, then this difference would be small, right? Because you have BIB minus bid two and BIB minus bid one. If bid one and bid two are very large, then this will might end up being zero, right? Or might being might end up being very low. So, that means that validators in this case are extracting enough rent from the competing builder market. It's a very competitive market. So, there are very weak incentives to become builders. Why should I become a builder if I'm extracting a lot of rent from the fact that these builders are competing very

harshly among each other. On the other hand, if we have a weaker weaker builder market, which means that uh bid one and bid two are small, right? There is not really a large for example or maybe it would be a very So, we have in the extreme case of a competitive uh sorry, a very monopolistic builder market with only two builders, say have duopoly, and where they the the value that they're building is building is low, then it's you get a lot of revenue change from becoming a builder. Because in this case, the difference between VIV and VIV 2 and VIV 1 will be large. So, that means that you gain from becoming a builder, which means weak builder market are markets where validators wants to become builders. So,

bottom line of this side is that validators have an incentive to become builder if the market of builders is not competitive. Otherwise, they want to just function as validators. Their profit will also be larger again. When the formalizing this into a corollary, we see that profit of the validator is increasing from becoming a builder. And it's basically this profit increase is higher if we have if we have less builders, so if n is small, or if we have let's say less building skills, if b is small. So, this brings me to the end.

The main point of this work was to show us the impact of PBS on centralization. I think the takeaway like of this paper is that PBS is reducing centralization in validation, but might create centralization in building because of this disproof of MEV competition, the fact that they are these builders are able to attract order flow uh from like order flow providers, and they become even stronger, and as a result, they will basically tend to monopolize the market. Whether or not builders want to be validators depends on how competitive builder market is. A very uncompetitive builder market gives more incentive for validators to jump in and be builders. But, if it's already very competitive, maybe it's better for them

to just extract rent, just extract value from this competitive builder market without becoming validators. Two points that I want to make for further development. First, I think it's a fix that probably one has to do to the model. I think nobody asked this question, but I briefly discussed it yesterday with my lecture. So, I had some discussion with Jason uh that there is somewhat an assumption that I'm making that this building block is given by a common value component X and the private value component XI. So, the common value component X is known to everybody, right? But, the XI, which is the private value component, is only known to be known to builder I. So, now if I mean, I said that basically this ascending price auction is equivalent to a second price auction where truthful

value bidding is the dominant strategy. I mean, this is not strictly speaking true because there is also a public component, right? It's not really that the XIs are independent. BIs are dependent because they all have this common component X. And uh I mean, I think Jason team and uh uh I think Siamak, right? They have a paper on the Myerson uh approach uh to the MM where you rely on the single crossing assumption. Uh and I think team has also a lot some other papers without single crossing assumption. I think if I want to make this formal, I I think this is the opposite way. Okay, sorry. Yeah.

Yeah, you're right. I I messed it up. Yeah so I think the paper with uh the recent paper of uh team Jason and Siamak is without a single crossing assumption, but the one with team and uh Tal game coin is with a single crossing assumption. I think I have to find a way to incorporate some of these results in this paper if I want to make the inter-dependent value auction reasonable or I have to get rid of the common component of X. We'll see what what is best to do. And I mean, in that in general, I think other directions one could think of is looking at what happens if you have like I mean, this is what we want to do next is think about a dynamic model where you have new builders jumping in and operating maybe initially operating at a loss, subsidizing low value blocks

in order to attract more market share, and then become more competitive. So, let's see that creates a very interesting dynamics. Or they go along the direction of sitting what happens in this model if you have integration between order flow providers and which in a way they act as searchers in the model with builders in addition to integrating builders with validators. So that's what would would go along the lines of the work by Max and Malesh like where you have integration between builder and search sorry builder and searcher. So here I only have builders and validators. Maybe see what happens if you have full integration of full vertical integration.

Or like looking at potentially like how this problem of centralization gets worse if you have cross chain MEV. So in this case there is only one chain MEV but presumably these builders might operate across different chains. So these problems of centralization can become even worse. Or like what happens if they get access to multiple blocks like instead of a single instead of constructing only a single block. So this multi-block MEV might make the dynamics even worse. Yeah. So so my first question was going to be on the dynamics which some of your results are about centers. So one way to do this would be to introduce that there is a probability of a new builder entrant that has a um like a skill to build that is random. So there you know they

can be better than the previous one the larger ones. So then the distribution will not be degenerate toward just the very the earlier one. Mhm. Uh capturing the whole market. So from there then you can study what these policies that you mentioned or something for example to understand is whether the the staking rewards rule does it affect the centralization of builders in this context. For example we know that it does affect the centralization of just validators without proposal builder separation.

Um Yeah. Because without that we cannot save any positive like what are what are sort of solution when it goes to 100% ownership. On the ownership, yeah. Yeah, I think I agree. The maybe one good first step would be just for us to say that you have an incumbent with the incumbent market of builders and then there is uh a new entrant who is potentially new builder. Yeah. And then uh what would happen of exit. There you know, this it's a a kind of a static problem. It's a dynamic versus static problem.

Essentially how to Yeah. You But basically whether or not the entrance of a new builder will lead to more decentralization in the builder market because it will take some of the market share from the other builders or instead it will create even more concentration. Yeah. That's Yeah. That that would be good. Yeah, I I would have to think how to But that seems to be more feasible compared to a fully dynamic model. I think with the case of the centralization of validators there is just a hope or appeal once we get to 33% uh and then yeah, what can be done? Do you have a sense just what can be done to avoid centralization of

builders as a what are instruments even that Ethereum can consider? Yeah, that's a good question. I think we were discussing with Quintus right before the presentation. I mean I think what one potential I mean I don't have a solution. I mean I don't know, right? That's the answer. But I'm thinking if I I have to conjecture for example, modifying the auction mechanism perhaps like making sure that uh they don't have access for example I mean what we discussed with Windows is few if you constrain builders from uh having access to the entire of the flow instead of giving them full visibility, you hide some of the content so that they are not able to extract uh in full the MEV. This goes into

direction of like reducing a little bit of centralization because they will have less content or less information to construct blocks. And this prevent presumably should go into direction of reducing uh the MEV extraction. And if you reduce the MEV extraction, then you also reduce centralization because you construct less valuable blocks. And you attract less order flow from the providers. That's uh I mean that I mean that that seems to me a plausible solution, right? Uh I mean the other Yeah, the other Yes, potential solution I mean for example like

the the inclusion lists like you you make sure that you can only include maybe a sum. You have to guarantee that only you cannot include uh only transaction from a single builder, but there must be like transactions or blocks proposed by other builders who presumably are paying even if they are paying less in terms of the bids to the validators. The It's a good question. I mean in fact I think this paper has identifies a problem, but it doesn't propose a solution. I think the the solution is exactly what to do to reduce centralization in in uh in builders.

I mean I think my but no no no, I'm just All I'm saying is the problem as you correctly point out with like multi-block MEV the centralization of builders is really really really bad. Yeah, because you can do all sorts of stuff if you're if you know you're with 80% probability going to be the winner of the next block as well. You just keep all the trades out and arb them in the next block or uh you know, get Thanks to Jason, We know you can now you effectively double block times and can help yourself to like eight times the LVR. So, lots of fun stuff you can do. We had this sort of semi proposal to like split up the block and sell it separately. Mhm. So,

it's like sell top of block. It reduces it in in the context of his model, you can think of it as reducing the complementarities or, you know, between my own order flow and other people's order flow that I can search on. So, if you sell the sex decks out separately from the bottom of block stuff, then the fact that I'm an SCP means I don't have the incentive to go search, you know, I I don't have either the incentive or the marginal value. I can just run my trading shop on the top of block and other people can compete for the bottom of block stuff like that.

That was our idea, but it's technically difficult but from simple versions. Sorry. Yeah, I just I don't mean to hog the talk. Yeah. I wanted to ask a question about um this endogenous searching capability. In your model you had that as part of the private order flow um of a builder. My intuition is that mostly this endogenous searching that happens um you know, if you have an integrated um searcher builder, basically that is kind of like a common um common component. So, it would be better integrated to possibly like X instead of each individual um person. Because right now these are like these capabilities are usually overlapping among almost all of the builders and maybe some of the are

at a disadvantage if they are um solo and they're not um integrated or run by by huge searchers, basically. So, I'm just wondering how how does like the endogenous searching capability affect the results and and why you think you thought that um putting it as part of the private order flow is the kind of best modeling assumption to have. I think I mean I think you have you have valid point. I think the reason why we put it in the XI component is because we wanted to relate it to to this PI. So that PI is basically what is differentiating uh builders from each other.

Uh because X is somewhat known common to everybody. But in principle, I think if we move the PI instead of modeling XI in this way, we would model X plus XI in this way or just X in this way. Uh I don't think it will change drastically the conclusion. Like I think there will be still uh differentiation between the builders coming from the initial exclusive order flow acquisition. So that So in a way we have PI is only PI zero and then that PI tilde I will impact the X.

My guess, but I have to verify is that one would still end up with uh the the conclusion that if you have a larger exclusive order flow acquisition in the beginning, you will basically increase your advantage even more uh in terms of ac- attracting new order flow. Uh the the only thing question that I'm thinking is that if you model if you add the PI tilde I to X, how would you interpret this as like uh better ability to process order flow? Because this order flow is public. X right? It's public order flow. So now if you have better better access to order flow, that does it mean that

uh you are able to better process the order flow? Because we all see the same order flow, right? Now if some of us are better than others, it be it be the the service that the order flow providers this this order flow providers are basically helping us to better process this public order flow. Is this what you had in mind that these are order flow providers are helping to process the public order flow? I think the key example that I have in mind is for example the uh like the example of the sex decks arbitrage. This to to a large extent is mostly common among all of the builders, but maybe there is a tiny component that some builder has a tiny latency advantage compared to the so the largest component is part of um capital X. Basically,

that's common to everybody. Anybody can capture it, but yes, you do internalize it um as your own builder because you're you're running it in an integrated fashion. Um but then you have a tiny advantage on top, but this is tiny compared to the entire value that you'll obtain from from this arb roughly. Yeah, and this comes from uh order from order flow providers uh or mhm s- searchers like those who I mean, I would have to get an advantage that means somebody In this model, this PI is basically coming from order flow providers allocating order flow.

In I mean, under the interpretation, it would be more yourself, right? It's not order flow providers, but you have Yes. Yes. a better advantage. common value. It's common to everybody. And perhaps I think what you're saying, if that's I mean, if one models that, maybe without your order flow allocation, I just model X as uh different from builder to builders, this might actually make this auction easier to analyze because then there is no common value. I mean, there is a there is a common value component, but it's multiplied by some parameter which is independent across different builders. So, it's somewhat making the variable P tilde I X more independent, like That's it. From my understanding, the

capacity constraints and the concentration Yeah. I don't know anti-concentration preference. I I I can't remember what it was called. Feel like If if those we didn't have those in the model, which I think is you can argue is the case in practice, do Do you think that that's like significantly changes the results? Because it it feels because in practice you can send transactions to duplicate transactions, duplicate flow to multiple block builders, and we don't see people with preferences to avoid concentration. If anything they

favor concentration or they spread their flow just to make sure they get inclusion. So, if we took those terms away, would you think that would change the result significantly? Okay, so you're saying taking away both the the adverse adverse aversion with respect to concentration and with respect to capacity constraint. Right? Then you have basically that these are completely risk neutral, right? They just want to maximize their expected revenue. I mean, I think what would happen is that you might end up with some kind of extreme Yeah, it depends also on what you do. If you enlarge the action space where you allow order flow provider to send the same

order flow to multiple builders, as you're saying, that might be that the similar results would be One might be able to recover similar results. The issue is that then you would have also to model the fact that if you send order flow to multiple builders, there might be some information leakage, right? Because I mean, you in principle you don't want to I mean, or in principle you want maybe some builders to have only access to some part of the flow rather than others to avoid that some information is being leaked. Yeah, your rebate would certainly be be smaller. The rebate will be smaller, exactly. Yeah, just just because in practice when you speak to these order flow providers, traders, whatever, They all They usually think about things

in terms of like inclusion versus like execution quality trade-off. Yeah. And if you have sufficient uncertainty as to who's going to build the block, Yeah. the that that sort of trade-off ends up pushing you just to sending your flow everywhere and favoring inclusion. Yeah. Yeah. Which which could lead to a a different result than what you're pointing to. Yeah, no, definitely because if you have I mean, if you remove the adversity with respect to concentration, then uh maybe the centralization result would be less prominent right?

I mean, that's a That's a good valid point. I should think about that. Thank you.