Anna Rose (00:00:05):
Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast, we'll be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online.

(00:00:27):
This week, Tarun and I chat with Mallesh Pai, Associate Professor of Economics at Rice University. We explore mechanism design in economic context and his work around MEV topics, specifically his work on censorship in MEV. This discussion brings us back to the MEV topic where we revisit the proposer builder separation concept PBS and the impact that this may have on efficiency and censorship resistance of these systems. But before we kick off, I just want to remind you to check out the zkJobs board this month with the zkSummit around the corner. It's happening on September 20th in London. Many of our sponsors have put their jobs on the zkJobs board. If you're looking for a new job or opportunity in the field, be sure to check it out. We'll add links to the show notes. Also, a quick note, we're going to be taking a few weeks off of the show so that the team and I can focus in on the zkSummit, but expect another episode later this month. Now, Tanya will share a little bit about this week's sponsors.

Tanya (00:01:22):
Anoma's first fractal instance. Namada is launching soon. Namada is a proof of stake L1 for Interchain asset agnostic privacy, Namada natively interoperates with fast finality chains via IBC and with Ethereum via trustless two-way bridge. For privacy Namada deploys an upgraded version of the multi-asset shielded pool circuit, otherwise known as MASP, which allows all assets fungible and non fungible to share a common shielded set. This removes the size limits of the anonymity set and provides the best privacy guarantees possible for every user in the multichain. The MASP circuit's latest update enables shielded set rewards directly in the shielded set, a novel feature that funds privacy as a public good. Follow Namada on Twitter @namada to learn more and join their community on Discord discord.gg/namada. So thanks again Anoma.

(00:02:12):
Ever feel like developing zero knowledge proofs is a daunting task? Well, the team at RISC Zero is here to remind you that it doesn't have to be that way. Their out-of-the-box tooling allows developers to access the magic of ZK proofs from any chain without needing to learn custom languages or build custom ZK circuits. Bonsai RISC Zero's most anticipated product allows developers to prove huge programs off-chain, roll them into one succinct proof and verify anywhere with low amounts of gas. Visit R0.link/zkpodcast to learn more and to sign up for the Bonsai wait list. And now here's our episode.

Anna Rose (00:02:52):
Today I want to welcome Mallesh Pai, Associate Professor of Economics at Rice University and someone who's working on mechanism design at the Special Mechanism Group. Welcome to the show, Mallesh.

Mallesh Pai (00:03:03):
Hi, glad to be on.

Anna Rose (00:03:04):
We have Tarun joining this one as well.

Tarun (00:03:06):
Hey, excited to be back.

Anna Rose (00:03:08):
Yeah, and today we're going to be doing a return to the MEV topic. I'm going to add links to, I think we've done at least 4 episodes that touch on MEV specifically, and we're going to add these in the show notes And yeah, I think what we wanted to talk about in this particular one was the work that Mallesh has been doing around this field and also maybe a little bit more of a focus on MEV and censorship. But before we start that Mallesh tell us a little bit about yourself. What got you interested in this topic and what exactly are you actually working on when it comes to this?

Mallesh Pai (00:03:41):
Awesome. Yeah, thanks for having me on. So I'm like you said, I'm an Associate Professor of Economics at Rice and my day job or my training is in mechanism design and mechanism design is kind of the engineering wing of game theory. So game theory tries to study strategic interactions and tries to understand how participants will play. Mechanism design is the engineering wing of that. So instead of studying a specific strategic interaction, we ask how can you design strategic interactions to get the right kind of outcome? So auctions and Tarun was on the show about that a few months back is a specific example of a broader set of tools that we have in the mechanism design toolkit. Now around the pandemic, so I've always had friends who've been talking my ears off about crypto. I sort of understood it from the background, but I wasn't super into it. Around the pandemic, I decided that there was only one way I was ever going to learn this, which was to teach a class on it, and I decided to teach a sort of undergrad economics class trying to put together how do we think of crypto from a game theory perspective, and the really hard part of doing an undergrad class is you really have to understand it and you have to be able to break it down. That got me started on my journey and then sequence of unlikely coincidences later, I'm here now.

Anna Rose (00:05:07):
Nice. When you say mechanism design, I guess auctions is a form of mechanism design, but what else would fall under that category that we might be familiar with?

Mallesh Pai (00:05:17):
Things that don't use money. So for example, matching mechanisms. If you know anyone who's a doctor in your family, they got matched after their MDs to go to a hospital using a mechanism that doesn't use any money, but does take preferences from people, both the people, the doctors and the hospitals, and tries to come up with a match that has good stability properties. Another example is voting systems. We need to select a president, a governor, a mayor, different countries, different cities do things different ways and all of these are examples of mechanisms that take people's preferences and shove them together and try and come up with a good outcome.

Anna Rose (00:05:56):
That's interesting. As you said it, you said mechanism design. What kind of popped into my head was incentive design, but I guess incentive is the type of design with money usually or with some sort of benefit.

Mallesh Pai (00:06:08):
I mean even stuff like voting is a form of incentive design because you care about your mayor or you care about your president, so you do need to design, even there you're designing incentives. I think things like auctions are just the incentives are your money and your profit, but mechanisms can be much more broad.

Tarun (00:06:28):
I mean, one thing I will say is I remember going to one of the main conferences and mechanism design like last year EC, which I think Mallesh was a chair of this year or virtual chair.

Mallesh Pai (00:06:41):
Well, it was virtual chair. Yeah.

Tarun (00:06:43):
I remember going to the mechanisms without money conversation and talks, and honestly, I find that everyone who talks about mechanisms without money is lying to themselves so that they can say that there's no money used because you're still metrizing something, you're still giving numbers and weights and solving some optimization problem, which is not that different than number. You just don't want to call the numbers money. You want to call the numbers some other embedding of preferences into some space, but I find the phrase mechanisms without money, a bit duplicitous in the sense that they're both end up solving some optimization problem then.

Mallesh Pai (00:07:19):
Oh, definitely. It's just that we explicitly mean money isn't changing hands, but you still might value the stuff and money. Yeah, exactly. So I think mechanisms without money just means money doesn't change hands on the other hand, in crypto money or things that are worth money often does change hands.

