The Transaction Supply Chain for High Performance L1s with Pranav Garimidi

Transcript

Welcome everyone to today's A6Z research crypto um seminar. Very pleased to introduce our own Prenav Geramdi by popular demand. This is going to be uh his second talk on block building specifically today in Salana and other high performance chains. >> Yeah, super happy to be here um and give follow-up talk. So a few weeks back um I talked about kind of the transaction supply chain for Ethereum kind of what it is how it worked. Um we got a bit into Slana but we didn't get too far. Um so today we're really going to dive into Salana pretty in depth and with some time at the end talk a bit about ATOSS too. So yeah so just reiterating let me talk about the transaction supply chain.

We're really trying to answer this question um about kind of in practice, how do transactions actually land on chain um and so we've seen that for Ethereum now where things move a bit slower and so you have lots of time to run these different auctions and things can move kind of um piece by piece and say we're really going to focus on kind of when we try to scale things up and move to like a faster environment what new challenges arise um in particular how does Salana um deal with these things and so again these are the three um kind of main things we're addressing with the supply chain Right. The first one is ME. Right. So, ME kind of adds lots of different technical incentives uh to the protocol and so in turn many kind of sub components have sprung up um and change how transaction flows work to

accommodate it. There's also computational constraints right so even in Ethereum block building was hard of kind of deciding by order of transactions. That's going to be even more so in Salana um with kind of the faster speed and kind of more transactions they're dealing with. And then the same thing with the bandwidth um constraints of even in Ethereum we kind of had bandwidth constraints of kind of how much can validators be expected to download and upload. Um we move to these faster environments that only gets exacerbated um and kind of the just the raw demand um that these systems are trying to satisfy. And so the very simple version of this problem is just how does a single valer decide what transactions to include right?

They're kind of seeing all these things. They need some mechanism by which they said what gets included. And so we're going to talk about kind of what this looks like at the metagame level. You know, one thing to keep in mind, what types of preferences people have, right? They're not going to be simply just people that want to land at some certain price. While that might be a lot of transactions, there will also be lots of transactions where people have very specific constraints around I only want to be included if the transactions fail. So this is also called kind of revert protection. Maybe you want to get some certain kind of um guaranteed price when you get executed. you know, so there's these various kind of very specific types of constraints people might have.

Um, and we want the chain to be able to kind of support these. And then separately, apart from just kind of the the richness of preferences people might have, we'll also have that there's going to be just tons and tons of transactions. Um, and it even might be the case that kind of there's more transaction demand in terms of just pure bandwidth that can even fit um into a single validator. And so we'll see kind of how uh Salana in particular kind of addresses this. So let's get into it. Yeah. So, just as a highle picture, uh this is kind of the the holes of PyChain and Salana. And while this might look like a fairly simple picture compared to the Ethereum one um I showed you guys a few weeks back, there's actually a lot of interesting stuff um happening inside these boxes uh that make the system

pretty complicated. So, let's start with the network layer. So, we're going to kind of start talking about how do transactions get to the validator, how do they leave the validator. Um and the first thing that's kind of interesting on Salana is this notion of stake weighted quality of service. And so so here the problem really is that there's more incoming transaction demand from a a bandwidth perspective than the the leaders have capacity for. So Salana doesn't have a mempool. Um and so the the protocol is that everybody directly sends their transactions to the current leader or kind of the next set of leaders. So those leaders can like immediately include those instead of kind of just gossiping transactions around for a while. The problem with that um as you can imagine is that

there's just way too much stuff going to the leader that the leader has some fixed amount of ports and fixed amount of bandwidth um and this can very quickly overwhelm um how much capacity the leader has. And this was fine for a while of kind of people and so on dealt with it. Um and then um about I want to say kind of 8 nine months ago or kind of around that time frame um there was this thing called or that spun up on Salana and it was basically this like proofof work smart contract where the more transactions you spammed into this thing the more money you would make and so now there was actually this like massive economic incentive to just be like spamming transactions to people. Um and basically the network started having problems of there was so much demand um

to spam the validators that normal transactions like just weren't even being seen by by the leaders, right? The leaders were had their ports completely filled with these kind of garbage transactions. Um and there were even incentives for kind of adversaries to basically just do the leaders and to just fill up all their capacity with their own transactions as possible. Um so leaders like couldn't even include kind of uh these adversaries competitors transactions. Uh and so kind of the the hot thick Salana uh approach this with is what they what they call this quality of service. And the basic idea is that instead of allowing kind of anybody to connect to the leader um every node gets a connection whose size is determined by

their stake, right? So if you assume that I had 10% of the stake, then the next leader would maybe dedicate kind of 10% of their bandwidth personally just for my transactions. Um and so in practice, it's a bit different. There's a split between what they call kind of stake connections, unstake connections. So it it's not the case that if you have no stake you you can't hidden at all. Um nodes are supposed to reserve kind of some fraction of their capacity for these public connections. And so that's kind of this circle at the bottom. Um but the majority of the connections really really are for kind of the the staked nodes. Um and so it's RPCs as other validators. You can imagine kind of any party that wants reliable transaction inclusion um kind of often either contracts with the party that has

lots of stake or themsel has a lot of stake um to kind of get included. And now one natural question you might ask is how is this enforced? It it's not really. Um and so the way it works in the protocol is it's literally just kind of a file um that kind of is like you know kind of a mapping between different addresses and how much stake they have based on kind of what's on the chain. Um and it's expected that kind of the default client um follows this faithfully. There is nothing in the protocol that stops any kind of validator from overwriting this file and inputting whatever connections they want. And in practice that does happen actually. Um and so how faithfully the the protocol kind of follows kind of this QS is kind of up in the air for for

right now at least. Um you know kind of initially when they rolled it out everybody was using it. Um now there's kind of a mixture of how different nodes allocate their incoming bandwidth. But I think the the main takeaway being of that even at this level of abstraction of kind of how do nodes decide who to listen to and how to get transactions even to be considered to the validator isn't itself kind of an economic process um on salon is something I think kind of any chain that's operating at this kind of capacity needs to to face at some point. >> And so the tension here is that some of the transactions um you know there's transaction fees. So if you just follow that you may be leaving some transaction fees on the table. Is that the main tension about whether to do this or not

or >> um so I think it's yeah you have to do something. So there's also centralizing concerns here right. So so even the notion that I need lots of stake to like lend a transaction is undesirable. Um so it's really you need some kind of economic back pressure on the entry point to the the validator. Um so the transaction fees is less of a concern like the highest transaction fees probably are going on the the stake leaders and that's probably okay. It it's more so in some notion of fairness or efficiency in the sense of um you know if a few RPCs or validators get lots of the stake um do they have outsized market power and kind of dictating other terms in the market structure um and so that's not ideal and so people have been thinking about different ways to address this um but at

