Motion: We should always reduce MEV on blockchains (Ed Felten vs. Tushar Jain)

Guests:

Ed Felten (twitter.com/edfelten)

Tushar Jain (twitter.com/TusharJain_)


Host:

Richard Yan (twitter.com/gentso09)

Today’s motion is “We should always reduce MEV on blockchains."

Generally speaking, MEV or Miner Extractable Value is a way for miners to derive additional revenue by executing transactions based on information in the mem pool. For instance, say a miner notices a transaction in the mem pool waiting to be included in a block. Maybe this is a transaction to buy up some cheap Ethereum. The miner can execute that purchase themselves, at the expense of the trader that placed the original order. And of course, this means value got extracted by the miner, transferred from the original trader. This behavior pattern, of course, applies to both miners and validators. Or to all block producers, to be generic.

The question is, is MEV an inevitability of blockchain systems? Are there ways to reduce it? Are our resources better spent creating systems that reduce as much MEV as possible, or should we acknowledge their existence and try to distribute that MEV more fairly, or at least transparently?

Our two guests today include a layer-2 founder and a VC well-versed in this area. It will be a great discussion.

If you’re into crypto and like to hear two sides of the story, be sure to also check out our previous episodes. We’ve featured some of the best known thinkers in the crypto space.

If you would like to debate or want to nominate someone, please DM me at @blockdebate on Twitter.

Please note that nothing in our podcast should be construed as financial advice.


Source of select items discussed in the debate (and supplemental material):

• https://pdaian.com/blog/mev-wat-do/
• https://multicoin.capital/2021/09/08/tokenizing-mev/
• https://medium.com/offchainlabs/meva-what-is-it-good-for-de8a96c0e67c
• https://docs.flashbots.net/flashbots-protect/overview

Guest bios:

Ed Felten is co-founder and chief scientist at Offchain Labs, the inventor of Arbitrum, a layer-2 scaling solution for Ethereum. He was previously a professor of Computer Science at Princeton, and before that the Chief Technologist for the Federal Trade Commission as well as Deputy U.S. Chief Technology Officer at the White House.

Tushar Jain is co-founder and Managing Partner of Multicoin Capital, one of the most successful crypto funds in the last cycle.

Chapters

• 0:00 INTRO
• 1:56 DEBATE
• 1:08:08 OUTRO

Transcript

INTRO 
 

[00:00:00] Richard: Welcome to another episode of the Blockchain Debate Podcast, where consensus is optional but proof of thought is required. I'm your host Richard Yan.  
 
[00:00:15] Today’s motion is “We should always try to reduce MEV, also known as Miner Extractable Value, on blockchains."  
 

[00:00:23] Generally speaking, MEV or Miner Extractable Value is the way for miners to derive additional revenue by executing transactions based on information in the mem pool. For instance, say a miner notices a transaction in the mem pool waiting to be included in a block. Maybe this is a transaction to buy up some cheap Ethereum. The miner can execute that purchase themselves at the expense of the trader that placed the original order. And of course this means value has been extracted by the miner, transferred from the original trader. This behavior pattern of course, applies to both miners and validators. Or to all block producers, to be generic. 
  

[00:01:05] The question is, is MEV and inevitability of blockchain systems? Are there ways to reduce it? Are our resources better spent creating systems that reduce as much MEV as possible, or should we acknowledge their existence and try to distribute that MEV more fairly, or at least transparently.  
  

[00:01:27] Our two guests today include a layer-2 founder and a VC well-versed in this area. It will be a great discussion. 
  

[00:01:35] If you're into crypto and liked to hear two sides of the story, be sure to also check out our previous episodes. We feature some of the best known thinkers in the crypto space.  
 
 [00:01:44] If you would like to debate or want to nominate someone, please DM me @blockdebate on Twitter. 
 
 [00:01:50] Note that nothing in our podcasts should be construed as financial advice. I hope you enjoy listening. Let's dive right in.  
 
 

DEBATE

[00:01:56] Richard: Welcome to the debate! Consensus optional, proof of thought required. I'm your host Richard Yan.

[00:02:03] Today’s motion: We should always reduce MEV on blockchains. Or, we should always reduce Miner Extractable Value on blockchains.

[00:02:12] To my metaphorical left is Ed Felten, arguing for the motion. He agrees that we should always reduce MEV on blockchains. 

[00:02:20] To my metaphorical right is Tushar Jain, arguing against the motion. He disagrees that we should always reduce MEV on blockchains. 

[00:02:28] Let's quickly go through the bios of our guests: 

[00:02:31] Ed Felten is co-founder and chief scientist at Offchain Labs, the inventor of Arbitrum, a layer-2 scaling solution for Ethereum. He was previously a professor of Computer Science at Princeton, and before that the Chief Technologist for the Federal Trade Commission as well as Deputy U.S. Chief Technology Officer at the White House.

[00:02:52] Tushar Jain is co-founder and Managing Partner of Multicoin Capital, one of the most successful crypto funds in the last cycle.

[00:03:00] So Ed and Tushar, welcome to the show.

[00:03:02] Ed: Thanks for having me.  
 

[00:03:04] Tushar: Excited to be on and excited to discuss this topic. Thanks for having me.

[00:03:09] Richard: Great. So we normally have three rounds: opening statements, host questions, and audience questions. So currently our Twitter post shows roughly 50-50, agreeing with the motion and disagreeing with the motion. After the release of this recording, we'll also have a post debate poll. Between the two polls the debator with a bigger change in percentage votes in their favor wins the debate.

[00:03:30] So Ed, you are in the “for” position. Please define for us what MEV means, and why we should always reduce Miner Extractable Value on blockchains. Go ahead. 

[00:03:42] Ed: Sure. So when we talk about MEV, what we're talking about is some party who's in a position of power using that power to affect the ordering of transactions, or to insert transactions, um, in an unfair way, in order to gain an advantage for themselves. So MEV stands for Miner Extractable Value. And the key word there is extractable. 
 
[00:04:08] This is value. This is money that goes into the pocket of some party that is extracted from somewhere. So if a miner ends up with more ETH in their account because they did some clever MEV trick, somebody else is going to end up with less ETH. That is value that is extracted from a user of the system. And it's extracted by someone who has a power position like being a miner that isn't available to everybody. 
 

[00:04:36] So the reason that we should reduce MEV essentially is two things. First of all, basic fairness. Fairness dictates that someone shouldn't have an advantage over me, the ability to extract value for me to make my transactions or opportunities less, because they happen to be in a position of power. The system should be fair to everybody. So everybody gets the same kind of treatment. 
 
 [00:04:59] But also MEV makes the system less valuable as a whole. If the transactions that ordinary people are going to do, give them less reward and give them less return, then they'll use the system less. And it means that the system has less activity and ultimately less valuable. 
  

