Mechanism design for stake weighted QOS with Max Resnick | a16z crypto research talks

Transcript

We're about to start kind of day two of the the workshop and today we're kind of focusing on more kind of alternative L1s that are more kind of high performance and they're kind of exploring some of the mechanism design problems underlying those spaces. So really trying to kind of push the the frontiers of kind of what these blockchains can do and kind of along with that comes lots of problems. Max is going to start by talking about kind of the the bandwidth problems that aren't quite there in Ethereum but just kind of how many transactions are trying to go through with these different blockchains. And then we'll we'll have some more talks and kind of general Solana mechanism design and kind of understanding how fee mechanisms kind of have to change for kind of addressing the high throughput concerns these blockchains have.

So yeah, excited to kick it off and hand it off to Max Resnick, head of research at Special Mechanisms Group. Just a brief primer on SMG. We basically at ConsenSys we work on the problems where uh our products touch the chain most directly. So kind of the last mile problem of getting things on chain uh across all our products and we also do a lot of mechanism design research as the name suggests. This talk is going to be about some recent and in in progress work that's going on which I like to kind of talk about as an implementation detail. The reason I say that is because anytime we talk to somebody on Solana and something is broken, it's always an implementation detail. But the actual

reality is it's always a mechanism design problem that they're kind of like saying is an implementation detail. For example, they didn't implement a priority queue which is obviously a mechanism design problem if you think about it. So this is the story of how Solana broke because of an implementation detail or more accurately a mechanism design problem. And I just wanted to zoom out a little bit more generally because I think the theme of this talk today is going going let's do more prescriptive work because the people in this room are very smart and we know a lot of things that that engineers don't know. And so, right now, kind of the way things work, here's an example with execution tickets. There's somebody like Justin Drake who works on the Ethereum protocol will say, "Hey, let's do execution tickets." And then all the researchers

will say, "Turlock" sorry, that should be Tullock contest, but uh the you know, all the researchers will be like, "Oh, this is like a Tullock contest. We will tell you the equilibrium. Oh, maybe you shouldn't do that because there's multi-block MEV or there's some reserved price issues with execution tickets, etc." So, all the researchers will go out and say, "Given the design that you, Justin Drake, have come to us with, here is our descriptive analysis of what that does. And what I would like to see more of is actually Solana says, "Hey, we're going to do stake weight quality of service because our network broke." And then we say, "Hey, what if you did this other thing, bandwidth markets, instead?" And then the Solana people are like, "Okay, that's probably a better idea than what we came up with, so let's go ahead and build it and

see what happens." And that's I think the general theme of what we should do. And I'll talk a little bit more about where some of these open problems in are at the end of the talk just to kind of throw out some ideas and where there's there's obviously a full employment act for mechanism design here. Many implementation details that need to be worked out across the stack and across all the chains. What happened on Solana basically has to do with this quick uh networking protocol. The thing you need to understand about Solana is there's no mempool. Uh basically transactions go directly from the transaction initiator, the sender, to the leaders. And that means that the bandwidth to the leaders can get congested and

the idea of how to mitigate this was through this quick uh networking protocol. This is an illustration of kind of the predecessor to quick, which is TCP. And the key point here is that before information starts getting passed back and forth in TCP, there's this handshake. So, for example, the client will say to the server, um will send a synchronize message, then the server will say back, "Okay, synchronize acknowledge." And then the the client will say, "Okay, acknowledge." And that initiates the handshake, and now we can start sending packets back and forth.

And if some packets get dropped, the server can say to the client, "Actually, you dropped some packets. Resend those." Um And so, this is a great reliable messaging service um that's kind of part of one of the initial uh frameworks for how message passing works on the internet. Now, the alternative to that is this no handshake model, this kind of datagram model where we don't initiate the handshake, we just kind of request some data, and then the place that we requested the data from just kind of like fires it back at us. So, this is kind of like great if you're playing League of Legends or some game where you're okay with losing some packets, what you really want is a fast response.

But, it's not great if you're worried about um losing messages, or if you're worried about denial of service, etc. What Solana wanted to do, basically, is put in this quick implementation, which is a version, like a kind of a updated version of TCP, which came out in uh 2013 by some folks at Google Research. And it's kind of a parallelized version of the TCP protocol, modernized version. It has some other implementation details which uh I think are interesting to read about, like the handshake itself is actually faster because it uses some cryptography. And so, even in this first in message, you can send some uh

information as well, which is important. We'll we'll probably be important later in this talk. But, the quick implementation has like a bunch of upgrades across the stack, but I think the most important is that it has no head-of-line blocking problem. And that means that, for example, in a TCP implementation, if message one in this diagram didn't come, we would not continue to process information until we had sent a message back to the client and said, "Send one again cuz I didn't receive it." And then we would wait until one gets received, and then we would we would process two.