least as like a a first fix this is kind of what they came up with. Yeah, but you could imagine a fee based back pressure, right? Which makes >> uh so the the tricky thing is is this this all happens before execution like before anything happens on chain, right? So there have been ideas floated of like uh the validators auction off kind of their incoming bandwidth kind of some blocks ahead of time. That could work. The concern is that there's it's very hard um to enforce the validators actually following the agreements they gave or so say a validator likes like like ransom auction and they permissionlessly sold off you know 20% of their incoming bandwidth to like some nodes then it's hard post to verify if if those nodes don't get the

transactions in is it because they were faulty was it the leader was ignoring them they wereing the commitment it just kind of in a permissionless setting it's hard to actually verify things at the network layer before you can actually run on chain. >> So this allows you to kind of do side bets outside of the fees in some sense. >> Right. Right. Yeah. So yeah. So everything here is kind of outside the protocol. Um I think it's an interesting open problem of kind of to what extent can we meter at the network layer in a permissionless way without these kind of more standard like legal agreements and other things. >> Yep. So like if my transaction doesn't get in in this block like will I have to resend it to the leader of the next block like myself or is there a way to directly forward this for transactions

that >> yeah so so validators in Salana do forward transactions by default um now that doesn't always work like you probably would I mean it depends on the use case right so um in some cases if you're not super concerned of execution and you just like you know don't want to do something too many times you can probably rely this um RPCs might do it for you. It's kind of a there's various solutions to it. Um but yeah, so I'd say depends on the use case but by default it should be forwarded. >> So I thought you will just send to the next uh X validators or in validator right the VR PC themselves >> whenever they send them next validator.

So in that case we won't forward right >> um leaders anyways forward. So yeah, so it's like uh there's room on the table for optimizing this and people have definitely talked about it. Um so the the default behavior at least I I still think is what they do is that a leader will forward the transactions they didn't get to to the next leader. Um but RPCs anyways send stuff to the next leaders. So there's typically there's tons of duplication like the network is being spammed by tons and tons of transactions. And there'll be a graph later on. I'll show kind of showing that more exactly. But yeah, there's tons of duplicated things um where there maybe just don't have to be just because people want to like really be sure their stuff gets in. They'll send it through like kind of all the paths possible.

>> You you said that there's a smart contract on chain that if like there's like proof of work uh and then I get money. >> Some like random app somebody did like it's some uh it's not part of the protocol. >> I see. Oh, okay. Okay. Okay. Okay. >> Yeah. Somebody just made some application that was like I'm going to make this fun game and then people started using it and stuff like this. So this is kind of the outgoing bandwidth. Um so it's called turbine. And so um Roger also spoke about this a few weeks back as part of openlow. There's a new version of this that's going out called rotor. It's basically the same idea. Um but what's in production today is this thing called turbine. Um, and this is basically this observation that when you're disseminating data, uh, you should probably do it kind of according

to stake as well and that you want kind of the highest stake nodes, uh, to hear about transactions first. Um, and so basically what what Sana does is kind of when they're producing blocks, um, they arisha code these blocks up into chunks and then they send this in this basically stake weighted tree where basically the the more stake you have, the higher in the tree you kind of expect it to be. And you know, here I'm showing a fan out of three. I think in practice span out more of like 32 of or 64. Um so the tree is only kind of like two or three levels um in practice. Um but this is also kind of just a a way of trying to optimize kind of how do we get the data from the blockchain um to people as fast as possible. Um and so

that once you collect enough shreds from the turbine tree, you can reconstruct the block. Um and yeah, so it's kind of just the the flip side of being very intentional on the both kind of incoming side and outgoing side of how um the network is treated. >> Cool. >> So preferring high stake is like a little bit of a rich get richer effect, right? >> It is. Yeah. Um I mean there's So that's definitely true. So if you are like a trading type entity um where you want the information faster, then you definitely want to get more stake. Um, so the new version of rotor kind of helps with this a bit and that like there's a bit less incentive to be higher staked. Uh, it is true with kind of like there's multiple levels of the tree. Um, people that want information faster definitely do want to be staked.

I mean it doesn't like uh help you too much beyond that. Like if you're not doing trading type stuff, you'll hear about things, you know, maybe 200 millonds later, 400 millconds later, which is, you know, not ideal, but for a consumer app, you probably don't care. Um but yeah, I think this is kind of a tension that's interesting of um the the network is a resource you need to meter somehow um in terms of it it's very constrained and in the absence of like having a chain from the network on um the only thing you can see that's permissionless is stake basically. Um and so when you prioritize stake then yeah naturally information uh both comes from high people faster and gets to high people faster. to what extent that can

be addressed I think is interesting. Um yeah >> and so for rotor you're saying everyone's on the same level anyways so they just get it at the same time basically >> right. Yeah. So so rotor basically so um so here there's kind of like this first node um in the tree. Uh and so rotors so bas the reason that first node exists today is that uh they didn't want the leader to do all the work of the like the racial coding and whatnot. So like the leader just sends everything to this one guy and then this one guy does the work of like eraser coding the stuff and sending things on to the next level. Um so rotors basically just going to be at just like one level of um you know some set of relays which I think it's going to be 128 or something like this. And

then those relays do kind of all to all of they they broadcast their shred to everybody. Um and so then kind of nobody kind of on the relay level should have enough shreds unless they have lots of stake to reconstruct and then everybody here is kind of in two hops approximately the same time whereas you know today there's a mix of kind of like data shreds and coding shreds. Um so some people are getting data shreds do learn stuff faster than people are getting coding shreds say. Um and yeah so so all this is kind of trying to be um fixed in helping glow but but for now this is the the current structure. So you're saying it's both the tweak in how the ratio coding is done plus the flattening of the tree structure.

>> Yes, exactly. >> Okay, cool. So now let's hop into the execution layer. And so I think one important thing to know about Salana is that they have continuous block production. And this really drives kind of a lot of the the market structure things we see. And so you normally have this 400 millisecond slot on something like Ethereum, right? Like you'd broadcast the block at the end of the slot. Uh Slana is not like this, right? They're kind of here the these boxes represent kind of in like many batches of transactions. Um and SA has this like parallel execution environment. So you can think of each of these batches as being kind of a set of transactions that can run in parallel on different threads. Um and so roughly every 20 milliseconds the validator is producing a batch of transactions, executing it and then pushing it through turbine.