[00:05:16] So I think of MEV as a sort of subtle form of corruption, if you will, right? Corruption is a powerful person using their power to do something that someone else couldn't do to disadvantage some member of the general public. And just like corruption, MEV can never be eliminated entirely, but we should be doing what we can to have less of it, and if we have to have it to have kinds that are less harmful. So I am a big supporter of trying to design systems and operate systems in a way that reduces MEV whenever we can.  
  

[00:05:50] Richard: Okay. Great. Thanks, Ed. Not sure how to argue against all of that. So Tushar, I think you've got your hands full here. Looking forward to hearing from you as to how you define MEV. Whether you think there's anything else to add to Ed's definition of it, and why you think we should not always be reducing MEV on blockchains.

[00:06:11] Tushar: So I agree with a lot of what Ed said, but I think that there's some nuances here that we need to dig a little bit deeper on. The first thing that I agree with Ed on, that I think is the most important, is that MEV cannot be eliminated. There will always be some MEV.  
 

[00:06:32] The simplest example is arbitrage trades. Someone needs to do the arbitrage to bring markets back in line. And who gets to do the arbitrage is going to be decided by the miner or staker who is producing that specific block.  
 
 [00:06:49] If we go out of our way to always seek ways to minimize MEV, that can lead to system designs with negative externalities, that can cause problems that reduce the value of the system. 
  

[00:07:07] Rather than always seeking to minimize MEV. I believe that we should always seek to redistribute the value of MEV, the maximum amount that we can to stakers in a proof of stake network, or to miner in a proof of work network. And I believe that this increases the inherent security of these networks. Because if you increase returns to staking, you will have more staking or the token will be more valuable. This will make the network more secure.  
  

[00:07:41] Or in a proof of work system. If you increase returns for miner, you will have more hash power, which will make the network more secure. And I think that that can allow you to reduce the issuance rate of the token and allow you to basically subsidize the security of the system through this redistribution of MEV, which can not be eliminated.
 
 [00:08:07] Richard: Okay. Great. Thanks, Tushar. So let's move on to second stage of the debate where I will be firing off questions specifically for each guest and Tushar and Ed, feel free to jump in and address anything you disagree with in the opening statement of your debate opponent. So my first question is for Tushar.

[00:08:30] So in the world of MEVs, we hear terms such as front running, sandwich attacks, time bandit attacks and so on. So in order for people to have a better understanding for exactly what MEVs are in the real world. Can you quickly just explain what each of these attacks are, and why they're bad? So again, there are front-running sandwich attacks and time bandit attacks.

[00:08:57] Tushar: Yes, absolutely. Those are three types of MEV that I would classify as malicious MEV. Not all MEV classifies as malicious MEV, in my opinion. For example, arbitrage trades do not classify as malicious. They're in fact, enabling efficient operation of markets. But let's discuss these three specific attacks. 
 

[00:09:21] Front-running is exactly what it sounds like. If I am the trader and I see that you are going to go buy asset XYZ, I can go buy it before you, and then sell it to you at a higher price. And when I do that, I am taking money from you and rewarding myself.  
  

[00:09:43] Sandwich attacks are just a specialized form of front-running. Specifically related to automated market-makers. But generally the concept is the same. I see that you're about to do a trade. I do that trade before you in order to give you a worse execution price and extract some profit. 
 
[00:10:05] Time bandit attacks are...
 
 [00:10:06] Richard: By the way, just to quickly interject. Front-running a sandwich attacks are only made possible because of AMMs though. With order book exchanges, the traders can specify the worst price at which to execute, and therefore wouldn't be susceptible to these kinds of attacks as the trace are seen in mem pool by miners of validates. Is that correct?

[00:10:29] Tushar: Not necessarily, even on the AMM protocols you can specify your maximum slippage or the worst price you're willing to accept. So you have that ability on both order book exchanges as well as automated market makers to put in, you know, the worst price that you will take. 

[00:10:48] Ed: Yup. And if I could just jump in here. One of the things that happens in a world with a lot of MEV extraction is if you say that the worst price I will take is X, then you're pretty much guaranteed to get X. Because the difference between X and what you would otherwise have gotten ends up in the pocket of an MEV extractor. By doing front-running or sandwiching or something like that, they can see to it that you get the worst price you're willing to accept.

[00:11:14] Tushar: That is correct. And MEV effectively turns market orders into limit orders.

[00:11:21] Richard: Mmm. Interesting. That's a nice summary. So, sorry, I cut you off. Can you move on to explain time bandit attacks? 
 

[00:11:28] Tushar: Yes. So time bandit attacks are the most dangerous and probably the worst form of MEV because they mess with consensus and cause block rollbacks. So an example of a time bend at attack is I saw a very profitable trade happen. But I didn't get that trade. That block was confirmed, but I go back and I try to compete with the block that was already confirmed in order to earn that profit rather than building on top of that block and moving the chain forward. And this is harmful for consensus. Can lead to rollbacks, and is generally very, very negative.

[00:12:16] Richard: And when here, when you say I see this trade as very profitable, but I didn't get to execute it. I mean a miner validator or a flash bot working in consortium with them? Is that correct? 
 

[00:12:28] Tushar: In this case, it would mean specifically a miner or a validator who has the ability to go and compete to produce that block. So to give a precise example in the current proof of work, Ethereum network. There are these things called uncle blocks. So what happens sometimes is, you know, people will produce blocks at the same time without knowing the other one has produced a block. And then the rest of the miners have to decide, which block are they going to follow? 

[00:13:01] And MEV can impact those types of decisions. Or even worse, if I'm an Ethereum miner today and I see that Ed did some trade and was able to produce the block. I can refuse to accept that block and just create my own block that goes in that same block height and try to encourage everyone to build on top of my block rather than his, because I will make more profits that way. And so you can see why this is very malicious and negative.

[00:13:38] Richard: Yeah. This also assumes though that whoever wants to execute time bandit attack has sufficient hash power or validating set to carry that out. Right? So this would also imply the network on which this is being done would have a centralization of the miners or validators. Is that correct?

[00:13:57] Tushar: Not necessarily. You don't need to own 51% of the hash power or the stake in order to execute a time bandit attack. You can also issue a bounty that incentivizes the other miners to coordinate with you in order to execute the time bandit attack. And example of this though, not MEV specifically was if you all remember when Binance was hacked for, I recall, you know, something like 7,000 Bitcoin or... 

[00:14:30] Richard: $400 million 