And that's called head-of-line blocking because, obviously, we can't do anything if one does not arrive. So, quick has these parallel lanes, which, of course, is nice if you're trying to build a really performant chain. What happened and why did Solana break? Um I'm going to be a little bit loose with the details here because, apparently, this is not quite uh all the way fixed yet. But, what happened is, you know, normally the the people who want to send transactions are supposed to initiate the handshake, but some searchers figured out that you could initiate a whole lot of handshakes, and you could kind of take up all of the quick connections on the box.

I'm again being a little hand-wavy with the details because I don't want to get into how to actually do this in case any of you decide to spin up the Solana bot. But, you can basically initiate all these handshakes and take up all the bandwidth, and then only you get to send transactions. And I think this is basically what happened. So, what did Solana do about it? They said, "We need a way to ration the quick connections." Each box has 2,500 quick connections that it's allowed to do. So, each validator is allowed to do that. I think that's probably just an implementation detail.

Um but, that's the number that they're working with. And what they did is they said, "We're going to have 500 of those on the old model. And we're going to put 2,000 on this new stake-weighted quality of service model." And the way that works is I I 2,000 connections, I'm going to allocate them on a pro rata basis according to your stake weight. So, the three biggest validators right now are um Galaxy, Helios, and Coinbase. They each have roughly around 3%, a little more than 3%. So, they're going to get each 3% of those connections if they want them.

And this prevents basically those connections from being spammed by the searcher bot. Just to Just to make sure that I'm following. So, these are connections between the validators and uh Solana the the the the protocol. These are So, the valid See, these are connections between places that have transactions that they want to send to users. Or sorry, they want to send their transactions to the leaders to get sequenced basically. On Solana, there's no mem pool, so they send directly to the leader. The leader is the thing with 2,500 quick connections that it has to ration.

So, if you send more connections to the leaders, you will be able to send more package. Right, you'll be able to send more transactions, you'll be able to kind of guarantee that your transactions get in faster. Eugene is going to talk a lot about like the rest of the pipeline, and it may become And do you need to pay for these connections, like you when you start If I want more connections, I can buy them by paying some ticket some price? Well, that is a change that I will will discuss that we I suggested, but this was with this was the change that is currently implemented, the stake weighted quality of service change um is what's currently implemented. And then we'll talk about the obvious thing which you just suggested, which is also what I suggested, which is to do a just-in-time market. Got it.

If I have less than I guess 0.04% of the stake, do I then not get a connection? Um I'm not sure exactly what the rounding looks like, but I think in most cases, I I would assume that that is basically the way it works. If you maybe you get it some percentage of the time or something. what does it mean? Like I can't be a leader effectively? You can still be a leader. You're going to be selected as a leader according to your stake as well. But this is I can't necessarily send messages to leader over these prioritized 2,000 quick connections.

There's 500 that are available to everyone. Of course, those are the old system, so you can't actually use them, but um the you you actually do need a bunch of stake to be able to even send transactions to the leader. So, what is the end game of this stake-weighted quality of service thing? Here is a little dot that is Margin, which is a protocol on Solana, but also has some other things going on. And they like stake because they have some other things going on. They are going to go on Twitter and say "We are offering more yield than everybody else because we can pay. We we can use the stake better than anyone else." So, their stake is going to start to grow

over time. And it's going to continue to grow because, again, they have some other stuff going on. And eventually, I'm I'm also making Galaxy bigger cuz they're also trading firm. The The reason they're so big right now is because of the FTX estate, basically, but I I I assume that they will continue to become more active in in trading on Solana, as well. Basically, more and more connections are going to be controlled by trading firms. And there's another validator I didn't put on here uh goes by the pseudonym D's Nodes, which is allegedly doing a lot of sandwiching on Solana. I think they've now changed their name. I didn't see them on the registry this morning, but they're around still. They're They're probably doing some sandwiching.

And they're going to get big as well because having more connections uh and more stake i- is valuable for this and for some other things, too. So, I I think I had a argument with Anatoly on Twitter about this. Basically, this is the end game of stake-weighted quality of service. And moreover, it's not even rational for the validator, if bandwidth is constrained, to give it to people based on their stake because they could just give it to the people who pay the most. That's why suggesting this just-in-time bandwidth market and there's a few implementation details that are important. One of them is the fact that this is so far from execution itself.

Basically, this is before messages even get past the leader. And so processing payments is more difficult than say tips. Uh I'm suggesting the usage of a payment channel which would allow uh the handshake messages to come with payments themselves. And then allow some subset at first of those 2,500 connections to be allocated in a just-in-time model based on how much people pay. Exactly as This is obvious I mean it's obvious to all of us that this is what should have happened, but it wasn't obvious at the time and they did the stake-weighted model.

