Why Only 3 Builders Control All of Ethereum

Transcript

Welcome to epicenter the show which talks about the technologies projects and people driving decentralization in the blockchain revolution. I'm ants and today I'm speaking with Kubi Mensah who is the CEO and co-founder of Gatka. Gatka builds the Titan builder. >> A lot of the edge that you actually get as a trading firm comes from understanding how things work under the hood. So then we had to really go deep into the EVM, the P2P layer, how nodes work, how consensus work and all of that. that actually unleashed even more fascination around like oh this is actually how this all gets put together and how it all works. It took us a little bit of time to get full conviction in terms of the sustainability or the business

durability of that venture. But once we did that we basically burned our boats. We stopped all trading activities and we went full on into block building and yeah I guess the the rest is really history. Thank you so much for coming on. >> Hey, good to be here. >> Cool. Um maybe give us a little bit of backstory because uh kind of Gataka and Titan are very much projects that don't dominate um the discourse a lot. So kind of kind of people who are deep in the stack, they know who you are. Um but maybe talk about kind of how Gatka got started and um how Titan emerged and and so on.

>> Yeah, sounds good. So, Gatka has been in the space for a while and we have our origins in um trading actually. So, we started off as a proprietary trading firm initially on centralized exchanges. So, this was in the early days when it wasn't as competitive and you know the professional uh traders from you know try hasn't move uh or hadn't at least moved in at scale yet. um they were there to some degree. And then we um moved some of our resources from proprietary trading on centralized exchanges such as market making just the standard stuff, arbitrage, liquidity provisioning and moved some of those resources on chain when we started seeing more activity on um decentralized

exchanges. And the thinking basically was hey you know um the market structure might be a little bit different in crypto and centralized exchanges but it's still very close to the traditional system. So most people will probably just be able to move over their playbook and then just dominate and so probably not an ecosystem where we would have sustainable modes. But then when you look at decentralized exchanges um that was just like a new world that had never existed before. So there was both the sort of strategic reasoning of okay this is actually something new and novel that hasn't existed before. So being one of the early adopters um or firms to move into the space can give you an edge but also just bit of a fascination around

the technology and what was possible. And then over time we basically shifted more and more resources fully on chain versus central exchanges. And a lot of the edge that you actually get as a trading firm uh comes from understanding how things work under the hood. So then we had to really go deep into the EVM um like the P2P layer, how nodes work, how consensus work and all of that. That actually unleashed even more fascination around like oh this is actually how this all gets put together and how it all works. there was almost a little bit of an element of FOMO so to speak that we were participants outside of like the the cool stuff that is actually being built and almost this new industry and

we weren't actually part of that. We are just sort of on the sidelines um sort of trading on the layer but not actually being part of the layer itself. Then I remember a few months ahead of the merge and um there was 2022 and um I think it was me day or something and PBS was discussed and the role of the block builder. I think that was the first time where we were aware of oh there's a potential for this new infrastructure player that's actually going to be part of the underlying fabric of this ecosystem but at the same time also recognizing that a lot of the things that we are good at or the capabilities that we sort of build up in house by becoming competitive traders

were very much applicable to this uh problem set but it's not just purely an optimization problem there's also this the service layer to it and so I I think um that made it really really interesting. And so when the merge happened and obviously PBS and the block building market emerged from there um it took us a little bit of time to get full conviction in terms of the sustainability or the business durability of that venture. But once we did that we basically burned our boats. We stopped all trading activities and we went full on into block building. And yeah I guess the the rest is really history. Block buildings changed a lot since you guys started. So kind of

it it kind of it used to be a fairly niche thing and now it's extremely competitive and kind of it's it's just become professionalized. Maybe talk about kind of how I mean it's been what four years or something. It's not been all that long. Um so te tell me about how block building has changed from your vantage point. >> Yes. So I would say four years in crypto is actually really long. [laughter] So um there's that and I think the as with any other markets you over time you know the market matures and the participants mature. I think not just block building itself but just crypto as an industry has also matured a lot and

so the sophistication of um on the professionalism of the entities um that are in crypto um as we just actually discussed before getting on um is um increasing. So I think that applies I think also to the broader industry. But then block building specifically is also very competitive uh in its nature. And so if you put those two things together then you have this natural acceleration of like what is required to be the best um at this game. And so I think what has changed is basically on on one side the just from a pure tech technical perspective the capabilities needed and

the type of infrastructure the performance the latency the uptimes the the consistency of processing transaction in different markets scenarios um all of that the bar has just gotten a lot higher and the expectations from let's say block space consumers so anyone who actually sends a transactions transaction and wants that to be executed on chain the requirements depending on the use case have also gone up and so I think that put together has just increased the bar so much and yeah that's the the state of the world and happy to go into some more specifics um of course this episode's brought to you by Lido as Ethereum staking continues to evolve more teams building staking products are running into a familiar

challenge on one hand poolled liquid staking gives you liquidity and access to DeFi but can limit customization And on the other, bespoke staking setups offer more control over things like pricing, performance, and operator selection, but they often come with added complexity and less flexibility. Lido V3 is changing that with SD vaults. SD Vaults is modular staking infrastructure. It lets builders and institutions deploy custom staking vaults tailored to their specific needs. At the same time, they're staying connected to SDH as a shared liquidity layer powering Ethereum's broader DeFi ecosystem. If you're just looking for a place to generate yield on your idle assets, Lido Earn makes it super simple.