[00:14:31] Tushar: I forget exactly how much it was. But it was a significant amount of Bitcoin and they briefly contemplated just publishing the private key that had been hacked and that could have caused all of the Bitcoin miners to stop mining on the current longest chain and go back to the point where the hack happened and try to produce rival chains from that point on in order to use that now open, private key to give themselves the Bitcoin rather than the hacker getting the Bitcoin. And that would be an example of a time bandit attack. 
 

[00:15:12] Richard: Hmm, I see. Sorry, not to distract further, but why would that benefit Binance though? They would still be losing that 7,000 Bitcoin, just not to the one hacker, but to all the other miners.

[00:15:27] Tushar: That's correct. That's why they didn't end up going forward with it. Also, it would have been quite bad for Bitcoin if that had happened. (Oh, yeah.) So I think, you know, they thought about the externalities of their actions and decided to not do that. But it was a very interesting thought experiment at the time.

[00:15:45] Richard: Okay. So these are all malicious attacks like you pointed out and I'm sure Ed would agree. So you had mentioned earlier about some forms of MEVs actually being good MEV. Can you elaborate on that a little bit more? 

[00:16:02] Tushar: Yes. So there are forms of MEV which actually enable better execution for traders. An example of that, that we are seeing on Ethereum today is people actually providing liquidity into an AMM pool, right before a trade occurs. Which effectively gives the trader a better price, but reduces the amount of trading fees captured by the passive liquidity providers in that AMM pool. So, another way to think about this for some of the listeners who might be more familiar with TradFi and central limit order books is if you see a large order come in to the order book and it's a market order, and you quickly submit more liquidity into the order book such that that market order gets a better fill than it would have if it was just going down the order book and only taking advantage of orders that were already on the order book.

[00:17:15] So that's one form of positive or beneficial MEV, in my opinion. Because here you have a trader who is specifically going and acting on chain based on someone else's transaction. Is probably paying a large gas fee or tip to the miner in order to get their transaction included. Probably using a tool like flash spots bundles to get guaranteed execution. And is actually leading to better execution for the trader. And an exchange is collecting the trading fees, which would have otherwise gone to passive LPs. 

[00:17:56] Another example is simple arbitrage. You see the price on two different exchanges is out of line and you do a trade to bring those prices back in line. Having prices come back in line with each other is net positive for the whole ecosystem. We want all traders to get fair execution and to be able to get fair execution no matter where they are, and you know, which exchange they trade on. You don't want the price of a token to vary significantly from exchange to exchange. And so arbitrage is beneficial for the efficiency of capital markets.

[00:18:32] Richard: Okay. So, yeah, it sounds like if you were to delineate the good MEV from the bad MEV, kind of like the good fat from the bad fat, you kind of have a point there. Not sure how Ed would be thinking about this when you talk about always reducing MEVs. What are your thoughts in terms of the pros and cons of the MEVs that Tushar mentioned?  
 

[00:18:54] Ed: I would say two things. First all, on the first one, if you listened carefully to Tushar's description there of his first example, he did point to someone who is worse off because of this. It was the liquidity providers who were there in the first place, right? And so when that form of extraction becomes possible, it deters people from being in that early liquidity provider role. 
 
[00:19:21] So whenever you extract from one party in an interaction in order to benefit another party, the party who is extracted from is deterred and you get less activity. So it's not a free lunch. Right. Someone gets an advantage that someone else doesn't get. Similarly with arbitrage. If an arbitrage opportunity exists, the question is not, will someone take advantage of that. The real issue is who's going to take advantage of it. And I guess my question is, as a system designer is, why should we favor one party over another to get that arbitrage opportunity?  
 
[00:20:00] The other thing I would say, and I think this is really important is that, you're not going to find a way to eliminate the bad MEV while preserving the good MEV. If someone has power over the ordering of transactions, or if someone has power to put transactions into the sequence through a back door, through an advantage position. If they have that power, they're going to use it in a way that benefits themselves maximally. And so if they have some, um, what they consider good MEV to take advantage of, they will do that. 
 
[00:20:37] If there's some other MEV of the kind that we agree as harmful, they'll take advantage of that too. So I don't think there is a sort of selection where we get to pick only good MEV or MEV we think is good and not get the bad MEV. The question is really, is there a person who's in a position to extract value because of their ability to influence transaction order? 
 

[00:21:01] And if there is, what are we doing to stop them from doing that? Because if someone is in that position and we're not doing something to stop them, they will extract and they'll extract more. Including a lot of the things that I think we all agree are harmful.  
  

[00:21:15] Tushar: I'd like to respond to that. 

[00:21:18] Richard: Yeah. Go ahead. 

[00:21:18] Tushar: So a few things. One, Ed you asked, " Who should get the arbitrage?" And my claim there would be from the network's perspective as a systems designer, I think the entity that should get the arbitrage is the entity that is willing to pay the highest fees to the network. Because the highest fees to the network helps secure the network.

[00:21:42] So I think that's a very clear line. Whoever's willing to pay the highest fees is the one who should get the arbitrage. And by doing that we have MEV in that, yes, the block producer is actively deciding discretionarily, which actor gets that arbitrage profit. But that profit is going towards the benefit of the whole system by increasing the security of the system.

[00:22:11] Ed: So this assumes that we're in a situation. I think you're assuming that we're in a situation where giving more money to the miners is good for the system as a whole. And I think in general, that's not necessarily the case. There are some amount of mining that is efficient and we'd like that amount to happen. And the question is how do we pay for that?  
 
[00:22:37] And giving rewards to miners based on say the susceptibility to MEV extraction of the things they do is not necessarily going to lead to the best outcomes. Some ordinary user transactions create MEV extraction opportunities and some don't. And we don't necessarily want miners to favor the ones that create MEV extraction opportunities. 
 
[00:23:08] In general, I think when we think about how to cover the operating costs of a system and how to induce people to use the system efficiently, what we want to do is arrange things so that the cost of a transaction is closely related or even proportional to how much cost it imposes on the people operating the system. 
 
[00:23:31] Right? if you and I are optimizing our transactions to try to reduce the burden that they put on the network, then the network will operate most efficiently. Whereas if we're optimizing our transactions for something else, then you're going to get transactions that are not as well designed for the efficiency of the network. 
 
[00:23:50] And when we think about, at least about the design of our network, we think a lot about this. How can we better align the cost and benefit structure for our users, with the overall goal of efficiently sharing the network's resources? And so anything that distracts from that in my view is going to lead the system to operate less effectively. 
 
[00:24:11] And if the system is less efficient because people are optimizing for things other than reducing resource use, what you end up with is a system with a higher cost of operation, more congestion, and people pay for it through the back door. 
 

[00:24:26] Tushar: So that is possibly true, but not always true, right? Like we have different actors in the system that should be acting in their own incentives and should not need to trust each other in order to make the system function. So if I am a adapt developer. You know, I'm building a DeFi exchange for you know, whatever tokens. 
 
