00:05: Anna Rose: Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast, we will 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:26: This week, Guillermo Angeris and Alex Evans returned to the show to chat about the research that they, along with Tarun, have been putting out over the last year. We explore the methodology behind their work on CFMMs, AMMs, and related primitives. We also dive into some of their recent findings and what they're looking forward to working on in the future. Before we kick off, I also wanna remind you about the ZK Hack online event. ZK Hack consists of weekly workshops about key ZK tools and an advanced puzzle competition. There is a fantastic community forming around this event, so do jump in. I've added the link to the site in the show notes. You can sign up there and find out more about the program. Hope to see you there. 01:04: Also, if you're looking to get into the ZK space professionally, we are hosting a ZK Jobs Fair, happening on December 2nd as part of the overall ZK Hack event. The ZK Jobs Fair will be featuring some of the top hiring teams in ZK. This gives you the chance to meet them in a more casual setting as you're applying. So you may want to check it out. You can also check out the ZK Jobs Board where you can find ads from these teams looking to hire. The links for all of these can be found in the show notes. 01:32: Today's episode is sponsored by Aztec. Aztec aims to be the privacy layer for Ethereum. They believe that unlocking programmable privacy is the next frontier for blockchains. Aztec is the first zero-knowledge rollup built from the ground up for anonymous payments and DeFi transactions. If you want to protect your payments, you should join the thousands of users already sending funds privately on zk.money. That's zk.money. We've added the link in the show notes. So thank you again Aztec for sponsoring this episode. Now here's my conversation with Tarun, Guillermo and Alex. 02:10: So today I'm talking with Guillermo, Alex, and our sometimes co-host Tarun. Tarun, I think for this episode you're going to be a little bit more like a guest because what we're going to be talking about is the work that the three of you have been doing over the last, I don't know, year or two. So yeah, I want to welcome back Guillermo and Alex to the show. Welcome guys. 02:28: Guillermo Angeris: Thank you. It's awesome being back. 02:30: Alex Evans: Thanks for having us. 02:32: Anna Rose: So both of you have been on the show before, but I know a lot has kind of happened since those episodes. Alex, you were on, I think almost two years ago. I'd love to hear what you've been up to in that time. 02:43: Alex Evans: Oh, my life has taken a turn for the worse. 02:47: Anna Rose: Oh, no. 02:50: Alex Evans: I've now come to a place where we're writing one paper a month with these two, mainly as punishment, but also as entertainment. 02:58: Anna Rose: What about you, Guillermo? You were on the show actually earlier this year. What have you been up to since then? 03:02: Guillermo Angeris: Yeah, so for the most part, well, I mean, as with these two, I've just been writing a bunch of weird, sick and twisted papers, but I've technically come to the conclusion that at some point I should finish my PhD and one of my two professors also come to a similar conclusion, although the other one is yet to be convinced. So hopefully by March I'll be defending and presenting the whole diddly-doo to physics that almost nobody, I guess, from the show probably has ever heard of. For the better, in fact, I would say. But that's the plan, at least so far, fingers crossed. 03:34: Anna Rose: Very cool. Let's talk a little bit about the research you've been doing. And maybe before we jump into the specifics, what is this research for? Why are you producing one piece of research every month and who's paying attention to it? 03:48: Guillermo Angeris: I think it's a question for Tarun actually. 03:50: Tarun Chitra: Yeah. So, I mean, I think we started working on kind of research in this vein realistically in 2019\. And part of the thing that I guess, I had seen and it took me a while to convince Guillermo, but I think he eventually believed me. With that, there was kind of this thing that was happening in DeFi that really resembled kind of the early days of AI pre-ImageNet, like basically like 2008 to 2011, where a lot of the important research was actually done outside of academia. And not only was it done outside of academia, a lot of the kind of rigorous stuff, the theory was also sort of started outside of academia, not just like, hey, we ran a bunch of experiments and we could predict X thing at 99.8% instead of 99.5, which is like 90% of machine learning papers nowadays. 04:49: And I think like there was this... There' a thing where like there's all this stuff happening and there are all these very counterintuitive things going on, where there is something like Uniswap, which to someone from finance and certainly like SBF, Sam from FTX and CMS and all these trader people were always shitting on Uniswap on Twitter. And part of the thing that more careful observers who were looking at the on-chain data kind of noticed was that there was actually quite a crazy amount of usage and people weren't losing as much money as one might naively think. And I think that just led us down the rabbit hole of like, hey, this stuff that looks kind of like on the surface, like it shouldn't work or it's stupid in some way, actually seems to be working in practice. So there must be some more fundamental reason for why that is. And around that same time, I met Alex randomly, and he was also doing the same thing. He kind of believed sort of the same thing. He'd been writing these, I think probably the only formal-ish paper on MakerDAO at that time. And so this is like early 2019. 05:54: Alex Evans: No, it's right. I ran into Tarun at his office, they would host a number of events there. And I'd heard of him from actually another guest on the show, Akis, who had mentioned him as somebody who really knew his leap on mathematics. And as some of the listeners who have seen Tarun might know, he does stick out in a crowd. So I approached him with that research and turns out he was working on very similar things at the time. I think he was doing some credit risk analysis for Compound, which was somewhat analogous using actually much more efficient and useful techniques than the ones I was using, hence the emphasis on the ish. And then with automated market makers, turns out we were asking very similar questions. In fact, I'd written a whole paper that Guillermo and Tarun had sort of answered the same question that I was going after in one appendix and two paragraphs, which is a common theme in our work. We'll get into that soon of me writing very, very long and complicated things to which Guillermo will respond with a paragraph replicating the result in a simpler way. But that's sort of the origin is I think we were working on very similar things around the same time and couldn't beat them. So I joined them. 06:59: Anna Rose: Nice. Okay. So your starting point is sort of the CFMM and AMMs and exploring these I guess when you talk about Uniswap being I guess one of the first dApps you were really looking into like why does this thing work? What are the properties? But do you feel like has that expanded from AMMs or do you still see that as the core focus of most of your work? 07:23: Guillermo Angeris: So at the end of the day, CFMMs or AMMs very generally are like one very particularly nice class of things to study. And as one can imagine the problem with research papers is that you always end up with more questions than you actually answer. In fact, this is almost universally true, and if it's not true, then you haven't written a research paper. It's like you've wrote something, you wrote an essay instead of a research paper. So in some sense, I guess kind of stepping back and going pretty a layer higher to the meta, it's that we've kind of realized that, there's a bunch of products that people want to replicate on-chain, a bunch of financial products that all have these interesting properties like options and all of these things. And most people kind of come at it from a very traditional finance angle. And that's simply because of the fact that that's what people are trained in, and there's like these simple notions that we all know and love about options, for example. This is a very specific example, but. 08:19: CFMMs give you kind of a weird perspective on how to actually do things on-chain. In some sense, they're like a very natural, let's call it a primitive, a DeFi primitive, if we may, that lets you do a bunch of things that don't seem intuitively obvious how to do on-chain, but give you a very natural framework to think about. So in the previous case, one such case is options, right? It seems kind of weird and you have to do these complicated mechanisms that require Oracles and all of these things. But the case of CFMMs, actually gives you kind of a natural way of constructing roughly the same object without the use of Oracles. So CFMMs are kind of... The way we think about it is you have this class, this very large set of items that you can do on-chain. And CFMMs are a particular set of items that's very surprisingly large. It's a very large class. Now, I mean, it's kind of actually shocking in our research highlights just how shocking it is, how large that set is, even though it looks like a very specific instance, right? That then you can do... Of things you can do on-chain without using Oracles. 09:20: I don't know if that kind of made sense, but the point is like, it's this very natural framework for which to think about what are the things that we can replicate without using Oracles on-chain? It's not the set of all things you can replicate without using Oracles, but it's a large class. And our point is, there's some boundaries around this like set of items one can replicate and our research kind of pokes at the boundaries repeatedly of like, how much is it, how much can we actually subsume within this umbrella of constant function market makers or whatever? 09:49: Anna Rose: So are you finding though, things that don't work in them as well? Like, are there some examples that you could already like say these we tried, this won't work, we're gonna have to rely on Oracles. 09:59: Alex Evans: A simple example would be just in the example Guillermo just mentioned, we have one of our more recent papers, this is now two papers ago, replicating monotonic payoffs without Oracles, describes a class of, for instance, payoffs that users may desire that are fairly popular, for instance, regular call options and so forth that have unbounded upside and are convex. And we can get into what that means, but you can't do that just simply without an Oracle. You need either full collateralization, which is very inefficient, or you require an oracle in order to do that. Turns out actually that things that don't require Oracles, and this is maybe the big thesis or idea of a lot of this work turns out to be quite broad. So you can do short of that, almost anything. For instance, you clip the payoff at some upper bound, you'll be able to do that without an Oracle. And maybe even taking a step back, why is this a useful exercise to begin with? And that is that Oracles are perhaps the main source of both financial and technical complexity in DeFi. And turns out that they expand the surface vulnerabilities quite significantly for on-chain financial contracts. 11:11: So if you look at a lot of the exploits that have happened, and Guillermo has a recent thread on this, a lot of them are related to Oracles. And so it's in fact a useful exercise, not just theoretically, which is our primary motivation to be candid, but also practically in terms of how do we design systems. The exercise of how do we minimize use of Oracles and how much damage can we do without them is, I think to us something practitioners in DeFi and beyond should be asking. 11:38: Anna Rose: When you mentioned that like the fact that there's an Oracle could lead to exploits, is it mostly like arbitrage opportunities? Or like when you say exploit here, I want to understand a little bit more what you mean. 11:49: Tarun Chitra: I mean, there's a bunch of different types of ways that this can happen. I mean, I think the simplest ones are where you have another product that does a non-reversible transaction. So when I say a non-reversible transaction, I mean something like a liquidation where once the transaction is through, there's not really a way to put back that capital indirectly, right? So like a trade in an AMM, if you're willing to take the fee is reversible and that I can trade back and forth and get it back to the same initial price. But there is a whole notion of transactions that are irreversible in finance. And that's usually when it's something like a liquidation or some type of settlement... Final settlement. And whenever those occur and those are dependent on an Oracle price, on some notion of price of the asset such that it triggers such an event, then it can at times become much more valuable to manipulate the price calculation rather than try to enter into that financial product. 12:51: And so, manipulating the price calculation can either be done by manipulating the Oracle directly or manipulating sort of the inputs to the Oracle. So the recent Cream attack and the almost Ave attack are effectively Oracle manipulation attacks where in a flash loan you manipulate an Oracle, cause a liquidation, and then sort of take the other side with that indirectly. I mean, it's a lot more complicated for those assets, but are the assets that were used in both of those. But Oracles are certainly a source of vulnerabilities. And I think one of the reasons the Uniswap stood out to us in 2019 was really this fact that somehow, in spite of there being no Oracle, it was able to effectively induce market participants to make it a good Oracle, where there's enough arbitrageurs trading against it that the cost of manipulation is extremely expensive. 13:47: Whereas protocols that try to be explicit Oracles like UMA, none of them had a couple other properties. One is they had to artificially create this notion of the cost of corruptibility was expensive, right? You either do it by having a token, force people to stake dot, dot, dot, dot, dot, but you don't really give them financial upside in an asset they might already value like ETH. Whereas in Uniswap, people were earning ETH and stablecoins. And that was like one big difference between that and sort of the other Oracle systems. The other thing is that other Oracle systems act more like legal courts than they do like blockchains, because they rely on all sorts of challenge games. You could view the UMA Oracle is not that different than an Optimistic rollup in some ways. And I don't mean that necessarily positively in Ethereum. In other blockchains, it's actually great for a bunch of reasons, but in Ethereum, the way that doing these kind of like post-event resolutions is just extremely, extremely annoying. 14:47: And I think in like other blockchains, some of the more complicated designs are actually going to be more user friendly because I think people just don't like having this... When people submit a transaction to Ethereum, they want to say, okay, I submit it, it's confirmed, I never have to think about it again. The problem with Oracles that have sort of post-trade settlement is that you submit the transaction, you see it got confirmed in the block, but then you also have to keep watching the blockchain for another 10 blocks before you decide, okay, it's actually in. And for better or worse, this is an industry of degens. So it's not like they're actually really gonna wanna do that. This is no knock against the UMA design, I think it's just that it doesn't work as well on Ethereum. I think it's actually not a bad design somewhere else. 15:32: Alex Evans: It turns out that our work explains in some ways where that design is, where some version of that design is necessary. And then it turns out that these problems can't be avoided for certain financial applications. It's just that some applications, in fact, very many applications don't need that sort of complexity at all. So one way to think about it, just to make it really clear, is the types of guarantees that you have in Oracle dependent systems are of the form either property X holds, in other words, I don't get liquidated unless the price falls below a certain amount, or the Oracle has failed, which in the case of UMA falls down to the cost of corruption versus the profit from corruption and some equation holding between those two. And that requires that sort of security assumption to hold, in order for your property, whatever desirable property your system to hold. 16:24: And in the work on CFMMs as well as related systems, the assumption is either property X holds, in other words, in this state of the world, this user gets the same payoff as this option or some other property holds, such as the portfolio's 50-50 balance between two assets or whatever else, or somebody has a very significant arbitrage opportunity that they've left on the table and haven't exploited. Which is a much stronger assumption to make, right? Which is there's free money somewhere and somebody's going to pick it up. And if they haven't, then I can't make any guarantees about my system. But if they have, here's what I can say about what the user will get or whatever other property I'm interested in. 17:05: Guillermo Angeris: Yeah. Maybe the tweet long summary goes something like CFMMs, in our admittedly biased opinion, are a particularly natural way of thinking of financial instruments, or replicating financial instruments on the blockchain without Oracles. They might not be the space of all things, but they are a very surprisingly large section of it. 17:27: Tarun Chitra: Right. Not zero. I think like the SBFs and people like that, who ran exchanges, centralized exchanges, one of the reasons they couldn't kind of believe this was true is everyone thought the space of such things was zero. Like it was empty, there were no such applications, right? Uniswap was the first thing that proved that, hey, the set's not empty. But then since then, basically you could think of what we're doing as trying to find the largest surface convex hull in some bad joke manner of the set of all of these mechanisms. 18:00: Anna Rose: What I still wanna understand though is like, who is this research for? Are protocols asking you like, hey, can you look at my CFMM? Can you look at my model? 18:12: Tarun Chitra: It started more out of pure intellectual curiosity. Also, I guess my company was certainly like, we use these types of things within how we simulate stuff, but it also started from like, hey, there's actually something bigger here. And over time, the more we started writing these papers, the more random people on the internet would message and be like, hey, I'm building this thing based on your paper. Or like, hey, I'm going to do this other thing based on your paper. And over time, it became much more clear that by going this route, we were sort of actually opening up the space for other people who maybe were not so mathematically sophisticated, but were your usual DeFi developer, like 19-year-old, lives in Asia somewhere kid. And this was kind of a way for them to find new things to do. And then when MEV happened, it became much more clear why people really liked our papers because no one else knew how to write the formula for what the arbitrage, optimal arbitrage was. And so the Flashbots Discord is filled with lots of random anons pasting our papers back and forth. 19:19: Anna Rose: This actually speaks to something. This is this idea, and I mean, I think we're starting to notice this more and more where researchers, academics, or not, are putting research out into the world and sometimes there's these groups that are forming around this research and those are becoming in a way the next generation of projects. It's very much not the way I've understood this kind of progress in the past. Like working more inside, potentially in labs or what have you, still kind of keeping it a little bit to yourself until it's ready. Here it's like as it's being built, there's teams forming around some of these ideas. I think Flashbots, as an example, we had them on the show a while back and I just think the idea of forming this research group just around open public research, it's so organic and I think it's really powerful. It's not something you guys could push though, can you? You can't predict like, or have you been able to find teams to build out any of these ideas or test them out? 20:18: Tarun Chitra: Yes. Yes, the answer to that is definitely, yes. 20:20: Anna Rose: Okay, you have. 20:22: Tarun Chitra: I think the bigger thing is like, it wasn't clear when we started this, that that would be the direction things would go. I think when we started it, it was all of us were just like, how does this make sense? But also does... There should be some like... There was just this inkling or feeling that, hey, look, in the 1970s, sort of when options pricing theory first was developed, the options market was basically non-existent. It only existed in legal contracts. And people were basically like, when they had options, they were employee stock options or warrants. They were not traded options on equity. But the idea that there existed a model to price things is actually what caused plus electronic markets is what really caused the options market to boom. Once people had sort of a lingua franca to use for deciding what it meant to hold X amount of risk, people were able to use these instruments more. Of course, things blow up, model doesn't work all the time, yada, yada, yada, whatever. I mean, those are the devils left to the user. 21:24: But the point is that there's clearly with some new theory here, and we were just more convinced that it was this intellectually curious thing, and all the people in cryptocurrency land are really always focused on these distributed systems or cryptography guarantees, but they'd kind of always leave it as a "exercise to the reader", all of the economic or crypto economic things. I mean, just look at the Chainlink paper, for instance. It doesn't really specify what it's the true economics are. No knock to them, but they probably start to figure that out soon. But I think that the main point is that, there is clearly some new type of way of thinking about quant finance here, that due to the idea that settlement is sort of instant, amongst other things. And I think that that was where it started, was that kind of curiosity, which probably was true for a lot of people in the bear market who were looking at the stuff because there were only 10 of us. 22:20: Anna Rose: Yeah. It's true. 22:21: Guillermo Angeris: Yeah, we all know each other now. And we all DM each other constantly and try to nerd snipe each other. So at this point, it's like a weird click of random people. 22:30: Anna Rose: Okay, but tell me more about the builders that you are finding. Are you actually sourcing these things? Are you saying like, I just published this paper, we need a group. How do you even do that? 22:40: Alex Evans: So people come out of the woodwork. I mean, on Twitter and so forth, and we won't know their names very often. And you'll find that people can go very deep and understand very concretely how things work, sometimes not so much to be counted. But very often we have... These ideas are mostly theoretical. You see the papers are mostly like Guillermo's PhD advisor who I recently met calls street-fighting mathematics of just essentially, little cute things that we do, and here's this thing, like it or not, here's how it works. And there's a lot of work that needs to go from... To take that from a theoretical idea to actual code and something that's implementable in practice. And so these people will ask all the right questions about how this thing will work and all that. One team, for instance, that's working on the replicating market makers paper, which Guillermo in very high level terms rehearsed earlier, essentially went through that exercise and are currently going through that exercise of taking sort of a fairly abstract academic idea and turning it into an implementable project that users can actually interact with and get the types of guarantees that at least in theory are possible. 23:52: And that obviously requires a lot of engineering work, it requires a lot of security work and it may be some of the mathematical properties help you there, but of course what they look like in the scary, horrible, twisted world of the EVM and Solidity is very different. And so we don't claim credit to any of these or these teams' work. And we've been helpful to the extent that we can. But of course, these are brilliant engineers, developers, and so forth that are really sort of pulling the weight here. 24:22: Tarun Chitra: To be fair, also, this is also true with ZKPs and consensus protocols, where the original paper is a very far cry away from what the actual implemented thing looks like. But it gives you sort of a North Star, but it's a very lossy North Star. And as you try to chase the rainbow, metaphorically, well, that's a bad metaphor, but as you try to follow this guide, you realize, hey, I'm getting finer and finer resolution and like, oh, I missed this thing, or I missed this other thing, I missed this other thing. And you kind of only learn that stuff from actually trying to build these things, or write code that does what they're supposed to do. And I think that's sort of the next step from this type of stuff. But it's almost the same in my mind as the people who are writing the early ZKP papers, where it was more this curiosity as to, can you actually get succinctness? Can you actually get non-interactivity? Can you actually get these random polynomials to not be in a field whose order is more than the number of particles in the universe, dot, dot, dot, dot, dot, right? 25:30: And these things always start with a kernel of that. All of the AI and machine learning stuff that people do started with this kernel of, actually, I believe, just throw more hardware and increase the size of this stuff and don't care about proving the formal math. I must, Guillermo should grin because he's around more of the shills in Stanford, unfortunately. 25:52: Anna Rose: It's interesting because it's almost like, especially looking back at some of that early work, it does sometimes feel like, through the curiosity, solutions are offered, but the problems haven't been defined yet. Like you can kind of figure out what is the problem we're trying to solve with this, but it's like, there's so many interesting properties in this solution that you're looking to see if it fits other problems afterwards. I don't know if it's like that at all in the work you're doing. 26:18: Tarun Chitra: I think for DeFi, it's a lot... One thing I would say is different is a lot of times our papers are fast follow to like, hey, someone did something in practice that they have no justification for and there's no reason it should work, but we kind of started trying to write out the math and then all of a sudden it's like, okay, ah, there's clearly some reason it should work and here's the reason. It resembles more of the relationship between physics and math, right? Where like physics finds something that completely is non-sequitur to mathematician, and then mathematicians spend 50 years and try to create the theory for it, try to create the... Like, oh, we have to invent some new type of math to do it. Here it's much more pedestrian. It's more like there's got to be something that's working. The space of things that it could be is quite small because blockchains kind of restrict the actual execution and state and everything of the system. There's only certain types of users, et cetera. 27:14: But I think some of our papers are predictive, some are sort of retrospective, but in some ways, I think one thing that's been very clear is that people who are like economists and applied math people and people from machine learning, people who like kind of hate crypto normally, they read our papers and like them because they write them in a language that they understand. 27:35: Alex Evans: That's an optimistic version of it. There's also another type of paper, which is perhaps our most popular, certainly to that group. Also typically our most simple, which is just us being the really annoying, stupid people at the back of the room and somebody coming to us with a solution. The most recent example is this paper we wrote on liveness failures on blockchain, so actually our most qualitative paper of the ones we've written. And it came out of... 28:02: Tarun Chitra: It's really a slightly better than a blog post. 28:06: Alex Evans: Yeah, I think that's one way to say it. And... 28:08: Guillermo Angeris: I think that the technical term is called an academic shit post is what I believe is the actual technical term. It's written in tech, but that's about all you can say. 28:17: Anna Rose: Okay. 28:17: Alex Evans: But essentially the premise of that, and maybe this is a good segue into that work here briefly, so we can touch on it is, we're just getting a lot of DMs and talking to really smart people that are building things, let's say on non-ETH chains that are a little faster and cheaper to build on. And very often we'll hear this pitch of like, Hey, here's this thing that works on Ethereum, call it a lending protocol, call it an options protocol. And we'll just rip out the CFMM and add an order book. And we're going to have a much better system in so doing. And so this paper is saying more like, whoa, not so fast. Not saying that that's a bad idea, but here are some trade-offs potentially to consider. And in particular, one of the things we point out is sometimes we have liveness failures on blockchains and that was no more acute than in Solana. And so this kind of leads into Tarun's point of, we just notice an event and we're like, well, what happened here? What are some underlying dynamics to consider? 29:14: And in this case, we noticed that in order to align the prices of CFMMs with an external market after liveness failure, you only need to do one really big transaction, and computationally, that one transaction is just as complex and expensive as a smaller transaction, as opposed to on an order book, where if the price moves against you in a really big way or in Uniswap v3, the price moves against you in a big way, you have to cross multiple ticks and that's much more expensive to execute, or you need to clear significantly more orders in order to walk to the new price. And so once the blockchain regains liveness, that requires users to submit much more expensive transactions at a period where everybody's rushing, for instance, to clear their liquidations, to execute certain transactions for safekeeping. And that creates an environment where you're much more vulnerable, for instance, to very significant price moves that negatively affect your returns as a liquidity provider to these AMMs. So certainly we like the capital efficiency and we like the flexibility of these types of designs and are excited to see them proliferate in places where transaction costs are cheaper. But fundamentally what we're saying in this paper is that there are trade-offs to that and those trade-offs need to be considered in the design of these protocols. 30:31: Anna Rose: Interesting. And that paper you're talking about, it's like liveness on Solana. You're looking at, what is the effect of liveness? Where I guess if liveness goes down, is that what you say? If liveness disappears, what happens to these? I guess you're looking at the two different systems, right? Like order book and CFMM and comparing? 30:51: Alex Evans: Yes, effectively. 30:53: Anna Rose: To me, it's kind of an awesome case study you got to examine. Or could you have predicted? Or did you need this to happen to say like, oh, this is gonna happen? 31:01: Tarun Chitra: Let's put this way, all the math in the paper, for the most part, I mean, minus a couple little technical nuances was already stuff we'd written a long time ago. In fact, we have this one paper that basically is the God paper and has all of this stuff, but I feel like no one has actually ever read it because everyone who cites it... 31:20: Guillermo Angeris: The gift that keeps on giving. 31:21: Tarun Chitra: Yeah, I feel like every single thing I work on now, just like somehow I'm referencing that paper all the time. But basically became sort of clear that... It's not like the math was new as much as it was like, what's the actual story for what this thing that happened was, using the existing framework. 31:43: Alex Evans: Stories are typically one's Tarun uncovers, which is also descriptive of his role. We jokingly call him our PI. And sometimes the math will all be there, but there's no story around it, and Tarun is our fearless leader in that regard. 31:59: Guillermo Angeris: Yeah. And we're like, Tarun, please fill in, Tarun autocomplete, whatever the GitHub code AI thing is, that's Tarun for us in stories. He just like, press tab. 32:08: Alex Evans: Copilot. 32:10: Guillermo Angeris: Yeah, there we go. It's the copilot. So we have a Tarun Copilot AI where here we message a telegram group, and then, Tarun goes and fills in all of these nice little gaps and be like, oh, this beautiful story about how it all works. It's like, oh my God, you're totally right. I almost convinced myself that that's exactly what the paper was about at the end of the day. 32:29: Anna Rose: Can you share some other examples of that? Like what other kind of storytelling type papers have you done? 32:35: Guillermo Angeris: So like Tarun said, there's the God paper, or as I like to call it, the gold mine or the gift that keeps on giving. And it's this weird paper that actually has a hilarious title, it's kind of silly, but it's called, When Does the Tail Wag the Dog? 32:47: Anna Rose: Okay. 32:47: Guillermo Angeris: And I think it's called Curvature and Market Making is the subtitle or something like that. That was the first, the OG storytelling paper. It's like, we realized that at a certain point, what became the most liquid exchange for a bunch of random tokens, it wasn't Coinbase, it certainly wasn't FTX, no, it was like Uniswap v2\. And so, Tarun and Alex had been talking about this and it was this... At the beginning it was a little bit of a complicated story because we were like, oh, we have all these things that we want to show and all this like, what's the largest trade you can make in order to incur, or after which LPs start losing money, right? And things like that. These kind of things that we all knew and wanted, or at least had some idea that if you make... If a trader trades really large trades against you, you kind of end up losing money and all of these things. So that was the original storytelling paper where I think the original paper started at, what did it start at guys? I remember it was 8 pages or 10 pages. And then I think, if I recall correctly, the last posting on archive was about 45. 33:52: Anna Rose: Whoa. It's a big story. 33:54: Guillermo Angeris: Yeah, yeah, yeah, truly big story, but it's kind of fun because it turns out that paper predicted a bunch of weird results that we ended up writing. But that was the original one where we tell the story about, oh, look, why do you need yield farming? Like, why did yield farming become so interesting and useful? And it's like, well, it's because LPs were used to kind of losing money if they weren't careful about things exploding. But it's like yield farming kind of helps you out with that. And so it has this effect, it has all of these qualitative but mathematical, you can write them down, effects downstream for LPs and for traders and so on and so forth. And it was kind of the paper that outlined using very basic math exactly how these things came into play. And then it told you things like, okay, how much do you have to incentivize a pool in order to keep LPs happy and all of these things? But that was the OG story paper, I think, and it's still the gift that keeps on giving. 34:46: Tarun Chitra: I think the meta-narrative is like, when we started, it was like, okay, everything was on centralized exchanges, but there was this kind of niche thing that was somehow growing. And the initial idea was like, okay, well, clearly the centralized exchanges are way better for the users. So the secondary exchanges must be for people who really need them. And so most of the arbitrage must be coming from people who see the price on centralized exchange being different than the price on the DeFi exchange and the centralized exchanges almost as if it's an Oracle. It's like the perfect price, but the DeFi exchange is this kind of shitty price, but people who have no other way of getting the asset have to go there. And so we started with this model of like, oh, how do these things work, assuming there exists some sort of infinitely liquid external market. And then as the market progressed, it just became more and more natural to say, hey, look, wait, these markets are growing faster than Coinbase and FTX. 35:42: Like Coinbase and FTX, their volumes are flatlining and Uniswaps and Sushiswaps and stuff are mooning. There must now be some other market structure thing that happened and our initial paper kind of doesn't capture that, right? It only captures the case when it's sort of the secondary or shittier market. But when it's the main one, then there's this kind of this question of like, oh, well, what happens when these DeFi things are actually dominating the centralized thing? And that's a very different question. And you have to come up with a new way of framing it. But the math is not very hard. In fact, Guillermo usually just yells at Alex and I, anytime we try to do any math that undergrad, first year couldn't... Barely can take a derivative, like type of student could use. 36:27: Guillermo Angeris: I'm sorry. 36:28: Tarun Chitra: Which is like a sort of philosophy of his advisor, of like, keep it simple, extremely simple, stupid. Any of the more complicated math, by the way. 36:36: Alex Evans: Guillermo, he's seen some things, to be fair to him. He's, oh, have seen you like seven pages of differential equations that I sent him and I got a virtual slap in the face and grabbed me by the shoulders and shook me. And we do for the listeners spam Guillermo enough to the point where he's become quite annoyed I think. But it is a typical approach, right? Like we'll see something like what Turun is describing, right? Which is, look, it looks like these CFMMs are willing the centralized exchanges to obey their price as opposed to the other way around. Or we're seeing all these people design these "private CFMMs", do they work or do they not? And very often, the first order approximation is just brute forcing an answer to the question that this type of phenomenon poses. And it is typically very ugly. And I think the approach that hopefully works over the long term is to simplify it as much as possible to the point where it's accessible to a wider audience and Guillermo in our group is kind of tasked with doing that as annoying as it is. 37:51: Tarun Chitra: To be fair, I think that is sort of the part of the reason that I think people from other disciplines are able to read this stuff. I think one of the problems I oftentimes had when I was an outside person and was reading like cryptography research, both zero-knowledge proof stuff and proof-of-stake stuff, is it's almost written in a purposely, fuck you reader, you're too dumb, knave. Don't read, don't read. And the way these papers are written is obscuring, oftentimes I feel like it's overcomplicated to obscure that it's actually a simple result. 38:25: Anna Rose: Totally. 38:26: Tarun Chitra: Or extremely long, something that in math would be a one line to express, someone wants to write it as an algorithm, and it's like, now you have to do the reverse engineering as the reader to try to understand, oh, they really just meant use this concentration inequality instead of run this algorithm with randomly, on random input. So somehow I think coming from outside of the space, also for all three of us, made us not necessarily like the writing style often found. 38:59: Anna Rose: I want to ask a little bit more about the storytelling though. The MEV paper that you did, like are you... There you're kind of going outside of some of... I mean, I think you're going a little bit outside of the CFMM, maybe not actually, but is that a storytelling one or is that prescriptive? And maybe you can talk a little bit about that work. 39:19: Guillermo Angeris: Yeah, yeah. So the MEV paper essentially, so let's talk about the MEV paper. So the MEV paper essentially says like, look, miners get a bunch of bundles, which the bundles themselves or something tell you something like, look, I want my transaction placed before and after another transaction like some whale trade on Uniswap. So it's called a sandwich. Or I want my transaction placed right before it or whatever. And the question of course, the miners have is, okay, I have this huge thing of this number of bundles, how do I optimally accept bundles such that A, they don't interfere with each other because that's kind of silly. And B, very importantly, is how do I do that in order to maximize my profit? Right, so right now people, we're coming up with all kinds of complicated heuristics and all this kind of stuff. It turns out there's a very, very simple kind of framework to think about these problems called a mixed-integer, I guess it's linear programming in this case, right? Where essentially you have a bunch of constraints and you say, okay, subject to these constraints, which is you can't have a sandwich transaction and also something coming after it that requires it be immediately after. So essentially you can't have these bundles interacting too much. And B that the bundles are actually fit in the places that they're supposed to be placed. So those are your constraints. Then you wanna maximize what? Well, you wanna maximize your total profit from including these bundles as a miner. 40:39: But this kind of, you know, can maybe stepping back from that, that's what one might call a somewhat storytelling paper in the sense of all of this is a note and it's five pages long and it's really not that complicated. So why are we making it that complicated? But kind of stepping back from that, this is what Alex and I guess my advisor Stephen Boyd call street-fighting mathematics. It's this notion that at the end of the day, all of these problems are actually fairly straightforward. Look, it does take a lot of thought to get them down to this very simple looking shape, and in fact, we've gotten knocked for it a few times by reviewers, which I continue to completely ignore and just continue with my stuff. But the point is, there's a set of pretty common mathematics that doesn't require that much sophistication, and you have these problems that look very complicated at the surface, they kind of are complicated if you think of all the details and everything at the same time., but the point of math and computer science and all this stuff is, is abstracting a very, very clean, simple solution from these problems. And sure, it requires a little bit of math, but at the end of the day, it's all actually shockingly simple. 41:45: And so the, our rabbit hole has been CFMM simply because it's kind of been an interesting thing of ours, but I guess maybe probably by the end of the year, we'll probably be stepping back and leaving people with a set of open questions and kind of moving on to these more adjacent fields because CFMMs sure are fine, they're interesting and they're great and they're like whatever. We've done all this research about them. But at the end of the day, they're yet another tool in the toolbox to do things that we want to do. And that's kind of the purpose of our research is not so much the point of here are CFMMs, here is all the cool things about them. Like, yeah, that's fine. And that's a great consequence, but it's not the point, right? The point is to do useful things. And that happened to be a useful case. It's now kind of, I think, personally reaching the end of its life in terms of like truly novel, interesting solutions. But there are many, many more fields like it. 42:38: Anna Rose: Yeah. I mean, actually, you were on the show previously to look like we were talking mostly about private AMMs and are they possible and what are techniques to do that? Are you also looking though at these intersections? So you're saying like, oh, there's these other problems faces, MEV is a very well known one. But are you ever thinking about what do they actually do to each other? I mean, privacy and AMMs there you see it like that was part of the work. But yeah, are you also doing that with MEV or maybe some other things? 43:06: Tarun Chitra: One thing to say about the liveness paper and the differential privacy paper, basically show that in order to get certain properties or avoid certain bad scenarios, you actually do have to reason about how the consensus protocol interacts with the application. So in the liveness case, it really boils down to your choice of mechanism for liquidity provision is actually implicitly reliant on some sort of bound on the maximum time the network goes down and the maximum price deviation. You might not think about that when you're designing the application. You're just like, I'm writing an order book. How do I have a FIFO queue? How do I do this type of order? How do I do an iceberg order? 43:48: Anna Rose: Because you're not expecting the network to go down, I guess. 43:50: Tarun Chitra: Exactly. Right. Or in the privacy case, you're like, oh, great, I'm going to hide the balances. I'm going to hide the balances so no one can figure everything out. And then you're not thinking of the threat model of, well, okay, what if the person who's actually trying to de-anonymize you is also a validator, also a miner, right? And in some sense, a lot of our more recent work, I think personally, the paper I'm most proud of from our thing is definitely the differential privacy thing, but that's just my... Because it kind of exemplifies this fact that you can't really design these things without thinking about consensus at some point. There are just certain properties that will eventually be that. And for Uniswap, it did get kind of lucky that it took so long for MEV to happen. Right? If there was so much MEV at the beginning when Uniswap started, I think it would have actually been much harder to bootstrap or people to understand how to use the mechanism without getting blown out of the water. 44:49: Anna Rose: One thing maybe to note though, the paper you just referenced the differential privacy is not the work we talked about with Guillermo. 44:56: Tarun Chitra: Yes. 44:57: Anna Rose: So there was an evolution there, right? Like, or was the first one that you did much more like, here's why people's approaches are wrong, so a bit of story, and here's a few ideas. Maybe you can talk a little bit about that journey and that evolution of your thinking into this more, I guess more spec'd out solution of differential privacy. 45:19: Guillermo Angeris: Yeah, it was kind of a one-two punch. And it was actually not intentionally a one-two punch, but the point was the original paper that we talked about, I think, yeah, March of this year, essentially said, look, here's the deal. You can't just willingly hide things from the user and from anyone snooping around and then expect that in fact, that actually confers you privacy when you're interacting with a CFMM. And it was kind of a simple result. It was pretty short. This notion that a lot of people had intuitively, but it spec'd out exactly how the attack would play out. And then we just kind of gave a few simple paragraphs stating, look, here are some cases where the proof fails. 46:02: One is, okay, if you batch a bunch of transactions together, then people can't tell them apart, then congratulations, that's one. Number two is, if you add kind of noise to the price, so if you present the user with a price that isn't actually exactly quite the price of a CFMM, then it's a little harder for them to reconstruct up to a certain degree. The more noise, of course, the worse it could be for LPs or the user, but the harder it is for them to infer the underlying prices, and therefore, the harder it is for them to infer what trades have happened. And so that was the first one, and it kind of said, look, the approaches here, it's not obvious, right? The problem isn't an obvious one. It isn't just simply add a ZKP to Uniswap and be done with it. And then we were left with this horrible, sick, and twisted itch of being like, okay, this is great. We've just told you that you can't do this. But can you actually do this in some way that makes sense? And this is a... Tarun's answer was a differential privacy paper. 46:59: Tarun Chitra: Yeah, so, around the time that we wrote this paper, actually Anna and I were both in Austin at that time. 47:07: Anna Rose: During the snowstorm. 47:08: Tarun Chitra: Yeah, this was right after the snowstorm actually. And we put out that paper and I had basically by happenstance kind of been a little annoyed that we didn't find some simple trick, like a Buzzfeed article way of getting around the impossibility theorem, like one easy trick that makes this wrong. But I happened to run into this paper by pure happenstance by Nika Haghtalab and Roughgarden and someone else that kind of introduced me to this whole new world of things that people were working on in terms of privacy versus utility trade-offs. So like, there's this kind of this idea for any learning algorithm, and so we can make the Uniswap... You could think of the Uniswap price algorithm as learning algorithm. It's learning like in a very dumb sense, it's not a very sophisticated learning algorithm, but it is something that's sort of learning how to update the price as a function of the reserve. There's this kind of natural trade-off in machine learning that people in cryptography and in cryptocurrency don't think of a lot, which is this utility versus privacy trade off. If I add in a bunch of noise to blind your data, will I also make any function of your data worse? 48:28: So if I randomize your height, well, maybe I preserve the mean height over everyone, but I kind of mess up the variance of the height or I mess up other statistics of the height, if I had like a table of people's heights. And in some sense, there's always this trade-off. You effectively can't get out of it. And going down that line of research just kind of led me through how people in sort of machine learning think about this stuff, which then I found over time, over many months of agony, a way to adapt it to this setting. 49:04: Anna Rose: Interesting. Just one side question, why in machine learning do you use these techniques? What are they for exactly? 49:13: Tarun Chitra: So the best example is the US Census. So the US Census collects a lot of data, right? And there's tons of sociology researchers, and people who do that type of stuff, historically have relied on the census for data, but then people have shown these kind of attacks where people can de-anonymize people's individual census items based on the average that is produced. So let's say someone gives you the average of the height of a certain area, and it happened to be an area where someone lived that was seven feet foot tall, you could effectively infer if their data was in the data set or removed. And so in some sense like this... 49:54: Anna Rose: Some of the exceptions, the unusual ones. 49:56: Tarun Chitra: Yes. And those are the people who oftentimes value their privacy the most. So there's kind of this weird thing where that happened, then the US Census was like, okay, we're going to use these privacy techniques. And now sociologists are a little pissed because they didn't know how... To be fair, all they learned how to do is import our library, call our library on census data. But so I don't think they really checked carefully the math they were doing and how sensitive it was to noise. But the point is, there's a lot of times where someone can take a data set and augment it with external data, a data set that's anonymized, and then de-anonymize it. So there's this famous example in New York where Uber had to provide New York City with all the Uber trips, but they were anonymized. And then someone found another data set related to Uber coupons or something, and then they joined it and they were able to de-anonymize because the one was de-anonymized, one was anonymized. And so then they found all these... And this actually, I forget if it was the Eliot Spitzer thing or if it was some other like sex scandal, but they did find this like politician who was constantly going to this one strip club and that was like a big. 51:07: Anna Rose: Whoa. 51:08: Guillermo Angeris: The other famous example, which is actually really, it's kind of what started, kind of kicked off this whole field was Netflix in 2008 had a very famous Kaggle challenge. That a very famous challenge was can you predict what movies people are going to like given their previous ratings or something like that. And this dataset was completely public, right? It was a big dataset. And some researchers went through and essentially what they did was they just using mind you, this is ridiculous, right? Like, just using people's preferences for movies, they were able to de-anonymize, I can't remember the exact number, but it's either a quarter or a half or something of all people watching. This is again, mind you, Netflix movies in '08, right? Like think about that. And that's, they were able to de-anonymize something like half of the... Or a quarter of the dataset just from their movie preferences and combining it with some other dataset. 52:00: Anna Rose: It's crazy. 52:02: Guillermo Angeris: So it's, we joke that it's some esoteric mathematical thing, but at the end of the day, actually, it turns out to be hilariously simple and you can run it on a laptop and do some real damage. 52:10: Anna Rose: But where the differential privacy, like where was that first thought of or implemented within a machine learning context, if you remember? Like was it that census one? I mean, I think you've given great examples of the problems. 52:24: Tarun Chitra: I actually think it's Apple, because they were like the biggest proponents. So in iPhones, a lot of the data you send to Apple servers is encoded in a differentially private manner. I don't know about which things are and aren't. I haven't actually read their docs carefully enough, but they were the first big tech company to invest a lot into it. Their whole claims of being really good about privacy are about this. But of course, they have other things that are not so good. So let's not try to lionize anyone. But the point is that basically when things started moving to the cloud in 2006, I think Apple was the first one to be like, no, no, no, we're only putting stuff on AWS servers if it's differentially private because fuck AWS. It actually ironically wasn't about protecting the user, it was about protecting someone else from taking the data of your user and that wasn't you. 53:13: Anna Rose: And using it for their purposes. 53:14: Tarun Chitra: Yes, and making money off of it. 53:15: Anna Rose: Wow. 53:16: Tarun Chitra: But the idea here is that this utility versus privacy trade-off is like, say you have a machine learning algorithm that takes your ratings, like what Guillermo said, and it can perfectly predict your ratings, but it leaks information about you versus something where I add noise and now I've ruined the prediction quality. Its prediction goes from being perfect to like 75% accurate, but your privacy has gone up, right? So that's sort of, that's the thing you should be thinking in your head. That's why the Netflix example might be the cleanest one. 53:46: Anna Rose: Now let's hear then how is differential privacy actually used in our context? 53:52: Tarun Chitra: So imagine you have someone who has a machine learning algorithm, where they can try to predict where the whale order is. So let's say there's like a thousand trades of size one. So it's like one Gui coin for one Alex coin. And then there's the whale, Guillermo, who's like, I want to ape into Alex. So I'm going to bank a thousand... I'm going to trade a thousand Gui coins for... Sorry, Alex. 54:17: Guillermo Angeris: I think it's Alex too, don't worry. Trust me. Much more valuable than Gui coin. 54:21: Tarun Chitra: I guess that sounded a lot worse than what I said. And so the idea is the people who have this very small trade size, the one coin size, they all want to actually be in front of the person who is the 1,000 trade size. Because once the person who trades the size of 1,000 trades, they will push the price up a lot, right? And all the people who are the small fries will get way worse price impact. But from the whales perspective, you actually are like, hey, I just want to be fairly priced. I don't care where I get put, I just want it to be fair. And so the whale is the one who's trading their privacy in some ways because they just stick out like a sore thumb. Their trade size is way bigger than everyone else's, so statistically, people can try to say, oh, I know this is the whale's order, I'm going to front run them. 55:14: Anna Rose: And this is the exception we were talking about before, I guess. This is the exceptional result that's very, very visible. 55:18: Tarun Chitra: The outlier. Right. And in trading, that's much more common, right? When there's like a liquidation, there's just like a million MEV bots and searchers trying to chase it. Right? So, and they all have small size relative to the thing that's getting liquidated. So this type of scenario is extremely common in finance, even more so than in the sociological data type of scenario. And so the idea is privacy, well, what does privacy mean to the whale? Well, it means that somehow they can still get the same amount of quantity, the thousand orders, but it's going to get interspersed. So imagine if now I cut up the trade of size thousand into 100 pieces of size 10, and then I randomly intersperse them amongst the other trades of size one, do they get a better price? And how easy is it for someone to front run every single one of their size 10 orders? And so because I'm adding some entropy by cutting up the orders and splitting them, that's increasing my privacy, but I'm making my price impact worse in some sense, because I'm splitting up my trades and I might have had more... It could be worse. And so that's sort of the trade off that we kind of analyze and show that you can, if consensus can provide a source of randomness for doing this kind of chopping up and permuting action, then you can achieve kind of these types of privacy guarantees. 56:39: Anna Rose: When you talk about cutting them up though, would it be cut up in equal sizes or is this also somehow random? 56:47: Tarun Chitra: No, that's a good point. That's a very nuanced detail that Guillermo asked me about five times when I gave the paper because it was like, which is no, no, you actually do sample from an unknown distribution, a way to cut up the pieces. So not only is... The randomness, not only does it randomly cut up the pieces into different sizes, but it also does it in such a way that the distribution over how it cuts them up is not known. That's the key. That's the very key crucial part. Otherwise, you're kind of... If someone knows the distribution, they could simulate it and try to say, oh, this is the most likely cutting. 57:24: Anna Rose: But how would you keep that private? How would that not be known when you're talking like open source? Isn't it kind of there? 57:31: Tarun Chitra: Provided you have an input source of randomness that you trust, like a VDF or a VRF, you can sample from this distribution of how to cut things up in a differentially private manner itself. The root security detail will end up being like, does your VRF or VDF actually give you enough entropy? 57:52: Anna Rose: I got it. 57:53: Tarun Chitra: So that's why consensus is important to this. It's an application that takes advantage of the randomness guarantees of consensus. But this is another situation where the application layer has to interact with the actual blockchain. 58:06: Anna Rose: So I mean, the example you gave was focused on the whale and this exceptional amount, but are you actually imagining this running on all amounts, even if they aren't exceptional? 58:19: Guillermo Angeris: So the idea is that that would be, well, A, there's kind of a trade-off for the user, for the whale. For most small users... 58:26: Anna Rose: I keep saying exceptional, I mean outlier. 58:28: Guillermo Angeris: Yeah, yeah, yeah, exactly. Right, so for most users, the trade-off is the following. It's zero, because they're just gonna trade anyways, right? The trade-off is either there's kind of two, there's one at the exceptional user level and there's one at the base layer level of... Actually the CFMM itself is going to have some sort of price impact that's different. But at the whale level, you have a slider that says, how much privacy do I want versus how much do I care that this thing just gets executed and doesn't cost me personally. So there is a cost. In some sense, the point that Tarun is making is that there's a cost of privacy, right? And it's a cost of very literal sense of, at the end of the day, you're paying for that whether you want to or not, right? And you can choose to not pay for it, but now you've traded off your entire privacy. So the point of that... 59:13: Anna Rose: Which could impact your actual trade. 59:15: Guillermo Angeris: Exactly, exactly. So it's, you either eat up the cost of the trade or you eat up the cost of privacy and take your pick, right? There's a slider there and that's fine, but at the end of the day, there's not really an obvious way of making them together. And then certainly there isn't one obvious and immediate exception because of the paper that we were previously talking about. At the end of the day, you can't have your cake and eat it too. 59:35: Anna Rose: This is interesting. So it isn't blanket differential privacy across the board, but more of an optional differential privacy. Are there, and I imagine you've explored this, but are there any other edges or leaks that could come out of this that are not covered by the differential privacy slider? 59:53: Guillermo Angeris: So there are some. One case that we've made previously, which is kind of interesting and also requires kind of control of the consensus layer, although you could implement it later, is one thing that would actually just immediately improve privacy is just simply matching orders off-chain. So you can imagine that there's some sort of there's a bit on a contract header that if that bit is one, what it does is it immediately starts some algorithms. So when the block is minted, part of consensus requires you match orders prior to including them in the CFMM. Right? So the idea is like, look, Alice and Bob trade in opposite directions, and then there's like whale, I don't know, Willy, whatever, who trades in some other direction. The point is you match everyone's orders off-chain, right? And then it's kind of if no one can see the amounts and privacy is preserved in some sense, right? In the CFMM itself, and then Willy just uses the remaining part of whatever is left over to trade against the CFMM. And then of course, here's the deal, Willy loses privacy, right? But everyone else is pretty much safe. 1:00:56: Anna Rose: Got it. 1:00:57: Alex Evans: Assuming you obviously trust the aggregator. So there's some off-chain operator that is collecting these trades and matching them when they offset and there's some secure way of communicating with them, which I would love to see it if somebody has it, but it doesn't suit that. 1:01:12: Guillermo Angeris: Exactly. So at the end of the day, it's all trade-offs, right? There's not an obvious, like, it's not a bomb-proof box, but it does seem to be at least somewhat watertight. Maybe that's the statement. 1:01:24: Anna Rose: So that paper came out, I don't know, two months ago or so. Have you seen anyone try to do it or play with it actually, like implementing it? 1:01:34: Tarun Chitra: Osmosis. They're the ones who are actually going to... Osmosis and Penumbra, they're both going to actually try to implement it. 1:01:42: Anna Rose: Amazing. 1:01:44: Alex Evans: I mean, just as we said earlier, these are mostly theoretical ideas and taking them to practice. In particular, this one is going to require some really talented people. I think the Osmosis and Henry of Penumbra, these folks are brilliant. And so if somebody's going to do it, they're going to do it, but it certainly is not all there, in fact, very far from it. These are just high level ideas with horrible constants and so forth. They give you a vague idea of a set of tradeoffs that one should consider, but doesn't tell you what types of parameters you should select or how you should actually implement these types of systems in production. 1:02:17: Anna Rose: It also sounds like in that implementation, I mean, I'd be so curious to see if they find new problem spaces or maybe new solutions too, through that. 1:02:27: Tarun Chitra: Yeah, for sure. I mean, one of the things Henry seemed most excited about this was like, he was like, I don't care about the constants, SNARKs still have the worst constants if you read the papers carefully. Like a lot of the original SNARK papers have just like horrendous, like hidden exponential constants, and over time people in practice, like I would say like, Ariel and Zac's research program, at least for me as an outsider, if I were to describe it or something, it's like literally just reducing every single constant that is in all the original SNARK papers to something practical. 1:03:01: Anna Rose: You mean Plonk, like what they've done with Plonk? 1:03:03: Tarun Chitra: Yeah, all the entire series. 1:03:06: Anna Rose: And all the turbo-Plonk and super-Plonk. 1:03:07: Tarun Chitra: Like Plookup, FF-plonk, all these things are like, if you read them carefully, are just constant reduction mechanisms, which is the type of thing that you do when you're actually doing engineering and not armchair math in some sense. 1:03:22: Guillermo Angeris: Yeah, when you're what I like to call doing real people things as opposed to like fictional made up world fantasy that we do when writing papers, like like 90%. I mean, 10% of it is actually useful, but at the end of the day, it's storytelling, as we like to call it. 1:03:36: Anna Rose: Well, I am so excited to hear that people are now experimenting with this. Yeah, it's awesome to hear this. So I think to wrap up this episode, what I would like to hear from each of you is actually a space or topic, something that you haven't yet explored, where you see your research potentially going towards. So Alex, why don't we start with you? 1:03:56: Alex Evans: The honest answer here is that, and you know the answer because we've been chatting about it, is that we've been looking a lot at ZK and we're so early in that exploration where the directions are less clear. We're really interested in ZK more generally, right? But some areas where we can be useful and our work can potentially be constructive, out the gate are more in application areas, as well as some of the things Tarun described in terms of acceleration of certain things and maybe some more practical examples of how these things can be used. The economics of ZK systems, there's very little work sort of on, there's now all these rollups, there's now all these private layer ones, right? What are the different types of economic arrangements between the agents in these networks? And those are areas where we can maybe do damage out the gate, but then we're certain there's much deeper and more sophisticated problems that we'll encounter as we pursue that exploration. As there were in CFMMs and MEV and staking and lending protocols that we discovered in that work, but the reality is we're very early in that exploration. 1:05:04: Anna Rose: Very cool. All right, Tarun, what about you? 1:05:09: Tarun Chitra: Two main things to your point about there being a lot of cart before the horse. I kind of think a lot of the cryptography ZK stuff is a little cart before the horse and that's not necessarily bad, but we're going to have all of these private networks with smart contracts soon. TM and like the Aleo transitions, all these types of people. 1:05:33: Anna Rose: For sure. 1:05:33: Tarun Chitra: But I guess I think that there's not really any applications that exist, to be honest, other than transfers. Like, yes, we want private smart contracts, we want private smart contracts, we don't really have that many applications. And as kind of our CFMM thing shows, there's kind of this thing where you need to figure out how to design applications, where you partition the private part from the public part, and you're able to like cleanly abstractly separate the two of those, and then, then consider the set of applications, financial applications, you can build conditional on there being a clean separation between public and private data. And I think that is sort of the realm of things that I want to really understand more carefully. And then of course, MEV, I think one thing about MEV is it's like a great meme, but I do think in general, the research has been quite muddled, partially due to marketing, partially due to other things. I think fair sequencing as a thing is very half-baked in a lot of ways and it doesn't kind of reveal all of its warts to the average end user. 1:06:41: At the same time, I also think MEV has not been theoretically described. I think there's been some work, like Phil has a recent paper that kind of tries to get at things, but everything is very brute force. It's like use formal verification or do something, and there's no actual mathematical theory that has any sort of aesthetic beauty that has shown up. Everything's very ugly or extremely like... It doesn't really get to the meat of the system, which is like, hey, we introduced this type of behavior, the economic equilibrium changes amongst the agents, and the new equilibrium has all these different properties that are very different from the fully honest, non-rational user case. Right? Somehow we don't have a story like that. We only have this thing of like, hey, I can do this kind of not very easy to explain mathematically thing, and maybe we find that you can make a profit. Well, that's not like much of a story, right? That doesn't really actually tell you what's going on amongst all participants. And so getting to something like that, that's less brute force, I think, and less computer science focused, because I think like no offense, the computer science parts of MEV are kind of boring in a lot of ways. They really don't illustrate the reason that people are having these big shooting wars, when I say shooting war, I mean like data center wars and co-locating next to certain miners, doing X, Y or Z, right? Like all people don't do that stuff just because of a computer science reason alone, right? 1:08:16: There has to be some sort of like... It's like finance, like why do you build a microwave towers? Well, there's like a certain equilibrium that occurs once they actually exist. You change the equilibrium, right? And in some sense, that's what's happening, and yet people want to just focus on kind of the kind of boring details to me, boring at least. Like there's no aesthetics to it, and people should have some sense of aesthetics when they write papers. And I don't know whether Guillermo's laughing at me or for me. 1:08:46: Anna Rose: With you. 1:08:47: Guillermo Angeris: Yeah. I think, to reinstall the phrase aesthetics, because I have this weird joke that I like to say, and I apologize because this might offend, in fact, some of my colleagues, but there are three fields in ranked order that have probably the worst aesthetics I've seen, and they're in exactly the following order. It is physicists, and I can say this because I'm a physicist, this one I can say without offending people, and it's because if you go read most physics papers, absolutely eligible, even if you're like in the field and often what ends up happening is you go and re-derive everyone's results. Then right immediately after is economists. Some actually there's some cases, very special cases where they have good aesthetics, but almost universally, completely eligible. And furthermore, they often depend on parameters that you can't even measure. So they say something like, oh, the number of or the proportion of informed versus uninformed traders. And it's like, okay, good luck measuring that looking at market data. And you can't even come up with models and all this crap, and at the end of the day, it's like, whatever. 1:09:46: And number three, and these are kind of the most impenetrable, and I apologize, it's computer scientists. Specifically theoretical computer scientists. Some algorithm papers are okay, but for the most part, almost universally, illegible. And the reason why is, and this kind of feeds into why I think our work is interesting, is at the end of the day, there is kind of one kernel of important distilled knowledge that comes from a paper and you should write a paper thinking very explicitly about this. And it's hard, it's really hard because it means you end up rewriting your paper a bunch of times and you end up reworking a bunch of all of these things that at the end of the day you're like, yeah, of course, that's obvious, it's immediate from this long 50 paragraph description of the algorithm, right? Kind of what we were talking about previously. But, I think, the point of our research now is we like to find good and clean abstractions that explain things simply. 1:10:44: And of course, we landed in this interesting case, which was CFMMs, but there are so many more problems that have, in some sense, have this heuristic that if a human can intuit the behavior of a system, then that system, it's probably simple enough that you can describe it simply as well. And so I think the kind of taking the meta level here, as we kind of go forward, the point is finding these pockets of things that people care about and things that people find interesting and describing them using very simple language. And at the end of the day, it's almost universally very simple. If you can work out some calculation for it, why the hell is it not simple? You don't need a SAT solver to describe X or Y or Z. You can just write down a three paragraph definition from which all of these results follow. Again, we landed in CFMMs as being a particularly one such abstraction, but at the end of the day, there's millions of these things that people are kind of hinting at. 1:11:41: We're all slowly but surely churning through, but no one's really sat down, and it's hard work, right? No one's really sat down and put in the hours to be like, all of these results are in fact just consequences of X, right? X here could be many things, it could be some framework for finding out how protocols interact with MEV in a simple way that is clear. It could be the same case with privacy, you know? What can you say? What must private protocols have in order for those things to even be real and all of these things. So I guess that's kind of where we landed and this is the thread of all of our work at the end of the day, but we're looking forward to moving past, I guess, maybe what I guess, this trio is now known for, which is CFMMs into broader spaces that are hopefully at least as if not more interesting as this area we've been exploring for the past two years. 1:12:39: Anna Rose: Very cool. All right, I wanna say thank you so much for walking us through all of this research, kind of landing on where you're going. I'm so excited to see what comes next. So thanks. 1:12:51: Tarun Chitra: Thanks. 1:12:52: Alex Evans: Thank you. 1:12:52: Guillermo Angeris: Thank you for having us. 1:12:53: Anna Rose: And I wanna say thank you to the podcast producer, Tanya, the podcast editor, Henrik, and to our listeners, thanks for listening.