It offers curated DeFi strategies built around SD. You deposit once, you choose a vault and manage everything from a single interface. To learn more and start building with SD vaults, go to lido.fi/stvtts and get in touch with lighter contributors today. Is Kataka today just a block builder or do you have other parts um that kind of other projects that you're working on? >> Yeah. Um so that's a good question. So I think our mental model of how we think about block building has evolved a bit. It used to be hey this pure function that you plug into an existing protocol.

There's an existing market structure. It's permissionless. So you know anyone can come in. There's a set of transactions in the mele. If you build a better block with these transactions, um then you win as a builder and you get a bit of a margin depending on what the delta between you and the second best builder is. The mental model of thinking about a block builder has changed quite a bit. And with that also um the scope of what we do at Gatka and so there's just the pure block building business which from our perspective is just something like optimal allocation of block space, right? But we have also expanded a little bit further across the supply chain. So for example, we operate um me boost relay which is basically how validators connect to this out of

protocol block construction market. The way to think about it is basically where price discovery for the wholesale block space happens. M >> um and then on the other side we also have something um that falls into the category of an offa order or an orderflow auction platform which serves both as a sort of privacy preserving endpoint to send transactions so you don't go to the public meleool but also um a service where um if you leak any MV the MEV gets rebaited back to the users or the originators. It is it's also now a venue where you optimize for how much gas you actually pay because it's quite difficult to actually price how much your transactions are paying. So um we've basically taken a more holistic

approach where we we see all of this together almost like as a bit of a platform where uh from one side of you have a on one side you have the blockspace consumers and different categories of users that all have their use cases and they want to consume block space and on the other side you have um the validator. sort the core protocol that basically produces raw block space and we are building sort of the platform in between to optimally allocate and sort of serve both sides to refine this raw commodity into some higher value good and on the other side basically give the best services to the consumers >> and yeah >> that makes a lot of sense. So basically it's just kind of like uh block builder adjacent services on either end that

kind of you offer. In addition um maybe let's um deep dive dive into block building itself. So kind of I think a lot of people even technical people in this space um have a very naive view of kind of how blocks are actually built right kind of like they think kind of like you you send a transaction to the memp pool and then kind of uh the validator um who uh whose slot it is kind of picks it up um and kind of uh send builds the block right and in principle kind of like blocks can be built like that. So kind of like it's not completely false, but kind of like there's there's a lot of nuance missing in kind of why the process of block building and proposing has kind of been divvied up between different parties. Um

and then secondly also kind of the role of the mempool and kind of how um orders transactions actually get to the block builder because last time I checked um only about half of uh the transactions that later get included are actually go through the public meool and everything else is public flow and that's by number of transactions by by kind of transaction value. It's it's more than half. So kind of they they never actually see the light of the meool. um because obviously kind of you make yourself extremely vulnerable to kind of leaking value there. Maybe give us your um take of how block building actually works for someone explain explain for

someone who kind of who knows how Ethereum works but who's never really thought about how the block building works kind of on a construction level. >> Yeah. Um so I guess the way to think about it is uh think about it like a journey of the transaction. So you know you have the originator and then the intent is for that transaction to be actually included on chain right in the final block. And then there's a lot of infrastructure and piping in between that um in order to facilitate this. And um as you said before um even if you think about the public me there isn't really such a thing as you know one pool where everything is publicly but you know it's a it's a network of nodes and each node has a local view of

transactions that they are seeing and they're sharing that with each other right so even uh if you just from a block builder perspective getting access to public meo transactions is not just hey you know I run one node locally and then I just subscribe to some websocket but It's it's operating multiple nodes globally across the world making sure that they are peered with the right peers in the network to make sure the connectivity is high and then from each of those sort of funnel uh transactions to local builder instances. So that's connectivity to uh the public mele. At the same time, there are also some thirdparty providers that have some optimizations and latency um advantages rather than just running nodes directly

if you don't want to spend too much resources. So that's also out there and it's also good to have that as a failover. So that's the public me side of things. Um and then there's this other less transparent I guess uh part of the ecosystem which is a private me a category of um players that aggregate transactions privately. So you have RPC endpoints for example that are offered by certain RPC providers that connect directly to block builders and just fan them out. There are um orderflow auction platforms like I mentioned previously and you have things like math blocker for example right or blink or flash protect and a bunch of other services right and similarly we also have an

orderflow auction platform and basically it's an endpoint where then you send your transaction to and it doesn't just forward it directly to builders so that um your data doesn't get leaked but it actually um looks at what your transaction is doing. Let's say you are doing a swap and if that that swap would cause an arbitrage opportunity, it will also um auction that transaction off to traders to compete for the right to correct that arbitrage and then bid a lot of the value back to the um originator who actually caused that transaction. There's also a gas optimization component because um it's actually quite hard to price exactly how much priority fees you need to pay in order to be included in a block. And so

