L2 Resource Pricing, Layer 1 R&D - Day 1

[Music] hi everybody i'm going to talk about l2 resource pricing and if you're interested in a longer and more opinionated version of this i'll be doing that at the economics event on thursday at 10 15. um so what i want to do is talk do a mini deep dive into one piece of how state-of-the-art roll-up systems work and i'll focus on the part of roll-ups that doesn't depend on zk versus optimistic the part that in other words doesn't depend on how you settle transactions on to l2 i'll talk about the front end part both because that is is more common across roll ups and also because it is that it's a good basis for for then drawing out what are the resource pricing issues we might need to talk about okay so let's start here with the with this component called the sequencer this might be a centralized component it might be a distributed system but in any case its job is essentially intake of transactions either from users or trend either from eoas or transactions that come from contracts on the l1 chain so the sequencer gets a bunch of transactions that are sent to it and its job is to put those um see those transactions into a sequence hence the name sequencer so the sequencer is trusted only for ordering it can't modify the contents of the transactions if they come from eoas they're signed if they come from l1 contracts they're recorded on the l1 chain we don't so we don't trust it to do anything other than sequencing we in particular don't want to trust it to direct where flows of eth are going to go okay so its job is to put transactions into sequence then we have some kind of a state transition function which takes each transaction and is going to is going to decide how the state of the l2 should change so the state transition function is going to take in the current state think of this essentially as the the current state tree it's like the state tree of an ethereum chain so the state transition function takes one transaction takes the current state it will update the state and it will perhaps emit an l2 block different roll-ups have different different assumptions about how often l2 blocks get emitted but one thing that differs from l1 is that l2 blocks might get might get produced at a higher rate in the limit you might produce an l2 block for each transaction that comes in or anything in between that and it doesn't make sense to have an l2 block much bigger than what would be an l1 block but if you have higher throughput than l1 and the same limit on block size then you have to produce blocks a lot faster so variable block time and block time the difference between l2 designs is part of our picture here all right so at the bottom here we have the l2 blocks getting that are produced those l2 blocks will ultimately need to be settled onto the l1 chain using either an optimistic protocol or a zk validity proof i'm going to set that aside because i think that is relatively independent of the topic of l2 resource pricing at least for now okay so the sequencer produces these sequence transactions and then typically those are those are published in two ways first there is a sequencer feed this is typically almost instantaneous whenever the sequencer decides on how to sequence a particular transaction it will publish some kind of feed that people can subscribe to and this represents a soft guarantee from the sequencer that is if you trust that this sequencer feed is telling the truth about how the transactions will eventually be recorded onto the l1 chain then this sequencer feed tells you the sequence of transactions now the state transition function over here on the right is fully deterministic meaning that the the result of the state transition function depends only on the transaction that you're currently processing and the state so recursively it depends only on the sequence of transactions thus far so if you know the sequencer feed and if you trust the sequencer soft guarantee that the feed does represent what it will initiate what will it will eventually what it will eventually settle onto the l1 then you can immediately execute the state transition function for yourself and know what the result of a transaction will be and this in fact is the reason for the sequencer feed because the sequencer feed is almost instantaneous and because it allows you to deterministically figure out what the result of your transaction is if you trust the soft guarantee then you know almost instantaneously what the result of your transaction and indeed every transaction will be so that is the sequencer feed with soft guarantee then eventually typically those um a a group of those transactions will be batched together and compressed using some kind of general purpose compression algorithm and then that will be written or somehow settled onto the l1 chain today that will be they'll be written as call data eventually we hope they will be uh recorded as data blobs so this batching and compression happens in large chunks typically uh the sequencer will wait until it has a large enough batch because obviously you want to first of all you want to amortize the cost of posting a batch over more transactions and second the larger you make this thing the more efficient the trend the compression will be and so this typically happens in large chunks and so it will be minutes you can imagine five minutes in a typical setting about every five minutes some batch will be posted back onto the l1 so very different time scales here okay so this leads to sort of three different notions for finality in a typical rollup you can start with soft finality which is on the order of one second from the time that you submit your transaction so that is finality if you trust the sequencers a soft feed to be uh to be an accurate representation of what will be settled so the way you can get that soft finality is you subscribe to the sequencer feed which anyone can do you then compute the state transition function over the sequence of transactions that are in that feed and now you know for certainty what the result of every transaction will be assuming that the sequencer's feed is not lying to you the guarantee of course is it's correct if the sequencer's feed is correct the second notion is what i would call true finality which is going to be on the order of about 10 minutes so in order to get that you're relying on the sequencer recording the uh you're relying on reading the batch compressed sequence of transactions off the l1 chain that is the final official um and um version of the sequence of transactions so you read the compressed batches off of l1 you can again compute the correct state transition function and then you wait for l1 finality on that posting of the batch once you have l1 finality on that then you have finality on the sequence a finality on the transaction results follows at this point it is inevitable what the result of the transaction will be you need only to trust that the rollup protocol's settlement mechanism will work correctly so it's as good as your l1 finality assumption assuming you trust the l1 uh settlement mechanism and if you don't then why are you using the rollup and then finally you have confirmation and this is the final confirmation and recognition on the l1 chain of that inevitable result that takes hours to days depending on what kind of system you're using so there you just wait for the l2 blocks to be confirmed on the l1 and this realistically will be used only will be relied upon only by l1 contracts the l1 chain doesn't have the capacity to do the middle finality thing because it can't compute along the results of all of the transactions that's why you're using a rollup all right so those are the three notions of finality okay so now let's go back to this and think about the different time scales and think about the different ways that the different costs of executing this and what are the and what are the resource pricing issues that arise so the first thing to observe is that over here on the right where you have the state transition function this is where gas gets charged to user transactions user transactions execute on the l2 this execution of the state transition function is what knows uh first of all that the l2 transaction is valid that it has appropriate nonce and that the user has the has the funds they need on l2 to execute this transaction so this is where gas gets charged and this is where the l2 costs uh say execution gas um and and storage allocation are known down here is where the other and what's today the largest component of the cost is experienced and that is the cost paid by the sequencer to store these compressed batches onto the l1 chain right so there's a couple things that are relevant here uh which are going to drive the discussion one of them is that the l2 gas up here and the l1 gas down in the lower left those are denominated in in what amount to different kinds of gas so l2 gas of course is priced based on the conditions on the l2 chain and so if the l2 chain is busy or not busy the l2 gas price is likely to be different the l1 gas the l1 cost down here is denominated in l1 gas and the l1 gas price or base fee is going to fluctuate independently of the l2 base v and so that means that there's two different flavors of gas that the users is ultimately incurring cost in and that's going to be one of the issues the the other issue that drives this is the timing of this because remember that the state transition function is fully deterministic it depends only on the contents of that transaction which the sequencer has committed to but note that the sequencer commits to a transaction by publishing it on the sequencer feed and that happens minutes before this l1 cost is incurred so at the time that the sequencer commits to the transaction therefore necessarily committing to what's going to get charged on l2 at that time the sequencer doesn't know um what the full contents of the batch will be how well it will compress and it doesn't know what the l1 base fee is going to be a few minutes from now when that batch is ultimately posted and so that time difference the fact that you have to um commit to the contents of the transaction and therefore what it will be charged before you know everything about the cost also drives another of the interesting issues here so you might ask why do this why have these separate feeds why have this time difference the answer is user experience that users want a result of their transaction at least a soft guarantee quickly and this approach can give them that in order of one second they don't want to have to wait minutes for a batch to be posted on the l1 or even they don't even want to have to wait for an l1 block time and so that's what drives that user experience consideration is what has driven um the uh the has driven roll ups toward this sequencer approach and towards a fast feed and but that leads to that time discrepancy okay so what are issues to discuss around pricing and resource pricing here the first one goes to multi-dimensional gas the fact that some of the costs are denominated in l2 gas some are denominated in l1 gas the prices or base fees of those will fluctuate independently so we would love to have for user experience purposes transaction formats that admit multi-dimensional gas but more to the point that's relatively easy or what's relatively more difficult is to get wallets to support um multi-dimensional gas so if we had a multi-dimensional gas standard that was widely adopted by wallets and other user-facing tools then we could expose to users the idea that there are two types of gas and they could um and they could provide gas limits and uh and the usual sort of spending limit parameters that that they're used to using for l1 gas so that would be nice but regardless we have to live with a one-dimensional gas user experience for now and so cramming a two-dimensional gas dynamics into a one-dimensional user experience is a hassle there are different ways of doing that different roll-ups do it differently depending on trade-offs between developer experience user experience and security and there's a bunch of interesting considerations there about how that's done and that's something we're going to continue to need even after a world where we have two-dimensional gas supported because some users and tools are going to still be in the legacy user experience on the legacy formats that's number one okay issue to discuss number two is about how to price l2 gas so you might think l1 gap 2 gas should be priced just like l1 gas just do the eip 1559 thing and that is i think almost the right answer but l2s do have some different considerations there's different differing block times for example it's more natural in l2s to to run the pricing based on timestamp rather than blocks i think that's number one number two is l2s have more flexibility to absorb larger bursts of traffic so with l ones you want you want it to be the case that the burst of traffic you get within any one block is not too large because you need uh miners to be able to or validators to be able to keep up with each block but in l2s you can allow larger bursts you can absorb larger bursts because the natural units of computation or the natural units of um of response work differently in particular you you might be able to absorb a burst within you might say if 1559 tries to keep the amount of uh activity in each block from not being too high not being more than a factor of two above the target above the average um in an l2 you might be able to accept a much larger burst over a lot over over the same time frame as long as the burst is not too large over the time frame of say one batch or um or of l1 finality time and so there's more flexibility there there's some additional considerations as well and then finally the last issue to discuss is l2 storage pricing l2s have the same kind of issue of storage growth and therefore of a desire to price storage in an independent and adaptive way same issues as l1 except if an l2 chain runs n times faster than the l1 chain then its state is going to grow end times faster unless you do something in either design or in pricing and so as an l2 designer i am incredibly eager to see everything that reduces storage growth state to see statelessness to see state exploration and so on um and i think blobs are a part of that story as well but regardless of that or at least until we have it uh we need to talk seriously about l2 pricing and so i think the conversation there starts with the things that vitalik has written about storage pricing on l1 and then the question is um should we be pushing to do essentially that or should we be doing a bit more so these are all the things i hope that we get to talk about later in the day thanks [Music] you