Tarun (00:07:37):
Well has to change hands, right?

Mallesh Pai (00:07:39):
Yeah.

Anna Rose (00:07:40):
You're an Associate Professor of Economics. Is mechanism design traditionally in economics? Is that where that is being developed?

Mallesh Pai (00:07:50):
It's sort of a long history. It started in the 70's. It was sort of a part of operations research, so game theory and mechanism design started off in applied math and operations research, then moved to economics through the 80's, 90's, 2000's, and then in the late 90's-2000's, the computer scientists joined in and now we have sort of EC, the conference that Tarun refers to is now one of the largest places and so we have a lot of people in computer science working on this, we have a lot of people in economics still working on this and the operations researchers have joined back in. So there's a bunch of people in OR also working on mechanism design questions and it's because all three fields, economists think a lot about incentives. Computer scientists think a lot about, well, you can think about incentives, but you need a mechanism that's computable or that can be efficiently computed and run and operations researchers are thinking about, okay, if you're going to use this mechanism for kidney exchanges or things like that, which is things that they've been used for, you want to think about the actual logistics of these markets and how they weigh with the designs that you've sort of proposed.

Anna Rose (00:08:59):
Oh, interesting. That's cool. You are part of this group called the Special Mechanism Group. Can you describe what that is? So this is outside of your academic work, I guess?

Mallesh Pai (00:09:09):
Okay, that's right. So I'm a senior mechanism designer at Special Mechanisms Group, and what this is it's a MEV research and tooling outfit. So we want to push forward the research and the thought space that comes around MEV and ideally we'd like to be part of helping to solve these questions or at least make them better.

Anna Rose (00:09:35):
Cool.

Tarun (00:09:35):
One question that maybe more listeners who've listened to prior episodes on MEV might ask is, what is the difference between say a special mechanism group versus FlashBots versus Frontier? How do you characterize the things that are different in your view?

Mallesh Pai (00:09:52):
These are questions that go above my pay grade. Up and down the stack we care about decentralization. We care about not having a monopoly on any one part. These are competing firms that we respect, but broadly we also need sort of a collection of solutions and some kind of competition in the thought space around what kinds of mechanisms are we going to propose, what sort of solutions are we going to do at different parts of the stack? So I guess in terms of things that are happening outside my purview, there's differences like FlashBots is pushing privacy in Suave and Frontier has it's new builder, F1B. We have nothing to announce on that front, but from the research angle it's just 3 teams of smart people who are thinking as hard as they can trying to come up with solutions and hopefully some of them will work and work well.

Anna Rose (00:10:48):
I guess, I don't know if this feeds into the topic of censorship, but it seems like the censorship phenomenon is partly due to one of these groups winning and then making choices about what could be or not included. I've always found it kind of funny, the FlashBots whole mantra was like, we're going to democratize it, we're going to democratize MEV, and yet if everyone uses only their system, then it's actually not as democratized. It doesn't have the anti-censorship. There is still a controlling body in a weird way, but when you add competition, it's almost like they had to request competition. They're competitive and yet their whole philosophy won't work unless there's other players like themselves.

Mallesh Pai (00:11:32):
I guess part of the problem is the trade off between we want competition and we want a diversity, but a lot of the solutions that we propose are two-sided markets and two-sided markets inherently, I guess you were referring to MEV-Boost. If all the validators are selling their blocks in MEV-Boost, then all the builders have an incentive to bid on MEV-Boost, and if all the builders are betting on MEV-Boost, then MEV-Boost blocks are worth a lot. So validators have an incentive to be there. It's really hard to break out of these cold start problems. So credit to them for actively looking for competition and trying to say, we need more democratization in this part of the space too.

Tarun (00:12:13):
Yeah, I mean I think there's maybe a more different take is that there's probably many different solutions to designing marketplaces here for MEV, but you have a cost of actually trying them out. It's sort of like the classical exploration versus exploitation tradeoff which is for listeners who haven't heard of that, that's sort of this idea of suppose I have a hundred coins and I go into a casino and there are 50 slot machines. Each of them has a different expected value. One slot machine might be -1, one slot machine might be +5 if I keep putting coins in. So how should I figure out which slot machine to go to? You have to play to figure out which the expected value. If I play too much at one, then I won't have searched and found possibly a better one. So there's this trade off between the two and it does feel like the mechanism design landscape of MEV has a bit of that where in order to learn how the mechanism works, you have to go implement it, but then you've already caused the market to change by doing it.

Anna Rose (00:13:22):
Oh wow.

Mallesh Pai (00:13:22):
Exactly. And the only thing I'll add to that analogy is at least in just to show you how troublesome this is, at least in sort of Tarun's casino analogy, the casinos were each of these slot machines were paying out a fixed amount. There's some unknown but true sort of +5 EV -1 EV. Here the EV changes based on how many people are using it. So the casino, if a lot of people given slot machine, if a lot of people are using it, maybe its EV goes positive or maybe it suffers congestion and its EV goes negative. So we've got to work through that entire thing.

Tarun (00:14:00):
Since we're on the topic of MEV. A question I like to ask everyone, given that the thing is as dynamic as you're pointing out is what is your current definition of MEV? In fact, one of my coauthors on a paper recently, Guillermo refused to use maximal extractable value and wanted us to go back to minor because he was like, were not achieving the maximum anyway.

Mallesh Pai (00:14:25):
I saw that on your paper actually.

Tarun (00:14:27):
So yeah, I think as any good topic of research, no one agrees on the definition of it, so what's your definition?

Mallesh Pai (00:14:35):
Alright, so I guess I have a more functional definition. I don't have a strong religious view. I've seen memes going around, the one with the sniper and then another sniper pointing at the sniper and stuff and it's like, is it all MEV and yeah, then the last guy says, yes, it always has been. I just have a simple functional view, which is for me currently, the interesting part about MEV is that there's this one person, the proposer who down the line gets to decide what order transactions hit the blockchain and that ability that everything sort of stems from that original sin, which is there's one person with this monopoly power, there are valuable things happening on the chain. So ordering, removing, inserting transactions, all of these things have value. They can extract some of that value and then the questions are who gets to influence that value? How does that value get split up? What happens to sort of the overall economic efficiency of the chain as a result of this? That's the way I think about MEV.

