Michael Moser

This talk will provide a node operator's perspective on the preconf transaction pipeline by examining incentives and infrastructure best practices. 
Specifically, ways node operators may attempt to earn higher revenues than peers through custom optimizations will be discussed alongside, related risks, and potential mitigations.

Classroom A

A proposer's perspective on preconfirmations: a new game in town?

 Node Operator's perspective on prep confirmation transaction pipeline. Please welcome our speaker, Michael Moser. Hi everybody. Let me just calibrate this. So I'm Michael. I'm head of research at ChorusOne. We are Node Operator with just about 3 billion in stake. Some of you guys might know us from some of our research papers, actually. For example, we've designed MEV mitigation on DYDXV4, which is a system that's currently in production. We were also quite early to time in games. We started kind of experimenting with this type of thing early last year and then and then we think it's always important to strike a balance between rational competition and ecosystem health so we've published quite a bit about our approach right and we took a very transparent angle to that and I think philosophically this presentation is an extension of that I just want to talk about pre confirmations from a proposal perspective and maybe a more spicy way of framing this presentation could have been timing games in pre-confirmations, what do they look like? And then secondly, what could an earlier approach to pricing pre-confirmations look like? I think first of all, it's important to note that it's very early days. I think there's just one public pricing model for pre-confirmations. And so what I'll describe here is more of a general approach rather than a specific model, because this will be very parameter dependent. And in the spirit of rational competition, we'll talk about what it is that we do, but we might not have all the parameters public naturally. Yeah, so here's the agenda. I will quickly walk through the types of pre-confirmations. Then I'll talk about the pre-confirmations pipeline from a proposal POV. Game A is kind of like a timing game, right, what that would look like. And then game B is pricing and optimal inclusion. So let's dive in. Yeah, I think there's a lot of jargon flying around. I think it's important to just bring these things back to what they actually are. They are basically inclusion pre-confirmations and then the execution pre-confirmations. I think the key difference between those, you can really boil it down to the two points I give at the top of the slide. An inclusion pre-confirmation is just a credible commitment that your transaction will be present in a future block, but it's not a commitment of the transaction actually executing, right? The transaction may fail. So what the validator does is it tells you, I commit to putting your transaction in there, but then again, you know, if it touches contentious state, there's a chance that it will fail. An execution pre-confirmation, by contrast, actually commits to the transaction being one present, of course, and then two subset executed in the block. Therefore, it should not fail. So what does this mean in practice? Implication one, execution pre-confirmations can touch contentious state, right? They also require the block to be simulated because otherwise you cannot commit to a transaction actually landing, right? You need to simulate the block out as a whole to understand whether this is a commitment that can be credibly given. And then conclusion one from that is execution pre-confirmations are best issued by builders and I think there's two really simple reasons for that right if you just demystify it reason a is that builders have private flow and you know as it like a proposal you don't see that private flow so you a priori do not have the option of simulating a block out fully simply because not all the infrastructure, and the other thing is that the block out fully simply because not all transactions are available to you. And then B, builders also have kind of sophisticated pricing. This is something that they do in terms of part of their competitive edge. For a proposer, if I'm talking about running infrastructure really well. I see the light went out, but hopefully the rest of my talk will be enlightening. Maybe I'll do my best. Inclusion pre-confirmations on the reverse, don't touch contentious state, because otherwise it's not something that you could commit to without giving the execution pre-confirmation, which means they are typically best issued by proposers. And the reason for that is just that the proposer is certain to propose. With a builder, builder A may win the auction, but builder B may also win the auction. With the proposer, you know for sure that the proposer is going to propose to the next block. And therefore, you do not have to probability gate it, right? If you get a pre-confirmation from a builder, you always have to expect that that builder might not win the block, or it must solicit downstream agreement from the proposer. But with the proposer, there is no such uncertainty, right? The proposer is quite certain, unless something really terrible happens on the infraside of things, which is unlikely. Okay, so let's zoom in on the latter point. Let's zoom in on inclusion pre-confirmation transaction pipeline for a proposer. Yeah, I kind of sketched it out a little bit there. There's, of course, a lot of nuance here, but I think to understand the general concept, it's enough to understand the general transaction flow. And then I think we can dive deeper into more granular detail. The generalized proposal inclusion pre-confirmation transaction pipeline, you basically have a transaction originator, would be, you know, maybe it's a base rollup, maybe it's a user, and that transaction originator would send the transaction to some kind of transaction aggregator, right? You do not want transactions to be sent to the validator directly, because then what functionally happens is it can be, you know, it opens up a DDoS attack vector, and that would very badly reflect, for example, on the home stakers. It also generally wouldn't be the way that people are set up in the firm. On Solana, your proposers expect a certain amount of traffic. On Ethereum, that's really not the case. So there would need to be some kind of proxy in the middle. You can conceptualize a little bit like a relay. And this proxy can do two further tasks. Either it just takes the transactions and then forwards a set of transactions to the proposer for the proposer to choose, pick and choose, or it does pricing itself. And when it does pricing itself, frequently the lingo that's being used is we are talking about a gateway here. So really that's kind of where the path diverges. Either this type of proxy does pricing or it doesn't do pricing. And then for the proposer, if you want to optimize, you have to be opinionated about two things. First, you must source transactions optimally. This is basically how do you interface with the relay gateway proxy, whatever you want to call it in an optimal way. And then B, there's another scenario where this is like a subset of scenarios where you can engage in pricing. And then three, there's also maybe another game where you can strategically play inclusion and exclusion. And we've actually published about this, right? But this is more relevant for execution pre-cons. So if you're interested in that, you can find it on Eve Research. It's by Umberto, who's a colleague of mine. And maybe I just want to mention here, this is a co-op with two other team members, Umberto and Benoit, who are very, very active on this type of more quantitative research okay really let's take it back right either transactions will be sent to the electronic will be sent to a proxy or a transaction pricing can be delegated to a third party and then and then to kind of close the slide I want to just like structure out these two optimization axes. Optimal transaction sourcing, what that would mean in practice, there may be something like a timing game, but in actuality we would argue that it's a reverse type timing game. And then there's a sub game where some transaction types you might want to strategically include or exclude, but I won't talk about this today. And then secondly for secondly for pricing yes if there's no gateway design and the validator does pricing then you need to have an in-house an in-house opinion on that right i think in general it's important to say that all of these things always exist on a risk reverse axis for example even in normal pbs timing games if you push them really far, what you do is you simply delay into a flat curve, and you're actually on a very bad point on the risk-reverse axis. So I think it's important to always frame that in terms of expected returns. Let's talk a little bit about optimally sourcing transactions. So this is a busy slide. Therefore, I'll take it step by step. You see two kind of axes of graphs here. There's two graphs at the top and then there's two graphs at the bottom. And I think that the way to read this best is the two graphs at the top correspond to the first large point on the slide and then the two graphs to the bottom correspond to the second large point on the slide, and then the two graphs to the bottom correspond to the second large point on the slide. I will explain. I think the first thing to notice here, to set up kind of the timing game, is that gas use is dynamical, right? I mean it varies a lot between blocks, but then it also varies a lot within blocks. And if you look at the graph there at the top right, that's basically the gas per transaction distribution and it's of course extremely skewed. And then if you look at the gas usage versus position, which is on the top left here, you will notice that the higher a transaction position is in the block, the more gas it consumes. So let's just keep that in mind. The earlier a transaction is in the block, the more gas it consumes. So let's just keep that in mind. The earlier a transaction is in the block, the more gas it tends to consume with some edge cases around background specifically and the gas per transaction is distributed in a manner which is super skewed. And then I think, and then the second information we need to set up our case here is that PBS timing games capture value by soliciting the block very late, right? So you send a get header request really late. You give the builder a lot of time to gather transactions to kind of combine them, right, for 6-dex arbitrage to come in. And this is what you see at the bottom here, right? This is the way it works in PBS. So the bottom left graph is the number of transactions and kind of when they come in. And I think here the point to take away is just the longer you wait, the more transactions are available, so the combinatorial space is higher. And then the second graph at the bottom, which is on the right, is the longer you wait, the higher the ratio of the bit to the max bit is. So basically the way you would read this is simply the expected value of a block goes up over time. And now let's look at the game that we can deduce from these two categories of information. So conclusion one here is, PBS timing games benefit from expected transaction gas use going up over slot time. And PBS timing games also profit from winning over transactions with mainland in the next block. Now, for pre-confirmations, I would expect this to be quite different. And the reason for that is because the premium that you're willing to pay for pre-confirmation, it corresponds to the service level you're getting. And let's say you can land anywhere within a 12-second time frame. If you land at 11 seconds, then you're getting a certain service level. But then if you land at one second to the next block, do you really need a pre-confirmation? So there's definitely some like an effect here where instead of the expected value going up over time, it might go down over time, simply because the service level that you provide where pre-confirmation, this is earlier, this is better the earlier in the block, you're just doing more. And what this would mean to us is that the pre-confirmation inclusion premium scales with the expected wait time, right? And what this would mean to us is, on the one hand, we would expect pre-confirmation value to cluster early. So if you look at the PPS graph here, we wouldn't expect it to look like that for pre-confirmations. In actuality, the highest expected value per transaction, that would happen a lot earlier. And then you really probably wouldn't want to wait super long. Instead, what you want to do is you want to wrap the pre-confirmation auction up and you want to give the builder more optimization time. And then if you take it really practical, we think there is an optimal early end to the auction that is a function of the transaction arrival and distribution and the price decay. Right. And we have some we have some very specific thoughts on this, but unfortunately there's no time. So we'll need to dive into the next game. And this is pricing and optimal inclusion. So previously I mentioned that either a gateway can price it or potentially a validator can price it, right? If you asked me for a hypothesis, I would say it's probably more likely for the gateway to price it because I think node operators on the whole, as I mentioned earlier, are more set up to run good infrastructure, right? Pricing is not something that typically comes up. But yeah, that being said, let's go ahead and sketch out a quick model, right? I think the first thing to consider here is earlier I mentioned that the transaction, the gas usage of a transaction, that varies depending on where the transaction is in the block, okay? And so let's approach this heuristically. And there are kind of three tiers of transactions in the block, right? There's like tier one, which is super early, which is top of block, which is typically your sex-tax arbitrage. There's tier two, which is kind of like mid-block, and then there's tier three, which is anywhere else in the block, right? Can say like mid-block to bottom of block. And then, okay, so we have this heuristic, is it valid? Well, we ran the statistics on it, and we, you know, like this p-value, which is pretty small. If I read that out now, that would take the end of my presentation time. So these tiers are not the same in terms of transaction usage, right? In terms of gas usage. So it's a heuristic which is kind of, you know, like if you rigorously look at it from a statistical POV, it's fair. And then one conclusion we can draw from that is that validators compete for tier 2 and tier 3 transactions, because tier 1 transactions, they are just super tight to being at the top of the block, right? The sex tax arbitrage, you know, like there is no real discretion about maybe including it at a later point of time. It has to happen at that point in time because it is tied to a certain price delta between a centralized exchange and the DEX. Okay, yeah, that being said, again, take away one, there can be, you know, we can separate out transactions in the block into three tiers in a statistically valid manner. Takeaway two, tier one transactions here really aren't, you know, as useful for our pricing model because we are talking about inclusion pre-confirmations, which don't really touch contentious state in this way. That being said, let's sketch out the model, right? So the first statement that we can make is well what do we need to build a model here right can we even do that? Yeah I think we can do it right because inclusion pre confirmations do not touch contentious state you can build a model solely on public flow okay so the model can be built that's premise A. Two, how would the model look like if we dig in a little bit deeper? Well, okay, so we have a base fee component and we have a priority fee estimation. Let's look at some of the attributes of these two, right? The base fee is easier to estimate because it's discrete and then the priority fee is a lot harder to estimate because it is it is continuous right so just there's a there's a much much larger space the base fee we can generally frame as the the opportunity cost of pre-conferring transactions right because if you if you do not pre-confer a transaction, you can always get a future transaction which, you know, as a minimum incurs the base fee. And then the priority fee can be seen as something that's more akin to like a premium, right? Which it is in actuality, even in a spot market, the priority fee would basically correspond to a premium. Okay, so how can we schedule a toy model? Well, first of all, we need a way to forecast the base fee, which is something that can be reasonably done. And then we finalize a distribution of the priority fee over tier 2 and tier 3 transactions, because again, tier 1 transactions are not as relevant for inclusion pre-confirmations. And then what we think is a good first way of approaching it is you take the base fee baseline and then you add a percentile of the priority fee distribution as the pre-confirmation premium to it. And actually which percentile you add to it, I think this is largely a function of you can see it as I think this is largely a function of, you know, you can see it as a confidence interval of how well you understand transaction pricing in a future slot. I think this is a good way of approaching it. We hope to publish a little bit more on it. I think for both the last game with timing and for this, it's important to look at things empirically. For that reason, this is something that will mature over time. But in general, I think this is an approach that is valid for either an old operator, pre-confirmation protocol, or whoever else is interested in that. So I think I'm ahead of time. Thanks for attending, and this is it. Thank you a lot. We have two questions. I will give you a chance to choose which one you want to answer first? Sure, sure. I'll answer the question with the one vote first. Besides based roll-ups and MEV searches, we also might be using pre-confirmations. Okay, let's take the taxonomy that I mentioned earlier in the presentation between inclusion and execution pre-confirmations. I think for inclusion pre-confirmations, it's going to be two cases. One is based roll-ups and then the second case would be UX, right? Okay, so you can look at that and you can say well, you know, waiting 12 seconds is that really so bad? But then if you frame it differently and you say, you know, speeds that's comparable to Solana, then that actually that actually sounds a lot better, right? So for, I think it's UX, let's say wallets and based rollups. And then for execution pre-confirmations, I think that's kind of where searches start coming in. And not only like atomic searches, but then there's a point where it gets relevant for sex tax arbitrage as well. Yeah. Okay. Thank you. We still have a bit of time. If you have any questions, we have microphones available. Okay, thank you a lot. I think it was a very interesting talk. I also, not a predator.

https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67383bf21b0f83434d24292b.vtt