On The Brink with Castle Island - Robert Miller (Flashbots) on Decentralizing Block Building with SUAVE (EP.378)

Episode Date: December 5, 2022

In this episode, Ria is joined by Robert Miller, Steward at Flashbots, which is a research and development organization with the aim to reduce the negative externalities and risks posed by MEV, or maximal extractable value. We cover: The MEV supply chain and how it's evolved as Ethereum transitioned from Proof of Work to Proof of Stake The new challenges and risk vectors that have emerged as a result of the transition, notably around decentralization and censorship resistance The tools Flashbots has proposed and implemented in response, such as Flashbots Auction, MEV Geth, MEV Boost, and the open sourcing of these tools to foster a competitive market The risk posed by exclusive order flow and cross domain MEV in centralizing block building The latest endeavor of the organization to decentralize block building using a new network - SUAVE (the single unifying auction for value expression) Research mentioned:  Order flow, auctions and centralisation - Quintus  Flashbots – The Good, Bad and the Ugly of MEV

Hey everyone, welcome back to On the Brink. This is Ria from Castle Island Ventures. In this episode, I had the chance to chat with Robert Miller, who is a steward at FlashBots, to illuminate the dark forest created by MEV or a maximal extractable value. We talk about the MEV supply chain and how it's evolved post-merge on Ethereum. We cover new challenges and risk vectors that have emerged as a result of the transition. and take an in-depth look at these solutions that FlashBots has proposed and implemented at each stage, including the Flashbox auction, MEPGET, MEP Boost, the open sourcing of FlashB's Relay and Builder, and more.

In the second part of the show, Robert Sheds Light on FlashBot's latest and most ambitious endeavor, arguably, which is to decentralized block building and addressed one of address one of the most significant threats to censorship resistance, starting with Ethereum, via what they're calling suave, or the single unifying auction for value expression. So with that, I'll turn it over to my conversation with Robert. Welcome to another episode of On the Brink. I'm Ria, and I'm joined today by Robert Miller from FlashBots, which is an organization which aims to reduce the negative externalities and risks posed by MEV.

Thrill to have you on the show, Robert. Before we get into it, tell us a little bit about you. How did you become such an integral voice on the conversation around MEV? And how did that ultimately lead you to flashbots? Thank you so much for having me. Really excited for the conversation. I'm excited to hear your questions about suave and the work that we're doing. I am a steward at FlashBots and I lead our products.

How I became an integral voice. I don't know if I would characterize it that way, but I appreciate it. I think I've always tinkered with things on chain and really been interested in what kind of activity was happening on chain. This naturally led to MEV in 2019, 2020 kind of era right around the time that Flashwats was getting started and started contributing to their open-source codebases as soon as those were available

and joined the team right away. And people know me because I was posting all sorts of the weird things that I was following on chain and kind of tales from the Mempool and MEPV, shining a light on the dark forest before it became widely known. I'm still doing that today, sharing all sorts of interesting anecdotes on chain,

as well as trying to advocate for, you know, open, permissionless decentralized MEP marketplaces. Yeah. So I think that's a little bit about me, how I got involved and how I'm a part of the conversation. So to briefly establish a baseline for listeners, what is the dark forest? What is MEP? And then why is this question around whether MEP is good or bad, more nuanced than is typically portrayed.

Yeah, so the Dark Forest is this meme that came out of a blog post by Dan Robinson and Georgios from Paradigm a few years ago. And at the time, there was a user who had, I think, about $10,000 stuck in a uniswap pool. And Dan Robinson, as one does, was running support in the uninswap discord. while this user popped in and kind of let everyone know their issue. And Dan realized that actually this money was recoverable, but the twist was it was recoverable by anyone in the world that would just call a certain function on the uniswap pool.

And the problem with this was that there was theorized to be these predatory bots that were watching the mempool for transactions which people would make, which would gain them money, And the predatory bot could then copy what other people were doing and front run them by paying a higher gas price to land that transaction instead of the original user. And so while Dan could help this person recover their money, he realized that if he did so, he would reveal the existence of his money that could be recovered and thus get it stolen away from him by these generalized front running bots, which at the time people weren't sure, existed or not, but it just kind of theorized the existence of. And the TLDR is Dan and Giorgio's had tried to throw this bot off by doing things in a more

complicated way, and they were unable to, and a generalized front-running bot actually stole the money from them and identified the transaction. And so the Dark Forest is this idea from the three-body problem or work of fiction that there is a space where merely revealing information gets you totally obliterated. And it's supposed to describe how the Ethereum Mempool is an adversarial place where there are bots that are watching and trying to make money out of the transactions that you reveal into the public Mempool in any way that they can. So that's kind of where the Dark Forest meme comes from.

It's an interesting story. And we can talk more about Mempool stuff if you want. MEV or maximum extractable value, it refers to this more broad concept of the value that you can extract from transaction ordering. It was originally minor extractable value, so the value that a minor can make from transaction ordering within a block. And that includes inserting transactions, reordering them, or censoring transactions too. I think MEV is not necessarily good or bad. We should seek to minimize it, but it's just a fact of public blockchains. And it's a fact of these open, permissionless financial systems that we are trying to create.

So if we want to create a decentralized financial system, you need to incentivize people to take actions within them, jobs to be done, like moving prices on pools to be in line with market prices, or removing bad debt from lending markets or moving a game forward in a round. And since we want these systems to be open for anyone and to not have any privileged actors inside of them, the way that you get people to take these actions is by providing permissionless bribes that anyone can access.

In Dex's, this is arbitrage profit. it's like taking a piece of collateral in lending markets. And since this permissionless bribe exists and there is value to be made from extracting it, then MEV exists. And how exactly that MEV gets distributed is a result of transaction ordering policies on chains. And we have to contend with this fact somehow. And FlashBots is kind of about the study of the effect of these permissionless bribes on consensus and on users in the broader network health and trying to make it as user aligned as possible.