Anna Rose (00:15:43):
What do you make of the sort of MEV blocking techniques that have been proposed? Things like the threshold decryption where that role gets sort of altered?

Mallesh Pai (00:15:52):
Okay, so two parts. One, this could seem, I'm still too much of a professor. I hate making broad sweeping statements, which makes me a bad podcast guest, but...

Tarun (00:16:03):
It really makes you bad at making memes. Not necessarily bad at being a podcast guy.

Mallesh Pai (00:16:10):
Oh, I make the memes and I pass them along to my colleagues who are happy to post them. I don't attribute some of them, I guess I saw this one really good meme about threshold encryption, which is privacy based solutions aren't actually, at least the way I understand them, they aren't creating this level playing field of privacy. They're just choosing winners and losers who gets to see something first. So when it comes to threshold encryption, if it's like N threshold encryption, once N-1 people have in some sort of basic implementation, once N-1 people have decrypted, now the last person has a latency advantage. They can decrypt know what's happening and maybe take other actions before they reveal it to the rest of the world. So my broader take is these encryption schemes expand the possibility space of a mechanism designer or an incentive designer, but they don't make incentive problems go away in and of themselves. Those incentive problems are there, you just need to think about, think more carefully about where they've been hidden.

Anna Rose (00:17:14):
Moved and migrated. Yeah, but do you still think that those should, does that mean don't bother with those solutions or does it mean

Mallesh Pai (00:17:21):
Oh definitely

Anna Rose (00:17:21):
Do, like put them in

Mallesh Pai (00:17:23):
Bother with those solutions? Definitely. Like I said, we need a diversity of thought and we have some of these things might play in interesting ways with everyone's incentive, so we definitely need to push on every angle before we figure out which ones work and which ones don't. Especially while there's energy and lots of smart people are trying to move it forward, I dislike the people who seem to think that if we just threw enough encryption firepower at the problem, all the other problems go away off their own just because you muttered the right sequence of incantations.

Tarun (00:17:56):
As someone who's written a lot of papers proving this type of stuff, I agree. There are a lot of computer scientists who I feel like somehow think, oh, because I've encrypted something somehow no one's able to statistically decrypt things. It reminds me of the philosophical split between Cryptographers capital C who live in the ivory tower and lowercase C cryptoanalysts who try to break crypto systems practically and it turns out, hey, they actually find lots of ways that have nothing to do with the number theoretic guarantees they have to do with, you wrote to the wrong place in memory or you sent the same message five times in a row so I can figure out that from this sender. There's lots of little stuff that I think goes into this. There's also this fact that fundamentally, and I guess I've said this 5 million times on this show, so I'll say it only once to not waste air time.

(00:18:56):
Fundamentally finance, if we take the following axiom one, all cryptocurrency things are mechanisms that have transfers at every step because there has to be some transfer. You're paying gas, you're paying something to a protocol, your protocol is paying you. Then you sort of inherently are in finance land. You're not in this mechanisms without money land. You're just fundamentally in finance land and once you're in finance, land finance just only works in the following way. There has to be some public data and some private data. The private data can be empty, but the public data is not empty. There's always some public data, there's a price, there's an interest rate because why would you put your resources into something you don't know any public information about, right? And the moment you have this public data, the public data always says something that's private data and you have to be very careful about that partitioning and you can't just be like, I just threw everything into encryption and somehow I ignore that fact.

Anna Rose (00:19:56):
It's funny that you pull it into finance right away because do you not think that it's some sort of weird hybrid thing because it is, yes, there are these sort of finance like things happening always under the hood, but they're used in different dimensions, much more computer science network. I don't know, would you still put it in sort of that traditional finance framing?

Mallesh Pai (00:20:19):
I mean also even what we call traditional finance is a whole bunch of computers and algorithms and infrastructure. It's just traditional finance has evolved or it's matured to the point where that infrastructure it's moved into the background, it's become invisible so that the average user or the average observer of that traditional finance doesn't see all the nuts and bolts. Crypto is relatively new. Those nuts and bolts are still there for everyone to see and that's why everyone's thinking about when you do a transaction, you think about, which chain, which pool, which swap, what transaction, what gas fee, all those things used to exist in traditional finance. I used to have to think, not me, but maybe my dad or my grandpa or whatever had to think about what broker should I call? Should I call a bunch of brokers? What exchange are they going to trade on? How competitive are their quotes going to be? If they ever wanted to trade a stock, my grandpa didn't trade stocks, but that's a different story.

Tarun (00:21:16):
Well, I think it is fundamentally still finance, it's just different in that the decentralization aspect and the continuous time aspect in some ways change how the math looks. In the same way that if I perturbs an economic system by perturb an assumption in an economic system, I can completely change the equilibria, I can change the number of equilibria, I can change how hard it is to get to an equilibrium, and crypto has clearly done that. In some ways the decentralization aspect changes the set of equilibria, but inherently you're still trying to figure out these financial properties. I think that's in some ways inherently why all of the, let's just say the fool's Russian venture boom of 2021 into NFT and gaming stuff led to very bad games or very non-usable social apps because everyone thought, Hey, we're going to use this thing that's fundamentally about finance and do something very non-finance with it and we're going to just shove in the finance and hope that it works and it doesn't work that way. It's kind of like the cryptographers just pretending that throwing everything into a ZK shielded pool means fine, all the malicious effects go away. It is this naivety that reminds me of being a freshman in college.

Anna Rose (00:22:44):
Well, I mean you just associated though the NFT YOLO pile into ZK, which I think is different.

Tarun (00:22:51):
Well, I'm saying they both have naivety, they're just the one is highbrow naivety, one is kind of like animal senses naivety.

Anna Rose (00:23:00):
Do you actually think then, is there nothing, this is sort of a question maybe to both of you, but kind of a little more to Tarun, is there nothing new under the sun? Is everything you're seeing sort of just a replica of these finance type principles and is MEV does MEV exist in traditional finance?