um the these um OFAS so to speak often have a view not just of um what current gas prices are but also a local view of what the demand for block space is and so basically try to give more precise recommendations on how much fees you should be paying. So all of that sort of gets you know bundled together as one service and then those transactions either individually or with um some parameter around how much of the priority feeders that are being paid uh to the builder should actually be used to include the transaction and how much should be um paid back to the user for example. Or they might show up as bundles where the transaction plus the

the trade that then captures the arbitrage after it. Or some orderflow auction platforms actually combine multiple transactions into one bundle because then combine transaction pay more fees actually have an influence where these transactions will be placed in a block. So they don't just send transactions individually. And so there all these like techniques and optimizations that then completely gets abstracted away from users but overall tend to give the user just better execution um than if you send to the public meool or even just directly via a private mele service. All of this then ends up on the builder level. Often you have also very sophisticated other parties. So these are the more um large scale consumers of blockspace and a big

example would be the um C5 defi arbitrage traders right so they basically look at prices offchain and then what the local prices let's say within Ethereum are and if whether there's a discrepancy then um they'll basically hit the order book on one side or um the AMM on the other side. trading firms generate quite a lot of transaction volume and so they have very very specific um needs when it comes to the execution of those transactions. For example, um they would try to minimize as much as possible around the time when the transaction gets submitted to the builder closest to the end of the auction window. And for example, on

Ethereum, it's 12 seconds, right? which is like a lot of time. But then they would want to wait ideally till the last nancond possible before submitting their transaction because that means they have the latest information from the outside world where information is continuous. Often these um traders also touch their top of the block, right? Which means that if you include one of their transaction, you still you can't just add it to the end of the block and you're done with the block and set it off. you basically have now have to construct the rest of the block based on that transaction that just tried to get in in the last like microcond, right?

Then you potentially have other sort of um categories of players like for example Telegram bots that was like a a big category of consumers of block space um at least last year for example where they have sometimes these bundles of hundreds of transactions right that target a specific pool. they have requirements around like how those transactions or that big bundle gets included and so on and so forth, right? And so then it's basically the job of a block builder now to cater to all these different consumers of block space uh all of their needs and execute optimally optimally and the better you are in aggregate across all these different services um the better you are as a

block builder and the higher value blocks you can build which then and effect means there's more effective consumption of block space you generate more rewards for the proposer but also there's more on the table for the block builder to potentially also keep as revenue because their revenue is dependent on basically the delta between what you build versus the second best builder. >> Okay, there was a lot to unpack there. So, kind of um maybe let's go back to kind of the different kinds of transactions that you get. So, kind of you you get kind of the public transactions from the meool, then you get the private uh transactions from the private mess and kind of the the bundles. you also, I assume, get um order flow from from intentbased dabs on on top of that, right? So, kind of

that's probably also quite a chunk. Maybe we can talk about this after, but then kind of tell tell me about so I understand why someone who does deck sex arbitrage why they want to sit um at the top of the block uh because kind of they want to act on the state that they know is the current state, right? So, kind of this is kind of they don't want their state messed up. Their entire thing is kind of like they want to know the exact state they're acting upon. Um so how do they make it worth your while to kind of um for them to become top of block? Because you said kind of like okay they kind of they will send at the last millisecond and then kind of like we we need to reconstruct the block. You're not doing this out of the goodness of

your heart because you feel for the the arbitrage, right? How do the economics of that work? Mhm. So um the economics is uh a function basically of trying to collect as many fees as possible expressed either directly as priority fees or direct builder payments. And builder payments are basically just transfers to the Coinbase which is an EOA that's set for a specific block. And so the totality of priority fees plus Coinbase payments gives you the overall block reward. And that's the thing that ultimately determines whether you first of all win the auction and also how much revenue you make as a builder. And in a broader sense, the way to think about it

as well as what a builder is essentially facilitating, it's basically optimally auctioning off specific states, right? >> So now we we talk about top of block um but potentially you could auction off that piece of state also later in the block if no one else gets to touch it. So it doesn't necessarily have to be the first transaction, right? And so the incentive here is basically from the originator. If you want access to a specific piece of state, whoever pays the most gets access, right? So there's this latency component and we are incentivized to invest into building this very latency sensitive infrastructure because that allows the traders to basically bid more in terms

of the overall block value which then unlocks more value overall and um allows us to win the auction uh when it comes to the wholesale of block space. >> Okay, I understand. Um, so basically the block kind of now has a price attached to it, but kind of the the person who actually builds the block is the validator, right? So kind of that that money goes to the validator and they pay you on the delta of kind of between this next best bit or how does it work? >> Yeah. Okay, that's a good question. So the mechanics actually work. So the validator no longer builds the block at all. The validator just propose the block. So um in PBS proposal builder separation, the validator is basically

just the proposer. So how it works is that the block builder sets the Coinbase address to a wallet that they control. Then they collect all the fees and then once the block is constructed, they add a payment at the end of the block that basically transfers some value from the Coinbase to the proposes fee recipient. And this is basically what is uh classed as the bid, right? So the proposals or the relays on behalf of the proposers will look at the blocks being submitted and we'll just check how much is the proposal being paid and then just pick the block which pays the proposal the most. But naturally the more you collect