So MEP is not good or bad. It's a fact of life and we have to deal with it. So can you walk us through, you know, pre-merge in Proof-Work Ethereum, how different stakeholders were impacted by the existence of MEP? and maybe more specifically, what was the MEV supply or value chain pre-merge in Ethereum proof of work? Yeah. So I'll start at the beginning of the FlashBot's days. So when in early 2020, FlashBots noticed proprietary trading deals that were happening between trading firms and miners that were vertically integrating to give, you know,

prioritized access to some privileged players over transaction ordering to over others, as well as an increased amount of activity by these priority gas auction bots, who were bots that would try to one-up each other in the public amendment pool and pay higher transaction fees in order to capture MEV. In a response, we created the FlashBots auction, which is this side channel. that miners could opt into, whereby searchers or arbitrage jurors would bid bundles that had specific ordering of transactions to off-chain, and an auction would be run off-chain to decide the ordering of transactions within a block, and only the winners of an auction would be included on-chain instead of priority-guess auctions, which would have a ton of failed bids landing on chain from, you know, these bots in the MMP pool trying to one up each other constantly. And all those failed bids caused a network condition because it would use up a bunch

of block space that ultimately didn't do anything. It's not going to a productive end. So it just reduces the supply and makes everyone else's block space more expensive to use. And it moved all of this, it moved all of this behavior that was otherwise happening in the public MN pool. into this channeled private auction and freed up more space in the overall network and helped optimize the networking layer as well. This was the Flashpot auction, this kind of priority side channel that searchers could bid in for an off-chain auction where only the winners were included on-chain, reduced overall gas injection.

We also were able to take these kind of proprietary. deals that are happening in a high touch with trading firms and open it up into an open information list marketplace whereby any searcher could bid for inclusion through the flashbots auction and have access to 95% at the peak of the network's hash rate instead of only you know one trading firm having access to hash rate and on the other end this kept the network more open and democratic because any minor or you know most miners at the time could have access to the most profitable block instead of the miners that had relationships with trading firms or the social reputation in order to get those as well.

Can I pause you for a sec? Yes. I guess what incentivized those different participants, both minors and trading firms, to use this more democratic marketplace or auction mechanism? So if you were a searcher, previously you were competing in the mempool, and really the dimensions of competition was your view of the network. You had to have this really distributed set of nodes all around the world, so you could have the best view of the mempool possible and respond very quickly, and the latency of your code, because you wanted to constantly be able to re-up and beat out someone else on having the most. like the highest gas price transaction at the time that a block was was included. But this isn't really what you want to be competing on as a searcher.

You want to be finding novel alpha. You want to be finding new ARBs. You want to be, you know, extracting novel forms of MEV. And the FlashBot's auction instead by resolving these things off-chain and by kicking the only the bid that pays the high gas price to miners getting included on chain moves competition more to finding new types of MEP and having the most gas efficient code possible rather than being really good at priority gas options and like latency and mempool optimization. So as a searcher you can focus on gas optimization

finding new forms of alpha. As a miner you're incentivized to opt into you were incentivized to opt into the flashpots auction because you can make more money that way because even if you're you're a large miner and you had access to some proprietary kind of bundle flow or some deal with a trading firm, you should want to profit switch between that proprietary access that you have and the flashpots auction and just choose whatever is more profitable. And as a trading firm, even if you could get this proprietary access, you would also want to submit to the flashbots auction to and access block space that you didn't have access to. So on all sides, parties were kind of incentivized to opt into this more open permissionless marketplace.

Did that make sense? Got it. Yeah, that's helpful. You asked a question about the transaction supply chain, and I like didn't really answer that question directly. Yeah, so the question was around the MEV supplier value chain pre-merge in proof of work, Ethereum, and then like what challenges arose as a result of MEV within that supply chain? So what did the MEV supply chain? pie chain look like pre-merge, you had kind of two sources for transactions. You had one, the public mempool.

This is public, so nodes all around the world, including miners and mining pools, have access to this. And two, you had this side channel, which was the flashpot's auction, and arbitrageurs or parties who would want to extract MEPV, liquidation. bots, sandwich bots, NFT bots, all would send these off-chain transactions and what we call bundles to the flashbots auction that would then be forwarded on to miners through the flashbots relay. And at the mining pool level, they would run this specialized software to take all the transactions in the public men pool as well as the bundles coming from the flashbots auction and

create the most profitable block possible through kind of a complex. complex optimization problem. And so really, there are, I think you could call it three different parties here. You have searchers, the flashbots relay or relayer, and miners are the most important there. You also had users and their wallets. So users would express intents to their wallets that would generate transactions. Most often, these went to the public memple and got included. in the way that I was saying a little bit before.

But there were a subset of users who would send their transactions to the FlashBots relay and those would get forwarded on with bundles in the side channel that I was talking about through our relay to miners. I think that's what the MEV supply chain looked like in proof of workdays. One thing that you mentioned is this software that allowed miners to take bundles of transactions from searchers and include them in a block. So talk about that software. Yeah.

So in proof of work, minors largely, there are some small exceptions, but miners largely were creating blocks and ordering transactions within a blocks themselves using specialized software locally. FlashBots put out a client, which was a fork of geth, which did this on their behalf called MEV Geith. In short, it would run a bunch of paralyzed computational work to try to find the optimal ordering of bundles at the top of a block with Mempool transactions filling the rest of the block. Just optimizing for like this single constraint of what will pay the minor the most if I include this possible block template. But this is super interesting because we put out this open source software initially,