Tarun (00:23:18):
MEV is quite different, right? The point is the assumption that there is a single entity that controls that sequencing and inclusion thing means okay, well there's no point in looking at all the different types of equilibrium mechanisms. In some ways, the fact that this is decentralized basically means that you have many different possible equilibria that can come out of this, and a very crude way of measuring how much the equilibria of a system change is what's the ratio in some sense of the best case social welfare to the worst case social welfare, which equilibria gives everyone highest utility, which equilibria gives everyone lowest utility on average and what's the ratio between them? How much worse is it is the worst than the best or vice versa? And in the case of the centralized person, it doesn't matter, it's the same equilibria. There's one equilibria which is whatever they chose to include or not include here, there's many, some of those equilibria could be worse than the centralized equilibria. Some of those equalibria could be better. And the question is how do you constrain the mechanism so that that ratio is kind of well-balanced? And I think that's the part where economists kind of poo poo crypto in some ways. They don't see that there's anything new. But fundamentally, I think that's really the thing is that your choice of mechanism does change this welfare gap. The traditional finance welfare gap is just there's no gap. There's just the one thing that the venue operator chooses.

Mallesh Pai (00:24:56):
I add a couple of things to that, which is one, I mean is there anything new under the sun probably or hopefully. But we also see echoes of the same thing in the past. So for instance, what we call MEV now, there's a version of that well documented version of that that plays out in trial five, which is latency games. So high frequency hedge funds pay a lot of money to get their computers as close as possible to the exchanges computers so that they can get orders in quicker and exploit some informational advantage. I mean it's first come first serve, but who gets to be first can be determined now by milliseconds. So literally they're like, okay, we first want a fiber optic cable that goes from Chicago to New York. So I can see the quote on Chicago when I trade in New York and no wait, actually the fiber optic cable is too slow. Let's use a microwave that bounces off the earth. And then if that, no wait, the microwave is too slow. Let's use a fiber optic cable that goes through the middle of the earth so I don't have to suffer the curvature.

Tarun (00:25:59):
So I would actually dispute, and maybe this is a bias because I used to work in the industry, but I would dispute that it's very similar to MEV. There's a couple reasons for that. The first is the fact that you don't control the order types. The CME tells you, here's a limit order, here's an iceberg order, here's a go fuck yourself market order and then that's it. You can't really program that much around that. You can program a lot around when you send orders and how you aggregate orders, but you can't really create new orders. And one of the interesting things about MEV searchers is that they write these throwaway contracts that try to basically, you could argue they're creating order types and destroying order types as needed. They're creating security like objects. I did not call anything security, created security like objects and destroyed them. And this creation and destruction thing on demand doesn't exist anywhere else and that actually changes the set of out large scale outcomes quite a bit.

Mallesh Pai (00:27:07):
Sure. Maybe I should walk that back a little bit. I think a lot of what makes the crypto MEV space interesting is there's just such a wide design space. There's also a lot of flexibility. It's not an ossified space where if I had a better market microstructure and I wanted to propose it to the New York Stock Exchange, I don't know, I could put together a consortium of 50 famous professors with eight Nobel prizes and spend five years trying to lobby congress in the New York Stock Exchange and still get nowhere. Whereas here it's literally like I call up a few searchers, I call up a special mechanisms group, I come up with a few ideas, we code up something and it could be up into the races after a weekend of coding. So that's sort of what makes it exciting. There's definitely a lot more richness in this space, but some of the ideas that sort of how trades happen respond to incentives. So the idea that if there's a trade on a public mempool and it's front runable, someone will try to front run it, someone will back run it if it leaves an arbitrage open those things versus HFT will do a statistical arbitrage between Chicago and New York. I just feel like at some economic level, those two are conceptually similar. Even if how they play out is kind of different in the mechanics.

Tarun (00:28:30):
But I still will say, and maybe this is a good way to dovetail into your research, the idea that you can create destroy, add, remove versus just like here's an interface and that's it, you can't change it. The idea that the users are also changing the types of structure that they're interacting with is very different than normal finance versus tech where it is built off user generated content. So the user sort of influences the network in some ways that just never really exists in finance to be honest. It only exists in the sense that, okay, yeah, the exchange has a board and the board has a bunch of the market makers on it. Fine, whatever. Okay, fine. They can influence that a little bit, but they can't really influence that much other than fees and rebates and stuff. And it's not like they could wholesale be like, hey, we're going to actually get rid of the order book and put an AMM.

Mallesh Pai (00:29:28):
No. Exactly.

Tarun (00:29:28):
Something like that can't happen. And this idea of user generated finance is what I think crypto offers that's uniquely differentiated, but that's the thing that the Silicon Valley people don't get is that that doesn't mean user finance doesn't mean Minecraft 2.0 is going to come out of that. It might look just very different and they're unwilling to believe that.

Mallesh Pai (00:29:49):
Yeah, I think that's what makes it exciting though, this sort of richness of stuff that you could do. Whereas everything is ossified and tried to fight.

Tarun (00:29:58):
I hope I've memed user generated finance into existence because I think that's something that's never, something that people haven't really focused on, but it is a thing that it seems to be what's attractive to users.

Anna Rose (00:30:13):
You just sort of mentioned this sort of Silicon Valley mentality looking at this stuff. Do you actually see that where it's a lot of investment in tech in the past just had a very different framing than the crypto space and all of a sudden it's like now they're faced with trying to evaluate and understand this very different paradigm where success is not based on very quick up into the left user growth, but on something else.

Tarun (00:30:42):
I think the fundamental difference between user generated content and user generated finances, user generated content has this traditional like, hey, we put in some money to get certain metrics up, number of users, number of clicks, whatever, number of likes, whatever. And then based on that, we use that as our collateral to underwrite future investment. It's basically like, hey, it's clearly achieved this ability to do this with more capital maybe it can achieve more. And then with the idea that at some point you find a way to turn those views into dollars, you've basically made a security. And I explicitly think if you're going to count crypto as security, you should count YouTube views and online ads that are sold based on those metrics. No different. It's literally no different. The SEC should, if they want to go after AI, this is a good way to go after it.