Um so that is kind of the proposal is very simple. I'm not going to prove any theorems about it, but I will tell you that this is much more individually rational for the validator than the stake-weighted quality of service and I think has less centralizing effects in the long run. It's also good because like as your to your question Benedict like there's people who don't have enough stake, who are maybe apps that want to send user transactions through their app, and they can't necessarily do it under stake-weighted quality of service, and so they go to somebody like Helios and they say, "Can we rent your bandwidth?" Well, why not just if if you're going to rent the bandwidth from Helios, why not just rent it directly from the validator itself. So anyway, uh this is kind of

there are some people working on influencing this. Um I think it's a good idea and probably better than stake-weighted quality of service. And the good thing is we can do it because there's 2,500 connections, we can do it only with a subset of the connections at first. So we can even try it out without breaking anything. So I said I was going to talk about some other things that are kind of like this that I think are very low-hanging fruit where everybody in this room would going, "Oh, this is an obvious thing to do." One of them is the blob market, which I heard some people are working on. May I Can I ask a question about that before?

Yeah, go for it. How do you enforce this connection rule? How do you enforce the you enforce? Right now, you're doing it stake-based. How do you enforce it? How does Solana enforce? Well, I mean, as a validator, I'm not actually receiving uh transactions from Leo and Joachim, even though they have no stake. Uh you can enforce it. It's It's not individually rational. Yeah, so the question is So, I'm supposed to repeat for the mic, but the question is, how do you enforce this stake-weighted quality of service? Again, this is The point that I'm making is not individually rational, and I think that's one of the broken parts about it.

Incentive compatible. Huh? Incentive compatible. It's not Oh, sorry. Well, I mean, it's also like All right, sorry. It's not incentive compatible whatever. I think individually rational works here, too, because they should opt out of this mechanism, right? The validator. All right. It's not incentive compatible for the validator as uh This is why we hire game theorists at SMG. How do you enforce that the service is provided once the payment is made in your proposed system? Like, if someone pays five bucks to make the connection, sends a transaction, how do you enforce it? The validator can just take the five bucks and not process any of the messages.

Yeah, I think I I think this is a good point. It's a repeated game. A lot of the validators are I mean, the validators are rotating quite quickly in Solana. Every 1.6 seconds, the validators are rotating. Um you're going to pay a small amount for the bandwidth in the slot that's coming up. And if the validator is not trustworthy, then you're not going to continue to pay for bandwidth from them. Um I think it's impossible to enforce that the validator accepts your messages, but it's kind of What the validator really just wants to do is like have spam prevention and have good transactions coming in. And a good sign of whether there's going to be good valuable transactions coming in is

whether the person is willing to pay a lot for their bandwidth. So, I think in some ways the incentives are aligned for the validator to build the most valuable block. It's a good signal when somebody's willing to pay $10 for the bandwidth connection that they're going to have a lot of good transactions that I want to include. You can also do it with smart contracts, right? That you get the payment in the future if the validator posted this transaction. Yeah, yeah, that's true. But then it depends on the transaction and you're relying on transactions again, which is like upstream or like later than the band.

Yeah, I think it's a delayed payment. Yeah, but but if you need to process the transaction to know that you'll be paid, then you don't know whether you should open the connection, which is why you need the system to close the bids. I have like one more minute, so let me just say on I think the block market right now is an area where a lot of work is going on and there's room for low-hanging fruit to be picked by some of the people in this room. I put on the board over there some of the names of the people who are working on it and I'm happy to chat afterwards with people who are interested in that topic. And there's so many more, like I said, every mechanism design or every implementation detail on Solana is a mechanism design problem.

There's so many more. This is just the first layer of how to get your transactions to the leader once it gets there, as you're going to see in Eugene's talk. There are many, many more issues to deal with and implementation details. So, uh yeah, stay tuned and and notice in Eugene's talk whenever there's an implementation detail that comes up that might might need to be addressed. Any other questions about this? Maybe I missed this, but how did they respond to this? It's It's uh in development now. They're working on it. And that um yeah, the I'm working with uh some of the team at Helios is kind of working on the initial prototype for this.

Do you Do you see something like this coming to Ethereum? Right. Um I don't think we have the same issue with I think we kind of have this market already in place because the the people who are doing the block building have kind of priority lanes and stuff that happens already. Um so, I don't think we have that. deals or like Uh it's more like uh there's a repeated game and if you're sending valuable bundles that don't revert to a block builder, then they'll kind of prioritize you in the future. Um I'm sure there are other deals like that. I'm not aware of any details of them. Do you know how uh how far along some of the out-of-protocol bandwidth markets are?

Uh I'm not You're probably more familiar with how far that is, but I'm sure that the I mean, Helios's whole business is out-of-protocol bandwidth market, right? So, I think the out-of-protocol bandwidth market already exists, but it's like kind of it makes sense for the validators to deviate to kind of operating that service so that it's not kind of Helios operating that market as a monopoly or like there's no reason that something that belongs to the validator, which is your bandwidth, should be allocated by Helios because you for free delegated to them something that's valuable.