Right? So we kind of see every 20 millconds it'll kind of run a new batch of transactions and push it through turbine and kind of go on so and so forth. And so it'll do this until kind of you get to the full block. Um and so now the the important distinction here is that a block is still the full set of things in the form interval, right? So consensus only happens at at this level of granularity, right? So the fact that there were these kind of mini um what they call like you know like shreds that are being sent through the network is not part of the consensus protocol. It's kind of an implementation detail in that nodes on the receiving end kind of tur turbine is continuously gossiping these like kind of mini batches and then nodes are continuously receiving these mini

batches re-executing um and keeping up with kind of the tip of the chain in that way. And so other other chains um would have something like you know only this big block over the four millisecond interval is kind of all broadcast at once and everybody starts executing right once they receive that and then they vote after they execute everything they've received. In this case, it's only this last last bit, right? So, so you're like up to 380 milliseconds, say you're you're receiving stuff, you're not voting yet. You're just keeping up with what's in the block so far. And then in the the very last bit of the block, kind of the last shred, now you execute that and then you vote immediately um after having received kind of the very last bit of the block.

And so, basically, this means that you can kind of just pipeline things much more efficiently. um and that instead of kind of fully doing um you know block proposal then execution then consensus these are all kind of interled together um where that the time between receiving the very last shreds of the block and building gets very small. So now let's talk a bit more about how this kind of parallel block building actually happens. Um so this is kind of like a highle overview of kind of what's happening inside um the validator and we'll talk through some of these steps more in more detail. um but you know just to get a high level grounding right so this transaction injection point is kind of this sided QS thing I was mentioning along with some other um details in practice but basically just

it's the the validator receiving incoming transactions and one point also is like you know here it's like written as one box in practice this might be multiple computers right like you might have you know one server just dealing with transaction ingestion and acting as like a buffer between some other node that's like doing execution just to make sure there's like not one process getting overloaded by everything but logically it's kind of all one component at least controlled by one entity. Um and yeah so transaction ingestion is kind of just managing like what are all the packets I'm hearing about all the quick connections all this type of stuff. Um and then s verify ends up being kind of a a fairly big bottleneck.

I mean it's not anymore but at times it has been signature verification is actually one of the the large um yeah roadblocks and doing block production. Um and it's also just because kind of the magnitude of transaction ingestion um or the amount of transactions being ingested will be quite a bit larger than what actually gets published at the end. So for example, if you think of the blockchain as being 100 um the valer might hear like a thousand or 10,000 transactions that want to be included. And so each of those has to be all of those signatures have to be verified before you start putting them in the rest of the stack. Um and so that that can be a lot but you know that can be paralyzed and people have thought about different ways of making this even faster. Um but it's something to keep in

mind. And so once all the transactions have been kind of verified and dduplicated um they hit what's called the centraluler. And so this is only kind of like a this is basically how the valer just decides how to batch the transactions in a way that they can be parallely executed. And so we'll talk more about that in a bit. But basically they run some algorithm um take all the incoming transactions and then they shoot them off to these worker threads um where kind of all these threads kind of execute in parallel and then like commit to their values and then basically the validator just broadcasts everything it's done so far. Um I know there's another kind of component to this is notion of a builder right so this is going to be part of the MV pipeline we'll talk about that a lot more um in a bit but basically like

while this is happening there's kind of external parties that have a different pipeline of the block who are also kind of feeding batches of transactions the validator to to include um that's a high level picture and so let's talk about theuler part for a bit um and so another >> sorry uh do you have an idea of how expensive each of these components are like how expensive is sig verify in comparison to the central scheduler. >> Yeah. So, not exactly. Do you mean like in terms of milliseconds or >> percentages? Anything like how much of signature verification is a bottleneck? >> Right. Off top of my head, no. I know where to look for that. And there are people that have like so people have done like the full flame graphs of kind of the full kind of cycle of a a client.

Um and so there are dedicated threads. So, so part of it is that it's not as bottleneck and there's dedicated threads for that. And so while things are being like verified, other things are being kind of batched and processed. Um so my impression is as of today it's not that big of a bottleneck. >> Okay. >> Um but people have talked about for example having FPGAs just for signature verification. um where everything that comes in immediately just hits that and then in parallel you're building the block and then you know you can you can do fancier stuff >> right because it feels like a very easy way to do a DOS attack because you could just send bad signatures especially at like >> uh yes for sure that is definitely a concern. Yeah. So that that that's part of the secrets thing of like if you

start sending bad signatures I'm going to like cut you off. >> I know where you're coming from and you're you're a stake person. >> Uh okay because you have the stakeh so it all kind of ties together. >> Gotcha. Gotcha. Okay. So like at fees like signatures are handled specially with the transaction fees, right? My sense was the original architecture they were thought to be most of the computation that was going to happen. Is that right? >> Yeah. Yeah, I think this is the case. Yeah. >> Okay. >> Like you paid per signature in the transaction fee, right? Right. I know there's the CU stuff also, but I think that came later maybe. >> Uh they're actually Yeah, it came later.

Yeah. Yeah. Um and and so one thing is you know like um the difficulty of like scheduling transactions it's like not really captured in the CU cost of like that's just you running some algorithm over the the whole set. Um and so you can run simpler or more crazy ones. Um so I think like that is where the bottlenecks like are kind of hard to compare running a very expensive like napsac algorithm that's very very good then it might actually be that it's much more expensive than sign verification compared to like running some very simple greedy algorithm then maybe it's it's actually it's fine. So yeah on that point for the scheduler one important thing to note is that in Salana all transactions are forced to declare every address they will either write or read to ahead of time and so that lets us build this kind of graph between

transactions. So kind of in this picture think of every node um as a transaction and there's an edge between nodes if they're conflicting and by conflicting that means that maybe one node writes to an address and the other one's going to read from that same address. And so in particular what it means is that these transactions cannot be run in parallel. They they have to be run serially. And so we can build this graph given that people are forced to declare these things kind of up front. And so then the question is what what do we do with that? And so basically um what you have to do is basically just pick independent sets of this graph and that's what are going to be our batches.

And so I mean so also keep in mind this is happening kind of continuously. So transactions are streaming into um this kind of set. And I also forgot to mention that each of these transactions also has a priority fee attached to it, right? So Salana kind of has um a base fee and a priority fee as it transaction fee mechanism. Um and so there's roughly the the guarantee that the higher your priority fee, the more prioritized you are by the scheduler. Now that's not enshrined in any strong sense. That's kind of a rough guarantee the protocol gives you. And the reason it's not enshrined is kind of because of this reason of that you're picking independent sets of this graph um kind of as your batches and your ordering. Um and so it's not super well defined what