(00:31:37):
There's a sense in which user generated finance is actually those metrics need to be, the cashflow to them needs to be realized much faster. So it's sort of something that's in between trading where it's already a fully liquid asset that you're moving back and forth and these kind of like, hey, we are venture underwriting this thing for many years based on some metrics that are non-financial with the idea that eventually this thing is able to have some way of making an exchange rate between the non-financial and the financial. In some ways, I think the crypto apps are successful somehow thread this needle where they find a way to have that type of growth but then also have a way of financializing it. And that's the part I think the idealism of the old school view of crypto for privacy reasons or non-state owned money. I think that kind of misses this seemingly weird aspect of how investment works in this space. But that's also why you got so many of these kind of bad investments into things that are like, hey, it looks like a duck. It walks like a duck it should be a normal Silicon Valley investment, but actually it doesn't work because it doesn't have a fast financialization angle.

Anna Rose (00:32:58):
As you described this stuff, what at least pops into my mind is a lot of the metrics that are being used, especially when you have things like airdrop hunters, it's like numbers in this don't mean the same thing, but I guess in traditional Web2 stuff they also inflated numbers all the time.

Tarun (00:33:16):
Yeah. SoftBank filed a lawsuit last week, two weeks ago against this company called IRL or something that was a social media app that I'd never heard of. And not surprisingly, it turned out that they faked all their users and then used that to raise money and whatever.

Anna Rose (00:33:34):
I mean, isn't there talk of TikToks view counts being kind of fudged as well just to make people feel really popular. There's no one checking any of this stuff, are they?

Tarun (00:33:42):
Well, that's the problem with the centralized version of this. Now the problem, the decentralized version is you have no way of de-duping, right? You have no way of knowing it's the same, really the same person 500 times. So the middle ground will be the thing I think that looks will give you these Silicon Valley style things, but until then it's only going to be financial stuff and you just have to be okay with that. But one interesting to go back towards MEV, one interesting aspect of this is in most cryptocurrency designs you have a temporary monopolist like the block proposer or someone who is making a block or adding a block. And this temporary monopoly is sort of this interesting weird thing that I think in the case of these views and metrics, you have this perpetual monopoly and the perpetual monopoly allows you to inflate those views and metrics. But in these temporary monopolies, it's actually quite a bit harder to do that. But there's still things that can happen like, hey, I don't want you to increase your user counts. So when I'm a proposer, I don't include your transactions. And Mallesh's research is on that type of stuff of even in these decentralized systems where theoretically the view counts can't be manipulated. I mean you can Sybil by making many versions of yourself, but you're not manipulating a single identity. You still have some other things that can go wrong.

Anna Rose (00:35:15):
Let's dive into that Mallesh, tell us a bit about the work and research space that you're focused on.

Mallesh Pai (00:35:21):
Sure. So I mean I'm focused on a bunch of stuff, but the censorship sort of question that started this all is like Tarun said, we talk about decentralization and we say things like, oh, like Ethereum has millions of validators or pick your number and that sounds like a lot and it sounds like you're getting a lot of competitive properties and nice outcomes from the fact that there are so many people validating or proposing blocks. But every 12 seconds there's only one block proposal who's out there. And that means that for that 12 seconds, if you want something on that block for that 12 seconds, you got to go through that proposal. There's nobody else, there's no competition. You can wait for the next 12 seconds, hope to find the proposal you like more, but, and economists will in general tell you that unless I made this comment and got in trouble with my colleagues, but unless a monopoly is paying us, we think monopolies are a very bad thing unless

Anna Rose (00:36:24):
Unless monopolies are paying us. Okay.

Mallesh Pai (00:36:26):
This is a case where this monopoly has two properties. So one is, and okay, so the other thing I heard from someone is that anytime you think of something, Vitalik has thought of it 5 years ago and in this case Vitalik thought of it 7 years ago. So he walks us through this. He has this blog post, you should look it up, it's from 2015, it's called The Problem of Censorship. And he walks us through a very simple thought experiment, which is, let's say I write you an option, I will pay you the positive difference between the price of Ethereum and $1,500, let's say a hundred blocks from now or a thousand blocks from now, whatever. And that means that if you sign this contract with me, I promise via smart contract that as long as you put in a transaction a thousand blocks from now, it'll look up the price of Ethereum and if that price is larger than $1,500, it'll take the difference and it'll take that difference and transfer the money from my account to yours.

(00:37:24):
Now suppose the price of Ethereum that day is $1,600. So exercising that transaction in that block is worth a $100 to you. That means you are willing to pay up to a $100 to include a transaction on that block. If you pay $90, you still make $90 as the transaction fee as the tip, you're still going to make a $10 profit. The trouble is I'm willing to pay a hundred dollars to keep it off that block. So you and I are going to be in this competition to get either your transaction included on the block or me trying to keep that transaction off the block. The person who walks home happy is the proposer, the monopolist who's the only person who can decide whether that transaction gets up on the block or not on the block they get to in equilibrium, the price of that transaction or the price of censorship will be somewhere close to a $100.

(00:38:17):
The proposer makes off like a bandit, but the financial system as a whole is not well served because the proposer is taking a large fraction of the economic benefits. Whatever economic value we were making by hedging has now all been moved over to that proposer. Secondly, you can't trust that this even getting into this transaction in the first place is worth it to you because you are concerned that you won't be able to execute that option a thousand blocks from now when the chance come through out. So that's sort of the problem of censorship that we started thinking about and we proposed a solution. This is with my colleague at Special Mechanisms group, Max Resnick and Elijah Fox who's at Duality, and we proposed a solution that we call multiple concurrent block proposals. It's a solution that works particularly well if all you need to do is get some set of valid transactions and you're not concerned about how to order those transactions. But we use a principle in game theory called the prisoner's dilemma to make it so that transactions are very cheap to include, but very expensive to censor. So that's sort of the high level idea of the censorship problem and what we think about it.

Anna Rose (00:39:34):
In that example. Do those aggregator groups like the liquid staking or things like FlashBots, do they have any impact or would the individual proposers still be like an individual and they could use that and it doesn't really matter. I'm trying to figure out if the existing system that obviously had not been envisioned has any impact on that problem.

Tarun (00:39:57):
I can tell Anna that you run a validator because that question sounds like a validator asking that.