[00:24:50] Then it's my responsibility as that developer to try and structure my transactions, such that the users who use my dapp end up getting good execution. An example of that is, users interacting with my AMM protocol being able to specify a maximum amount of slippage that they're willing to incur in that transaction, right. Though you can do many more advanced things as well.  
 

[00:25:16] But at the same time, like that is not the responsibility of miners or stakers in a proof of stake system to ensure that, right? I think if you want the system to be stable, you should have the block producers acting in their most selfish self-interests. You should have the DAP developers working in their own selfish best interests. The traders working in their own selfish best interests. And you need to design the system for those actors to come together in this way. 
 
 [00:25:47] Ed: Right 

[00:25:47] Tushar: And so that's why I'm thinking that it's actually net positive to have a system designed with MEV in mind. Knowing that MEV is going to happen, that you can't eliminate all of it. So why don't we try to redistribute some of it to block production and chain security rather than potentially take approaches like, you know, randomizing the order that transactions are within a block, which just creates negative externalities. Because now you don't have deterministic ordering which messes a bunch of other things. 
 
[00:26:23] And so, that's really the core of my argument is the motion that we're discussing is should we always try to reduce MEV? I agree that we should do common sense things to reduce malicious MEV, but I disagree that we should always do things to reduce MEV. Because sometimes MEV has positive externalities.  
 

[00:26:45] Ed: Right. So the question is, so if you're postulating that some types of MEV are positive but most are negative. Can you design a system that actually distinguishes those? So only the positive kinds are possible and the negative kinds are not. Because otherwise you're going to get more of both kinds. And you're going to end up with a more negative system, right?  
 
[00:27:07] And I agree that you want a system in which if parties behave in their reasonable self-interest that the collective outcome is efficient. But I don't think it's efficient to be in a world where there are parties who are either centralized or serial centralized. And I'll say in a minute what I mean by that, and then are able to effectively extract large amounts of value from everybody else.  
 
[00:27:31] But let me take a minute and talk about this sort of serial centralization concept, because I think it's important to understand what's going on often with MEV extraction and systems. 
 

[00:27:42] So we could probably agree that a centralized system where like one party got to be the miner every time and just make whatever blocks they want would be harmful. What proof of work and proof of stake chains tend to do is a serial centralization where say in a proof of work system, the miners all compete to solve some hash puzzle and whoever solves it first, they get to be the king for the next block.
 
 [00:28:08] So we don't have one king for a long time. What we have is a series of kings who were each a king for say 15 seconds. And this notion of kind of rotating monarchy is better than a long-term Monarch, but it's certainly not an ideal in terms of how we think about how a system should be designed. Because by giving that party a large amount of power, even for a period of seconds at a time, they are in a position to extract a lot of value from other people.
 
 [00:28:40] And that's what you see in systems. And that's indeed why this concept was called Miner Extractable Value in the first place. Because of a realization that the researchers who initially discuss this had, that miners in a system like Bitcoin or Ethereum, and especially Ethereum had a huge amount of power to extract a lot of value from everybody else.
 
 [00:29:01] And again, like I said, at the beginning, a miner who is greedy and trying to extract as much as they can is extracting from everybody whenever they can and they're not just extracting the kind of MEV that you might classify as good. They're extracting all of the MEV. And to the extent we can find ways of reducing that extraction, we'll be better off overall because on net, MEV is in my view clearly harmful and I haven't seen any proposals that would be able to separate types of MEV to say that some types can be extracted and other types can't. 
 
 [00:29:36] Richard: Okay. Alright Tushar. Go ahead. 

[00:29:37] Tushar: So there are some ways to address this, right. Like I agree with you, Ed. You can't have a clear line that says this MEV, or we will only allow this type of MEV and we will not allow that type of MEV. That is extraordinarily difficult. Possibly not possible. I don't know.    

[00:29:56] But what I can say is that we can be smart and address the main sources here, right? And example of this is, in our proof of stake system, you can do things with slashing to reduce the ability for people to execute time bandit attacks. Right? If you double sign blocks, you can get slashed is the simplest example of this. But we can have more complex structures in a proof of stake system to reduce the ability to have time bandit attacks. 
 
 [00:30:26] If you want to reduce front-running attacks. You can have users use a private RPC and perhaps that's built in to their wallet. Whether they're using, you know, a MetaMask or Phantom or, whatever wallet they're using, you can have a private RPC built in, in order to reduce some of the harmful MEV.
 
 [00:30:46] But I think we have to be careful as we're designing these systems to not go too far. Because just like our immune systems are really powerful at fighting pathogens that can be negative if, they're tuned up too strong, you get auto-immune disorders. And actually you start attacking your own body. And that is what I'm arguing against is going too far in fighting MEV can cause effectively an auto-immune disorder for the system where it's actually attacking itself because it's too aggressive.
 
 [00:31:20] Richard: Okay. So why don't we talk about some specific examples here? So Tushar, I noticed on multi coins website. Your team, and I think specifically you has published a writeup about Eden network that multi coin has invested in that effectively uses some type of MEV auction to quote unquote, "Make the best of the fact that there will be MEV". 
 

[00:31:45] And then after this, I would love for Ed to maybe talk about some of the advancements in the protocol design land to deter MEV as much as possible. So maybe Tushar, go ahead and talk about Eden first. Tell us what it does and how is it making the best of the inevitability of MEV.
 
 [00:32:05] Tushar: So Eden is really focused on one specific goal, which is how do we financialize MEV and redistribute it to the players in a way that creates the most positive externalities for the whole system. 

[00:32:23] The first implementation of Eden was on proof of work Ethereum, and the intention was to find a mechanism where you have a continuous MEV auction and that MEV auction is done using Eden tokens. And Eden tokens are mined by the Ethereum block producers in order to increase rewards for those block producers and therefore increase the chain's security. Eden has since then been working on research and development in proof of stake systems and I expect that they'll have some announcements about how they intend to work with proof of stake systems, notably Ethereum after the merge, but other EDM chains as well. With this specific goal of reallocating MEV in a way that boosts security and helps create positive externalities. 

[00:33:23] Richard: So, if I understand correctly, the miners in Ethereum have been persuaded to run a modified Ethereum client made by the Eden team, such that the mining takes place in a way that prevents bad behavior of the value extracting nature. Is that correct? 

[00:33:42] Tushar: That is correct. I do have to say the Eden team cannot take sole credit for creating this code, you know, we all stand on the shoulders of giants. And they've been many many contributors. Yeah. 