it means if you know I have a very high transaction fee but I'm conflicting with lots of people and somebody else has a very low transaction fee and they're not conflicting with people of like who exactly should be ordered in and what sense and you know if the there's like some path between these two transactions in terms of conflicts then it gets more tricky of what guarantee you actually want to make. There is no strong guarantee but roughly the the algorithm that the default client uses will be to make some priority Q type structure um and trying to pick the the highest priority fee transactions at any given point that it can um and then putting sets of those that can be parallel executed into a batch and then kind of shipping that off to worker threads.

>> Yeah. >> Did people considering consider running a more sophisticated like maximal independent set algorithm? Um yeah so it turns out this actually is a bottleneck in practice with just like the size of the number of transactions going and how fast things are. So yeah so it's a streaming algorithm going in 20 milliseconds um with I mean not crazy high number of transactions but a reason high number of transactions and so um even not like even unsophisticated algorithms that were just like uh like build a DAG and like pick you know kind of the the highest things in the DAG that seemed you could do at the same time. Turns out like even like sorting was too slow or something. So like um now it's like a so I think as of very recently the default client uses just like a pure greedy algorithm um and just

in terms of like speed this gets you enough um where the throughput is just meaningfully higher and that's actually more revenue than doing the things slower that are more sophisticated algorithms. Now of course you can attack these right like if I know the algorithm I can give you very very bad inputs um that's a problem in practice today lots of the validators run their own custom software here right so the default client has some greedy algorithm um people optimize their revenue by doing all sorts of things um as you can imagine running better algorithms here >> there's the classical randomized algorithm just like you know okay yeah we can talk offline >> you're not worried about me here or uh >> I am yeah so I I'll go to that in a bit so the me stuff actually goes through a different pipeline kind of um it very

much is a concern um but for now I assume it doesn't exist even then it's still kind of a hard problem of how do you build these blocks best and yeah so the other main thing to mention here um is that Slana has this notion of what they call local fe um which you can basically think of as these multi-dimensional knapsack constraints where there's a global kind of CU limit so in Salana Cu is equivalent of gas right so they meter all the computation in CU and so there's one big global CU limit limit and additionally every account has its own kind of local CU limit and that since we have these kind of read write lists for all the accounts um you can track kind of how many transactions interact with an account in any given block and there's a constraint that basically you know only some

fraction of the um block can be touching the same account and the point to this is that since we have this parallel execution environment um we want to try to incentivize workloads that really can be parallely executed. And so the kind of this local fee market structures kind of what allows for that. And the having these kind of um knapsack constraints that on the accounts that are smaller than uh the total limit means that like kind of if there's tons of demand on a single account say for some NFT drop or some price movement uh you won't have that the entire block gets taken up only by these types of transactions in which case it' be kind of a fully serial workload. you kind of enforce that like at most kind of like one thread um is focused on these transactions and then

the other threads are free to pick up kind of things like simple payments, you know, other applications and stuff like this. Um and I think it's a bit helpful here to get a bit more into the math than the other parts of it. So it's not too bad to express question first. >> Yep. >> In practice like splitting an NFT mint over over four contracts in order to like saturate all four. >> Um I don't think so. It's been a while since like the NFT meta honestly. Um, so so actually for >> or any other application obviously, right? >> Um, >> it's not clear that's bad because you're basically making the app layer conform into being a parallel workload, right?

So it's not exactly. Yeah. Okay. >> Yeah. So so for a lot of finance things it's hard, right? Like if I need to interact with the price then like this price better be in one spot. >> Um, and say that's the majority of demand that like hits these constraints. But it is true like when you're building things like order books and whatnot like you should be very aware of like this is how it works, right? So like your order book should split up your assets across different accounts in a way where you're not all hitting the same thing. Um which is good, right? Yeah. So now you are incentivized to actually have these kind of high um demand applications uh really of the their workflows in different ways that can be parallelized. Um but yeah so so you know like the the formal way to

define this would just be that you know kind of you have some set t of total transactions in the block where every transaction has some like you know amount of usage and some kind of account list. Um and you know we have one binding constraint on kind of the total amount of compute usage in the block and then for every single account you check um that kind of its local limit is also not being hit. And yeah I think the the main kind of takeaway here beyond the the details is that specific accounts can have be kind of at capacity in terms of demand while global block space is not at demand. Right? And so this is what kind of it means in the sense of that something like an NFT airdrop or like you know something like um uh you know some massive like ETH price or soul

price movement will not make the chain unusable at least at the execution layer for other types of transactions and they should always be able to get something like a payment through for a very cheap fee and I think one thing also to make sure it's clear though I was kind of confused by initially is that local fee markets aren't implemented be beyond this right so there's no notion of a base fee per account um in Salana right So the transaction mechanism is still just a fixed kind of base fee. Um that that's pretty nominal and then an optional priority fee and basically the the way the different fees come from different types of accounts is that the equilibrium prices are going to be different depending on the demand for that part of state. Right? So if kind of the total demand for block space is a

decent bit below the total capacity then normal transactions are basically just paying the base fee and like maybe a very very tiny tip. Whereas a certain at the same time there's transactions that are interacting with a very highly contested piece of state that really is at capacity then those are basically competing in effectively a first price auction where they're kind of trying to outbid each other um to to be the ones that get in kind of out of the the fixed supply even though there's kind of other supply that um they can't interact with. >> Yeah. I feel like local gas limits would be more accurate than local fee markets. >> Right. Right. Yeah.

>> Yeah. So the market is purely kind of a function of kind of the wallets and traders bidding uh with the kind of local gas limits. Um and there's nothing in protocol that actually says that like there is this price for a certain piece of state. Yeah. And so to see how this looks kind of practically um here's a graph um from the fire dancer team of they have this nice dashboard um where I'll show you the actual dashboard. It's kind of cool. Um so they they basically made this thing that basically allows you to see based on what their client is doing kind of how the transaction flow looks like. Um and so here you can for instance see kind of like this intro to the the pool of the quick transactions.

It's like 192,000 transactions which is kind of crazy. And now these are almost all duplicates um just because of how like this network is handling things or how people are kind of like kind of double sending things in various places just to get it to the validator. Um so in the end you know it's only this like,600 transactions of you know which lots are are votes but yeah so so this is kind of like this is kind of the level of demand that the network has to deal with. Um and that things like signature verification you know like here it's like these all you know almost 200,000 transactions um you know being verified um and then you know as you get through the pipeline more and more things get thrown out until the very end. Um and you just see what the continuous block production looks like.

This pink line is the amount of CU kind of throughout the slot that's been processed, right? So here we see this is a slot from 0 to 400 milliseconds. Um you can ignore some of the other lines. Some of them are kind of with fees and some other just artifacts. Um but you can see kind of uh in the Ethereum talk I I talked a bit about these timing gains and that people kind of wait towards the end of a slot um to bid really high. And you can see a similar thing at least in the fire dancer client of the CU is increasing at a pretty steady pace and then really right in the end in the last 50 milliseconds they're doing almost all their work in the block and like kind of filling up the block to capacity. Um and this is kind of just