Mallesh Pai (00:40:08):
If it's not like I want to point a finger at specific entities. I'll say a couple of things. One is that the sort of MEV-Boost type proposal builder separation, it's a good thing in many dimensions, but one thing it does do is it puts an explicit market for this kind of censorship. So before proposal builder separation, in order to keep your transaction off the block, I would have to know the validator who's going to propose that block, and I'd have to call them up and I'd have to say, make sure Anna's transaction doesn't hit that block. But if I'm, now it's post proposal builder separation, I just need to fire up a builder and propose a block that doesn't conclude your transaction and is willing to pay more than any block that includes your transaction. And we actually did a sort of at special mechanisms group, we did a little toy version of this demo, a couple of hours of builder time put together a little builder and for a hundred dollars and plus the value of a few hours of build of our engineer's time, we literally won a slot and it's a blank slot.

(00:41:13):
I can send you the number for the show notes later, but it's a blank slot and all it contains is a name to the first sensor of Rome as block graffiti and a link to our paper. So we sent in an empty block, basically an almost empty block only one transaction, which is the payment from the builder to the proposer and the name of the first sensor of Rome as...

Anna Rose (00:41:39):
Your graffiti.

Mallesh Pai (00:41:40):
Yeah. And now I mean the attack sounds like a bit, it was almost a prank. So it's not like this is meant to demonstrate a serious attack on Ethereum, but imagine if we had done the same thing we had included 150 other transactions, could have included 150 first, but just chose out of spite to leave out your transaction Anna, you would never have known or nobody would ever have noticed that this could have been done. Anna's transaction could have been on-chain, but the builder that was in charge or the validator that was in charge chose to censor. And that's I think part of what we view as the pernicious problem. When you don't have censorship guarantees, people ask, have you seen this kind of attack in the wild? And part of the story is A...

Anna Rose (00:42:32):
You wouldn't see it.

Mallesh Pai (00:42:33):
We don't know if we don't see it. Exactly. That's part one and part two is we don't know what else or we have some thoughts about what else is happening because people are concerned that this censorship attack is a theoretical possibility. So in terms of what kinds of mechanisms are people trying to run on-chain, they're trying to run on-chain mechanisms that they're reasonably sure will execute in a faithful manner given what they understand about the dynamics of the chain. That's why you see more and more, you see a few things on-chain. You see gradual Dutch auctions on-chain, but after a few original liquidation auctions that used to happen on-chain, you don't see us sending auctions in a liquidation auction on-chain. You either see some of these things off-chain or move to other faster, more things that they are reasonably sure will work in the light of these kinds of censorship attacks, if that makes sense.

Anna Rose (00:43:31):
The person who got censored might notice it, right?

Mallesh Pai (00:43:34):
They might notice it. Yes.

Anna Rose (00:43:35):
Especially if there was any sort of bet or block mentioned in something.

Mallesh Pai (00:43:41):
They might notice it. They might say, hey, I was willing to tip a lot cheaper transactions got in, there was still block space available. But if you're talking about time sensitive transactions, what are you going to do about it? I described this as like, oh, this is an option that has to execute in that block, but that's just a thought experiment. There are lots of things that are time sensitive. For example, a lot of current financial activities, what's called sex dex arb, so arbitrage that tries to use prices that are coming from traditional centralized exchanges and use them to trade against uniswap or other pools on-chain. And if you don't get that transaction in, you got 12 more seconds and the price might've moved quite a bit on Binance. So that's sort of the issue.

Anna Rose (00:44:32):
Could that be happening? Is there any sort of game happening where just certain MEV folks and traders hate each other and are tracking each other's activity and constantly screwing each other up? Is that possible?

Tarun (00:44:45):
A lot of the top builders are searchers and builders. So ostensibly that does happen, but it happens from the form of like, hey, I want this arbitrage transaction and in my block I'm not going to include yours. Why would I include yours doing the same transaction?

Mallesh Pai (00:45:01):
Exactly. I mean in a separate paper we talk about these transactions and so these integrated searcher builders, so they have a searcher and a builder, and what they do is at the top of the block they put their sex dex arbs and then the regular transactions go in the bottom of the block. Now, one of the blocks we pointed out to in this paper, the first 37 transactions were all arbs to different pools and different tokens by the same MEV bot. So in some sense this is not censorship, but already what you said has just happened because it's unlikely that this particular MEV bot was willing to pay the most for every one of those 37 arbs. It's just that MEV bot is owned by the same person who happens to own that builder and just put all of them at the top of their block. So there's an inefficiency in terms of block production that then engenders down the road.

Anna Rose (00:45:56):
Got it. When it comes to censorship, I mean there was another example that we did talk about on an episode with Martin Köppelman. This had been around the time of the Tornado Cash case and OFAC bringing its sanctions against that smart contract. In this case it was more about excluding addresses. It was certain addresses that were on a list that were meant to be disallowed and this really had more to do with FlashBots or an MEV system, an MEV piece of software that could then sensor. Does this factor at all into your work? Is this something that you're also thinking about?

Mallesh Pai (00:46:32):
So our motivation was not that form of censorship. Our solution, we think to the extent that you want to reduce censorship coming from other agents, regulations, regulatory bodies, the kinds of designs we propose are just resistant to all forms of censorship. It's just our motivations where these time sensitive censorships rather than the sort of OFAC saying that certain accounts just should not hit the chain. And what that results in is like a whole bunch of validate proposers. Don't look at those blocks at all,

Anna Rose (00:47:11):
But your solution actually would help that. How does that work?

Mallesh Pai (00:47:14):
So it would help in the same way. I don't mean to claim that this is sort of a turnkey solution out there ready to go. It would help in the same way it helps against the forms of censorship that I described in the sense what the solution does is it has multiple proposals simultaneously. So a block is not a single block, it's like the union of N blocks that are proposed by N independent proposes. And the way tipping works is you propose two tips. So you propose one tip, which is the tip that you would pay a proposer if it's the only person to include you, and that tip could be large and you propose a much smaller tip if multiple proposers include you. So this sets up a prisoner's dilemma between the multiple proposers who are all independently trying to decide which transactions to announce. So they would all choose to include transactions because if

Anna Rose (00:48:11):
They're the only one, they're a nice