and it was pretty good, but a bunch of miners were starting to improve on that with introducing their own proprietary kind of improvements on it. And if you could introduce proprietary improvements, maybe you could include 10 bundles where a smaller minor could only include three, or maybe you had a slightly different kind of algorithm for how you included bundles and it produced more profit. And so you even back in the proof of work days had different entities that were competing in effect on optimizing the ordering of transactions within blocks by making these proprietary improvements to the ordering of transactions within a block and improvements to how they optimize that. But one difference, and I'm sure we'll talk about this in a moment, from the proof of stake days is in proof of work, if you were a minor and you were really good

at optimizing the ordering of transactions within your block, you had no way of monetizing that by accessing other miners' block space too. You could only really include this optimized set of transactions within your own block space. And there was no way for EtherMine, who was an old miner, to make money off of F2 pools, block space as an example. And, you know, we changed that. Okay. So since you brought it up, let's talk about it. So now we're in a post-merge world.

And we've entered this era of proof of stake Ethereum, which has, you know, resulted in a new set of risks that requires changes to how blocks are produced, how MEP is captured and how it's distributed. You know, I think a lot of listeners might have heard our episode with John Charbonneau. and we covered some of this, but maybe for those who haven't heard the episode and maybe we missed some stuff in that episode would love for you to review, what does the MEV value chain look like now and then what are the new pockets of risk that exist

as a result of this transition to proof of stake? Yeah, there's a lot to talk about there. So stop me if you want to dig into any part I'm not sure what's most interesting to you. Okay. So what does the MEV value chain look like now? I think it's important to maybe go back and talk a little bit about the market structure before and how it differs in proof of stake.

So in the proof of work days, we had these large mining pools and they had a ton of stake capital in effect behind them. You had these huge expenditures on buying mining machines. And we were able to send miners bundle flow. Basically, because they were staking their reputation and we could monitor them for bad behavior and threatened to take away bundle flow from them if miners were taking kind of bad actions by front-running users, by stealing searchers MEV or something like that. And that was kind of the enforcement mechanism within the system. But in proof of stake, there are way more stakers than there were miners.

And they don't have as much on the line as what mining pools did. So anyone with 32Eath, you know, coming out of a centralized exchange or another privacy kind of tool, could spin up a validator. and if we want to provide democratized access to MEP, we need some way of giving it to them without those entities being able to see the contents of the block they're including because searchers will not want to share really valuable MAB opportunities with a random staker, right?

If your MED opportunity is worth a lot of money, then it's more likely or there's a decent chance that a small staker or a home staker would rather front-run that opportunity and take it for themselves. And as a result, you would see centralization by MEP researchers only sending their high-value bundles or bundles at all to kind of large entities that are well-capitalized, well-known, your Coinbase, Krakken, Binance, Lido, Rocket Pool, et cetera, of the world. So we needed a different design in proof of stake than we did proof of work. And in particular, we needed privacy so that you, as a home staker, could not see the bundles,

the contents of blocks before they were included on chain. So this is kind of a starting point for us in thinking about what an MEV marketplace looked like in proof of stake. That informed this new design that we have and how the MV supply chain has changed. So we get transactions from users and from searchers, and they go to a new set of actors called block builders who are these specialized actors who are only specializing in creating the most profitable lock possible. They're just competing on how do I make the highest payment to a block proposer or a validator possible in this block. How do I merge transactions? How do I offer features that get me to a higher number possible? And block builders send their

blocks to relays who have the job of keeping block builders and check. They simulate block builders, blocks, they see whether the blocks are correct and how much value they pay to validators. Finally, validators will listen to relays for headers of blocks and how much value those headers would pay out to them. So the validator does not actually see the contents of the block. They only get the header and a sense of how much value they would get if they signed that header. And a validator will just profit switch across many different relays who the relays are aggregating many different builders in order to know which header they should sign. So that's end-to-end what the what the MED supply chain looks like now and kind of how it differed from the proof of work world and why we made the choices that we did. There are a number of challenges within this structure.

So I think the number one, so two challenges are one. It's been relatively surprising the lack of relay diversity within the market. Relays are a super important actor in the system because they choose what blocks end up landing on chain. And without a diversity of relays in the system, you can have subsets of relays that can impose their preferences on a large portion. of the market. So if you have certain compliance requirements, as I'm sure everyone knows that we do, then those can inadvertently get imposed

on a large percentage of the network, not inadvertently, of course. Number two, we have to deal with builder centralization as well, which again, there could allow a subset of actors imposing their preferences on the network, as well as extracting rent at the limit. there's one builder that is much more, much better than others. So those are kind of two key risks and issues that we've been addressing since the proof of stake.

Merge happened, you know, a lack of relay diversity within the market and builder centralization more broadly. So to summarize, in proof of work Ethereum, because there was this ability to, you know, for lack of a better word, trust, miners, you were able to send them bundles of transactions and they could include any transactions that a potential builder or relay didn't include and, you know, kind of deal with potential censorship from the builder or relay. In proof of stake theorem, we've kind of moved to this world where we can no longer scale that trust across a more decentralized set of validators. So now to preserve the privacy of blocks that builders are sending through relays to proposers and kind of avoid proposers, M-E-V-stealing,

they're being forwarded full blocks of transactions. But this, you know, if there is censorship at the builder or relay level, there is kind of no way to to insert these censored transactions by block proposers. And then simultaneously, while we've managed to kind of decentralize this or optimized for decentralization of validators, now there is this new. problem rearing its head, which is the centralization of builders. Is that kind of an accurate characterization of where we're at today? Yeah, I think it's an accurate characterization. In the proof of work days, you had kind of more collaborative block building is the way that you

could frame it and you aptly noted this. So both flashbots, blocks route also was a relay in proof of work and the miner collaborated on a block. And so there was less vectors for censorship. since the miner could get transactions through the public amendment pool and they weren't outsourcing the entire block. Today, the entire block, as he noted again, is outsource to keep the validator set democratized. And economies of scale and block building make us worried that a small number of entities can impose kind of arbitrary rules on blocks, including censorship. There's some other issues in the future, too.

