Starknet Economics

Transcript

[Music] one one can you hear me? Okay, great. Um, sorry about the delay, some technical issues. Um, so hi everyone, my name is Au Levy. I'm head of product at Starkore. I am going to uh talk today about uh the principles for Starket fees. Now this is a 15minut talk.

So I had um a bit more of ambitious plans to present you the entire mechanism and the reasons why we would go with this kind of mechanism and not another one but I had to cut many things out of the presentation. So we will remain just with like the main principle and some idea about resource pricing and if you are interested about the auction mechanism I'm I will be very happy to talk about it with you after the uh presentation. Okay, great. So, let's start. Um, behind me there is like uh uh the screen from uh Eric Wall. Um, so I don't know if you guys know, but every time Eric is buying a new computer, he's also starting a

thread on a Twitter uh where he syncs his Ethereum node and Bitcoin node and compares those. And he started a sync uh the last one 12 days ago. I know because I met him this morning and he told me that uh it was just finished this this morning. So as you can see the synchronizing an Ethereum node is a pretty heavy operation even for a new MacBook um and at some points not always but at some point it requires like 100% capacity of the um of the CPU. So how is it related to fees or to stark net? Well, the thing is that um when it comes to Ethereum, uh this uh Pac-Man on

the side here is basically an Ethereum full node. And the way it works is that Ethereum full node needs to eat the blocks as they come. And that means that if a Pac-Man is now starting from like fresh without the knowledge of anything about the chain, it's going to be able to eat the entire chain before it's fully synced. And even if uh the Pac-Man is already fully synced and you get more blocks, you need to be able to process them. That in particularly means that when you design Ethereum, you need to take you need to consider basically not just the throughput that you as a sequencer or as a validator as a builder can provide. You need to first of all consider the throughput that a full node can process. Right? So for example, if

you think that the full node can process something like X computation steps per second, then it will mean that you will need to consider this um on your network throughput. That's very like that's basic right we all know that. So if if a full node does X computation steps per second, then if you want the N nodes to be able to synchronize in a reasonable time, you're going to have to take a factor on that, right? So for so if your uh full node sync in a t like is able to do sorry x computation steps per second, then you will have your blockchain running at a speed that is some fraction of x. And that means that and this will

affect on the syncing time right so I'll give like a very uh concrete example that is also close to reality right if you have an Ethereum full node and you say well my Ethereum full node can do about 12 million gas per second then let me have my blockchain running at a speed of about a million gas per second that's more or less the numbers that we have on the target for Ethereum 1559 today and if I just count with those two numbers and I throw away everything about optimizations. Then you get that syncing one year of Ethereum at the current speed today, which is of course faster than what it was in the past, will cost you about 36 days, which is already pretty long. So it's it's not really the

number today. And Eric was actually uh able to demonstrate a full sync in about uh I think it was 12 days. Um but but there are some factors that I'm like throwing away here and obviously Eric's new MacBook is not the is not the slowest computer on the network and those numbers always relate to the slowest number to the slowest node that you want to consider in the network. So basically what we see is that when it comes to Ethereum you are limited by a significant factor on your slowest full node on the slowest full on that you want to include which is a problem.

On the other hand, we have starket and starket is a validity rollup is alert to validity rollup and in particularly that means that on starket you don't as a full node need to process and eat all blocks. It's good enough for you to jump every time there is a new proof. This uh small little uh cube there is actually a new proof. Every time there is a new proof, you as a full node can jump over all the blocks, verify the proof and be you know that the new state that comes with this small proof is valid without running all the computation across all the blocks. Right?

So now when you think about it for a moment um you realize that the sequencer doesn't have to take consideration anymore of the slowest full node. It can actually run without full nodes slowing it down. And this is if there is one thing you should take today, it's this. In starknet, we design everything such that we reach maximum throughput and we don't have to take into consideration slow elements in the network which is an amazing capability.

Okay. So how is it related to fees? And I'll give one example and if I will have a bit more time I'll give the second one. Um so in starknet we don't look on what uh full node is capable of doing which is this x but instead we are looking on what a sequencer can do which is why and most of the time y is is aggressive and is much larger than x and then we limit our blockchain with those y computation steps per second. And in particular the synchronizing time for any full node on the network is going to be very very short. Basically just very fine proofs which takes milliseconds and independent of whatever we limited the

computation of the network. Okay. Some comments on this part. Um as a full node you will have constantly fresh proofs but you will not have the proof of the latest block at least not for now in starknet you will have a proof for uh blocks few minutes old. So for most full nodes most of the time this is good enough but we should remember that there is some uh block proof time delay that comes from the times that it takes to generate a proof uh for the block. um we target uh getting to like few minutes and maybe even subminut uh long term for uh proof