just natural. You can imagine kind of any streaming algorithm like the longer you wait the more information you'll have kind of like the better optimization you'll do and sort of kind of committing to actions early in the slot by filling up lots of your block. you want to wait till the end of the slot to hear as much as you can. Um, and make sure you're not kind of excluding any valuable transactions you might have otherwise. >> So, going back to the shreds picture, you saying it's only the last few shreds that the last few shreds have all the good stuff basically. >> Maybe not, but you want to just make sure that you don't commit ahead of time anyways, >> but you're not going to be transactions.

You are sending shreds every 20 minutes, >> right? Yes. Yeah. Yeah. Yeah. So the last shreds will be lots of the um well it's also like the these fee charts can look different. Um so the blue line here is actually the the fees. Um and so here uh it is actually the case that the fees at the end of the slot are get really high. Um you can see if I look through some other ones it's not always the case. Um so here it's more less the case that like the fees are jumping earlier in the slot. Uh let's see if I can find another block. What I'm trying to understand is the pink line, the CU line, >> right? Yeah. So, at least the majority of the CU will be the end of the block.

It's not necessarily the majority of the fees though. Um, so what like good stuff means I guess is depends on >> I mean that does mean the shreds toward the end have more stuff in them than the shreds earlier on basically, right? >> More more stuff, not necessarily better stuff, but just >> Yeah, because I mean the top of block me goes in shred one, I guess, for example. Right. Okay. >> Yeah. Isn't this a me motivation to actually surprise people at the end instead of giving them a lot of time? So maybe that's the reason, >> right? Yeah, that's another reason. Yeah. And it's the MV pipeline is a bit different too. Um so the the block packing is partly done by the valer and probably done by other people and we'll talk about that actually. Um yeah, maybe I'll get to that first and then we can

get back to that point. But so your hypothesis would be that that is that is the reason that basically if I have something that I'm worried about being sandwiched, I would try to send it at the end and then there's a larger competition on the end in some. >> Probably not. Um I I think it really is that like there's lots of lowv value transactions and lots of just medium or medium value stuff, but the validator might as well just wait. I think things are being sent earlier probably. So there there is a way to express I mean this all like kind of depends on exactly what validator somebody's running and what MV infra they're running. Um but if you want something to happen like right now like there's ways to do that. Um or there's infer at least in theory that does that and to what extent that maps

into the practical guarantees I think it's not obvious um but like I want to trade at the beginning of a slot then you can make that happen. Um and so people do wait towards the end of a slot. So, so you know that graph al this graph looks different depending on the validator that's running. Um, so this is the curve fire dancer decided was making them the most money. Um, to wait towards this kind of last 50 milliseconds to like pack a lot of the block. Some people will kind of just follow a more linear path through this of kind of linearly include transactions as they can until the end of the slot. Um, but yeah, it's right that yeah, so so for me reasons like generally you want to send at the end of the slot. um the continuous block production is what

makes that less obvious of exactly how that works. Whereas the validator made a commitment to I will be literally flat until the last 50 millconds now literally nothing. Um then that would certainly be the case and you would certainly expect to see this behavior. But the fact that stuff is executed before makes it a bit harder to reason about. But I guess your point is there I mean even setting aside MEV a really simple theory for what's going on at the end is just you don't know what the market clearing price is for transactions the blockchain. >> Exactly. Yeah. >> So you see 3 cents and you're like should that get in or not? I don't know yet.

>> Right. Yes. >> And so you just wait till the end. >> Right. Yeah. So I I think that's what this mainly explains. >> Makes sense. That makes sense. Um, you can think of this as like kind of an online knapsack algorithm where the more things you see, the better you can pack instead of the packing half your knapsack at second, you know, or millisecond 100 and then you see all this very valuable stuff come in millisecond 200 for whatever reason, some price moved and now you just kind of lost money for stuff that you you could have included otherwise. So it' be different if if every shred actually, you know, had to spend like if you spread the CU budget equally across the 20 shreds or whatever, that would be different, right? Because then you would see the Yeah.

>> Right. So that that's almost like making the block time 20 milliseconds you could think of. Um which you could do. >> Um although it's hard to enforce without making the consensus time at that level. >> Um but yeah, so I mean so this is things people are talking about like let's make the block times. So one other detail I forgot to mention is that in Salana the same validator controls four slots in a row, right? And you can ask like why why is that? Um one reason is kind of this for these performance reasons of you know like if you could have the validator make you know 10 blocks in a row but they were all 30 30 millisecond blocks. You know it's like a just different kind of performance trade-offs and that like now you know with with four blocks in a row at 400 millconds.

There's also games they can play with kind of, you know, between, you know, their second and third block or something. Um, there's all these timing games that can happen. There's lots of annoying stuff. Um, what it means is that leader rotation happens less frequently while consensus is still pretty fast. And so, you know, like every 20 milliseconds you get some kind of mini confirmation. I mean, it's there's something behind it, but it it's something that at least statistically like tends to mean that you're included. And then every 400 milliseconds, you have a consensus process. Um, and then, you know, every 1.6 six seconds you hand over leaders between people. Um and uh yeah and you just like as you can imagine leader rotation is pretty expensive and you have to like kind of move all these transactions in your state to the next guy before they can

start running things. Um and so these are all kind of things that might change in open and glow. Um these are might change in general and that people are kind of discussing or important things to think about for any chain really. Can you go back for a second to this like graph that show the amount of do dup duplicate transactions? Uh is there a reason why you verify the signatures before you filter out the duplicate? >> Yeah. So there's actually two phases of duplicate. So like there's this first one and then the second one. Um yeah, I don't know the engineering details behind this of uh presumably there's like even on the network layer you get like the exact same packets um just from like different sources maybe or something and then like once

you actually verify the signature and like it's a real transaction there's some more thorough check for like it's formatted correctly or something and even then um it's the same thing but yeah I'm not entirely sure. Okay. Yeah. So now let's talk about MEV. And so just to remind people kind of a a primitive of kind of the MV pipeline is this notion of a block builder auction. And so you recall basically people are allowed to submit bids that are arbitrary functions of state. Um where basically just kind of the the way it's implemented is kind of like the last kind of function call or last kind of uh transaction in the bundle. This is just transferring some soul to some address that the builder interprets as a payment to them. And then basically the builders are just using heristics to decide the optimal ordering. Right? Right? So in