in fees and the better you sequence that leads to you being able to pay the proposal more. And then there's is also a little bit of a game to try and understand how much do you need to pay the proposal to win the auction but still leave a bit of a margin in order to make some revenue yourself. And so basically the full block is constructed by the builder. The builder decides how much to pay the proposer. The relay selects the block that pays the proposer the most. And um the proposer basically just signs off on that block the relay has picked for um the proposer and then the block gets propagated to the network. Is there any optionality on the side of the validators? So can I as a validator say look I really don't like

this guy Kooby. I just don't I don't want any Titan build blocks. So kind of give me whatever was next best. >> So currently most relays don't have any sort of filtering logic other than um the OFAC SDN list. some some relays actually look at that list and if there there's a block that includes over transactions they'll not serve it to specific proposals and the proposers can basically specify that when they register with a relay that I only want to accept uh those kind of blocks now in theory you could try to as a proposer filter for let's say I only want you know quazar blocks or I only want titan blocks or only want build and that's definitely possible but in general just

not incentive compatible >> there's a lot of builders around but kind of not a lot of builders actually build the majority of blocks right so kind of if you look at the stats kind of 90 plus% of blocks are built by Titan plus Beaver plus plus flashbots right those are currently the biggest three why is there only the small handful of competitive builders >> yeah so actually currently the so we are the currently largest the second largest is build it so by flashbots um and then the third is a builder called quazar and so inaugurate I think they have like 15 to 20%. Flash Bros has like 20 to 30 and we have like something around 50 usually. The key reason is that there's a bit of a flywheel effect to block

construction and also the incentives um and I'll double click on that. So let's start with the incentives and I'll give a simple example. So let's say just to oversimplify things, there was a single transaction in the me pool for a given slot and that was the only transaction on Ethereum that's willing to pay to get included. And let's say that transaction pays one ETH. If that transaction went to let's say two builders, now two builders will have exactly one ETH of priority fees and now they're competing in an auction to win. And so the outcome will probably be that 90 plus or 100% of that value would just be paid to the proposer. But from a originator's

perspective or block space consumer's perspective, you would want to pay as little as possible, right? which is sort of this fundamental tension between like the producers of block space and the consumers that producers want to, you know, get as much as possible for their block space that they're selling and the consumers want to pay as little because the consumers want to pay as little. It is in their incentives to not send transactions that pay a lot of priority fees to all the builders, right? Because if you send let's say to all the builders then every builder will have the exact same amount of priority fee and then 100% of it will be paid. But um if you send that transaction to a single build then now the the builder can sort of try to keep as much of that as

possible and then refund a bunch of that back to the user so that the effective price that the user is paying is actually lower than the initial sort of one ETH in that example. And so I think that is crux of it and this realization was actually made by the old um the first block builders that were also sex stacks trading firms. Um so there was Viva build um and there was arsync which were which are both like large trading firms. They were at the time the largest block builders and a lot of the edge came from the fact that they were creating all this in-house valuable order flow that was paying a lot of priority fees. But they realized if they send those transactions to everyone then all those priority fees would be bit

away. And so if they just kept it to their own builder um they could optimize on those fees, right? And so that was sort of the starting point where different uh players in the industry realized that okay us included obviously um especially because we didn't have any internal order flow. So we purely came in this from the perspective of being a service provider. So okay what service can we provide to other originators that don't have a block builder itself? Can we do that on their behalf? And so that's sort of created this game where like the better you are at block building and targeting specific users for specific services, the more they will use your builder over someone else, which meant

then that you have more priority fees, which then meant you can refund them more, which then but also has this flywheel effect of um basically um you know competing um lots and lots of builders out of the market. And this refund, is this something that is contractually kind of specified or is this kind of a handshake kind of agreement? >> Yeah, I mean some of it is um via just APIs and you can set sort of refund percentages and stuff like that. Um some of it is also a bit bespoke um where it's if you have like one or two players across like an category, it often doesn't make sense to like spend the resource to build like a fullyfledged system that's then fully permissionless.

But yes, um so it's basically a mix of those. >> Do you give traders access to your block before you post it? Because I would imagine that kind of like if I wear market maker obviously um kind of being the maker um is typically a lot more expensive than being the taker. So kind of you you have to make sure kind of your orders don't go stale. Basically you the prices don't move under you. Um so kind of if you give me your block and kind of that you've constructed and you tell me okay this is the block I've constructed is there anywhere you kind of want to insert an order here it's possible that I might want to do that right so kind of do I mean you do that yourself I assume but kind of do you

also give third parties the same the same opportunity I mean obviously not anyone but kind of like you also accept bundles from other searchers right despite the fact that you can also search yourself. >> That is actually something we feel very strong about and till date we have not given any external party access to private state and that is just because of the guarantees we give to all of our originators and it can just be that there might be some trading firm that has some niche strategy, right? But then you know there's the more sophisticated trading firm and now it looks into the block and sees what someone else is doing and there's all this like conflict of interest and potential um use cases that arrive that might be adversarial to

the other side or more serving the customer base more holistically. So it's something we absolutely don't do. What we have done um we have done a little bit of an experiment with flashbots where we basically streamed our state into a TE that was locked down and um the TE was configured such that the only data that was leaving the TE was a bundle that is sent back only to our endpoint. So that was like end to end under control. So under these conditions, we were comfortable sharing that data within this trusted execution environment that was written like you know within a cloud and we knew no one else had access and we knew the only data that was leaking out of this was a bundler sent back to our builder and then we also decide where to place this