generations for blocks. Um but in any case doesn't matter if you are a full node that is capable like a sequencer or a very weak full node as a newcomer you have very easy life on starket because you can take the proofs and you immediately get or almost immediately get to the latest state. Okay, that's great. So that's the principle that we want to have and now how we utilize it in um fees. So I'll give two I'll give one major example and uh the other ones if we have time. Okay. So pricing resources pricing resources is basically the question of like okay you have many operations how do you charge users for those operations?

And because we don't have so much time I won't let you think about it but instead I will just tell you. So we have um the sequencer this is the main resource that we should uh quantify but we have three other things one is also shared in Ethereum and two that are new. The second bullet here is talking about storage. And when I spoke about proofs and how you do as a full node sync really really fast with proofs, I was a little bit lying. That's true for computation. But full node still has to eventually download and store the state of the of the network. And that means

that while we can let the sequencer get crazy and take as much computation as they can, we can't really do the same with storage because if we would that means that potentially storage can becomes uh several terabytes and then it will be harder to access for full nodes. So proofs doesn't save really all the new storage and we need to take that into consideration. That's not anything new but should remember that remains. And the last two bullets are actually new. So we have on starknet this burden. That means that for every block we need to generate a proof. So we need to take that into consideration obviously. And as long as we publish data to Ethereum as data availability layer, we need to

take also consideration a main cost which is the L1 cost. Okay. So how do we price it? Here's the main suggestion and I'm going to explain uh very very shortly why is it the case. What we suggest to do is that users pay layer one cost separately and on everything else they bid. Now how do they bid? You can partic uh a multi-dimension bidding meaning you bid on the storage you bid on the computation you bid on the proving but it's very very hard practically for everyone else like it's hard for us it's hard for users it's hard for wallet you

don't want that so instead what we will do is we will keep the payment for L1 separately but everything else all other costs all other limitation we will just fold into what we call L2 does. So I want to show how this folding um is done. Okay, this is a complex table. Take a moment and I'm now going over it. So the main resource that we care about, the major resource that we care about for throughput is uh the column that includes the sequencer. We want to make sure that users are very careful with sequencer times. So we are going to take

sequencer time as uh the component and we are going to fold all other dimensions to it in the following sense. Those are like by the way those are just examples for numbers. Those are not necessarily the most accurate numbers. It's just to show you how this is done. And then what's the logic behind pricing right? So on the sequencer let's suppose that we have uh 10 to the 7 steps and step is a random arbitrary um unit of time that we chose because this is the time that takes a sequencer to run one chyro step and what we are going to do is every time I will I will go over those examples every time uh

when we look on the prover and when we look on storage we will compare the percentage that some operation is taking to the sequencer. time and if we get that the sequencer time in percentage is higher we chose this we choose this if we get that the percentage of the operation on a different column is higher we'll ch we will just convert it to steps so in particular if I'm looking on um a new bite that people are writing it doesn't cost the sequencer almost anything on time but it does require storage so we are going to price it as one unit out of 10 to the five but we are going to compare it to sequence time. So because the difference is 100

we will going we will count a new bite as 100 units of uh L2 gas and let me just give one more example because this example is stronger on the bottom we have three different hash functions right so most of you are probably aware there is Person Ketchup and Poseidon what's interesting to see here is that Pederson and Poseidon are hash functions that are very slow on the sequencer so even that they are extremely cheap on the prover side the because they're so slow on the sequencer. It turns out that for ketchup which is terrible on the prover side it might be the case that ketchup will actually be cheaper for the network when you fold it into algaazen for example peron which is exactly what

you would expect when you fold other dimension into the major dimension that you care about. Okay. Um so I said that multi-dimension is better but it's complex. So the question is what do we lose by not going multi-dimension? Well on the usual what we will expect on the usual case is the following. We would expect that most of the time what will be congested is the sequencer and the proven storage. We will get some requests but they will not congest the network and so the pricing will be close to optimal meaning we will mostly price the sequencer. We won't reach full capacity but that's fine. We can live

with a small loss. But in the worst case it might become that in fact most of the operations are being split somehow between the sequencer the prover and storage for example and then even though the network could do three time more operations in this case we will already close the block on a third of the capacity which is not that good and in particular the more dimension you fold into one dimension the more uh you are risking throughput loss. So uh this is something that we keep in mind and we might change or update as the time comes and we see the actual uh demand.

Okay, I'm getting to the summary. I know that I don't have so much more time. So uh to summarize, Starnet is not bounded by full node computation and that means that everything that you see on the fees side we optimize for throughput and we don't need to worry to hard decentralization. This is like the bottom line. This is what we do. It affects everything. It affects the pricing that you just saw. It affects also auction mechanism. Come ask me about it later. By the way, we have a bunch of open questions. Uh if you're interested about taking part in any of uh those re those questions, any research about them, please come talk to me after. Thank you very much. Um yeah,

that's it. Thank you. Do we have time for questions? Questions? Any question? Okay. Thank you very much. [Applause] [Music]