this picture um you can think of FG and H as being kind of different functions um presenting bids over state and now the builder is just trying all these different orders of FG&H um and it finds the order that maximizes uh their profit basically. So this is kind of just like a blackbox thing that in Ethereum is the whole block builder auction and as long as it's going to be kind of a sub component of a butter butter stack and yeah so just uh recall so this is an Ethereum thing not transaction but the concept is very similar where you have some transaction just like the last function call is just a transfer some amount to some address. Um so think of this as a very general kind of bidding language um that people can can express.

Okay. And so we're going to call this kind of a state auction of just uh as as one of these primitives that given some inputs, you run this process and out comes some ordering of these transactions or some subset of transactions. What happens? So I'm going to describe the jetto auction. Um jetto is what kind of built most of the blocks in um Salana. There's a couple other ones more recently um but for the interest of time and and clar focus on the jetto one. And so what happens is kind of similar to central scheduler people will input um kind of transactions and bundles and we'll similarly form a graph between them um where you know the the same kind of readwrite graph of two bundles conflict if they're touching the same piece of

memory um you know writing and reading from the same thing right so then basically what the auction does is going to basically take the connected components of this graph and then split them up into different pieces and so now we have the very nice guarantee that whatever ever I do in one piece won't affect another piece, right? Whatever the outcome of the auction on these on this blue state is not going to affect the outcome of the auction on the green state because the transactions aren't interacting the same pieces of memory. And so basically what I'll do then I'll just run this kind of block auction or go state auction that we just defined on each of these individual components. Right? it's now each individual components I'll get some subset of those transactions um and we'll have some ordering between them and then basically the the block builder will put that

whole thing into a batch right and so you can think of it as a as very similar to like the Ethereum process except motivating by the fact that anyways has this parallel execution environment um you can do things a bit more efficiently using that information um and run these kind of parallel auctions at the same time um now you might ask like what if I just throw in kind of random garbage transactions to connect these pieces, you can totally do that. Um, there's lots of ways to game this thing. Um, it's very much a huristics based uh mechanism and does not have like a very clean, you know, kind of functional form or kind of allocation and payment rule.

Um, yeah, also it's kind of pay as you know it's pay as bid um based on what you set the bid. So people do all kinds of games here of spamming this auction. Um like JTO has lots and lots infrastructure kind of to make sure that people can't spam this too much um and kind of dep prioritize people who are kind of just explicitly messing with this thing of like connecting components and just kind of overall being nuisance to execute. Um so it is fairly permissioned. Um like this is all kind of happening inside this builder box that is just basically what Jeter runs. And so for things that are me transactions oftent times um yeah you you directly send to the builder.

Sometimes you'll send to the builder and the validator or like many many places and we'll talk about that in a bit but but yeah so you can overall think of this kind of builder box as effectively running the same thing as like an Ethereum style block building auction just using the SA semantics and being much faster. Right? Right? So the same kind of streaming thing we had before still applies here. Um where one thing to note is like the the block never stops for the the block builder. Right? So in in the Ethereum context it's like nothing is happening right nobody's commactions are coming in a block auction h like a block builder auction happens decide the optional ordering and then they give that to the the leader and importantly kind of like the leader there has full view over the state um or what they're

shooting on. This this is not going to be the case in general in Ethereum or in Slana where theuler is never pausing um for for the block builder is just that the builder's batches get priority on theuler. Um and so the way this might look like in practice something like this, right, of like the the scheduler is doing their thing. They're making these batches. They're sending um you know these transactions that can be run in parallel and then the builder basically lets to like kind of pop their stuff ahead to the front of the queue. And so the builder is sometimes part of the scheduler. So, you know, there there's some or many nuances here and that sometimes the builder tells the scheduler, hey, I'm running auctions over these accounts. Please lock them.

Don't build batches for these accounts. And then once the builder auction happens and finishes, it schedules those transactions and then those accounts get unlocked. Um, so the exact interplay between the centraluler and the builder is is kind of it's pretty delicate um in terms of like who is grabbing locks when kind of how much time advantage does the builder have in grabbing these locks. Um, yeah. So, as you can imagine, it's a very complicated system. Um, where yeah, again, there's like there's weak guarantees you can get. Um, but there is no kind of clean description. A lot of how this plays out is just really like just engineering choices kind of dictating market structure. Um, and just iterating of like as people find ways to break it, they find ways to fix it. It's kind of a cat and now scam. Um but at

least at a high level this is what's happening of there's a stream of transactions you can think of as generally being fairly simple going to the the validator and then they schedule themselves with some greedy type thing and then the more complicated preferences that are much higher in volume go to one of judo's you know few data centers they try to run this auction get stuff around the world and then they you have much much more compute to be running these kind of uh just different uteristics to build these blocks optimally and then they forward those batches is um to the validators. And so in the Ethereum world, the validators themselves don't run a special client, right? They run their standard clients and they run MB boost as a sidecar to kind of hear about these blocks and off sign off on them. Um on

Salana, people actually run the like JTO Salana client, right? So you you run kind of a fork of the default client that has this build integration into it, which lets the builder talk to the client very easily and kind of get these transactions in, these batches in, and that's what makes this whole thing work. It's all a much more synchronous process uh than what happens on Ethereum for example. Now this is being changed a bit as of like very recently. There's this thing called bindings um which try to break this up and don't actually require that like to be running JTO you have to run the judo sonic client. As you can imagine that's very annoying. Anytime the default client ships any kind of like patch fix or any type of uh you know hot fix or something the goto client has to be kind of uh updating at

the exact same pace. And so that leads to security issues and vulnerabilities and just overall headache devx and kind of devops-wise. And so they're trying to change it or maybe RDB live where the scheduler now just has kind of like JSON interface with the builder and the builder can just stream transactions in directly instead of having a more complicated integrated client. Um but yeah, just some other details aren't super relevant. Um yeah. Are the batches that the builder submits is is it supposed to be like an atomic bundle the same way like searcher bundles are?

>> Yes, it is. Yes. >> So they're and so they're generally not they're going to be executed on a single thread kind of in the same order that was suggested. Yes. Okay. >> And in principle the validator could modify the Salana client to unbundle those and Okay. >> Yes. Which would be pretty bad. Um I'm not sure to what extent that already happens. But yeah, it's like a very different trust model than the Ethereum world. Um and that yeah, validators totally could unbundle people. So being a judo um you know judo sending you stuff is like not also kind of permissioned. Um like most people have access to it. Uh but you know if you did start doing very bad stuff, they can just stop sending you things and then you'd be kicked out of the network basically.