I think builder centralization is kind of the long-term issue. In the short-term, you do have relay diversity, also relay-relay centralization, but relay centralization may not be as much of an issue long-term because some of the role at relays play will get obviated by including proposer-builder separation within the protocol. So it was a very good summary, yeah. Okay, so then let's talk about that a little bit because we actually didn't touch on it as much in the episode with John, which is going from a world where you have out of protocol PBS to enshrined PBS, which removes the need for an intermediary. but even in that case, the threat of censorship still isn't removed completely.

So why is that? And then maybe what are some proposed solutions to that? So the role that relays are playing within the market is to make sure that, you know, blocks are valid and they pay the proposer a certain amount and then to choose which block. forward on to the validator. And in protocol, PBS is just a way of performing all those functions by the Ethereum protocol itself by running a committee that will, you know, tally up all of the bids from builders and decide which one is the highest bid and like forcing that to get included on the market and some, sorry, included on chain and some sort of process for how contents of blocks are revealed to.

Even in, even in that scenario, and I think this is getting us close. to the discussion around, you know, why block building needs to be decentralized. But even in that scenario, you're removing the need to trust an intermediary to facilitate, kind of trust between a builder and a proposer, but the threat of censorship still isn't removed completely. So why is that? And then what are some proposed solutions? Right. So in the proof of work days, there are many more parties that, had kind of the ability to create a block. And in proof of stake, we're creating these specialized entities called block builders

that are relatively centralized as a group. So something like five to six entities control 80% of the block building market. And there are, you know, 10 different relays, which is much more centralized than the, you know, proliferation of minors that existed and the 400,000 different validators that existed also. And these smaller groups of parties can impose their preferences on the network like censorship, much more consistently than the large distributed network of validators does, which you are seeing from flashbots today because of what, you know, because of the utility functions and the compliance that we have as an entity.

But with this said, we think that we've been taking a bunch of actions to prevent this. So FlashBots has open-sourced our relay. We did that before the merge. We're encouraging other neutral relays to come to the market. We introduced this feature called MinBid. We opened-starts our builder to create kind of more competition in the market. market and I think as a relative percentage of blocks that are going through the flashbots relay and that we're censoring, the number will probably start going down. I think it's probably peaked at this point for a few reasons. First, it looks like adoption of Mev Boost has reached a relative peak at somewhere like 90 to 95% of validators. And that last percentage of people are, you know, either running local building for some reason,

or they're just not going to adopt Mev Boost. The second thing is, is more relays are starting to get adoption. So validators who previously were only connected to flashbots are now connected to other relays that are not censoring. The third thing is that existing relays that are being connected to by more validators are accepting submissions from external builders. So for some time,

FlashBots and our relay was the only relay that was accepting external block builders at our relay. And, you know, the best builders that exist are FlashBots, Builder 69, this builder called Beaver Build. No one seems to know who they are, but it's a very funny name. Eith Builder, and there's some others on the network too. But, you know, all of these folks don't run their own relay. They use the flashbots relay to access block space. And our relay is censoring. And so the only way that they have access to block space is to go through this censoring relay.

And there is no non-censoring avenues for them to get access to block space. But in particular, there's now these two new kind of neutral relays from ultrasound money and nois that are accepting external block builders. and I think it's eighth builder, one of the builders, has started to land a lot more blocks through blocks route, which is running a non-censoring relay. So if you've seen the scary charts with like a bunch of red and a bunch of green for the OFAC percentage versus non-OFAC percentage, I think that percentage has probably peaked at this point.

In the medium term, there are proposed solutions, what are called CR lists, censorship resistance lists, or inclusion lists, where you give the proposer some say over the contents of the block that a builder has to create for them. So the proposer still doesn't see what the contents of the block are before it's included, but an inclusion list is something like the proposer saying, hey, you need to include these two signed transactions or whatever you return, whatever you're going to propose to me, I'm not going to include on chain and it's not invalid. And, you know, that way a proposer is able to force the inclusion of certain transactions

into a builder's block. And the thinking goes that like a more decentralized validator set will be more censorship resistant than a centralized kind of builder set. You know, there's 400,000 validators on Ethereum and there's much fewer builders. There's some problems with this too, and we can talk about kind of the tradeoff some problems and inclusion lists if you're interested. But we could implement this within Mev Boost in two or three months if we want to. It requires a bunch of work, and it's not, you know, just Flashbots' decision

because we would need clients from all around Ethereum to implement changes alongside of us. But if the community is interested, this is like a tool available to us on a relatively short timeline if we're willing to take the tradeoffs. The last thing that I point out is in the long term where we want to move is away from this model where there's only one party proposing a block in the block builder role. And instead, you have this more collaborative process of many different parties coming together and creating a full block together. You know, one builder or searcher proposing a small part that gets built on by another builder or searcher who's, you know, snowballs into a slightly larger block that's built on someone else. And so you distribute this builder

role into many, many, many parties, reducing the ability for any single party to censor transactions or to impose their preferences on the overall network. And this is kind of the long-term research goal that we have and one of the products that we're going to be building at FlashBoth and part of Swab 2, which we can talk about. So I'd say those are the three things we're doing about it. One, open sourcing and try to induce competition, two, inclusion lists, and then three,

this kind of collaborative or decentralized block building. Another thing that I saw that you guys wrote, I think, a research piece about last week maybe, the piece was called The Cost of Resilience. And it discussed the introduction of a new feature or parameter that would allow proposes. to specify like a minimum amount of MEV that a block would have to include for them to accept it from a relay. And if that threshold wasn't reached, then they would kind of default to building it locally. Can you talk a little bit about that as a kind of potential interim solution to this challenge that we're talking about right now. Yeah.

