Well, this demonstrates that your services are about to turn to the second set by the distinguished lecturer named after Christopher Scrunchie, research students. Um, before I tell you what, we think our sponsor is Oxford Asset Management. They've been funding this series since 2015. And so thanks to their generosity, we've got to bring people together. And also, if any students are interested in talking to company afterwards, I think very often don't do that.
Before I introduce speaker, I just want to say that afterwards there's going to be some, um, microphones for asking questions. So just raise your hand. And I think as if you were asking questions about here. Probably. Um, yeah. Let's just leave out these. Okay. So I'm an enormous. Um, thank you for listening. Jim is a professor at Columbia, professor of computer science. I was building something very prominent on the world stage, uh, ever since he was a PhD student, which is quite rare.
Yeah. Uh, so he's interested in lots of different areas. The connections between, uh, computer science and genomics, all aspects of algorithms. And then coming back today, which is his recent works on blockchain. I selected a few of the works. Just, um, some of them. So Jeff is the recipient of, um, ACM Grace Murphy Corporate Award in 2009 for his work on Social Security. In 2012, he got a third prize. Uh, actually, um, also with UBS, um, for work on research that limit selfish internet use.
He's the winner of the Social Choice and Welfare Prizes in 2014, which is 200 outstanding accomplishments in social choice, theory of love or economics. He's the recipient of the Kalai Prize in Game Computer Science in 2016 for his paper Intrinsic Robustness in the Price of Energy. He received a The Nine Fellowship in 2017 and ACM Awards 2017. Um, that's actually a pretty small selection, a much longer list.
Um, you know, a lot of just, uh, talks, including, um, being in fact, most of the international conference competitions, but just, um, quite cutting edge. Here's the shock lecture world. No question. Thank society. Um, not so many people, probably many prepared for the many books that he's written. And, um, lectures, 30 minutes, I'm not sure. Especially a lot of the younger people here, though. Uh, present. So stock rooms that accompany the whole algorithm series.
20 Lectures on Algorithmic Game theory. Um, beyond endorsements, analysis of algorithms to learn. We're really competition today. Um, so if you want to come and do that. Um, today's topics have been the double, um, blockchain. I mean, it's called the computer in the sky. So. Thank you. All right. Thank you, Professor Goldberg. Thanks, everybody, for coming out. Uh, great honour to be given today's stretchy lecture.
When I got the invitation, I looked at the list of some of the previous speakers and had a fair number of heroes on that list. Really? I'm very grateful to be here. Particularly cool, actually, to have Professor Goldberg, uh, do the introduction, because now, almost 25 years ago, she was one of my earliest ever supporters as a graduate student. I was totally unknown. She was so nice to me, so supportive about my early work. I've never forgotten it. So, um, really happy to be here.
So what I want to talk about today is a hard computer science problem. Okay. So I want to talk about some computing functionality I think would be really cool to have. And I want to explore some of the scientific and engineering challenges that come up when you try to actually realise that functionality. For an analogy you could imagine, like 60 years ago, having a vision of a technology that enabled any two people on the globe to communicate digitally pretty much instantaneously.
And you can view today's internet as some kind of approximate realisation of that functionality. And if we think of the internet as kind of a neutral infrastructure for communication, you're neutral. I just mean there's no one sort of individual or company or nation state that controls the internet. In some sense I want the analogue of that for computation. Okay. So a neutral infrastructure for general purpose computation. So the functionality I'm interested in is that of a computer.
General purpose. It's going to be a computer that, you know, has its own operating system, its own processor, uh, its own storage. Um, but unlike, you know, a typical computer which has is owned by an individual or a corporation, there's someone that has root access to that computer. I want a computer with none of those properties. No owner, no operator. In some sense, it just runs, if you will, in the sky, where we can all view its computations.
And it just sort of runs there on its own as a public good. I want us to have very high confidence in its computations. It'll carry out the intended computations correctly and for a very long period of time. Uh, no one should be able to shut the computer down or otherwise tamper with it. And I want it to be open access in the sense that anybody can use it and hereby use it. I mean, maybe you interact with software that's already, uh, installed on that program on that computer.
Maybe you install your own programs yourself, uh, for others to use. So this is the this is the functionality I'm interested in building out. Okay. So almost all of the talks are just going to be about some of the challenges that come up in trying to realise that. Another obvious question would be like, suppose you could build it, what would you do?
And this is something I'm happy to talk about at great length after the talk, but it's not going to be the focus of the talk except on this one slot.
There's a bunch of different ways I could answer this question. Um, let me give you one answer that I think is really kind of, um, under discussed in popular discourse around this technology and the sort of one thing I want you to remember from today's talk is that blockchain protocols in the applications built on top of them, it's not fundamentally about cryptocurrencies or about prices or about finance.
It's really a technology that's about something, in my opinion, much more profound, which is stronger notions of ownership of property rights than we've traditionally had for things we might buy or creates in the digital realm. So let me sort of unpack that a little bit. The story starts with a gift given to us now almost 50 years ago by public key cryptography. And specifically, I want to focus on secure digital signature schemes.
Uh, because I claimed if you look at the cryptographic guarantees offered by digital signatures, there's kind of a loose analogy to the types of property rights that we're accustomed to for physical items, right? Like think about real estate, for example. Like imagine you buy a house or you get various property rights along with that, you get the, uh, right to use, okay. So you can live in your house if you want. No one can stop you.
Uh, and that's a little bit like how sort of digital signatures no one can, if you're the owner of a public key. Should have said that at the outset. I want to think about cryptography. Is letting you own a 512 bit string okay. Representing a public key or by own, I mean, you mean you own, you know, the corresponding private key. So analogous to the right to use. Right. No one can stop you from producing valid digital signatures because you know the corresponding private key.
Another property, right you might have is the right to exclude. So no one else can live in your house unless you unless you want them to. And so there there's a loose analogy with digital signatures. No one can forge signatures on your behalf because they're not the owner of that public key. They do not know the corresponding private key. Okay, so I claim we can think of digital signatures as allowing individuals to own, in a meaningful sense.
Public keys. Bits of five of length 512. Let's go back to that computer in the sky. Capable of general purpose computation, certainly capable of verifying digital signatures. And now a sort of, frankly kind of trivial idea, actually, is to extend the notion of ownership of 512 bit strings that we already have to ownership in the same sense of arbitrary digital data that lives on this computer in the sky. Right. The idea conceptually, is trivial, a program running on that computer.
Maybe it's the computer's native operating system. Maybe it's a user installed program. Running in that operating system just can create a pair, okay, data X coupled with a public PPK. And we can now just define ownership of arbitrary digital data X as inheritance as inherited from the associated public key. In other words, you would own X if you're capable of producing a digital signature that witnesses your knowledge of the course of the private key corresponding to PK.
Okay, so I claim if you combine cryptography with the computer in the sky, you get a notion of user owned data, uh, up there in this sense. Now what is that good for. And again, happy to talk about this a great length afterwards. But you know, the upshot is it's interesting to own data on this computer in this sense.
If it allows you to do something you could not otherwise do, perhaps on the computer in the sky, interacting with other programs on it, it lets you do something you couldn't otherwise do. Maybe you can exchange your ownership of some data X for ownership of some other data Y that you're curious about. Or maybe it lets you do something you couldn't otherwise do in the physical world, right?
A simple example would just be representing sort of one of a limited number of membership cards that, I don't know, get you in the cool parties. That allows you to have a special communication channel, sort of with some musician for their superfans, whatever. The point I want to make is that once you have the right mental model for what this technology is trying to achieve, it is not very hard to brainstorm lots of different things you might do with it.
And again, I'm happy to talk more about that in the Q&A. Okay. So moving on to some of the engineering challenges. I've optimised the talk for breadth over depth. So we're going to talk about three different, quite different, uh, threads in my recent research over the past few years. Because of because of all of them, I'll have to, you know, just touch each one, um, pretty lightly. Uh, two themes I want you to look at, I want you to look out for as we go through them.
First of all, how amazingly interdisciplinary it is to work in this application domain. And I say, someone you know, I say that as someone who's almost his entire career has done interdisciplinary work. This is a totally different level I've never seen before, even the different parts of computer science that this technology touches on. There areas that historically had basically nothing to do with each other.
The areas of economics that it touches historically have had nothing to do with each other. And there's other disciplines as well that you're not you're not going to see today. The second theme I want you to look out for is just the incredibly rapid pipeline from just purely theoretical work to practical impact, which is probably as short as I've ever seen in my career. It's been actually kind of wild working in this area for the last few years.
So I'll tell you a couple of anecdotes about that as we go along. Okay. All right, so the first thing I want to talk about, I want to zoom in on the desired functionality of being open access, the idea that anyone can, can use, uh, this computer in the sky. And in particular, I want to ask, how do we make that economically sustainable? Okay. So demand for processing on that computer exceeds the supply. What do we do? That brings us to the idea of a transaction fee mechanism.
Okay. So that's what we're going to study in this in this first part. So you really don't need to know much about sort of how blockchain protocols work. Um, for now, like fundamentally, what's the responsibility of such a protocol? It needs to maintain a running sequence of transactions. Again, I want you to think of this as a general purpose computer. So I want you to think of a transaction as a little snippet of code.
Let's say Assembly language code. Low level code. A sequence of transactions is then just sort of a long sequence of assembly line assembly language instructions that are carried out in this computer in this virtual machine. Okay. So transactions get added to this running log in batches, which are known as blocks. And all that matters for us right now is that blocks are only produced every so often. And they're only so big. I'm going to use the Ethereum blockchain protocol as a running example.
It will become obvious why I'm doing that later. In Ethereum you get a new block, a new batch every 12 seconds. A typical block might have something like 200 transactions in it. Okay. And if you're doing the math in your head and you're saying that's only like 16 transactions per second, that doesn't sound like it's very much. That's because it's not very much. Okay. At least for the Ethereum protocol. Yes, it's a computer, but it's a very slow computer. Okay.
And so for the most popular blockchain protocols, certainly including Ethereum and Bitcoin, uh, the demand is much higher than the supply. Many more than 16 transactions per second would be like, would like to be executed in the virtual machine that the Ethereum protocol maintains. And so the job of a transaction fee mechanism then is to decide which transactions get in and which transactions don't. And in particular, the ones that get in, what price do they have to pay.
So that's the job of a transaction fee mechanism. What would such a mechanism look like? Potentially. Let me tell you about the one that's been in operation, Bitcoin, for its entire 15 years of existence. It's also the one that was used in Ethereum until about two and a half years ago, called the first price auction.
Uh, very simple, very natural. So if we take seriously this idea of this sort of computer in the sky as a public good, if it can't execute everything well, we should sort of allocate it fully and on the most valuable transactions. Okay. How is this computer supposed to know which transactions are valuable and which ones aren't? You ask users to bid. Okay, so a user of a blockchain protocol would submit, along with the transaction, an amount that they would willing to pay.
Should that transaction be included for execution. Okay. So then the way a lot of blockchain protocols work, there's sort of a unilateral sort of one actor that's chosen, you know, usually by winning a lottery. One actor is chosen to put together one of these blocks of, say, 200 transactions. And when they do that, all 200 users that hand their transactions included their bids get transferred to the to the block producer. Okay. So users submit transactions that they want to see executed.
They say how much they're willing to pay, and that gets paid to the block producer that chooses their transaction instead of others to include in the block. Okay, so what do I mean by a first price auction? And you know, this is worked reasonably well. Like I said, Bitcoin's used it for 15 years. Ethereum use it for many years.
Uh, if you've studied any auction theory at all, like if you've ever heard of a Vickrey auction or a second price auction, one thing you know about first price auctions is that it's non-trivial to figure out how to bid. If I ask you to pay exactly the amount that you say you're willing to pay. You're never going to bid your maximum willingness to pay your indifference point. Okay. You're going to shade your bid. You can say, well, I'd be indifferent at not at $10.
Maybe I'll bid $9. Or maybe I'll bet $8. Or you have to sort of think about how stiff the competition is. The stiffer the competition, the less you can get away with shaving your bit. So that's some difficulty in bidding on a first price auction. We've known that for decades, and being in the blockchain setting doesn't make it any easier. Like I said, if you studied a little action theory, you're aware that there are other formats.
If you just change, for example, from a first price auction to a second price auction, all of a sudden you have this magical truthfulness property, which is you just you should just be honest. You should just tell the auction, you know what? This is my indifference point. This is the most I'd ever be willing to pay for this item. And then basically, the second price auction promises to underbid for you on, on, on your behalf, given what everyone else bids.
And for that reason, you can sort of just delegate the under bidding process to the mechanism and you'll never regret it. That's what I mean by truthful auction. So you can ask the question with transaction fee mechanisms. Could we have a better transaction fee mechanism, one in which it's easier for users to figure out what they should bid, and in particular, why not just use something like a second price auction?
Yeah. So this is the question I want to understand in this first part of the talk. And I hope this feels like a reasonably fundamental question, right? A popular blockchain protocol. Some stuff gets in, some stuff gets out. You have to make those decisions. You have to figure out pricing should seem like a basic problem, I hope.
Uh, at the time I did this work, which was mostly in 2020, it was also a very timely question specifically for the Ethereum blockchain protocol, which then and now is the second biggest blockchain after after Bitcoin, uh, in 2020, the Ethereum community, um, was assessing a potential switch of its transaction fee mechanism from the first price auction. I just showed you to a very different one, which I'll show you in a couple slides called EIP 1559.
And it made many big changes. Some people in the Ethereum community thought it was a really cool idea. Some people hated it. Some people just a lot of people just didn't understand it. So we're sort of scared of it. And the Ethereum community prides itself on just kind of having a strong sort of social consensus to sort of in the spirit of open source software.
So whenever they have kind of a polarising issue, like should they switch the transaction fee mechanism or not, they try to come to some kind of rough consensus among the stakeholders. So this was a community outreach survey. So Tim Baker is sort of a major figure in the Ethereum community. Uh, and this was again in 2020. And so he sent out this survey to various stakeholders. Right. So, uh, sent it to various miners. This was back in the proof of work days of Ethereum.
Send it to people who run exchanges, send it to people who build wallets, software. Right. Which sort of prepare bids with transactions and asked all of these stakeholders, you know, how do you feel about maybe switching the transaction fee mechanism over to in 1559? And if you're nervous or unhappy about it, what can we as a community do to make you feel more comfortable with that switch?
Okay. And many things were mentioned on the survey, but what I want to highlight here was the issue of a lack of a formal specification or proof for the mechanism that people can independently evaluate and critique. Now, mind you, like none of the respondents, not not a single responding to the survey is someone who writes research papers, right? These are all people building stuff in the Ethereum trenches.
But there is a very obvious hunger from this group for the kind of work that my community does in algorithmic game theory, or that you can't community the rigorous assessment of the incentive properties of, uh, of an auction of a mechanism. So that, no doubt, was sort of a major motivator for me to spend several months of my life in 2020, uh, doing this work. Okay. All right. So what I want to talk about next is like, why is this even a hard problem? Right?
Like, why can't you just, you know, look at a textbook, my textbook or some other mechanisms on textbook and copy paste some cool mechanism like the Vickrey auction or the VCG mechanism? If you know about that, why can't you just copy paste that into a blockchain protocol and call it a day and you're like, you're done. You get this nice truthful mechanism. And the reason and this will be a theme through all of these sort of three parts of the talk.
Is that a problem that feels like a, well, sell problem actually needs to be revisited from first principles because of the idiosyncratic constraints imposed on you by the permissionless nature of blockchain systems.
Okay, we're going to see that here. I'm going to see it again in the other two parts of the talk. So in this on this slide, I want to walk through what are some of those weird challenges that don't come up in traditional mechanism design applications, which is going to motivate a couple of new types of incentive constraints that we're going to want a mechanism to satisfy. Okay, so I started with something I'm calling challenge zero because this challenge has it's,
you know, it's non-trivial but has nothing to do with blockchains per se. It's just always about mechanism design and mechanism design. What are you doing? You're eliciting preferences from the participants so that you can make a good decision in some sense. And whenever you deploy a mechanism, you are always worried about the participants misrepresenting their preferences in order to for the mechanism to compute an outcome which is better for them.
Okay, already, like in a first place auction under bidding is in some sense misrepresenting your preferences. So there's standard language and mechanism designed to say that you want a mechanism which is not gambol in the sense you might call it truthful, or also sometimes called a technically that's dominant strategy, incentive compatible. But don't worry about it. That just means like a second price option. You may as well just report your true value. Okay, so that's challenge zero.
That's exactly what a first price option does not have. Okay. So we would like a mechanism which does have this property. But. What else? Something that's much different. The traditional mechanism design allocations is if you think about who it is, who's carrying out the mechanism. Right. If you're selling kind of like wireless licenses, you know, it's kind of like the national government, government that's sort of running the mechanism.
And you genuinely kind of trust that they're going to run the mechanism that they promised they were going to run, more or less. Now, in the blockchain protocol, in the blockchain context, I mentioned that a block is assembled by one actor chosen at random using a lottery. Okay. And they can choose whatever 200 transactions they want. They can include anybody they want. They can exclude anybody they want. They can even actually inject their own shill transactions if they want.
Okay. So you can, you know, as the mechanism designer, write down on your pad like, uh, this mechanism would have like really great properties. Right. But again, the block producer can throw it out if it's not in their own best interests. So you need to have a transaction fee mechanism, which is in the interest of the block producer to run it as you intend. It should be profit maximising for that block producer.
So that's going to lead to our it's going to be part of our second type of incentive compatibility constraint. The other part of it I see is what I said about shill bids. The fact that the block producer can just inject whatever it wants. And if you think about it, that then tells you why we cannot copy paste a second price option into this problem.
Right. So if you're allegedly running a second price auction and you get to put in your own bid after you see everybody else's, write the high bids, $10, you're going to have a show bid of $9.99. Okay. So really, the second price auction really devolves into a first price auction. Anyways, when in this block, producer has this power to insert shill bids after the fact. So that'll be the other part of MC. We want there to be no incentive to insert shill bids of this form.
Finally, uh, in a blockchain context, if possible, you would like to worry about collusion a little bit more than you normally do in traditional mechanism design applications. In traditional applications, you kind of like, you know, make all of the participants kind of sign a legal contract promising that they won't collude. And if you catch people colluding, you kind of like hand them off to the to the rule of law in effect.
And it's not that that's impossible in a blockchain context, but it's really harder. So if you can design a mechanism where the mechanism design itself already discourages any kind of collusion, for example, between the users and the block producer, that's a property you would like to have. And that's going to be our final set of incentive compatibility constraints, which are going to be called OCA proof. This OCA here stands for off chain agreements.
The question then is going to be, is there a transaction fee mechanism that has all of these properties against the incumbents? The first place auction. It turns out it does satisfy both of these two types of constraints, not unrelated to why it's been so successful so far in a blockchain context, and it very much does not satisfy truthfulness. Again, in a first price auction, you always want to shade below your maximum willingness to pay.
So the question is, can we actually get all three of these at the same time? Sure. So in the next couple of slides, I have formal definitions of the two new and available constraints. Again. So remember that's the same as truthful. So there should just be no incentive for users to misrepresent their preferences. There's two novel ones. I'm not going to go through them in detail, given what I've told you in English.
These are the math definitions that any of you would write down anyways. So I'm not going to go through them carefully. I just want to point out that each of these two new types of incentive compatibility constraints kills off one of the mechanism design formats you'd be tempted to copy paste from a textbook. MSI we already talked about. This is what kills off the second price auction, because those kinds of auctions are easy to manipulate using show bids. What about okay proof? This is the one.
So remember MSI says it should be profit maximising for the block producer to run the mechanism that you want them to OCA proof. And that says a cartel of users in the block producer should not be able to do better off by sort of in a, in a coordinated way, deviating from what they're supposed to be doing. And so there what this kills off is the use of a reserve price, at least of the use of a reserve price.
And the most obvious way to see what I mean. Suppose you tried to have a transaction fee mechanism where you forced a price floor at ten sort of £10. You said to get a transfer, to be eligible for inclusion, you have to pay £10 for your transaction. Right. But now imagine, like it turns out there's a bunch of people that want to be included, but it's only worth £7 to all of them.
Okay, so if everybody did what they're supposed to be doing, there would be an empty block because no one bid high enough to get it. But now, if you think about it, there's a real incentive to cut sort of a deal on the side. Right. The block producer could just say, hey, everybody, make sure you bid £10 on chain so you're eligible for inclusion and I'll refund you. Let's call it three and a half pounds off Shane, and we'll all be better off than we would have been otherwise.
Okay, so reserve prices are the casualty of this. Uh, okay. Previous, uh, condition. Okay. All right. So those are three types in compatibility robustness to manipulation by users, by block producers and by coalitions of users and block producers. So we can assess any transaction fee mechanism. Now according to these dimensions. Let me tell you about the challenger for Ethereum. Yep. 5059. And let's assess it according to those three dimensions IP.
If you're wondering that stands for Ethereum Improvement Proposal. This is the way by which changes to the Ethereum protocol get vetted and discussed in that community. So what does this new transaction fee mechanism? Three pretty big changes. And it's important that they all happen together. Again this is one of the things that kind of freaked people out because it seemed like a lot of moving parts. First of all, I'm going to sound crazy. There's going to be a reserve price.
Okay. This is going to be called, in this context, a base fee. But wait, I said, okay. Prudence kills off any possible use of reserve price. All right. It kills off the obvious way of using a reserve price, in which the revenue raised by the reserve price is passed on to the block producer. As you would sort of expect it to. Okay. It turns out if you redirect revenue generated by a reserve price anywhere else, actually, you can get that property.
Okay. And in 50, 59, they're going to do the simplest way of directing it somewhere else, which is literally money that's used to pay the reserve price fee is simply burned, if you like. It's literally just removed from the circulating supply of the native cryptocurrency removed from the supply. Okay. So a reserve price or base fee with all revenues from it being burned. Now. Next question is how do you know what the reserve price should be? Should it be a dollar?
Should be $10 should be $100. How would you know? Ideally you would like a market clearing price where supply hits demand. You'd like the price at which the number of transactions willing to pay. That price is exactly 200. Goes up the block completely. And moreover, it's the most valuable transactions that you're including. You don't know. You know your supply. You don't know the demand. So you don't have the market clearing price.
So it's just going to do local search trying to find it. Okay. The current reserve price looks too high. It's going to do a local adjustment, make it a little bit lower and vice versa. Okay. How do you know whether the current reserve price looks too high or too low? Well, rather than having a hard cap of 200 transactions per per block, like I said before. So, uh, let's be a little more flexible. Let's make that a soft capacity rather than a hard capacity.
We'll let you go up to say like 400 transactions if you really need to, but the target is still 200 transactions in a block. And so now the target guides the local search. If a block is produced with 300 transactions, it seems like your price is too low. So you better raise it. If the last block has only 100 transactions, it seems like you're making things too expensive, so you lower your price. Uh, for the auction. That happens 12 seconds later.
Okay, so you have a reserve price adjusted through local search, using past block sizes as the unchanged signal for which way to adjust. Okay. Finally, you're going to have a built in sort of emergency first price auction. So users have the option if they want to pay above and beyond the reserve price, above and beyond the base fee, uh, in which case that extra amount is passed on to the block producer like bids were in a first price auction.
Okay. And as we'll see, this is kind of in there to gracefully degrade into a first price auction. If the reserve price happens to be very, very different than what you'd like it to be, the market clearing price. Okay. So this is the EIP 5059. This is the quite a bit more sophisticated one they were considering switching to back in back in 2020. And the question I want to ask is is this better than a first price auction.
And again I've set up the rules by which we mean better. I mean does it satisfy more of those incentive compatibility constraints? Disick MC and okay, let's review the incumbent first price auction. As we said, definitely not truthful. You always want to shade your bid. Easy to check. It satisfies the other two constraints. Okay.
And one thing that's kind of annoying, actually, in a way, about the first price auction, it's like there's a million different applications, a million different problems having nothing to do with blockchains, where that would be a totally reasonable mechanism to use. Right? It sort of is totally insensitive to the fact that you're working in this sort of blockchain environment where it's thinking about like IP 5059,
right? You're doing this stuff you would never do otherwise. You'd never think of this mechanism just like randomly, right? Like, first of all, you're using the fact that there's an auction every 12 seconds and the auction outcome is public. So you could just have this very natural local search procedure that takes what happens 12 seconds ago to inform the current base of it.
All right. So that's using the repeated nature of these auctions. And then there's also that burning of the base fee revenues, which would be very hard to do in a credible way in sort of a traditional mechanism design application.
And in exchange, as a reward for taking advantage of these unique kind of, you know, the enlarged design space you have in the blockchain setting, you do get a Parado improvement in the incentive compatibility compared to the incumbent compared to the first price auction. It's a little less trivial, but it is in fact still mesi and OCA proof. It's not the case that it's always truthful, but it is the case that it's usually truthful. What do I mean by that? Well, if the reserve price is zero.
Then it's exactly the same as the first price auction, if you think about it. Okay, so the first price auction isn't truthful. Neither is this mechanism when the reserve price is zero. Assuming there's more than 400 transactions that are willing to get in for free. Okay. In general, if the reserve price is way too low, you revert back to this first price auction. But you can show that is the only event in which you will not be a truthful mechanism, as long as the base fee is semi calibrated.
Right. If it's at least kind of high enough that there's at most 400 transactions, a double full block willing to pay that reserve price, then in fact, it's a truthful mechanism. Everybody sort of pays the reserve price. Everybody's happy. Okay. So in most cases it is in fact, uh, it is in fact, Disick. I proposed a variant of this mechanism where the usually moved from the D6 to the OCA. Proof. So always in my c always Disick usually oca proof with the exact same edge case.
Uh, so that's fine. Of course you want the best of all worlds. You'd like to have. Always all three of these. Uh, but it turns out. Let's skip that back. Um, there's a very recent result. This is, um, joint with Elaine. She, uh, of Carnegie Mellon and her PhD student, Hao Chung. In fact, you cannot get all three all the time, so you need to make some kind of compromise.
So both the IP 1559 and the variant that I suggested in some sense live on the Parado frontier of incentive compatibility of transaction fee mechanisms. Okay. So to tie this back to kind of the Ethereum story. Um. The epiphany 59 was indeed adopted in early August of 2021, and it's been running happily ever since for the past two and a half years. Uh, I released my initial report. It's like a 58 page report, kind of for the general public on December 1st.
Immediately, the people from the community we've been talking about, you know, they sort of realised it immediately. Vitalik Buterin Oh, I forgot to say that. Yep. 5059 the designer of that mechanism is Vitalik Buterin, who's also the, uh, co-founder of Ethereum.
Uh, so he and Tim Baker both sort of immediately commented on it as the day to the switchover in early August 21st approached, my report was kind of the standard reference people use to explain to a public audience, you know, what you should expect to be solved and what would not be solved by, uh, switching over to this, um, transaction fee mechanism.
So now it's just been running happily ever since. There's even sort of dashboards which sort of track the amount of East it's been burned to date, kind of because of the base fee revenues and, and so on and so forth. So it's definitely kind of a, uh, um, it's a it's a critical part of today's Ethereum blockchain protocol. So that was the segment where I wanted to zoom in on this notion of the open access property. Right, and how to make this computer in the sky economically sustainable.
Next, I want to sort of drill down on like, what do I actually mean when I say that has no owner, has no operator? Like what does that mean literally? And what it means literally is that actually it's not a single computer, but it's lots, maybe thousands of computers scattered all over the globe that, through cooperation, are simulating the state of a virtual machine. So this computer in the sky isn't physical. It lives in the simulation of thousands of physical nodes down on Earth.
Those nodes need to stay in sync about the current state of that virtual machine. And they do that by running what's called a consensus protocol. So this is going to be joint work with Andy Lewis Pi, who's just down the road London School of Economics I just had lunch with him yesterday. Um, and sort of all my papers these days, when I release them, I usually have sort of a corresponding, uh, tweet storm. And I know that's like kind of a gimmick.
On the other hand, it seems like it's been, like, super helpful for people like you haven't talked to academics and they'll say, yeah, you know, I went to this conference, you know, the formal talks were like, not that helpful. But like the quarter conversations were like, great. I went just for the quarter conversations. And these are the quarter conversations just made available to everybody, which sort of seems like a positive thing.
I think this is the longest research paper I've ever co-authored, 75 pages. I know some of you have written longer ones, but for me, this is my record. Um, so this is the only time I've ever had to do a recursive tweet storm, a tweet storm, a tweet storms. So still, I think a lot faster to read than the full 75 page paper. Obviously, I'll only be able to tell you a little bit about sort of the results in here in the time that I have.
Okay. So just like in the mechanism design section, it's not the traditional mechanism wasn't useful. It was we built on it, but we needed to extend it because of these sort of permissionless nature of blockchain environment. Exact same thing will happen here. Design and analysis of consensus protocols. Classic topic okay, brilliant work in the 1980s Turing Awards given to Barbara Liskov, Leslie Lamport and we will be building on that theory.
But again, because of the permissionless nature of blockchain protocols, that theory has to be significantly extended. Okay. So I want to tell you about that next. Be so again since census protocol, keep a whole bunch of nodes in sync with each other on the state of a virtual machine. The minimal properties you would want of any consensus protocol is liveness and consistency. Liveness, meaning as long as there's work to get done, it should get done.
If there are pending transactions, they should eventually be processed. Consistency means like really the nodes got to stay in sync, but they should not have fundamental disagreements about, for example, what instructions have been executed in this in this virtual machine? Okay. Why is that a hard problem? Two of the traditional challenges are, first of all, some of these nodes running the protocol may not do so correctly.
Who knows why. Maybe they crash. Maybe they have buggy software. You know, maybe they're controlled by a malicious actor. Who knows, they may deviate from what you you expecting them to do? Same thing with the communication network. Okay, so it may be a good day for the internet. It may be a bad day for the internet. It's hard to predict exactly how long messages will be delayed before received by the intended recipient.
Okay. And in my opinion, one of the reasons why the traditional, um, theory of consensus protocols has been so successful, there's this really rich, deep literature over the last 40 years or so. I really give a lot of credit to the pioneers in the 1980s for setting things up as kind of like a playground for theorists who just have a lot of fun with and with clear measures of progress.
Okay. In particular, if you take these two types of challenges, nodes that are not doing the right thing, the network not being as good as you'd like. They took each of those challenges and they parameterised them using hierarchies. So in effect, they almost like gave you ladders where like better papers just meant sort of climbing further up these ladders. Okay, let's take the faults. Okay. Nodes that deviate from what you want them to do.
You've got very benign types of faults. Like maybe there's just like a hardware failure. It crashes. You never hear from it again. Okay, that's relatively benign. At the other extreme, you know, maybe like a hostile nation state has taken over one of your nodes and is actually just doing everything they can to mess up your protocol be a Byzantine fault. Same thing with the communication network. You've got very easy models, like the synchronous model, where you can assume that guaranteed,
every message will be received within, you know, whatever. One second, five seconds, you've got the intermediate model, the partially synchronous model where synchrony may be interrupted with periodic, periodic but finite length denial of service attacks. And then you've got the sort of, you know, challenge level of the asynchronous model, where the only thing you assume about message delivery is that eventually that happens.
Okay. So obviously positive results get more and more impressive, sort of the weaker the assumptions and vice versa for for protocols for positive results. Now, when you pass to permissionless consensus protocols as familiar from Bitcoin and Ethereum, there's more challenges than just the network and faulty nodes. Okay. So one challenge is you don't know who's running your protocol. Okay, so any of us today could go download some software spin up and start contributing to the Bitcoin protocol.
Literally today it's been running for 15 years. Doesn't matter. It doesn't care. You could join the party right now. That's not a property historically consensus protocols have ever wanted to have. Secondly, you've got what's known as the Sybil problem. Given that anyone can sort of join the party and start running the protocol, anyone can also join multiple times under multiple identifiers, and you'd never know the difference. So one participant can masquerade as many.
So, for example, if you're trying to do something like voting, that gets a lot more complicated with symbols. If you've ever heard about like proof of work or proof of stake. Those are techniques to control the Sybil problem. What I want to talk about today is this third additional challenge of getting the permission of the setting, which is that there may be nodes which will not faulty. There's nothing wrong with them. They're periodically inactive. Okay.
So someone, you know, running a node to contribute to the Bitcoin protocol. Maybe they turn it off when they go out of town for the weekend. They come back Monday morning, turn it on again. And even though the amount of fluctuation, even though sorry, the amount of participation and who's running the protocol fluctuates. You would like the protocol to just, uh, hum along, uh, you know, come along perfectly.
Okay. And in the same way that in the 1980s, the challenges of false and unreliable communication were parameterised through hierarchies. In this work, we do exactly the same thing with inactivity. So we have a hierarchy of degrees of sort of stronger and stronger assumptions. We allow protocols to make about the activity of honest participants. So I'll show you the hierarchy on this slide. There's going to be four levels.
Uh, the top level is going to be the one where you make the weakest assumptions. So that's gonna be the hardest one to design protocols in. And then the assumptions and protocols allowed to make is going to get stronger as we go down the slide. So you you sort of have a back. So you expect to see lots of impossibility results up here. Hopefully you expect to see lots of positive results like protocols that have good properties down here.
Okay. So first level we call the fully permissionless or PHP model. And here literally the protocol is not allowed to assume anything at all about who is running it right now. No idea. Okay. And if you ask, I think people in the 20th century working on consensus protocols, whether any nontrivial functionality would be possible under that assumption. My guess is everyone would have said, no way, that's crazytown. Okay.
Turns out Bitcoin protocol under reasonable assumptions actually is provably consistent in live. Knowing literally nothing about who's running it at any given moment in time. Just still to this day, I find kind of incredible. All right, so that's the most demanding, fewest assumptions setting. You know nothing about who's running a protocol. Slightly stronger assumption is what we're going to call the Da or dynamically available setting.
Okay. And so here there will be this list of identifiers known to our protocol. Okay. And those of you that know a little bit about this area canonically this would be, you know, people who have locked up in escrow some stake in a staking contract of a proof of stake blockchain protocol. That would be this list of identifiers. So you're the protocol is allowed to assume that whoever is running the protocol has an identifier in this known list.
Okay. So you're not going to have like a block proposal from someone you've never heard of, for example. But you could in Bitcoin. On the other hand, you know, maybe people on that list have gone away for the weekends. Okay. So it's a necessary condition but not a sufficient condition for participation. Uh, that your identifier is in that list. Third level is the quasi permissionless or QP setting.
So we again have this list of identifiers. But now membership in that list is both necessary and sufficient for participation. So in other words, when you're designing a protocol, you are allowed to assume that all of the identifiers you know about controlled by honest players actually are doing what they're supposed to be doing right now. You can count on that. They are not away for the weekend. Okay.
And then finally we have the classical permission model, where at the time of protocol deployment, you know exactly who all of the nodes are. They're going to say stay the same all the time, and nobody ever turns the machines off. Okay. And if you want to map these onto protocols you might have heard about, as we said, Bitcoin operates even in the PHP setting dynamically available. This is in hindsight we can take proof of stake longest chain protocols like say Cardano.
And in hindsight, they're kind of built to work properly, even in a dynamically available setting. Um, if you've heard of like the Pbft protocol or things based on them, like say, Algorand, again, in hindsight, we can say and also actually today's Ethereum, in hindsight, they're meant to work in the quasi permissionless setting. Okay. Now in our paper, we show that all. We show that this hierarchy is strict. Okay, so we have separations every level of this hierarchy.
We show that there are things that are possible which are provably impossible at the level above. Okay. And from our results, it would appear that the really again there's a separation everywhere. But the really big separation the chasm would appear to be between D and QP. So I just want to add a little bit, add a little bit of colour about that chasm in the middle of the hierarchy.
Okay. So again lots of stuff which you'd like to do, which you can do in the q p setting, which is impossible in the day setting. Okay. So two slides, one about the negative results in the Da setting, one about the positive results in the q p setting. All right. So dynamically available setting. So again remember what this means. So if you want to think about a proof of stake protocol. But here's the protocol knows this list of identifiers.
Membership in the list is necessary but not sufficient for participation. So there's still going to be like wildly fluctuating participation. Some people might have gone away for the weekend. Uh, let me say three things you would like a protocol to have that you cannot have in the dynamically available setting. You cannot have them, no matter how clever you are with your protocol. Okay. All right. So property number one okay asynchronous safety.
So this means if you have a network partition or there's sort of a long denial of service attack, you would like to obviously not have a consistency violation. But if you actually remain live in the dynamically available setting, you cannot also remain consistent in the presence of network partitions.
If you have like a really specific protocol in mind, like, you know, Bitcoin or longest chain protocol, you can probably kind of see in your head why you're going to lose consistency with the network partition. That's not the point here, right? There's no concrete protocol on the slot. Right. The point here is to show that fundamentally, any protocol, no matter what it looks like, if it's live in the dynamically available setting, you must suffer consistency violations under network partitions.
That's the context of this first result. Okay. Second property you'd like to have something called accountability. Okay. Which is should you suffer from a consistency violation should nodes get out of sync. You would like to know why. You would like to know which nodes deviated from intended behaviour that led to that consistency violation. That's called accountability. You get a smoking gun for who's responsible. That is also impossible in the day setting. Finally optimistic responsiveness.
This is like an instance optimal version of liveness. So this just says like if the network's having a particularly good day to day, like it's five times faster than usual. Your protocol should also, uh, react five times faster than usual. So transactions should be confirmed faster as the network gets faster. Also provably impossible in the day setting. Turns out all of this is true even if there are no, uh, faulty nodes.
Okay? Merely the possibility of fluctuating participation triggers all of these impossibility results. Positive results on the QPR setting. So again, here a protocol can assume quite a bit more. It can assume that not only is there this list of identifiers, but membership in that list is sufficient for active participation. So any identifier you see in there, which is controlled by an honest player, you can count on them being online doing what they're supposed to be doing.
Okay. Like those of you who do know a little bit about Ethereum may know that there's sort of slashing. You can actually lose funds for inactivity. Okay, so if you're running an Ethereum validator, you're supposed to be like voting on stuff all the time. If you missed your turn for a while, you'll actually start losing some of the stake that you've pledged. There's economic penalties for being inactive, and that to be kind of like a, uh, sort of a light bulb going off.
Uh, I guess Ethereum is really motivated to be in the quasi permissionless setting. They really need all the people they know about to be active. That's exactly what you're punished when you're inactive in Ethereum. All right. So you obviously need some control over how powerful the adversary is. And so here the magic threshold is going to be a third. So you need less than a third of the voting power to be controlled by an adversary.
Uh, but in that setting you actually get all three of those properties. Okay. So you can guarantee that you have consistency. So there's a single protocol that achieves all three of these guarantees. Asynchronous safety doesn't matter what the network does. You will never have a consistency violation if there's a consistency violation because the adversary is bigger than the one third threshold, there's a smoking gun and you can figure out who they are, possibly for punishment later.
And then finally, it does automatically speed up the speed of transaction confirmation as the network speeds up as well. Okay, so this is what I mean by the chasm between D and CuPy. Again, the separations at all levels of the hierarchy, but the starkest one is the one I've summarised in these two slots. Okay. So, um, obviously there's a lot more results in the paper I'm not gonna have time to talk about, honestly.
I mean, we like the we like the results in those papers, in this paper, but we're really hoping that this becomes sort of the standard model and the standard language for lots of people to prove cool results about permissionless consensus. So we have a new paper also with Eric Buddhist, which is about slashing and proof of stake protocols.
It's a paper that like, feels like should have been written a long time ago, and I think the only reason it's being written now is because the previous paper I just told you about gives us the language and the framework to make it to state theorems of this form. Okay. When does slashing work in a proof of stake protocol? So hopefully much more. I'd love to see maybe some people in this room. Uh, follow on on this. The style of work. All right.
So for the last part. I said at the beginning, right. The one thing I wanted you to remember from this talk is that the technology is not fundamentally about cryptocurrency, about prices, about finance. That said, at the application layer, there are some really intellectually interesting things happening with financial applications. I want to tell you about some of my work there. Last. This is going to be joint, uh, with Jason Jonas, who's my PhD student at Columbia Cmac.
And well, let me who who's my colleague in the business school, Columbia, Anthony Lisanne, who's a professor of finance at University of Chicago. Booth. All right. So. Right. We talked about property rights for sort of digital assets. Once you have ownership, right. Another property right is the right to transfer. Okay. If you have transferable digital assets, you have that you have you have the possibility of exchange of markets.
Okay. Very simply maybe you want to exchange some cryptocurrency like say eath for some stablecoin, something pegged to the dollar like Usdc. And, um, we need a mechanism. We would like a mechanism to enable exchange of different digital assets. And once again, why is this a hard problem? Right? Doesn't this happen like, every single day? Like on every single stock exchange? Yes it does. The usual mechanism you would use in that context would be a limit order book.
So you would have standing by standing sales, you'd have sort of matching logic to sort of unclear trades as they come in. Uh, and again, it's just it's not a perfect match for the blockchain environment. Okay. For two reasons. Um, reason number one, at least for Ethereum, at least for the older blockchain protocols, uh, implementing a limit order book is computationally relatively expensive.
Okay. You have to maintain this. You have to maintain the order book. You have to do the matching, uh, more modern blockchain protocols. You know, probably they have enough computational power to do this. Well, but Ethereum does not. So that motivated looking at some different designs. Uh, secondly, to secondly, limit order books, whether you're in a blockchain environment or otherwise work really well in thick markets.
We have lots of people on both sides of the market's interested in trading right to trade. In a limit order book you need a counterparty. You want to buy it. You need someone to sell okay. And ETH, Usdc. I mean that's actually a very thick market. But a lot of the digital assets that people want to exchange are thin markets. And the worry would be that there's just usually not a counterparty to trade.
Okay. So both of these two issues have motivated, uh, the popularity of automated market makers or amms, on blockchain protocols such as Ethereum. Okay. So what's an Am? It's a market that in some sense is always open for business. At any given moment in time, an arm will quote you a spot price, and we'll be willing to take either side of a trade at that spot price. Right? So like, you know, $3,000 for eath that'll be willing to buy it at the margin for that or sell it at the margin at that.
Either way. Okay. And, um. Uh. Good. So the next question you might say is, okay, that's fine. So I guess the market maker, like the Am, is itself acting as the counterparty. So I guess, you know, there's always a counterparty there that's always open for business. But then you might be like, like, why does this arm even have any of these assets in the first place? Like where did it get its eath from? Where did it get this Usdc from?
And the answer is that those are provided via deposits by entities that are here called liquidity providers or LPs. Okay. So so these are people who hand over their hard earned cryptocurrencies two and a m so the traders can trade with them. Why would you do that. What's because you earn a share of the trading fees by depositing in this way. So it's a way to earn yield on your assets by depositing them in one of these. And that's.
All right. Well, if I put it that way, like, why would you not do that? Right? If you just get sort of free money, like, on your assets by putting them in the pool? Sounds like a good idea. Why would you not do that? And the, you know, so the the issue with market making and again this is not specific to the blockchain protocols, but the reason market making is scary is because of adverse selection.
Okay. Whenever someone's willing to trade with you like there should be this like fear in the back of your mind that like, maybe you know something that I don't like. Maybe there's a reason they're trading. Okay. And actually, if you think about it for for purely on chain exchanges. Right. Like a Uniswap that's a, that's a popular name of a one of these automated market makers like Uniswap on Ethereum.
Uh, that's going to be happening a lot because remember what I said? I said there's a new batch of transactions every 12 seconds. So Ethereum's virtual machine stays frozen for 12 seconds at a time. And in particular, the spot price of an arm, which is a function just of the state of the virtual machine, stays frozen for 12 seconds. A lot can happen on the open markets and 12 seconds, right?
And so generally, often there is an arbitrage opportunity with each Ethereum block that gets that gets added. So for example, if on the open market so that the price went up, all of a sudden there's an arbitrage opportunity where you buy from the AMM at the stale low price and then flip it on a centralised exchange at the current higher open market price. Okay. So that profitable arbitrage comes at the expense of the liquidity providers are playing a zero sum game in effect.
All right. So that is the cost of providing liquidity to an adverse selection costs. Uh which goes to arbitrage right. So, um, if you're thinking about possibly helping or assessing, you know, uh, I mean, in general making markets, these are the two things you're sort of weighing with each other, the fees you're making and the average selection costs you're suffering fees pretty easy to think about.
They're generally just sort of a percentage of volume, because you can sort of know how to think about how much revenue you might be making. It was the adverse selection costs where people didn't really have a good mental model for how to think about that in an EMS,
let's say, in 2022, when we did this, when we did this work. And so what we propose here is we propose what is now the industry standard for thinking about the adverse selection costs suffered by liquidity providers of EMS, something known as loss versus rebalancing, or LVR, which most people pronounce as lever. Okay, so let me just tell you a little about lever. There's two versions. First, I'll tell you one, which is really for empirical analysis. This is really meant to do sort of forensics.
You look back at trades that happened and you ask yourself, did I do well or did I not do well? The second version of lever is going to be for predicting the future and assessing, you know, do you think it's going to be profitable to be a deposit in a, to be an LP and an arm or not? So the first one, were you looking at the past? You just consider a sequence of trades. You say and trades. You focus on a single pool like eath for Usdc.
Uh, and you just the definition is you just sort of do the thought experiment and you say, how much better off would I have been had I made the exact same trades that the Am forced me to do as a, as liquidity provider? Had I done those exact same trades but done them on the open market instead? Okay, so the ideas here are the quantities, right? So this is how much sort of aether the AMA forced you to buy or force you to sell, because a trader came in and took the opposite side.
The piece here is the price on the open market and the Q's. Here are the possibly stale prices of the arm. You were forced to do the trade at this price. This would have been the price in the open market. So for example, right, if you were forced to sell by your amp and the you were forced to sell at a price which was less than what it was on the open market, that would be a loss and that would contribute to your lever. Okay.
So trade by trade, your lever accumulates according to the counterfactual of how much better off you would have been on the open market. Okay, so that's obviously very easy to take the data. It's about as hard as like computing the volatility of an asset, something like that. I think there's already kind of first year MBAs in certain schools that have Excel spreadsheets that are computing this on various data sets. Um, you can characterise it, you know, so why is this a good definition?
Well, one sanity check that you're on the right track is if you can characterise it in multiple different ways and you can here I've given you sort of interpretation, number one, which is this kind of thought experiment about trading on the open market. You can alternatively characterise it as the best sort of the maximum arbitrage profits that could have been attained from this profit of trades. Again, remember zero sum game between the LPs and the arbitrage years.
So that's kind of a you're seeing that reflected here. Um, alternatively you know, if you prefer you can think of it as kind of the residual losses after you've Delta hedged out all of the market risk that you suffer by sort of leaping in one of these pools. So three different ways to think about lever, which I take as a sign that, you know, maybe it is the right concept or a fundamental concept.
So let me just talk briefly about sort of predicting the future. So, you know, the lever is going to depend on the prices, right. We had a times P minus Q. Right. So obviously the way the PS move around is going to matter for what the lever is going to be going forward. If the price never moves, never any arbitrage there's going to be zero. The price moves a lot. You might think there's going to be lots of arbitrage and the lever is going to be high okay.
So we need some model for future price movements. You could experiment with a lot of different things here. This is the first paper on the topics. We decided to start with. Just the obvious Black-Scholes model. Price moving according to geometric Brownian motion. Uh, if you don't know that model, that's okay.
Just think of it as like a random walk in a way. Uh, and there's one really important parameter which is the volatility sigma, which you can think of is kind of like the typical step size in a random walk in the price. Okay. And so definitely as we discussed the lever will depend on the volatility. If sigma is zero and the price never moves it's going to be no lever. If sigma is high and is moving all over the place probably lots of opportunities.
It's also going to depend on the arm okay. Because remember the formula we had a times quantity p minus q q is a function of which arm you're using. Okay. So different arm designs will give you different spot prices different cookies even for the same sequence of trades. So at a bare minimum we want a formula. It's going to have to depend on sigma and arm. We would like it to depend as minimally as possible in as interpretable way as possible.
So here's the main result here. And I don't know if this seems like a clean formula to you or not. Probably depends on kind of your prior, but let me just unpack this a little bit. Okay, so now we're thinking continuous time right. So the price is moving all the time. So there's ARBs happening all the time. Lever accumulates trade by trade. So we have an end. That's why we have an integral.
Now trading is happening all the time at a given moment in time the instantaneous accumulation of lever is given by this formula okay. As expected the volatility is in there. Expect volatility squared which is actually pretty severe. So that's that's uh it's actually pretty high. And then the choice of the AMM does show up, but only in a very kind of local way to this DX by DP term.
So what this says is this is how much at equilibrium is the um, inventory of the risky asset of the AMM, the rate at which that changes as the open market price changes. Okay. So the marginal liquidity of the AMM at the current market price, that's what this is. All right. And if I had a little bit more time, I could literally just have a slide with a single triangle. And this would be like the area of that triangle. Okay.
So I actually claim if you dig into this a little bit more, it's kind of about the simplest expression you could hope for, I think in hindsight, okay. In fact, it's so simple that you can even sort of evaluate and closed form what this is for some of the most popular AMS. So there's this so-called x y equals k curve made popular by Uniswap v1 and v2. Uh, and here you can actually just compute how leaver accumulates.
And in fact, it doesn't even depend on where you are in the price range. It's uniform over the prices. If you normalise by the value of the pool, you get that the lever accumulates exactly as sigma squared over eight. Okay. And this is a sharp enough prediction. Right. You can really sort of plug in numbers here. Right. So if you take sigma equal to say 5% which would be kind of typical daily volatility for eath.
Uh, and if you assume you're making 0.3% fees, which again in this part of the world is sort of pretty standard, then what you learn is that for LP to be profitable, about 10.5% of the pools assets should be traded on a daily basis. If the volume is higher than that, you're going to be profitable. If the volume is lower than that, you're going to be unprofitable. Okay. So you can really evaluate this quite crisply, quite precisely okay.
And, uh, so we released this paper and started giving talks about it in August of 2022. And literally by the end of 2022, this was kind of industry standard for how people were sort of thinking about these adverse selection costs. So this was a few weeks later, just a couple of sort of leaders in decentralised finance sort of saying that they thought this was the right condition. And it's a condition that future design designers should take seriously.
Lots of times this is in sort of popular podcast and so on. Maybe what I'm most proud of is, uh, last year, 2023, we were voted the number one meme of the year in DeFi. So. I'm kind of trying to figure out how, like, how do I list this on my CV exactly? I feel like there should be some way to do it, but I haven't figured it out.
So, um, so anyway, like I said, just really within 4 or 5 months, you know, lever was just like a really well known concept and continues to be, uh, sort of a central concept in DeFi, which has been fantastic. Uh, pretty much out of time. Let me just sort of reflect for sort of one minute, because I've been working full time in this area, maybe for, I don't know, three more than three years now. Um, and I've worked in sort of immature areas before.
Right? So many of us in this room, you know, Julius and Lesley and other people are well, we're sort of in algorithmic game theory in the very early days, uh, which also have kind of a Wild West flavour at the beginning. But I'm being reminded of that Wild West feeling now. And in particular, it reminds me of everything you take for granted when you work in a mature field. Right? So take like algorithms or I would even put like ML theory in this bucket as well.
Right. Like you've got like relatively low barriers to entry. Like yes they're technical subjects but you've got good textbooks, you've got MOOCs, etc. Moreover, the research community has sort of solved the coordination problem, right? The sort of coordinated on an equilibrium where everybody more or less agrees, like the language to describe basic concepts like what are the most important definitions?
What are the yardsticks against which you measure research progress? Uh, and, you know, you work in sort of, uh, an immature field like blockchains. You get none of these things, right? So it's really there's frustrations. On the other hand, I sort of learn through experience that this is also kind of the universe trying to tell you that there is a chance you might be working in what's viewed in hindsight,
as a golden age. At the time, before everything, quote unquote easy, had already been done. So I like, you know, because, you know, you look at like maximum and cut. You're like, oh, man, I was born too late. I was there in like 1955. I could have I could have moved on and cut. Right. But the thing to remember is like, oh, like computer science is just changing. Like it's always evolving. There's always some current version of the maximum and cut through.
And the hard part is seeing it. The hard part is necessarily proving it. Once you see it, the hard part is seeing it. And so for those of you that are intrigued by this idea of getting in on the ground floor, uh, of a technology that definitely needs rigorous computer science behind it and hopefully will sort of, you know, eventually have a massive impact on lots of people. I would maybe encourage you to check out this area a little bit further.
So I'm out of time. I'll leave up the summary slide here, but, uh, let me stop there. Thanks so much for coming.