>> So there's no like relay in the main >> there is not. Yeah. Yeah. Yes. Yeah. Yeah. So, Ethereum has the relays to protect everybody and as long as you trust the relay, everybody can be pretty happy. Um, things are just moving too fast for that in this world of like the relay only works because of the asynchronous nature of things of like it's builder moves, relay confirms, they send a proposer, then proposer confirms and things happen. When everybody is continuously kind of moving and like producing stuff, there's just uh it doesn't quite as much make sense of some really in the middle kind of managing the whole process.

How how many builders are there in Solana? >> Uh really one >> one. >> Um kind of two now. I mean there's there's a few more. So like the way builders defined is a bit different. Um and that like it's not so so also worth saying kind of judo only builds something like 20% of the block today, right? So a lot of the block is still going through the centraluler. It's just the high value stuff that JO is building. And so it's not the the model of like the builder does everything and hands off everything to theuler. Um it's like the builder does some stuff and now this is also changing. Um so there are some rules where like might be the case judo is really building the entire block in the future. Um but at least as of a few months ago JTO is only building part

of the block. Um and so there the the notion of builder centralization is not as bad in that like if the validator includes you the builder can stop the validator from including you which is not the case in Ethereum right in Ethereum if the builder doesn't include you then you don't get included um yeah and so there's there's different types it's even possible for multiple builders in practice to be on the same validator in Salana right like you imagine two of these boxes streaming batches and then the incentives get kind of weird of how that actually works um but that kind of is how it works in some cases Um but yeah really there's one kind of two. Um now now there is I think it'd be fair to say there's two now but JTO is a dominant player at least for the world >> and there is there some like revenue

share mechanism between builders and the validators. >> Yeah there is there is I see. >> Um yeah I forgot exactly how it works I think. So yeah go takes some cut a lot of it goes to the validators and to their stakers even. Um yeah >> you said we rerun a few block auctions in pair rul. Yeah. How do we decide how many way when when >> Yeah, that's like an algorithmic thing basically. Um like how far how far down the tree can you search fast enough? Um so it used to be pretty shallow. Used to be like one or two. I think these days it's it's higher. I I forget the exact numbers maybe like three or four per block auction. Um but that yeah that's purely on JTO's side of like how much can this simulate in these time frames and send it off to the the validator in

time. So what is the incentive for the central scheduler to be doing anything as a val like what why should a validator run this if it's such low value transactions? >> Yeah, I mean so sometimes there are high value stuff going through it. So like this whole process is very jittery. It's kind of what what they say and that like um since it's all being continuous like you might have just missed the goto auction window and so sometimes you send to both actually very often you'll send to both centraluler and to the judo auction just to like maximize your chance of landing. Um, but yeah, this whole process is so messy and there's so many competing things of like, you know, did your packet hit the leader in time?

Did it get through verify in time? Did theuler in time? Did the scheduleuler have the lock to let you in? Does have the lock? Like, who has the lock? And then it's like, um, just to maximize your chances of getting in, people just send everywhere to everything. Um, so the centraluler actually still does a decent amount of work in like getting valuable transactions on chain. Okay. Um and yeah, just kind of the the last thing here, um is this thing that's called a transaction landing service that's become more popular because of exactly kind of this point. Um and that you can imagine it's like a very hard problem to decide like what RPC do I send to that has enough stake? Um do I send multiple RPCs? Do I send to JTO directly? Do I send to somebody else? Do I send to like the validator port

directly? There's like many many options as kind of a user and how you submit transactions on chain and really more as like a wallet or like as a it's like a you know more sophisticated trader of options to land on chain like as a user you're probably just like clicking some button and then like that app is like deciding on your behalf how this thing gets sent out. And so there's been lots of instances of like people having being very frustrated with their apps like not letting transactions, right? like you can imagine um you know some like some point thing is happening and I'm trying to trade it um and just all my transactions are failing and I'm very upset as like a retail user and so these transaction landing services have come up which basically like their whole job is like a wrapper around this entire

thing of you give them some tip and then they split up your tip amongst the priority feed to the the validator or some like judo tip or like kind of some mixture of tips different people um and yeah so so point being it's a very messy game um there's there's a lot of stuff happening. Um, and so the transaction landing services have come up as kind of a natural way to abstract it away for like the average person. Of course, now that's just one more part of the stack. Um, and so everything else is messier. Um, but yeah, expect to see more and more stuff like that at least kind of in the the short to medium run.

>> So should I think of Phantom as a landing service or they would use >> they would use a lambdom service. Yeah. >> Have you ever heard of any landing services? >> Uh, yeah. So I uh what can I say? Uh I I >> are there are there any is there like a biggest one to with a name or >> uh I don't think so. Um I don't know that I can say it but yeah. Yeah. >> Um yeah >> coming attractions you're saying? >> Yes. Okay. Yeah. >> Okay. >> So do they create bundles with your transa? So you gave them some tip. So now it's not like they can modify your signed transaction.

>> They need to create bundles now right? >> Yeah. So yeah, I think it's some notion of a bundle. I actually don't know the exact details of how it works under the hood, but something like that seems reasonable. Just takeaways now. So yeah, this is kind of the the whole supply chain. One main thing is that there's like two main points transactions can be dropped, right? So one is at the network layer and right, so there's tons of things that are competing for space and kind of the entry for a validator. And so even like getting through that can be tough, right? There's like the the goto stuff and like the normal entry points and whatnot. And then the scheduler, right, of like all these locks make things very awkward of like um even if you have a higher priority fee than some other transaction you're competing with.

Um if you hit the uh you know structure just like the wrong time the structure just like doing some round drop and thing in a weird way your transaction be dropped for just all these types of reasons. And so when you're building applications on Salana like we just think about this is pretty important and this is why it's kind of very messy. Um and it's very annoying for people to interact with sometimes. Um but yeah so so there's that to know. Um the upside of this is that you know if you are doing non non-contentious stuff like just simple prede transfers that the kind of local local fee model um and parallel execution means you should have pretty good guarantees actually like as long as you can get into the box. Um you probably should make it through the whole thing of

there's not much standing in your way. Um it's really the combination of the networking and the the locks that make contentious transactions hard to land. Um and yeah, and this is because the continuous local building um you know if you had a more Ethereum style thing of hey we're we're going to stop block production um for like you know 200 milliseconds and then we're going to run some auction and then the output of that all transactions are included like now it's much easier to reason about what's happening. It's really is the fact that everything is continuously happening that you don't have a clear interface to interact with and that people are continuously changing how they're they're doing things. Um then they get pretty annoying. Um yeah and so one thing that's like a