So because of some technical intricacies in how clients work, the way that Mev Boost was implemented is that by running MeF Boost, you are by default, just outsourcing all of your blocks to Mev Boost. So regardless of how profitable the block would be compared to a normal Mempool block, you choose the MEV Boost Block. And this became a problem because FlashBots and the FlashBots Relay was adopted to a high percentage of the network. And we are OFAC compatible. And that meant that our kind of legal risk analysis, our utility function was imposed on a broader set of the network.

But at the same time, if you are a solo validator or a staking pool, you then had the choice of, of foregoing, you know, optimized MEP rewards by building locally, which is more censorship resistant, or opting into this kind of censored system by accepting blocks from the flashbots relay, which is the most profitable one. And this is a non-trivial decision to make too, because there are a couple different times where blocks have been proposed through the flashbots relay, which are, you know, 300, 400, 200, something like that. So you don't want, and on average,

I think the median block or something like that is 100% more valuable than a Mempool block and Mev Boost. So it's quite a boost to the median profit, and at the limit, you can make 400-Eath. So you don't want to. It's not in your incentives to turn off Mev Boost and to build locally, but because of technical quirks,

there's no way to kind of profit switch across the Mempool and Mev Boost, or to say, I only want to opt into this system if it's a really valuable block. And that was this min bid function that you are highlighting that we introduced in our latest Mev Boost kind of release. So now validators can say, hey, I want to accept Mev Boost blocks, but I only want to accept them if they're bidding to me, you know, 0.05-Eath or 1-Eath. or 100 or something like that. And everything below that, I'm just going to build locally instead. And local building allows a validator to construct transactions from their mempool,

presumably with no rules on transactions that they would censor. So it keeps the network more resilient and involves more parties in kind of the block building process, which is what we want, while allowing them to still, you know, optimize for MEV profits and not incur too much of a cost for this resiliency. And if you are smart about it, you can even program this, you know, depending on the proportion of blocks that you want to build locally versus outsourced to MoV Boost. So, you know, maybe you want to build 50% of your blocks locally and outsource 50% to

MEP boost. And so there's like a concrete number in the blog post that you would need to set your in bid at in order to get to that point. So this is another kind of short-term solution that we had for how we can make the network more resilient while not forcing people to give up a huge amount of potential eth rewards in order to achieve that. So this is all great, great short-term solutions, but still not enough. And, you know, kind of the North Star, as you said, to, that we need to kind of achieve the censorship resistance guarantees that we're all here for on chain is trustless block building and decentralizing block building. So, you know,

you mentioned this a few times already, but last week, FlashBots shared details about this, this more, much more robust long-term approach in, in this post titled The Future of MEV is suave, which really sets out a comprehensive outline for this vision. So let's get into that. What is suave at a high level? What is suave? The question I've gotten a lot over the last few months. So suave is the single unifying auction for value expression. It is the future of flashwats and what we think the future of MED is. It is a decentralized network that unbundles the Mempool and the block building role and creates a more decentralized and collaborative process for how blocks are built that is permissionless and censorship resistant. It's also how we plan to address key centralization risks to the builder market like exclusive order flow and cross-domain MEV and hopefully address MEV on more domains.

than just Ethereum, like roll-ups as an example. So that's a very short description. That's light on details. So happy to dig into that anywhere you're interested. Yeah, let's get into it. So, you know, I think you had this great post. You shared a really great thread. And there's different components of suave

that you're bringing together to create this entire system. the preference environment, the execution market, and then the decentralized block building market. So let's unpack each of those one by one. Yeah. So suave begins with this environment that we call preference environment that aggregates and surfaces preferences on Ethereum, where FlashBots is a builder today. We have preference. We have the ambition of this being a universal place for preferences too. So not just on Ethereum, but on other domains too. And by preferences, we really mean something that a user wants to happen in the world.

So in M-EV land, this could be like I have transaction one and two, and I want them included in this order, and I'm willing to pay, you know, X amount for this, only on on Ethereum. It may be I want to be included at the top of the block or to be included without front running as an example. These are kind of more MEV native preferences, but suave is intended to support broader preferences than that. Like I have asset X and I want Y and I'm willing to pay Z. So this is the preference environment is this place where we surface all these preferences, we aggregate them together and we get a lot of information. How are these preferences translated to and expressed in suave?

And then is there a cost associated with expressing the preferences? And if so, who bears that cost? Good question. So the way that they are expressed translated is by users signing messages that express their goals and that unlock payments if their goals are met. So concretely, there is a suave chain where money is locked up into these bid contracts that program kind of the goals that users have within the world. You know, I want the state to be X or Y or I want transaction hash Z to be included and the conditions under which kind of payment.

would be unlocked. So there's a cost to getting money to this chain and then into these contracts. And once you have borne that upfront costs, there is no cost to signing a message that allows someone to unlock that payment if your preferences or your goals are met. So we envision this environment where it's optimized for this purpose of people being able to express kind of the widest range of preferences possible, not just MEP, not just trading, but all sorts of different types of preferences across many different domains. And we're optimizing this environment for that purpose and for really the purpose of preference

expression, execution, and settlement, which is to say to make it as costly and good UX as possible for this. And that's the role of the preference environment and part of the role of this blockchain that we're launching to called suave chain, which is optimized for this purpose. But preferences don't do anything in the world if they're just expressed. You need some way of these preferences getting actioned on. And we envision this marketplace that specialized actors called executors, who their only job is to take preferences from the preference environment and to execute on them and to compete for providing the best execution.

possible to users on what their preferences are. Again, abstract, but to break it down, as an example, you may have one of users who have preferences on trades that they're interested in making. I have X asset, I want Y. In the execution market, you'd have different executors that are bidding to give them the best trade possible.

Or maybe you have Oriflow auctions that are taking place. place and the executor that pays the user the most for their transaction is the one that gets the right to execute on them. So your preferences are first surfaced in the preference environment. They're passed to the execution market where there's competition among executors for executing them. And the output of that is either a single transaction or a list of transactions that are fed into a decentralized network of builders