[00:33:53] Richard: Oh yeah. The modified, modified version of the Ethereum client, of course. I mean, to me this is essentially MEV auction, but the payments are in staking form. Right? But at its very core, it is some kind of MEV auction, essentially giving away the MEV to whoever stakes the most amount of Eden tokens or whoever pays the most, essentially. Is that correct? 

[00:34:17] Tushar: That is a fair assessment. One other way to look at it is just giving network participants deterministic block ordering. If I know that I am the top staker and you're the second top staker an Ed is the third largest staker. Then we know that whenever we submit transactions, my transaction should always go first in the block. Yours is second and Ed's is third. And you should be able to act with that fact in mind. So if you know that ahead of time, that will change some of your behavior. And you can imagine that being played out to many more than three participants. But having deterministic ordering of transactions within a block can reduce harmful MEV. 
 
[00:35:03] It can't eliminate it. I have to admit. You know, you can't eliminate harmful MEV. But it can reduce harmful MEV because, in order to front run someone, it's extraordinarily difficult if you don't know which, uh, slot they're going to be within the block, right. How do you sandwich attack them if you don't know which slot they're going to be in. 
 

[00:35:22] And that reduces the ability to do those negative malicious things. So that was the first attempt now. I think that is going to get a lot more sophisticated with proof of stake networks, because you can introduce the concept of slashing based on misbehavior. Whereas in proof of work networks, that is very difficult, if not impossible to do.
 
 [00:35:45] So, I'm very excited about the possibilities for deterministic transaction ordering within a block.
 
 [00:35:51] Richard: Okay. Ed, do you have anything to add about the Eden design for making the best out of the inevitability of MEV? 

[00:36:00] Ed: Well, so I have not studied Eden so, I don't want to try to analyze or critique the design here. I do think though that the idea of just accepting that there will be a lot of MEV and selling it is I think not the best approach. Or at least I would say that first try to reduce the MEV opportunities that exist. And then, once you have gotten rid of as much as you can, only then would I think about how to order or structure an economics around what remains. 

[00:36:34] In general, I think it's best to try to reduce MEV as much as you can as a first step. And then yeah, if you can't figure out how to get rid of more then, um, yeah. Then think about how to design an economy around it. 

[00:36:47] And I think, you know, if you're in the world of proof of work or eventually proof of stake mining where you have this kind of serial, um, centralization going on then, thinking about, well, how can we structure that? An economics around that, yeah. Makes a lot of sense. But I would not start by conceding that that kind of overall design for how blocks get made is the best from the standpoint of user experience or efficiency. 

[00:37:17] Richard: Okay, so let's go back to a previous question then related to this. You had mentioned in an article "Five theses about transaction ordering, MEV, and front-running" that some advances in recent research has been done to mitigate front-running to begin with. So to your point, we want to tackle the reduction of MEV as a step zero, instead of admitting defeat and then just working with the status quo. So what are some new developments in the space that you can cite perhaps from your own protocol or some other area where MEV can be mitigated to begin with. 

[00:37:56] Ed: Sure let me talk about some of the things that we are doing in the Arbitrum protocol to try to reduce MEV extraction opportunities. And the first one is pretty simple and that is just to have a very low response time for submitted transactions. So in Arbitrum, when you submit a transaction to the network, you'll get a result back from the sequencer in usually in one second or less. 
 
[00:38:23] And so that's something that users love. I think it's a great user experience, but it also has an interesting effect with respect to MEV. And the reason for this is that in a design like Ethereum, one of the reasons that MEV extraction can happen is because you have a large mem pool of transactions that have been submitted by users that miners have received, but are waiting to be put into blocks. 
 
[00:38:48] And so for a miner that wants to maximize its extractive power, it has a large menu of transactions to choose from because it has, you know, many seconds, 30 seconds a minute or so worth of transactions to select from. If on the other hand, the expectation of users is that their transaction will be included in the transaction sequence in less than a second. That means that that mem pool is very small. And if transactions are not put into order very quickly, if they don't pass through that mem pool very quickly, users notice, and the user experience gets worse. And users will push back.  
 
[00:39:25] So just having a short response time is one of the thing, rather than this sort of big mem pool type model, is one of the things you can do. So I think that's number one.  
 
[00:39:34] Thing number two is the direction that we're moving with the operation of our sequencer. So right now that is a centralized component. It's run by our team. We published the code and so on, and we're definitely would be in a position to extract MEV, although we choose not to. 
 
[00:39:52] But in the long run where we're moving to is a distributed sequencer. And this is not one king at a time. This is a situation where you have a committee of end sequencers. And if at least K out of N of them say two thirds, plus one are cooperating, then you'll get a result that is fair. Meaning first come first serve. 
 
[00:40:13] That is the transaction that arrived first at a majority of those sequencers will get into the final sequence first. So that's a different way of dividing power. And it doesn't require you to trust any one party, even for a short period of time. And also if those parties are geographically distributed, it makes it difficult for them to coordinate collective extraction on the timescale that they would need to given the sub one second response time that users are pushing for.  
 
[00:40:46] So to make that sequencer by committee by consensus approach work, you need some advanced algorithmic work. And there's been some great research at Cornell tech on this topic and we'll end up using a solution that is built on that.  
 
[00:40:59] So there are a bunch of things around the design that you can do which don't eliminate, but they reduce MEV. And I think that's important to do. And I think it's especially important to not go the other way and to not choose the design that actually maximizes or increases MEV, which you can do if you're not careful.  
 

[00:41:18] Richard: Okay. So if I understand correctly, Arbitrum is layer-2 and therefore any kind of MEV deterrent benefit would only be enjoyed by users of the layer-2 solution when executing on the Ethereum network. It does not help others transacting on other layer-2s or directly on layer-1. Right?  
 

[00:41:39] Ed: That's right. Yeah. So we've chosen to design our system, the part of the world that we design in a way that tries to reduce MEV 

[00:41:47] Richard: Okay. Got it. 

[00:41:48] Ed: For our own users. Right. We don't have a solution for, or we're not building a solution to reduce MEV for others. I'd certainly encourage people to do that. But it's not what we're doing. 

[00:41:58] Richard: Okay. So previously we talked about centralization and serial centralization. In one of your other articles, you talked about how the existence of MEV leads to mining centralization. Despite the claim that MEV auctions are a way to somehow reduce set centralization. Can you just quickly explain why it actually doesn't work that way? 

[00:42:23] Ed: Sure. 

[00:42:24] Richard: And MEV auctions worsens the centralization problem? 

[00:42:26] Ed: Yeah. So in MEV auction the idea there is essentially that if for some period of time at some block number or something, or maybe for just some like half day, if there's going to be one party who will be in a position to extract MEV, then what you should do according to this theory, which I don't subscribe to, but what you should do according to this theory is you should auction off to the highest bidder the right to be the MEV king for that period. 
 