bundle so we can make sure that no one could actually create front running bundles and anything that might be again adversarial but other than that we um we don't give access to um anyone else and I guess the other clarification I should make as well I often didn't talk about market makers and that's just because the competitive sex traders are all market makers as well because in order to be competitive you kind of have to have a really good global view of fair market prices which means that it's not just you know looking at Binance mids but maybe you have some OTC flow and you know you're looking at lots of other different sources so you need to have this global view and then whenever you see that let's say some unis swap pools out of whack you you hit it there and

skew a quote there so generally Generally people that are competitive at this are also market makers but they actually don't actively u move quotes on chain. So they they take on chain and but are generally also market makers. Um that being said there's a bit of an initiative on Ethereum right now to actually enable faster updates of being able to quote liquidity on chain. Um so that's something exciting that's in the works. um which I'm actually quite excited about u because I think that's going to just make Ethereum more competitive as an ecosystem for actually uh interacting and trading on chain but um yeah other than that which is not live yet the active liquidity

provisioning is um not as active because currently it's just too expensive to do >> and which EIP kind of is the um the improvement for the intrablock um quoting >> oh so that's actually not an EIP um And the V0 is also um not something that would happen intrablock. I think intrablock anything that happens interblock should almost be viewed as a based rollup that's synchronously composable or some sort of comp synchronous composability layer that can basically advance state um while and then when the 12 seconds slot time ends then settle uh to Ethereum. But um what we are enabling now is basically just

making sure that if you have let's say something like a prop amm on Ethereum which is like your contract you have priority ordering when it comes to feeding an oracle update into your smart contract before someone can actually take liquidity which just makes sure that you know you you are prevented from toxic takers um which then should obviously result in tighter spreads and then that's just net beneficial for everyone. >> Okay. So basically you allow kind of the originator of a smart contract to act on the state of the cosmart contract first before kind of anyone else is allowed to. Is that is that correct?

>> Yes. Correct. It's basically akin to the broader ACE or application controlled execution sort of um you know strategy where you give apps more fine granular control of how their transactions get executed. >> Okay. if you now kind of look at your average block. So I mean there's obviously also kind of a lot of really vanilla transactions, right? Kind of like um if you kind of had to classify kind of the block in terms of what it contains. Um how much of it would you say is just kind of like vanilla transactions that kind of like you don't actually make a lot on? What's the distribution of revenue for you? So kind of I assume you get most revenue from just a couple of orders per block. Is that correct?

>> Yes. So I would say overall um the it's quite spiky. So the priority fee based um like transactions that actually are contentious or contending for specific states. So I don't have a specific stat in mind but it's definitely skewed to especially if you look at like the really really big um blocks or the the is is very similar to volatility usually have like these big volatility events right that happen and then there's a lot of activity on chain and you know everything is full gas prices are out of whack right which is then where a lot of value h um gets passed through um and then you have just normal conditions which are a lot more mellow. Um, that being said, they're still, at least if

priority fees are at least a little bit high enough, um, even with transfers and sort of non-contentious transactions, there's still a lot that can be done by optimizing for latency, getting transactions in quick towards the end of the slots, by um, making sure that you you have the right connectivity across the globe, across different sources and stuff. So there's the sort of contentious auctioning off and handling that really well during spiky situations. But as long as there is some priority fee attached to it, there's still lots of optimizations that are not just ordering based um that also affect the overall block value.

>> Can you give me an idea of kind of optimizations that kind of can still um affect the value? >> Yeah. So I I would say a very simple example would be like a latency based use case. So let's say towards the end of the slots if you because transactions come in continuously as well. It's not like they only come in at a chunk of time and then they stop right um towards the end of the slots if let's say you know the proposer is in let's say northeast Virginia where you know a lot of the US based validators are um there's a transaction that originated from Tokyo right that's maybe just a transfer but it's urgent so it's paying a little bit more priority fees if you manage to get a transaction to your builder that is in North Virginia

quicker and have enough sophistication to incorporate it into the block usually probably easier because it's at the end of the block because it's non contentious. Um, but just as a simple example, if you will then have more priority fees that another builder who is not as fast has and then that again leads to a higher block and more revenue potential. >> Okay. So, if I were to become a builder, what I've kind of like now learned from the conversation is kind of what's important is kind of I need reliable physical infrastructure that kind of gets me the order flow reliably and in a timely manner. Um then kind of I need private order flow because I assume that's also where a lot of the meat is on the bone, right? Kind of I need and there kind of I need to be kind of a

trusted party in the sense that kind of people are actually willing to share their private order flow with me. Um then I assume kind of I also need to be very good at simulating outcome, right? because kind of like obviously if you have um a thousand transactions in a block there's um a thousand factorial ways of kind of >> placing it right place ordering them so kind of like you have some huristics kind of like which which um generally can can go in the back and then kind of I assume but I assume there's a lot of simulation going on and then kind of the fourth one I heard is is latency being able to send the block at the last possible millisecond how would you rank them kind of in importance.