that are collaboratively building a block together. So the output of the execution market is just this input into this kind of chaotic network of many parties collaboratively and progressively building a larger and larger part of a block together until a full block is proposed to the overall network. And that's end-to-end kind of the picture of suave.

What do you want to dig in there? Because I'm sure you've got a question. Yeah. So let's go back to the execution piece. Who are the potential executors in this system? So we have the ambition or the hubris of wanting to execute on many different types of preferences. So in the abstract, an executor would be anyone. who wants to compete on providing best execution for some type of preference.

And this is going to differ depending on the preferences that people end up expressing unswav. And why would someone want to provide best execution? What is the incentive to them to provide best execution? Because they could get paid for doing that concretely. Yeah. So as an example, like you, builders today are executors. Their job is to take searchers bundles, find the most optimal ordering of transactions in a block, and get that included on the network. And if they're really good at it, they can outcompete other builders and take a fee.

We're building an order flow auction at FlashBots, which will redistribute value that users create back to users. And you could run this auction and have users pay you a little bit or take a fee from the the MEV, you're able to redistribute as an example. So this is an incentivized marketplace and a competitive one at that where, you know, you can get paid for providing jobs, so to speak. Okay. And then how does that potential rebate occur in practice? In practice, it depends on the type of order flow auction.

I can like talk about some of the ideas that we've had at flashbots, but there's many different types of order flow auctions. So you'll see different parties running different types of executors and order flow auctions. So, you know, one simple way to do it. It's not what we're doing, but kind of the most simple structure and the easiest to understand is users send the order flow auctioneer their transactions, and they want to auction this off to get paid for their access. execution at their transaction creates NEP.

So a very simple, naive way to do this would be to strip the signature from a user's transaction forward that on to a network of searchers and have searchers respond, hey, here's a transaction that pays the user, you know, X, eth. And the auctioneer then aggregates all these bids, sees which ones pay the user the most, and chooses the highest paying bid to send onto the network. with the user's transaction that has a signature as an example. We're not sure whether this works. We think that there's some problems with the ability to enforce that

and with the leakage of information, but I think that's the simplest order flow auction to understand. One thing that you talk about is you need certain features within this network to actually build out all of these functionalities, the preference environment, the execution market, the block building market. What features are necessary to kind of build these different components and, you know, how are you planning on offering these features on Swab out of the gate? So the preference environment, the execution market, and the decentralized block building network

are really ways of describing kind of logical components of the architecture of Swave in different jobs that Swave needs to get done. So on one, it needs to surface as many preferences as possible within the preference environment. Two, it needs to minimize M.EV by providing the best execution to users possible given their preferences. So you're minimizing MEP. And then three, it needs to maximize MEP by finding the optimal ordering of transactions in a block given the output of the execution market. So that's where these like different logical components and features come from. But this is kind of a very broad and abstract way of thinking about things with much modularity

because we have the ambition and the need to address problems in many places across crypto. And so we have to adapt for different environments, right? So to kind of address cross-domain MEV, you can't just build things for Ethereum. You have to build them for roll-ups, as an example, and super high-low latency chains and non-evim chains and centralized exchanges, probably also. Which is to say that, you know, these components are very modular and very broad and adaptable. And it's more of a framework for thinking about the architecture than each of these is like one concrete product. The way that we are approaching that is by thinking about the immediate market needs that exist within crypto and how to keep the broader MED marketplace on Ethereum healthy

and trying to take what we think would do that in the short term and link it up to the broader long-term vision of Swave in these three different parts. So concretely, what that is has been working on these short-term kind of changes to MEV boost, inducing more competition in the builder market, the relay market, min-bid, inclusion list research, etc. And creating an executor in the execution market with an order flow auction that redistributes value back to users. We have a different design that we'll be talking about in public soon from what I shared earlier. And that's kind of the first step here where we're starting. While we do R&D and research on collaborative and decentralized block building,

we think we'll learn a lot from the OFA process in that and get the preference environment kind of ready and think more about how we work with the community to address MED, not just on Ethereum, but all of crypto, all roll-ups, all of their chains also. So that's a little bit how I think about the features and different components and kind of the approach that we're taking and building this and where we're starting and why, if that addressed your question. Going back to the preference environment, and, you know, this question is, kind of relates to the fact that Swav wants to be a network for the expression of preferences and decentralizing block building across chains.

Is it possible to standardize the expression of preferences across different ecosystems, or is that kind of still an area? of research that you don't really have all of the answers to? I mean, probably. So at the limit, like, in a bunch of different chains, what really matters for MEV is transaction ordering, or at least like ordering after a certain piece of state. And so all you really need to express is, like, I want this transaction hash included at this spot,

either behind another transaction hash or, you know, the first transaction hash included after a piece of state is equal to a certain thing. So we think you can standardize that. And we'll be launching with a couple examples of how you could express your preferences in that way. And then it's a matter of kind of scaling swab in the preference environment to be able to read data from a bunch of different places, I think. but you're always going to have kind of nuances to this and different ways in which these preferences are executed. So you can standardize, you know, this transaction execution for a good amount of places, but of course not everything. I don't think there's ever going to be kind of universal standards.

As an example, if you have an L1 where you have super, super low block times and super cheap block space, the dominant MEV strategy is actually to spam the chain and to do your MEPB search on chain instead of off chain. So you have a smart contract where you're trying to find ARBs as an example. You're doing all that within your smart contract. And since it's super, super, super cheap, you just hit the chain as hard. hard as you can over and over running that MEV search until probabilistically one time you find an ARB. And that one ARB that you find is going to pay for, you know, 10 million failed transactions or something like that. And if you have a preference of extracting MEV on a chain where spam is the