[00:42:56] And then whoever is the highest bidder that money gets taken and it gets used for, you know, some good purpose. But then that party has the ability to extract as much MEV as they want, however they want during their reign. And what I've argued is that if you do that, if that's your approach, then economic says that in that auction, the high bidder is going to be the party who is most effective and most ruthless about extracting as much MEV as they can from everybody all the time. 
 
[00:43:27] Right? Because whoever that high bidder is, they will need to recover what they paid to be the MEV king. And the party who knows how to, or is willing to be more ruthless to extract more, will be willing to bid higher. And so what you get is a situation where the best MEV extractor in the world is always in that position of making blocks. And you've created an incentive structure where you're practically forcing them to extract as much MEV as they can.   

[00:43:58] So this is kind of what I was alluding to before when I said, you want to try to avoid a design where you create incentives to maximize MEV extraction. Because if you auction off the right to extract MEV, not what Tushar was talking about before. That's a little bit different. But if you're auctioning off the right to be the extractor, then what you get is maximum extraction. And whatever party is the most effective extractor, they will always be the high bidder. And so you're going to have someone who becomes the king for a period of time. And they became the king because they were more ruthless and extractive than anybody else. 
 
 [00:44:36] Richard: Okay. So Tushar in response to that, I think one ethos of the various solutions to the MEV problem have always been, let's try to make MEV auctions transparent, fair, and available to all. What seems to be the underlying truth here is that the right to extract still goes back to the most effective extractor. And in this case, generally is the party with the most capital and the best know-how and so forth. 

[00:45:09] So what are your thoughts in regards to the prevailing solutions right now, and helping make MEV auctions truly transparent, fair, and available? Is that a lost cause? Are there certain constraints that simply cannot be broken in this set up? Or are you seeing new solutions in the horizon that would make this ethos come true? 

[00:45:32] Tushar: I think these things can exist together. But before I go there, I want to respond to a few of the points that Ed made. The first thing I wanted to respond to is the shorter block times, reducing MEV. And Ed said Arbitrum has a one second block time. I agree. I think shorter block times do reduce MEV. Especially if you have instant finality, which you can do in many of these proof of stake systems.

[00:45:56] In fact I'm a big fan of Solana, which has a 400 millisecond block time. And you know, I've joked with Anatoly on like, you know, how do we get it to go faster as we probably need neutrinos to send communication through the center of the earth because light takes too long to go around the outside. Right?

[00:46:12] Like, and so they are very focused on trying to get blocked times down to as fast as possible because, I think everyone can agree that faster finality, faster block times is not only a better user experience, but also reduces opportunities for malicious MEV. To be clear, faster block times do not reduce beneficial MEV. That arbitrage is going to be there. And that arbitrage profit is going to be the same size, no matter how fast blocks are. And that arbitrage is going to be taken by whoever the block producer selects no matter how fast the blocks are. And so, reducing block times is probably one of the highest value add things that any system designer can do in order to reduce negative MEV, and make the system better. 

[00:47:08] However, at the end of the day, we have to expect all these parties to act in their own selfish, best interests. Ed mentioned that right now the Arbitrum team is running the sequencer. And we can expect that Arbitrum incentives are to not extract MEV. As you know, they're running the sequencer because that would just be very off-brand and off ethos, from my understanding. 

[00:47:29] And so when that gets opened up and gets decentralized, which I believe is the goal, we have to expect that those sequencers who joined the network have to act in their own self-interest. Otherwise, they're not going to get any stake allocated towards them, right? If you're the validator who is earning 5% while everyone else is earning 5.5 or 6%, then the stakers will just allocate away from the low yielding validator, sequencer, whatever the term is and to the higher yielding one. And so there's just like a force of gravity to this stuff. And it's going to drive people towards highest yields and that is going to yield just like you said, it's going to mean that whoever can extract MEV will attract MEV. It's just like a force of gravity. 

[00:48:21] So I think, I can agree that we should do things like reducing block times. Have better synchronization between block producers. Whether they're, you know, the current leader of consensus or not, through mechanisms, like what Ed was describing or what Solana does with proof of history in order to help reduce the flexibility that those block producers have to extract malicious MEV, but does not reduce beneficial MEV.

[00:48:51] Richard: Okay. Did you want to respond to the question that I raised at the end, though? About making MEV auctions transparent, fair, and available to all? This vison... 

[00:49:00] Tushar: Yes. Absolutely. Because right now, there are MEV auctions happening. They're just happening in secret. There are backroom deals that happen between mining pools and trading firms to give those trading firms preferential treatment or access. There are preferential deals that happen between what are called searchers and staking operators. We all know these staking as a service operators. And they look for ways to increase revenue and they're doing these deals that are only available to people who have the relationships and have the capital and have the technical sophistication. 

[00:49:37] This was part of what excited me about Eden when we announced that and, you know, we've made several other MEV related investments at Multicoin since then that we're also very excited about. And one of our core values for that is, it should be open and permissionless and everyone should be able to access these auctions. It should not just be the big trading firms who can work a backroom deal, being able to access these auctions. 

[00:50:05] And I think we have to promote these types of solutions that open up access to MEV because we can't eliminate it. And I don't think anyone in the ecosystem wants MEV to be centralized with big trading firms that have preferential treatment or preferential access. No one wants that. We want the new market participant, the individual who shows up with a laptop and some coding skills and, a hundred bucks of ETH or SOL or whatever to their name, to be able to participate in these MEV trading activities just as efficiently as the biggest trading firms out there.

[00:50:47] And so I think we have to as an industry not just try to ignore MEV or try to eliminate it or say, oh, this can't exist. Or, you know... I think in addition to trying to reduce harmful MEV, we need to promote these solutions that encourage transparency and open access like Eden. 

[00:51:04] Ed: So I think we agree on that point, actually. So, my view is first reduce MEV to the extent you can. Try to minimize it and then having done that you will not have gotten rid of all of it. And so with the MEV that remains, you do want to have a situation which is as open and transparent and fair to different market participants as you could get.

[00:51:30] So I don't think we disagree about what to do with the MEV that remains. But I do think that it's important to minimize first, before that happens. And so I don't think that the contradicts the thesis that I'm arguing for here that we should reduce MEV. Right. That's really just about what we should do after we've reduced it. What should we do acknowledging that we have not completely eliminated it. 

[00:51:59] Tushar: I agree with that. And my entire position for this debate is really centered around the use of the word "always" in the debate prompt. Because there are mechanisms that can be implemented that reduce MEV but create negative externalities. And those are the harmful ones. That's the auto-immune disorder analogy that I was making earlier. You know, an example of that would be a system that randomizes the order of transactions within a block and just reduces the types of execution guarantees that traders may need in order to provide efficient functioning of markets. 