>> Yeah, that's a difficult one. So I would say if you don't have any transactions then obviously there's nothing to optimize, right? So you need to have a set of transaction that is significant enough and as you said correctly there's there are the transactions that are just available to everyone in the public mele and there are the private sources for the private sources you now need to go to like these RPC providers and like these orderflow auction platforms and you basically need to demonstrate that you're not going to do anything nefarious right if you are running it in a sort of trust decentralized setup there's also an alternative something like builderet right where you do a block build at and um then people can verify the code that you're actually running and so then it probably will be

much easier if you're just up and coming to get that order flow but at the same time you're making a trade-off because now you're running a TE which means you're very constrained in sort of like compute capacity uh in terms of like what data centers you can provide your um deploy your um your infrastructure in and also in terms of your alpha because if you need to actually show what you're running that means like you know all the proprietary juicy stuff is probably not something you can put in there. So there are some constraints on on that at least depending on the setup. So there's the trusted part and so getting the order flow and so I would say overall there's sort of a minimum hurdle of transactions that you need to see in order to be competitive and then it really depends

on the market sentiment as well. So for example, if it's there's a lot of volatility on centralized exchanges and the price are moving all the time during those market regimens, you you need like those like big CFI defy trading firms, right? Um then during when it's more quiet and there's not a lot of activity, then it doesn't matter as much, right? So I think the key is probably just in any other market when you're starting off, you want to find like one niche that you're good at and sort of make sure it works well. And that also gives you some time in the market and establish yourself and so on and so forth and then expand to broader sources of order flow. Going back to your original question, if you don't have the order flow, there's obviously nothing to

build with, but then you also don't need to have all the order flow. So just being a little bit more strategic in trying to find some sources of transactions that you can get access to and then really make sure you start optimizing the rest from there. And then in in terms of optimizing latency versus um your local simulation and um your ordering algorithms and their huristics. Um again this all depends. you can sort of choose your specialtity first and then optimize for one sort of regiment which is then for the use cases that are very latency sensitive then you build better blocks than others for example right and so in general it's just like these are all sources of alpha so to

speak and so the more alpha you can stack the more competitive like it makes you and as in any industry my recommendation is always you know find your thing that you can specialize on and that you can do really really Well, and then if you're really good at that thing, try to expand from there versus trying to be the best at everything because that's just very hard. >> Yeah, I think that's generally a very good recommendation kind of like being the best at everything. It's something I constantly fail at. So, it's uh um [laughter] >> um tell me about your relationship with um the searchers. So, kind of the searches are basically parties that send bundles to you um that then may or may not be included in the block. Um how is that relationship rooted? So, kind of is

it rooted in trust or kind of do we have some sort of contractual agreement? How does the searcher know you didn't already have this bundle, right? Because kind of like I I could just submit trivial bundles and then be outraged about the fact that you're not paying me for them. How does it work? >> Yeah. So, I would say overall um the way we approach it is it's a a category of customers, right? And then the question is what are they optimizing for and how can you serve them best? And then in terms of how you actually maintain this relationship, you have different categories of players as well within let's say the broader searcher category and you have like smaller sort of unknown teams that maybe are just on the

discord and telegram and some of those guys like we've never seen before like we have a discord so anyone could just DM us ask us some questions ask for some debugging or whatever it is some relationships are just of that matter uh of that nature and there are some that are wellestablished players like some of the brands that like you know most people in the space already know and they'll just straight go to us and say hey can you give us this feature and like with any other product if a customer asks for a feature you build it and then you have a better service and you know it's win-win for everyone um I think even though crypto overall is maturing in the industry is maturing the number of players that actually want like formal contracts and so on and so

forth um is very small but that still does exist to a degree. But then given that the block builder itself is also permissionless and sort of anyone can use it and you know all all of those things taken into account that it's sort of like a big mix of you know this this cryptonative like permissionless sort of okay you just sent something to an endpoint to hey I have a very specific requirement and maybe can you give me some uptime guarantees and so on and so forth. I mean, it's also very much a repeat game, right? So, kind of like if I if I'm a searcher and kind of like I send my bundle to various block builders and kind of one of them never pays me

despite the fact that they may include my bundle, I just stop sending them bundles right? >> Yeah. I mean, in terms of payments, um, so often it it just works permissionlessly, right? Because like there's something that gets paid to the Coinbase and then there's like fixed refunds or like something you can specify on how it should be sent back. But then there's also this idea of batched payments which is we can because every transfer on a per block basis obviously consumes base fees. So that's basically then eats into like how much you can get paid back. So there's this idea so you can batch payments together and say basically after one week of aggregating these payments just send it at once and of course if for whatever reason after a week or whatever period a

day you the originator chose and you didn't make the payment then obviously yeah they will no longer be working with you. >> Cool. So you already said that kind of you also search. How much of the bundles that you include kind of do you create yourself and how much is that parties? >> So um as I said before when we launched the builder we actually stopped all trading activities. So we do zero bundle origination. We haven't since >> 2022 basically. >> Okay. So so the answer is kind of like it's kind of it's just uh Okay.