dominant, the dominant kind of model, then you're not thinking in terms of transaction hashes anymore because you don't have kind of the latency in order to have that abstraction. You're thinking in terms of spam. And in that world, your preference is something more like, I want to pay someone every time my contract successfully executes. And the natural incentive is for an external party to spam your contract such that they get paid upon a successful execution. So it's a long-winded way of saying, like, I think there's probably a good deal of standardization, but you're always going to have kind of some differences depending on the dominant M-EV extraction strategies, if that makes sense.

Just switching gears a little bit, you know, I think one thing that was highlighted by you guys is the importance of, having privacy for different stakeholders in this ecosystem, right? So how do you offer privacy while allowing these different parties to do their job in the SWAB ecosystem? It's a really good question. So privacy is really important for a few reasons, which is not what you asked, but one, to prevent censorship. Two, to, induce maximum competition, three to prevent things like front running and MEV stealing. And how you achieve privacy is still kind of to be determined. Right now, privacy is achieved by just trusting flashbots.

Searchers and users trust us not to screw around with their bundles. And of course, we don't. We, you know, this is suboptimal for a bunch of different. reasons like what we've been talking about today where flashbots can impose our preferences on the network and censor transactions we want to scale to be able to allow parties that are less trusted than flashbots to be able to run these kind of entities also and introduce privacy in the short term we think that the most viable way of doing this is by using secure enclaves it's like Intel SGI

where you're running a piece of hardware, where even the party that has access to the hardware can't see what's going on inside of that hardware. You don't have access to the contents inside. And there's all sorts of problems with XX, and we can talk about it, but this is the most viable way to add some level of privacy

with reasonable efficiency in, say, the next three to six months if we want to distribute the market, away from flashbots and to add privacy even from flashbots. In the medium term, we're super excited about multi-party computation and the prospect of using actual hard crypto to do this. And in the long term, you know, MPC or fully homomorphic encryption or some even more magical forms of crypto are also kind of exciting.

But none of the pure crypto solutions are ready and we don't think that they're going to be ready in, say, the next year or two. And the only thing that seems to be ready to go would be kind of secure hardware solutions. So that's what we're going to use for privacy in the very short term and move away to pure crypto as soon as we can.

Suav is launching or will launch as like a standalone chain. Does that require any kind of bridging layers between networks that connect to suave for any of these activities or will different chains that plug into this network be able to plug into suave trustlessly? So kind of as a principle here, we're trying to make this as easy for validators as possible, making it simple for a validator on ETH to plug into suave. And functionally what that means is that all validators need to do is to continue to listen to Mev Boost in the marketplace.

As they do today, we expect that to be similar on other chains also. And it's the job of executors to handle the inclusion of preferences as opposed to the values. validator. And the validator is just listening to transactions in whatever way they get them, whether that's the Mempool, whether that's Mev Boost or some other way. The burden instead is put on searchers who are highly sophisticated, highly motivated entities that can make money, and executors who are similar in kind of scope of searchers to get some money on some money on suave if they need it, sometimes you won't need it on swap chain. And to use swap chain, if you need to, you do need to bridge over some value.

So there will be a bridge, at least starting on eith, where if you're expressing your preferences on suave for execution, you'll need to bridge some eth, lock it into a contract, you know, express your preferences in the way I was saying earlier. But trying to make it as easy for validators and users as possible. as a principle. So I know you guys just put this out and you know, you want to build this in the open with anyone and everyone that wants to contribute. But do you kind of have an ideal timeline in mind?

Do you feel like, you know, you need to get this out as soon as possible? And as you're building this out, is there any risk that, like, centralized block building prevails? And it just becomes really hard to transition to this decentralized system. It's a really good question. So I don't feel great that Flashwold. Lots of runs centralized infrastructure that has as much influence in the network as it does. On one hand, I'm proud of our team, the products we've made. On the other, it does place a lot of trust in us.

And we have had negative impacts on the overall network, in addition to the positive ones, like you were saying earlier, of course. And I want to move to a world where FlashBots is much more decentralized as soon as we can. So really the answer to your question is yes, as soon as possible, please. But these are super hard problems, and this is a super ambitious vision that we're building. And even building this for Ethereum will be very hard, let alone addressing it, these challenges for all of crypto too, which is our eventual kind of ambition because you need to do that to address cross-demean MEV. I hope to have kind of the end-to-end picture working in some frame, which is to say the preference environment all the way to some basic decentralized block building.

Of course, in enclaves, most likely, where the block building is happening collaboratively across many different entities instead of just one centralized AWS server. I hope to have that at some point in 2023, along with the order flow office. And that'll be kind of the MVP end-to-end process of suave, which will be relatively inefficient. It'll be using secure enclaves, which you hold your nose and accept that it's the best trade-off in the short term. And we will iterate from there and probably only, at least flashbots, running this infrastructure for Ethereum first.

While we figure out some of the open problems, while we figure out how to make it more efficient, while we work with partners to scale this to other places also. So that's kind of how I'm thinking about timelines. There are risks here, Ria, and it's an important question. I want to get to the system as soon as possible because the market could still centralize in many ways. So to come back to those two key builder centralization risks of exclusive order flow and cross-domain MEV,

I'm a little worried looking at the market structure today that builders are already engaging in exclusive order flow deals where like a wallet or an application is only sending their transactions to a single builder and not other builders and this gives them an advantage over other builders who can create these kind of flywheel effects. This is not the crypto that we want. This is not open. It's not permissionless.

It's like high-touch social deals between builders and another one. And it kind of defeats the purpose too because you generally engage in exclusive order flow deal because a builder will kick you back some MV rewards. You think your users will get better execution. But if you take this to its natural conclusion, you just get one single dominant builder. And that one single dominant builder can extract rent from users and from validators, which is the kind of business model of an exclusive order flow builder. So we're worried about exclusive order flow. We don't think it's in the interest of wallets or users. We want open, permissionless, competitive marketplaces,