[00:52:41] There are other mechanisms as well that people have contemplated. You've probably seen a lot of these where it could reduce MEV, but it's also very costly and negative in other ways. 

[00:52:54] Ed: Sure and it's not the case that I wouldn't argue that MEV reduction is the only goal. The only good thing that we should be aiming for in designing systems. Clearly, if you changed that could reduce MEV a tiny bit, but multiply the cost of the system by a hundred X, is not something I'd advocate.

[00:53:10] What I'm arguing though is fundamentally is that when we're making choices about MEV, we should always be favoring the choice that reduces MEV. That that is a good, and it's not the only good that we're trying to design for in our system. Not the only thing that we seek regardless of trade-offs. Simply that less MEV is better, and that to reduce MEV should be a significant design goal, and we're thinking about how to design systems like this. 

[00:53:39] Richard: Okay. Great. 

[00:53:40] Tushar: I agree with that. If the prompt had been MEV should be a significant design goal, I don't think we'd be having a debate. 

[00:53:46] Ed: Awesome. Maybe we don't disagree that much. Um, yeah. 

[00:53:50] Richard: Okay. Now you guys are making my job difficult by agreeing with each other. 

[00:53:55] Ed: Sorry about that. 

[00:53:55] Richard: It's okay. Let's uh, let's move to audience questions. So one person was asking about ZK block production slash transaction ordering. So I believe this person is talking about, essentially how do you have transactions sit in mem pools and somehow you know that these are legitimate valid transactions, but you don't have insight into whether they would be profitable. Because the whole point of MEV is a miner could be looking at a transaction and essentially wanting to execute that transaction themselves or executing other transactions that would benefit themselves based on the knowledge of each transaction in the mem pool.

[00:54:40] So I think this person is asking the abstract question, if zero knowledge proof technology can somehow be applied to blind the miners or validators from the knowledge of whether they would be benefiting from executing that transaction or executing a transaction that would benefit themselves from the knowledge of that transaction. If that makes sense. 

[00:55:03] Ed: Yeah. I think I understand what the question is getting at. There's something I meant to mention before but didn't, which is one of the anti MEV mechanisms that can be used is to have users encrypt their transactions when they submit them. And you can use a private RPC connection, but you can in some designs do even more so that even the miner or sequence or whatever party is deciding on a sequence of transactions has to commit to an order of the transactions before those transactions get decrypted. Right? So that at least that party doesn't know the contents of the transaction beyond what they can guess. 

[00:55:41] Now that said they do know somethings. They know the timing of it. They know the size of it. They might know the IP address that came from. And so they're not completely without knowledge. And it may just be that somebody knows that getting their own transaction in really quickly or their friend's transactioning quickly is to their advantage regardless of others.

[00:56:00] So it's not a panacea, but there are tricks that can be used there. It's not always simple to incorporate that into protocols because you open yourself up to attacks where say someone submits a transaction and then it gets put into the sequence and then they decide, or they just refuse to decrypt it.

[00:56:19] So, you know, there's some complicated design issues there, but it's one thing that you can do to try to hide knowledge from the transaction ordering party about some of the knowledge about what's in the transaction. That can help. 

[00:56:32] Tushar: Agreed. It can definitely be helpful, but it can't eliminate MEV. Like here are some examples where the zero knowledge solution that you just suggested, like doesn't really help. Let's say we see the state of the current chain and we know that there's a million dollar arbitrage opportunity sitting there. Right. And I am the block producer of that. Well, at that moment. I'm leader of consensus. Well, I'm just going to make sure that my transaction that gives me that million dollar arbitrage is the first transaction in the block, regardless of whether all of the other transactions are ZK or plain text, or, you know, what they are. It doesn't matter.

[00:57:16] And that's still MEV. Other people might've been competing for that transaction. Other people might've seen it first and actually submitted their transaction first. But because I am leader of consensus for that 15 seconds, and I noticed that that transaction was there, I can just make sure that my transaction is the first one in that block. And, you know, I can still get that MEV. So... 

[00:57:37] Ed: Oh yeah. I was going to say, so this is not a panacea. It can help in some cases. If you do it right, it doesn't hurt. So it is a thing that I think some designs will want to use because it can be helpful at the margin. 

[00:57:49] Richard: Great. This person also asks about nonfinancial MEV and he cites these very short phrases as examples, which I made not to completely understand, but maybe you two can shed some light on it. He mentioned game mechanics changing due to transaction ordering, access control lists changing, et cetera. Does that ring a bell? In any way? 

[00:58:13] Ed: Let me jump on the game one. I think I understand what that's about. Basically, there are applications of blockchains that are not directly financial. There may be just games that people are playing for recreation or for bragging rights. And the ability to move first before somebody else moves, or to be able to react more quickly to some change in the game state than someone else did. That might give you an advantage inside the game. And maybe that doesn't translate into dollars and cents, but it's still something people prefer. 

[00:58:43] Richard: Hmm. I see. Okay. Yeah. I mean, I don't know who is writing sophisticated flashbots to take advantage of that kind of bragging right. And if that's a serious problem. Although the same class of problem. 

[00:59:01] Ed: In online games there are certainly are people who use various forms of bots and sort of mechanical aids to give them either faster or more accurate reaction time within the game. And it's viewed as cheating typically. But it is a thing that some people do. And so if you're talking about a game situation where reaction time or sequence of moves matters, making sure that you would want it to be part of the design of the game or the protocol that it's built on that it tries to resist people trying to cheat the timing and move ordering rules of the game. 

[00:59:37] Tushar: I'll take a stab at this access control list changing idea. I think this might have something to do with the white listing of addresses for NFT mints. Or something related to that. We have seen a lot of MEV around NFT mints where we see bundles of transactions that go through that mint all of the NFTs before regular users who don't know how to use those bundles get access to the system at all. And we see other examples of this kind of thing. 

[01:00:09] In my opinion, that's still financial MEV in a sense. Because like people are doing it in order to make money, whether you're front-running someone on a fungible token or a non fungible token, it kind of doesn't matter. It's still financial in my opinion.

[01:00:25] So, it's either you're doing it to make money, or like Ed was talking about, you might be doing something within a game to get status. But I haven't seen any examples of that. There's no games that have enough on chain activity and like a status sort of game where like, this is even plausible today. 

[01:00:43] Richard: Okay. MEV of social capital versus financial capital, I guess. 

[01:00:49] Okay, great. Well, that was a great discussion Ed and Tushar. So let's move on to concluding remarks. So Tushar, maybe starting with you, this is a time to synthesize your thoughts and shed some light on any new perspectives you have picked up from your opponent, and give us the final word on your position on MEVs. 