Okay. >> It's just um because of the conflict of interest and so that we we believe strongly long-term that's just not incentive compatible. >> Okay. What do you think about kind of a role convergence or some sort sort of vertical integration between builder and validator because kind of like that would make a lot of sense too, right? >> Mhm. The broader idea of PBS which was meant to give everyone access to competitive blocks, right? And so that prevents basically this centralization force being exerted onto the broader validator set which is what keeps the proto or the the entities that actually vote on the validity of blocks and do

the attestations. That's the core protocol itself and that needs to be maxally decentralized. So from that perspective um PBS had been quite successful. Now given that PBS already exists, if a builder was to integrate with a validator and that actually has happened and some are somewhat open about it, some are not, I don't see as much as a of a concern anymore because everyone still has access to these competitive blocks, right? And so unless this really gives you like a big big edge that no one else has, overall, I don't think is as much of a risk anymore. Now, if that this market structure didn't exist and only some had access to these very very

competitive blocks and some didn't, imagine this having vanilla local blocks or like me woo woo style blocks. Obviously, you know, that would be really really centralizing. So, >> if it happens now, I I I see it as way less of a concern. >> Okay. Um, what about kind of being a builder and and a solver at the same time? So kind of for intent based protocols kind of obviously it also makes a lot of sense kind of to not just send this as orderflow but to kind of um because you're leaking leaking value on the server side right >> mhm yeah that's a great question so it's something we have actually also thought about quite a bit. I think the edge as a builder really is that you can find the optimal solution at the time of execution versus just top of block while

because there's solvers that currently operate via lots of other like cow swap for example you you operate on the state of the world that's based the on the end of the the last block that was mind right but then just as we discussed before the top of the block oven is very caviar then you know taken by others that means now the prices have changed and so the route is no longer optimal. So we have been thinking about how to best reconcile that because ideally we don't want to get into solving business because solving itself like being up to date with all the liquidity pools potentially having internal liquidity and offering that via like some or versus passive AMMs that starts to then become more of a trading firm. But um so

what we're currently exploring is basically if there's a way we can give either something like um offchain sort of execution parked within the builder. So if you can give us some sort of logic that we can u park and have executed as part of the block construction process. So when we are evaluating your bundle, we won't just evaluate it as is, but we evaluate it by taking that off-chain sort of component into account, which raises some potential proprietary binary questions from the solvers. There's also this potential TE approach, but that has a lot of latency overhead, which is a problem. And something else we're also exploring is basically the solution

being submitted to us as the sort of um the floor and then basically giving us almost like um >> kind of like an intentbased kind of it's it's it's kind of like intent inception. So kind of [laughter] >> correct. Okay. >> Yes. Exactly. And then being able to then sift through potential other other solutions that we might swap that original solution out for. but only if it improves the price, you know. So those can all be sort of hybrid solutions. And the question is, can we make this as efficient as if we actually had a solver running on stage? And it might not be like 100% the same efficiency, but even if we can get up to 90 plus%, that should be good enough.

Um, so uh we haven't settled on a specific approach, but we're actively exploring that. And that's super interesting, I think, in terms of again improving prices for everyone and making Ethereum more competitive. >> Yeah, 100%. Cool. So if you now kind of zoom out and look at the larger Ethereum road map. So kind of there's a couple of things that are very relevant to you guys looming on the horizon. So there's enshrined proposability separation, there's inclusion lists and kind of there's still talk of pre-confirmations. What do you make of those and what are you looking forward to? >> I would say looking forward to all of them. [laughter] >> Now there are some nuances in terms of um the implementation detail. So um what are the design specifics and how are

these being rolled out? I guess the first one you mentioned was EPBS. >> Yeah. So the exciting part about EPBS is actually formally enshrining this market structure that currently is all like out of protocol in the core protocol which means and specifically with it the fair exchange pro part right so the fair exchange problem is the part where you have let's say in a two-sided market um especially if it's permissionless and not trusted someone has this digital goods and in this case it's the block if the builder were to just give it to a proposal proposer could just you take all the value and not pay the builder anything. And if the builder were just to give them the bid without actually proving that they have the block, then they could just lie about it. And with

EPBS, you basically solve this fair exchange problem through trustless payments. So that's exciting. So the idea that a bunch of this um centralized infrastructure now has like an in protocol fallback path for whatever reasons liveness robustness um if something fails then the entire pipeline just doesn't degrade and everything reverts back to the public mele which will be like the dark ages right I guess the trade-off here is though the complexity of the specific implementation how it's being done and then the the other question is in terms of priority there's so many things that we have to do as Ethereum like what's what are we prioritizing um all of this aside I think you know it's gone through

the process and you know it's beenified and so it's coming in the next hardwork so overall I have always been excited about EPBS um there are some nuances around this specific implementation detail but I think the fact that Ethereum as a core protocol actually can handle this uh market structure which has existed for 4 years and is obviously doing the majority of the heavy lifting now as part of the blockers construction process. It absolutely makes sense that it it there's an improtocol path for it. Talking about Fossil. So excited about the part that the core protocol itself has a say on how a block should be constructed and that it like really strengthens the censorship resistance guarantee because you no longer have one