Mallesh Pai (00:48:12):
If they're the only one they're in for a nice little bonanza.

Anna Rose (00:48:17):
In this case though, in your system you could actually be running a different kind of software then.

Mallesh Pai (00:48:23):
It just needs to be N different blocks. It could be that you use MEV-Boost and someone else uses something else. Someone else is like a literal old school validator who in 12 seconds calls up other people and says, hey, what transactions do you got for me? All that's fine by us.

Tarun (00:48:40):
I think you almost have the analogy, right? But the thing I remember that was hilarious. Now I'm sure, luckily no one with a brain who listens to this podcast is a big Cardano whale. So I can make fun of them as much as I want here. Whereas on this other podcast I'm on, anytime I do, they come attack me on Twitter, the Cardano mafia. But there was a time when Cardano's UTXO system had some issues because it locked state in their uniswap, the first uniswapped clone they had and basically there's only one transaction per block. So people were on Discord trying to, the proposers would be on Discord being like, Hey, running an auction and chat for that one particular slot. So it is basically what you're saying except it's a Discord chat not calling up.

Mallesh Pai (00:49:39):
And these things, I mean, yeah, they happen. I remember one of my first people who talked to me about mechanism design was literally concerned about, hey, you guys do all this mechanism design and you're concerned about, you think about efficient bidding and competition, but we have all the people who are going to be bidding in this auction. They're going to be on the same Telegram chat and they're going to be talking with each other. And we are really concerned about the fact that these people have a side network to sit in swap notes with.

Tarun (00:50:15):
So one trade off I think that maybe is worth highlighting about trying to do multi proposer is the extra communication complexity and latency issues. So you're sort of inherently introducing some OR problems as you pointed out earlier of like, well now I need to coordinate the proposers so that they can each coordinate the segments of their blocks or the lanes of their blocks and then that now adds in some extra overhead. Maybe someone could DDoS them and then cause a view change in BFT. So how do you think about the trade-off and sort of some bounds on how well you can do in sort of the practical environments because inherently having multiple block builders compete is not that bad latency wise, but having multiple proposers have to handle multiple auctions and then merge them turns this into a commentator auction versus a single item auction and we know all the bad results for that. So what's your response to that?

Mallesh Pai (00:51:20):
My Bot A responses? I'm an economist. No, but I think

Tarun (00:51:26):
Economists have to care about practicality too. It's 2023.

Mallesh Pai (00:51:30):
Exactly. No, I wish I could. Okay. And I think my more serious answer to that is I think this is useful for some parts. So we've been talking and we've been trying to think about can we take these ideas and we don't want this to be, it's also with all that added communication complexity, it feels like it would be a waste to use this for a blockchain because you've done all the work to engineer up N separate block proposals, but then you're not, at least in equilibrium, you're not getting a lot of extra bandwidth. You'll get the same top end tips included in a censorship proof way. So you're sort of killing censorship proofness with a very strong hammer and you're suffering a lot of other communication complexity costs, attack surface in terms of equivocation to make all this work. We think it might be useful for things like this design might be useful for things like EPPS. So how to get in the set of blocks that people should be sort of considering or how to even get in the set of transactions that should be part of the common mempool before you do a sort of block bidding competition on top of that. So that's the part where we're hopeful this could be useful for something that core in somewhere where having some common knowledge of a set of transactions is more important than the underlying communication.

Tarun (00:52:58):
This brings me to my natural next question, which is the place where we do have this type of partitioning showing up at least in Ethereum land, so let's ignore other L1s because they'll all get angry at me somehow for missing some design detail. That is probably irrelevant to the mechanism question, but whatever is roll-ups, because roll-ups effectively right now you could argue their sequencer is sort of running effectively an auction. I mean right now they're not exactly doing it now it's latency based, but then the roll-ups have to get matched, have to have some interaction with the L1. So there's this question of I have these two separate auctions. Arguably the rollups are taking portions of space of the main block. So suppose there were no transactions to mainnet and it was only roll-up transactions. Now I can split the block into each roll-up set of transactions and between roll-up ordering doesn't affect the roll-up execution. And so now you could argue that, hey, maybe the roll-up sequencers are your multiple proposers. They act as that instead of having the raw, because they're already the ones kind of handling that. So there's sort of this interesting weird dichotomy where the rollup sequencers could be your multi proposers in some way.

Mallesh Pai (00:54:26):
That's interesting.

Anna Rose (00:54:28):
Do you think of that, especially when you start to decentralize them so you'd have these different actors?

Tarun (00:54:31):
Exactly. Exactly. That's sort of in some sense I would argue that's the real benefit to these decentralized sequencers. I think everyone else's, if we're reading between the lines of everyone talking about decentralized sequencers, all of them are just thinking of it as legal cover my ass for my token. But if we get past that part, it is actually could provide this censorship property.

Anna Rose (00:54:55):
Which role does the sequencer take here? The builder?

Tarun (00:54:57):
The proposer. One of the proposers, right? Let's just say I have every block for simplicity. I'm choosing simple numbers, but obviously practically you have to be much more careful where one third of every block is optimism. One third of every block is arbitrary. One third of every block is zkSync and they're each

Anna Rose (00:55:16):
And you're going on the L1?

Tarun (00:55:17):
Yeah, on the L1. And each of them acts as a proposer only for their subset.

Anna Rose (00:55:22):
And so the chosen validator or the chosen sequencer at that moment, if there's a decentralized sequencer system, is acting as the proposer on the L1.

Mallesh Pai (00:55:34):
Yeah, and I mean the part that I guess I'd have to think about is sort of you as the user who wants to get your transaction in for all these guarantees to work, you as the user have to be sort of indifferent at that instant of doing your transaction on arbitrum versus optimism versus zkSync. So you'd need to have the same appropriate bridge that if you were doing an arb of some sort, you'd need to be able to do it. If you were doing a sex dex arb, you should be willing to execute on any one of the three and the three should have a closely synced state, something like that so that you are indifferent on which one you show up.

Anna Rose (00:56:11):
I guess I was thinking about this more as the proposer, not the app you're thinking of like, oh, the trader.