and we think that's what's going to drive the most value to users too. And I do worry about that, and it is a fire under us to ship Swave as soon as we can. And hopefully a fire under everybody listening to this podcast to come and build this system with us. you guys hammered home both in the announcement and a lot of the Q&A is that you want to be very aligned with Ethereum and, you know, the native asset of suave, and correct me if I'm wrong, in that terminology will be ether.

So talk a little bit more about that and maybe the wrong. role that ether will play in the suave ecosystem and network? We are Ethereum aligned. We love Ethereum's ideals, what it stands for, what its vision is, the world that it wants to bring in. We love its community and it's decentralization. It's the roots of Flashbots. It's what we want to build on and to preserve.

We are extremely mindful of the privileged role that FlashBots has within this ecosystem and how if the wrong incentives are introduced into suave and to flashbots even today, it could kind of corrupt the incentives of the validator set and, you know, have negative effects on it. It could have a centralizing effect on the validator set of Ethereum. And so we're being very careful of the incentives that we introduced into the system. We're being very careful to be eth aligned at every step of the way. And, of course, core part of that is using ETH as the token

for suave. So if you are paying for gas fees on Swave chain, you're going to need to bridge ETH over to Swaf Chain for that, which means that there's no suave token. And we're thinking that the validator set for

Swav chain also should be a reflection of the validator set on ETH. So it kind of reflects the relative distribution of power on Ethan's validator set back and we're not introducing any extra protocol incentives that way as well. The last thing that I'll say on this note, and it's something we're asked quite a bit, is about FlashBots monetization and sustainability. It's related to a token.

It's related to alignment. It's related to our business models. And in the long term, FlashBots does want to be sustainable. you know, we would like to think we're good actors, and we have this ambitious kind of roadmap of things that we think need to happen in order to preserve the decentralization of crypto and to bring a whole lot of good benefits that MEP could bring to the world. But to do that, you need to make money and be sustainable. With this said, we think that the current market structure of MED today is not sustainable,

and it is broken because of the censorship that, exists because of the effects of cross-domain MEV and exclusive order flow. And so we're super hesitant to monetize in some way until we have a market structure that we feel better about and until we've solved these problems of exclusive order flow across domain MED, you know, censorship resistance. And once we get over those and once we start to address those problems, then we can think a little bit more about monetization and it'll be more clear that we're not accidentally introducing some incentives that are misaligned with ETH and the networks that we are serving.

As this suave network emerges, will FlashBots itself perform some of these functions of being an executor or participating in. in decentralized block building? The kind of playbook for flashbots historically has been to stand up these new marketplaces and to bootstrap them to make sure that they are competitive and efficient. But this is the scope of our ambitions

in creating these marketplaces to design them and make them competitive and efficient instead of being a participant. And that's how we approach this in suave too. You know, we, do intend to be an executor. We do intend to be a builder as we do today, but it is not our ultimate goal to monetize, you know, these individual roles that we have. We want to be the neutral marketplace designer, not the participants, and to find some kind of like incentive compatible way

to be sustainable within that. And, you know, those are the ends that we have in running infrastructure within SWOV. So we covered a lot. And I'm sure there's, is a lot more to cover. So I kind of want to take a step back and ask you what, you know, what, what, what else should we be asking? What are kind of some important questions that, that you're getting that we didn't cover that you think listeners should be aware of? I still think exclusive order flow is relatively underpaid attention to by the majority of people. the effects of sending your transactions to a single builder, the effects of proprietary deals between applications and builders on the overall network.

This is one thing we should be asking about. The second thing is how geographic diversity affects the credible neutrality of public blockchains, the relationship between having builders mostly located in certain geographies like the U.S. or the EU of having, you know, the validator sets distributed in one, are located in one place and not another and how that relates to properties that we seem to like, like censorship resistance. So geographic diversity is something we think about a lot and I think is relatively understudied. And has, I know flashbots, you know, produces so much research, has flashbots or have you seen any good analyses on that, on both of those?

So exclusive order flow, yes. There are a couple good posts by a researcher called Quintas on our FlashBots form. So if you go to collective.flashbots.net and you search exclusive orderflow, you'll find them. Geographic diversity, no. You are going to have to go look at Phil Dian's Twitter threads. And he had a good podcast on Epicenter not too long ago about this. But there's no research that we put out on that, I think. The last thing is just generally privacy in the context of MEV is relatively under-explored.

So there's some trade-offs that you make with privacy. On one hand, you want privacy because you don't want parties to front-run you or give you worse outcomes. On the other hand, it's much more difficult to optimize for MEV if you have full privacy. In particular, if we have these systems that can pay users back M-EV that their transactions create, you actually don't want full privacy. There's some middle place in this frontier of full privacy and no privacy. That is the most efficient point on this curve that seems optimal intuitively. So this kind of way of thinking about privacy, we call programmable privacy at flashbots.

And this frontier of privacy and efficiency, I think, is relatively uninterested. explored. I can keep on going on, but I'll stop myself there with those three things. Well, I've kept you for way above our allotted time. So I'll ask my last question. How can people stay abreast of what you're working on and how can they get involved? So how can you stay abreast? Bertie Miller on Twitter is my Twitter and then I follow all members of flashwats. So you can go to my 30 following and like follow all of us. We don't have a Twitter account. We don't have a newsletter, anything like that.

So you're going to have to just follow us on Twitter to get information for what's going on at FlashBots. And we have a form. So collective.flashbots.net. Also, it's a discussion around MEV about the future of MEV research, suave, what we're doing today. We'd love to see more people on their posting and getting involved and contributing. So I think that's the best places to stay in date and best places to get involved.

great thank you so much robert this was awesome super comprehensive i'm sure there will be a lot of threads to pull at from this conversation that i'd love to continue to explore on our podcast but really really appreciate all your time