monopoly that decides the entirety of the block. the fundamental incentives which are like okay um if you don't build a more more valuable block your block doesn't win but there are all these like side effects of holistically as as a protocol what is Ethereum trying to offer as a service and is it always incentive compatible all the time and so with Fossil the that's quite interesting because you you start having multi-party block construction as part of the core protocol where the core protocol feeds into the block construction process itself, but the heavy lifting of like simulating everything fast and all of that stuff can still be outsourced. So, it's sort of the best of both worlds.

There is some push back here for especially from node operators or stakers that run in certain jurisdiction where certain transactions are not allowed to be led into the block. And so there's a bit of a tension between hey as a neutral infrastructure layer here Ethereum obviously needs to support like nonsensorship right but then there also these specific parties that are in specific jurisdictions and what does that mean for operators like that if now they have to process their transaction right so >> it also gives you an element of defense right so if you have to do it if your hands are bound it's kind of like this entire um legal argument about billing

being not willfully but actually blind and kind of like you're the pipes you can't see it you can't you can't do anything against transactions they're just forced down your throat in some sense and I think actually kind of I think it actually bolsters the legal defense of uh validators and block builders no >> I I agree um but then always depends on the sensibility of the regulator right some might just go all overboard and be like okay fine you can't participate then right which also would uh not be great but yes um I agree. >> Okay. Um so how do you see block building change over the next year? So it's been around for three and a half four years. Um let's give it another three and a half four years. What do you think changes and do you think who

captures the value will change? >> So the ch we've already enumerated some of the changes right. So um just being part of the poor pro core protocol or EPBS itself just changes the market structure a little bit. Nothing fundamentally changes but um there are some nuances and some technical details here. Um with Fossil now you actually start having more constraints. So today you already have constraints when you're building a block as a builder. So for example a bundle is a constraint. You can't just include these transactions anyhow. they have to be in this order and they can't revert for example, right? And there are a bunch of other like softer constraints. Um and so now the constraint of hey this is a transaction that you absolutely have to include, right? Then you can go even

further which is also the the other thing that we haven't talked about pre-confirmations for example, right? Which is someone issuing the the execution or inclusion of a transaction ahead of time that forms yet another constraint on the block. So I think it's going to become more more complex from that perspective. There's going to be more inputs uh that you have to take into account when when having running these block construction processes. But um it is all basically just evolving to a market structure where you and even with ACE right that's another constraint right where now the application also has a specific requirement on how like a transaction gets sequenced and how it gets how the block essentially then gets constructed with that. We're basically

just incorporating more and more use cases of different players in the ecosystem and that all feed into the block construction process and that's just understandable because the block construction process is just so fundamental to the core protocol itself. So I think it all makes sense, >> but it's also mostly on the vanilla side, right? So kind of like if you kind of look at kind of like the vanilla transactions and the non vanilla transactions kind of for instance fossil um this only applies to transactions in the me. So kind of it's it's just kind of like a set of uh it's just a committee of random validators that's that say oh I've seen these list of 20 transactions. So kind of like you you need to make sure that they are included in the next block. But if they've been in the meool, probably not um not the

most contentious transactions, right? That that siphon of value elsewhere. Um and and equally kind of on the Oracle updating. Yeah, maybe a little bit there, but kind of it's not the super meaty part of the order flow, right? >> Yes, that's correct. Um the more meaty part of the order flow would be things like preconfirmation, especially execution preconfirmation, right? where especially when you think about things like um swaps or other kinds of things that then affect state contentious, right? And so um then being able to price what is access to that state worth ahead of time and being able to like you know um then make these constraints

correctly such that the yield for the validator is not impacted negatively and other kinds of things. Um that's uh that's going to be a very interesting problem. Do you think um kind of I mean you you already said that kind of like there's more constraints coming for for block builders. Do you think um the dynamic of power is going to shift kind of like either to or away from the block builder? >> That's a good question. I think fundamentally both the proposer and the originators have power although the proposer is on a per slot basis clearly they're monopolist and the originators need to band together to get more power right because there's basically this world where proposer can say hey if

you're not paying me enough as a transaction originator I'm just going to not include your transaction well until fossil at least um right and so then force You can always think about a proposer setting some sort of reserve price almost right. Um so because they have that monolistic monopolistic power but then on the originator side the more originators band together in aggregation the fees are higher the more power they have to say like hey look there's this total pie that we together will pay you and so almost a little bit like a union like if you if you want all of it then we we are not going to give you that much and you rather take some of it than nothing kind of thing and so what what

does that mean in the long term as there are more constraints and so on and so forth I think the block builder has always been in a little bit of a mediator in the middle and always like kind of playing this dance like most marketplaces are and so I think that's just going to continue and then I think generally depending on what the market structure does and so on and so forth as long as none of the sites go too much out of whack um it's going to you know this dance is going to keep happening otherwise maybe something more drastic. Cool. Kobe, this was super interesting. If uh people want to learn more about uh Gatka or block building, where can you send them?

>> We don't have that much educational materials yet. Although um we have u with a bunch of other teams um in the space started to work on this initiative called the Blockspace forum. And so if you go to blockspace.forum forum um we've started to work on just some very very high level um educational material on like the state of the pipeline and what block block builders and all other kinds of actors do. So that probably would be a good place to check it out. >> Cool. [music] Fantastic. Thank you so much. >> Yeah.