design thing Salana chose is that they basically for all these reasons push complexity onto the users um instead of kind of dealing with it themselves, right? So things like declaring these readwrite account lists, having this first price auction instead of kind of base fees per state. Um you know kind of like having this continuous building model. Um these all make it like pretty hard for users to reason about and that's kind of on purpose to make the protocol itself very efficient and very fast which it is. Um but this is just a trade-off you can make as a chain, right? You could not make these choices and you could be a bit slower and you could give users a much cleaner UX at the cost of some of these efficiencies.

Um just something to keep in mind. And yeah, just just in general, I think this is a how this has all played out over the past kind of couple years now um just shows like how how hard maintaining clean supply chains is um for these blockchains, right? So kind of to date it's really only um Ethereum and Salana have had to deal with this in a meaningful way as kind of like decentralized chains with lots of usage that kind of necessitates the need for all these parties to spring up. Um and yeah, so I think there's basically for changes in the future, other applications should just be aware of like this will happen eventually. Um kind of once you get enough users, the demand is there and then it just really is hard to serve all this demand with like a a very clean chain. Um and so

making choices at your infrastructure layers and application layers to keep this kind of uh system as clean as possible is always good. Um yeah, and I I'll kind of I'll leave it um at what the future of SLA might look like. Um something we've talked a lot about here is up and glow um and changing it won't change any of the stuff I talked about kind of too much immediately. I say the biggest thing is it makes everything just cleaner, right? So everything I said is true and then there's like how are BFD today that makes that even worse um of the reasoning about like how things happen. Um things like one thing I didn't mention is that votes are transactions for example. So votes are forced to go through the same pipeline and they're given easy entry at least in theory. Um but there's even problems

there. So all the stuff around that um just the easier consens consensus is to reason about the easier the everything else is to reason about. Um so that'll be good to see. Then things like bigger blocks um help um async execution know. So like if you so here would be moving away from continuous execution and continuous just proposals still um but you only execute kind of after the law ends say or this is even kind of less of a less of a blocker. Um >> wait so with async does the 20 millisecond thing still make sense? >> Uh yeah so there's different versions of this. So one version is just you're allowed to vote before executing. Um and so you save like 20 millconds there basically and like the very last shred you don't execute you just immediately

vote vote on and things lead rotation become a bit easier. So so here it's like uh by moving execution off the hot path you can basically have people continuously proposing the 20 millisecond sublocks >> and like it's just it's fine like nobody gets slowed down at some point to like run the last bit of a block then vote in it then do something else. You're just like in parallel voting from executing. Um but >> so you're saying you would vote every 20 milliseconds now or >> No, no, no. You would still vote every 40 milliseconds, but right now there's like an awkward thing of like I between me receiving the like last shred of a block, I have to like reconstruct that shred. Well, so I still reconstruct that shred now to like execute it as well.

And if there's a leader rotation happening, it's kind of even more annoying. Like the next leader has to like wait to get that and then start proposing their blocks. Um, with async, that would be less of a concern. Um so so like today like blocks are only valid if they meet all these conditions of like you can't have your missing transaction fees. You can't have like certain transactions failed and or otherwise the whole block is invalid. Um and so that means for example like the next build like the next leader can't start making their blocks until they receive and execute the previous set. >> I see. I see. >> Um and so you know at least for now async execution just helps like it's really it's a marginal change today. The hope is for doing MCP type stuff it's actually like a requirement. Um so

making it the protocol now changes in market structure a tiny bit today for the the better for the most part. Um it's more just a clean cleanliness and kind of like um quality of life thing. But yeah. Yeah. So it's not a major thing today but it could be in the future. Um and that's really yeah. So MCP is basically this proposal that makes uh reasoning about transaction inclusion much easier by kind of taking away the power of block building and this execution stuff. Um and yeah so I won't go too much into the other things. Yeah. So the application control execution is that the sequence of transactions can depend on kind of the applications can choose their ordering instead of kind of the the leaders choosing ordering. Basically double zero is networking thing that should make some networking problems easier. Um we can pipeline this up even more in some

some different ways. Um and yeah different ways of charging fees that can help some of these estimation problems. So lots of stuff happening. Um a lot of stuff changes like literally every month. Um so some of this stuff might be outdated and very soon but at least at the high level picture I think is a good conceptual framework um and definitely at least lots of takeaways for for future projects. Um so yeah I'll leave it at that >> looking at the two example like big example like Ethereum are there some interesting invariant that are building like you made a you pose a really good question that all the new all the as chain grows they have to think about these things which if they're not thinking are there simple invariant uh like is it that your latency is always going to slow down because you have to

add some proportion between what are the general uh lemas or something emerging here >> right right yeah so so I think that's a good one that like latency So like optimistic latency is very hard um and that you basically always get the worst case latency that people are incentivized to give right. So me basically pushes um people making choices about state to wait as long as possible. Um yeah so so latency is one of them other invariants I mean yeah just like inclusion always gets harder right and like reasoning about so so I think one thing we think of blockchain a lot is like hey we have a fe mechanism we'll use that to meter things um I think understanding the network layer is very important um and oftent times your network layer will be

the first to go down before even the fee mechanism gets hit for example if I can dos your nodes so that they don't even hear about the high fee paying transactions I can get in right and so knowing what to do on that level is pretty tricky. It's not immediately obvious. I mean, you just need depends on your chain of how you address this. Um yeah, so maybe yeah, that like the network layer gets very hard. Um everything else once you get past number layer, you can deal with stuff inside the the protocol. Um but before that, it's pretty tricky. >> Can you expand a tiny bit on application controlled execution? What is it?

>> Yeah. Yeah. So this is uh not a fully fleshed out proposal. Um but so one example of this is this notion of um kind of MEV taxes and priority priority ordering. Um okay so say I give you uh that I I force all the transactions to be ordered by priority fee in your block. Um, and now as an application, say like I'm on an exchange or something or say I'm an AMM and I say you can only um trade like submit a trade if your priority fee is below this amount and if your priority fee is above this amount then I only allow you to like either deposit or withdraw like kind of LP funds like move like the LP position, right? All right. So, this means that

basically if I submit a priority fee above this threshold, then I'm guaranteed to like change my position in the AMM before anybody gets a trade in the AMM. >> Right? So, this is a way that the application can control its execution, the controlling ordering. Um, so that's that's like the simplest way that's fully fleshed out of how you could do it. Um there's other like feature flag type stuff you can do of like the application just says uh I mean so the way they were thinking of doing it is kind of at the level of the block builder or the the validator client. Um application like certain applications could tell the client hey I want you to order things in this way and the client would just do it in that way of like um we see that centraluler would just like have more information about what

applications transactions are interacting with and schedule accordingly. Now that's not a robust solution at all. Um, but that's at least the type of thing you'd want to implement and it's a I'd say active work in progress to figure out what's the best way to to get there. Thanks again. [Applause]