[01:01:13] Tushar: Absolutely. I want to thank Ed for joining me on this debate. This has been a fun experience and, I've learned quite a bit through this discussion. I want to say a few things that I think are fundamentally true that I don't think anyone would really argue. 

[01:01:28] One is that we cannot eliminate all MEV. Two is that there are some forms of MEV, which are positive and do not have losers. Specifically things like arbitrage rights. Three, that we should seek to make those types of MEV as transparent and permissionless to access as possible. And four, that we should seek to redirect MEV wherever possible to increase the security of the broader network as a whole. 

[01:02:11] I think if you believe those four things, and you think about the prompt very carefully of we should ALWAYS reduce MEV, you can see where my argument comes from. That we should seek to reduce MEV where it is harmful and where we can reduce MEV without negative externalities. But it should not be the only goal of system design. And rather than being over-focused on eliminating all MEV whatsoever, we can redirect some of that focus to redistributing MEV and using it to help make networks more secure. 

[01:02:55] Richard: Great. Ed your turn for the closing remark. 

[01:02:59] Ed: First, let me think Tushar for being a civil eloquent and worthy, um, I won't say opponent. I'll say counterparty in the debate. I really enjoyed it. And hope it's been enlightening to the audience. 

[01:03:11] The most important thing I think about MEV, I think there are several important things about MEV. I agree that we cannot entirely eliminate it. There are many things in life that we wish we could eliminate, but we can't. And we need to understand how to cope with them. 

[01:03:27] I think Tushar puts a lot of emphasis on this argument that there's good MEV and bad MEV. But I think at the end of the day, that doesn't matter because we don't know methods that can separate those. That if a party is in position to extract MEV, if they have that power, if they're in a scenario where it is approved or expected behavior for them to extract MEV, they'll extract all the kinds. And harmful MEV is larger and it's a bigger problem.

[01:04:03] And so I don't think we could in practice say, let's just take the good kind and not the bad kind. MEV is something that we wish we could get rid of. We should try to get rid of it to the extent possible within reason. And then having eliminated what we can. I agree that the way we deal with the rest should be as transparent and pro-social as we can.

[01:04:27] But the bottom line is MEV is today a significant problem in the design of blockchain systems. It is a hidden tax. Often hidden on much of what we do and it deters activities. It's one of the things that scares users away from using these systems. So we should reduce it to the extent we can. At the end of the day, the question here is not, what should we do about the MEV that remains. The question is not, can we eliminate all MEV. The question is, should we be trying to reduce MEV where we can?

[01:05:04] I think the answer is yes. I think MEV is on net harmful. And we should reduce it as much as much as we can. 

[01:05:11] Richard: Great. Is there a quantification of the amount of MEV being extracted from various chains today? Is published somewhere?  
 

[01:05:21] Ed: I think there have been some academic studies that try to quantify the Ether amount of MEV that is being extracted or the amount that could be extracted. It's difficult to tell because the MEV extractors don't always, uh, for obvious reasons don't want to talk about their methods or everything that they do. 

[01:05:40] Richard: Okay. 

[01:05:41] Ed: So I think we don't have a good picture of how much is being extracted. A lot of people believe that it is a lot. But we don't really know a lot of this happens in the darkness.  
 

[01:05:51] Tushar: Agreed. I think the best estimate that we have is that it's north of a billion dollars in 2021, and I expect it to continue growing.  
 

[01:06:00] Richard: Yeah. And how much of this do you think is a clever miner being vigilant about scanning the mental and picking up transactions that would benefit them and how much of this is backroom deals? And how much is something else? 

[01:06:14] Tushar: What's the difference?

[01:06:16] Richard: The difference being the first one is there's no backroom deal, right? It's just somebody literally finding a transaction that would benefit them and they would just execute (based) upon what they observe. The second one actually requires human coordination.  
 

[01:06:32] Tushar: I mean, if you think about it, right? Like the mining pools are not just a person, there's a team. So whether you're doing a backroom deal with someone else who works for the same company and they're finding it. And then you're putting the transaction in the block. Or if you're working with a third party who finds the transactions and pays you a fee, fundamentally it kind of comes out to the same... 

[01:06:53] Ed: Yeah 

[01:06:53] Tushar: ...thing. 

[01:06:55] Ed: Yeah. If something is worth a billion dollars or more a year, it will be available as a service to anyone who wants it. 

[01:07:02] Richard: Hmm. Got it. All right. Well, thank you both for joining the debate today Ed and Tushar. So how can our listeners find both of you starting with Tushar. 

[01:07:13] Tushar: So you can find me on Twitter @TusharJain_. Now that's spelled T U S H A R J A I N. And an underscore at the end. Or you can follow my writing @multicoin.capital, which is our blog. And we try to publish what we think on there, with a pretty frequent publishing schedule.

[01:07:35] Richard: Okay. How about you Ed?  
 

[01:07:37] Ed: You can find me on Twitter @EdFelten. That's E D F E L T E N. (Or) you could follow my company Arbitrum, at arbitrum.io. 

[01:07:47] Richard: Great. Thank you both. So listeners, we would love to hear from you and to have you joined the debate via Twitter. Definitely vote in the post debate poll. Also feel free to join the conversation with your comments on Twitter. We look forward to seeing you in future episodes of the Blockchain Debate Podcast, consensus optional, proof of thought required. 
 

[01:08:03] Thank you, both Ed and Tushar. 
 
 [01:08:04] Tushar: Thanks, Richard. Thank you, Ed. 

[01:08:06] Ed: Thank you both. This was fun. 
 
 

OUTRO

[01:08:08] Richard: Thanks again to Ed and Tushar for coming on the show.  
 
[01:08:13] What I learned is that MEV is inevitable, and there seem to be some advancements in reducing it in protocol designs, although they're not battled-tested and it's unclear what kinds of negative externalities they might introduce. In the meantime, as long as MEV exists, let's try to get it distributed fairly, or at least transparently.  
 
[01:08:38] What was your takeaway from the debate? Don't forget to vote in our post-debate Twitter poll. This will be live for a few days after the release of this episode. Feel free to say hi or post feedback for our show on Twitter!  
 
[01:08:49] If you liked the show, don't hesitate to give us five stars on iTunes or wherever you listen to this. That will help me reach more listeners and get more people to learn about the space. 
 
[01:09:01] And be sure to check out our other episodes with a variety of debate topics: Bitcoin's store of value status, the legitimacy of smart contracts, DeFi, POW vs POS, the merits of economic bailouts, the case for central bank digital currencies, and so on.  
 
 [01:09:18] Thanks for joining us on the debate today. I'm your host Richard Yan. And my Twitter is @gentso09. Our show's Twitter is @blockdebate. See you at our next debate.