Mallesh Pai (00:56:17):
I'm saying if you go one level up, where does the trader, what does the trader need to for multiple concurrent block proposes? It has to be that you don't care which proposer includes you as long as at least one proposer includes you. So if you're thinking of the three L2s as the three concurrent block proposers, you need to be willing to have your transaction executed on any one of the three at least. Right.

Tarun (00:56:42):
I see why you're saying that for the analysis to use the same proof you use, but I don't think that's the in real life thing though. I think you would have to analyze it, you'd have to analyze it differently where you assume that the arbitragers have some amount of, Eth or whatever, let's just say Eth, or USDC on each of the roll-ups and can do this equally, I agree that doing the rebalancing of where their balances are will make this much harder because that involves a transaction that may have to in the withdrawal period and all this other stuff. But I get what you're saying from to try to use the same methodology. But I think I suspect the more useful kind of version of this will have to have a slightly more general threat model. I think that the main, this is their very simplified model, obviously the percentage of each block that goes to each rollup varies over time.

(00:57:41):
The amount of arb that's actually to mainnet also exists. So it's competing with those three. But I was just trying to give an idealized setting. An idealized setting. You could imagine something where your multi proposer thing really comes from, and ironically, this is what some other Layer 1s had proposed, but for very different reasons under the name of fishermen or collators or whatever. But then all of those things didn't get used in production because they kept causing liveness failures because they weren't able to synchronize fast enough and they had all these latency bandwidth, trade-off problems.

Anna Rose (00:58:18):
Is that a prediction for the future then? Do you think the same kind of problems could happen?

Tarun (00:58:22):
Well, we're kind of going into a world right now where people want all this stuff that is getting rid of liveness guarantees in some ways. Intents are effectively no liveness, right? The market makers all drop out. They don't fulfill any orders because they're like, ah, the market's too crazy. Well, you've lost liveness. Your transaction is not going through. So the question is how much we do this trade-off of liveness of the network versus these other properties you might want better settlement or censorship right. And I think it's always going to be this kind of experiment. I was just kind of proposing that the roll-up sequencers already serve as pseudo proposers for at least in some ways. So using the fact that they're already doing that might be one way of doing this. And you could argue EIP4844 is a poor man's way of doing it, or dank sharding is sort of like a closer way of doing it.

(00:59:17):
But there is some sense in which all of the reasons people wanted, those are for purely state efficiency reasons, but you could argue that they maybe provide censorship benefits. So I think as you can see, there's a lot of concerns with this type of stuff. There's the economic concerns of censorship, there's the practical concerns of latency and bandwidth and implementation, just like you're talking about with mechanism design, where you had all these different types of parties involved in research. So maybe we should turn the mirror on crypto and say, what do the people who are doing these kind of interdisciplinary research on the outside think of crypto? Well, it's sort of the current view outside of probably a scam.

Mallesh Pai (01:00:04):
So it sort of splits into few sets. So there's the people you just said probably a scam. There's definitely sort of, I'd say the silent majority unfortunately as people like that, or at least people who are broadly, this sounds interesting, but I don't know what this does that I can't already do. And those are people who are waiting for somebody to come up with an application where they're like, this is how it adds value to my life, or adds value to some demand case that I hadn't thought of. I think the interesting set of people, there's a growing community of people within econ, especially within economic theory, mechanism design, people like that who view this field as a full employment act for our people. So there's a growing

Tarun (01:00:53):
Satoshi is Roosevelt, that's what you're saying.

Mallesh Pai (01:00:58):
Full employment act literally means that there always be jobs, there will always be jobs. Until MEV is solved and every use case generates new forms of MEV, we can't solve MEV problems purely based on throwing more cryptography at it or throwing more obfuscation at it. That might be part of a toolbox. But you also need to think about the incentives of all these parties. And decentralization means there's a lot of parties involved. There's the user, there's the wallet, there's the builder, there's searchers, there's the proposer, there's the validators. You need to align their incentives. And who better than a bunch of mechanism designers. So there's more and more people who've seen this and are sort of hopefully seeing interesting questions along the way.

Anna Rose (01:01:47):
Mallesh, I want to say thank you for coming on the show and sharing with us a little bit of your background, the work you've been doing, the research you've been doing, and helping us sort of tease out a little bit more on the MEV front.

Mallesh Pai (01:01:58):
Thanks for having me on.

Tarun (01:01:59):
Thanks for coming on. I think one thing I'm left with at the end of the show, as I always feel when I think about the censorship problems due to MEV, is that I still feel like there's not really a good solution, but it's always good to kind of go through the idea maze and then realize that it's probably, yes, like you said, a full employment act in that each time you hit one thing and you play that slot machine in the MEV casino, somehow you've changed the reward of some other slot machine. And then when you get there, you're like, oh shit, now I got to go build a new mechanism.

Mallesh Pai (01:02:37):
I think what's interesting is Vitalik thought of this, it's literally there in this 2015 blog post, and then no one was really concerned. People started getting concerned about censorship from the OFAC angle, but how much has this sort of censorship affected what we've actually done on-chain? Like you've thought about it, Tarun, I know you have, but I don't know how many other people were actively thinking about this until it's come front and center this year where people are thinking a lot more about on-chain mechanisms and how they interact and all the stuff that's coming with down the pike with Uniswap V4 hooks and all the sort of richer design spaces that we now have available to us.

Tarun (01:03:19):
Well I also think it's more that people realize that on-chain transactions are real and centralized transactions may not be real. And so now people are valuing them a lot more in that sense

Mallesh Pai (01:03:30):
Depending on when this airs.

Tarun (01:03:32):
Well, no, I am really meaning FTX, right? In the sense of the fact that the wrapped Bitcoin didn't even have the Bitcoin behind it is still my favorite. I think people value on-chain transactions more and they're realizing why. And so that's why I think this is becoming more important.

Mallesh Pai (01:03:51):
And that's why we need to hopefully, like you said, we're not going to solve these questions, but at least think through them carefully and work out where we want to be on the trade off space.

Anna Rose (01:03:59):
Interesting. Alright. Thank you again.

Mallesh Pai (01:04:02):
Thank you.

Anna Rose (01:04:03):
And I want to say thank you to the podcast team, Henrik, Rachel and Tanya, and to our listeners, thanks for listening.