Fair and Sustainable Fees for L2

Transcript

[Music] good morning everyone thanks for your time this morning i want to talk about fair and sustainable fees for l2 and i'm going to come at this based sort of on first principles but from a pragmatic point of view and i'll be talking as well based on our experience in arbitram on i'll talk about some of the decisions that we've made some of the preliminary things that we're doing and what we've learned from doing it i think it's fair to say that of the ethereum l2 systems arbitram is the one with the

largest and longest track record so arguably we have learned more about this perhaps than than others but i'll let you be the judge of that okay fair and sustainable fees what do i mean um just for some level setting when i say fair the definition of fare that i'm going to use is that the transaction fee for a transaction approximates the cost that that that transaction has imposed on the system as a whole right so this of course makes sense from an economic standpoint because this will align incentives well but also i'm going to treat that as part of the definition of fairness we don't want to systemically overcharge or undercharge certain types or categories of transactions so as an example some

mechanisms such as ones where people pay extra for better ordering in the transaction sequence it may not be compatible with this principle because you're charging more to a transaction because it's more ordering sensitive as opposed to because of the impact it has on the cost of the system so i'm going to make this one of the goals that so we're going to be thinking a lot about costs and how to fairly allocate costs among the different transactions and then sustainable i'm talking about fee policies that can be maintained over the long term of course an l2 system could strategically underprice to try to

gain market share something like that people may do that but here i want to talk about what is sustainable for the long run and in the long run i think that means two things one is that the revenue has to match the cost over time number one and number two we have to think about the long term about what is the sort of long-term behavior and trends and the evolution of the system that will be induced by how we price and we need to think ahead so you see examples of these principles playing out as they go on all right so in order to lay the groundwork so what i'm going to do is i'll talk i'll give you a little bit of groundwork about how a system like arbitram works this applies the the parts i'll describe

should apply to uh to uh most or all of the major l2s but i need to lay a little bit of technical uh groundwork so that you can understand the constraints that we're under in setting these policies and then i'll then i'll dig into three particular challenges that we have identified i'll talk about how we are thinking about each one what we've done and what we've learned okay so first a little bit of how it works one of the key components from the standpoint from our standpoint today probably the key component in the system is the sequencer so the sequencer is a component it is currently a centralized system it will eventually be a distributed system but

i'll treat it as a single box on the diagram for that purpose for our purposes the job of the sequencer is to take in a series of transactions that arrive from users or from l1 contracts they come in via remote procedure call and the sequencer is going to put them into some kind of order the sequencer is trusted to do this to establish order but it's not trusted for any other purpose we don't trust it to influence the prices we don't trust it to determine which transactions are okay and not okay all it does is put them into sequence now there's a backup mechanism that you can use if the sequencer tries to censor you i'm going to ignore that here for simplicity so let's assume that there's a well-behaved sequencer and the sequencer

is instructed to follow a first come first served policy in sequencing the transaction so the sequencer decides on this it will inform others and then the second important part of the system is the state transition function this is a deterministic function which takes the next transaction in the sequence and it takes the current state of the l2 system and it deterministically computes some updates to the state and then perhaps emits an l2 block so the determinism deterministic nature of the state transition function is really important what this means is that the outcome of the transaction both what l2 blocks have been emitted and what the

state is depends only on the contents of that transaction and the contents of all previous transactions in the history plus the genesis state there's no other information that comes into this the state transition function can't look at anything gather any information it just takes the transaction and the state puts out a new state and and the l2 block the fact that this is deterministic is really important because it means that if you're a node in the system or any participant and you know the transaction sequence then you can compute exactly what the state of the chain is you don't need to rely on anyone else to know the chain state all right but that that deterministic nature is also going to be a constraint

as we'll see okay so this is logically what happens but how do people find out the sequence they find out by two ways first the sequencer very quickly after it puts a transaction into the sequence will publish that transaction on the sequencer feed this is a feed the sequencer publishes anyone can subscribe to it and if you submit a transaction normally in less than one second your transaction will be in the sequence and in the sequencer feed this is i've labeled this a soft guarantee because this is the sequencer uh promising you that in the eventual final feed that it publishes will be consistent with this so if you believe that sequencer is being honest

to you about its intentions then you can trust this and you can immediately determine the state not only of your the outcome of your transaction but others in less than one second that response time is really important to users but that's of course a soft guarantee and it's important that we can do that faster than an l1 block for user experience reasons the sequencer then every several minutes will then take a subsequence sort of the next bunch of transactions that haven't yet gone through this process it will put them into a batch it will compress the batch using the state-of-the-art uh general purpose compression algorithm and then it will take that and it will

write it onto the l1 chain currently as call data we hope very soon as shard blobs and so once you've written that onto the l1 chain that is the final in official history and that is the one that will govern what the outcome of your transaction is so that will be consistent it will be the same ordering as the sequencer feed if all is well but this is the thing that you know that doesn't have caveats on it then also finally there's another piece of the system that takes these l2 blocks and settles them to the l1 that's interesting enough but doesn't really drive the conversation we're going to have today so i'm going to ignore that part of it

okay l2 transactions get finality kind of in three stages the first stage is soft finality this is the way you can get soft finality for your transaction is you subscribe to the sequencer feed whenever you see a transaction on the feed you compute the state transition function for yourself asynchronously from everyone else now you know the result and the guarantee is that this is the correct result of your trans of the transaction if the sequencers feed is consistent with what the sequencer ultimately publishes and the protocol is designed so the sequencer has the power to make its eventual publication consistent with its feed if it wants to the second stage is true finality and this takes order of 10 minutes basically

the l1 finality time so to get that you read the compressed batches from the l1 you decompress them compute the state transition function for yourself or rely on some node you trust to do it and then you wait for l1 finality on that batch because once that has l1 finality then you really know what the result of the transaction is and at that point everyone in the world knows the result of the transaction except the l1 ethereum chain doesn't because the l1 ethereum chain cannot do that step of applying the state transition function because it doesn't have the computational throughput to do that that's why we have an l2 in the first place so then confirmation which takes hours to days depending on which system you're in that is going to um

there you just wait for the l2 blocks to be confirmed on the l1 now that is an inevitable process if the protocol works correctly it will inevitably commit exactly confirm exactly the blocks that you got in the finality stage or if the sequencer was honest those will be identical to the results you got in the soft finality phase so from this from our standpoint of our discussion today really the first two phases are the ones that matter okay now with that background let me talk about um let me talk about some things that that some complexities that arise out of this um actually yeah let me talk about sort of um first sort of what are the where are the costs and the fees so first up

here on the upper right l2 gas is charged here this is where we charge users for their transactions where we collect the fees it's we collect eth on l2 for those fees and that is part of the state transition function one of the things it does is it deducts the fees from the sender of the transaction based on a computation that the state transition function does to determine what those fees should be and this is important because of the deterministic nature of the state transition function that means that the fees can only depend on the contents of this transaction and any information that the sequencer attached to it and then previous

okay now there are two two sources of cost in the system there are l2 costs that are incurred by nodes and those are basically the costs for nodes in the system to compute the state transition function and to maintain the state and so basically the cost of a transaction will be some cost because of the computation that needs to be done in the state transition function and maybe some additional cost if that transaction causes the state to grow but there's also l1 gas cost which i've drawn down here which is incur paid by the sequencer and that is paid because the sequencer has to post these transactions on the l1 chain and therefore it has to pay l1 gas as of yesterday the arbitrarium

sequencer was the largest buyer of l1 gas on ethereum that's not true every day but i believe it was true yesterday so this in practice is the largest component larger component of the cost it typically is around two-thirds of the cost of a transaction although that may vary up or down depending on the on the nature of your transaction so most of the cost is over there on the lower left paid in l1 gas yes ah yes so the state transition function will collect fees from the user and credit those to the sequencers account on l2 so the sequencer will be reimbursed for those costs

yes please no the secret yes currently the sequencer is a machine run by us and um eventually the sequencer will be a distributed system where the where the sequencer nodes are run by a variety of parties in our community right now the algorithm we do not trust the sequencer to decree how much it should be paid the sequencer is trusted only to order we run it yes correct right or to put it another way we do not require our community to trust us to run the

sequencer honestly right this is all about getting trust from the users of the system right and so the sequencer is trusted to put transactions in order but otherwise it's not trusted for anything okay yes that's coming from the state that's essentially the state and that number will be much lower after our next upgrade i have to say but that is the state right and that's one reason why we want to charge people if they grow the state yeah there's three economic issues or pricing issues that i want to talk about that

arise out of this system and i'll go through them one by one in the rest of the talk first there's how do you charge for the l1 gas cost there's issues of fairness issues of incentive compatibility that are interesting i'll talk about how we do congestion-based pricing of the l2 gas and then i'll talk finally about the issue of storage bloat how we keep the storage from getting very large in a way that's really unpleasant how to think about that okay first charging for l1 gas costs okay now there are a bunch of issues here that arise one of the issues is spillovers having to do with compression right so the way data compression works is you have a big blob block of transactions that come from a lot of different people and modern compression

algorithms basically look for similarities between different parts of that data stream and if there are two different sections in that data stream two transactions that are similar then the second one will compress very effectively because you can it can just be expressed as a diff from the first one all right so um there are still obvious spillovers here because the compressibility of one transaction depends on other transactions also if you have multiple transactions that are very similar the first one will not compress much at all because compression runs linearly through there and later ones will compress much better because of the first one and we need to be careful not to punish

people for being the first one so this is a kind of interesting thing there's an interesting theoretical question here but then of course we have to do something practical i'll talk in a minute about what we do but that is interesting issue number one here interesting issue number two has to do with time and what information is available when suppose that the sequencer you gets your transaction at time t and it publishes on the sequencer feed at time t uh what your transaction is and by the way that includes a time stamp and there are methods to keep the sequencer from messing with the timestamps very much but at time t it commits to the transaction and now in the logic of the the transaction is known the state

transition function computed from it is deterministic and so whatever you compute the fee is going to be it can only be based on information known at time t otherwise this process isn't deterministic and you don't get fast response time all right some of you see the problem already this batched compressed um the compression happens at time maybe t plus two minutes um typically right so at the time that your transaction is put into maybe appended into a batch that's being built the rest of the contents of the batch are not even known so you don't know what's going to happen in the compression at time t because that will only be

evident or completely evident at time t plus two but then after that compression has happened the sequencer will submit a transaction to the ethereum l1 chain and it might take say a minute for that transaction to get on chain and at that time at t plus three only then do you learn what the l1 base fee is that this transaction is going to pay so you don't know how well it will compress and you don't know what the l1 base fee is going to be at the time that you commit to what that transaction is going to get charged and those time issues are the other thing that we need to deal with okay so what do we actually do in arbitram about this for the spillover and compression issue

these these by the way are both really open questions our solutions here are the best that we could come up with but they're clearly not they're clearly i think far from optimal so for spillover and compression we use a heuristic estimate of the relative compression friendliness of each transaction that is we try to estimate how much it contributes to the overall compressibility of a batch of typical transactions according to this heuristic it's a very rough heuristic but it's better than nothing and then we also keep an adaptive estimate of the overall compression ratio that gets achieved by looking at the compression ratio of that has obtained in the recent past

and that allows us to figure out sort of how much savings there is from compression and then this heuristic tells us sort of how to allocate those savings among the different transactions that are in the batch this heuristic has to depend only on the contents of your transaction so that it can be known at time t so we do this and well the results are what they are you can't see well there are other approaches you could take one approach might be to take a larger deposit from every and then give a refund later if it turned out to be compression friendly

then you could do it based on the actual contribution to compressibility although even how to define that and how to make that incentive compatible is a kind of interesting theoretical problem we did not go with that approach we went with this upfront heuristic approach but i think there's a lot to explore here against this problem and this is something that all l2s that do this kind of fast finality and compression are going to face the other question the other issue is the early commitment that you have to commit early to what you're going to charge someone and we do that and we do two things there first the l2 keeps a running estimate of what the l1 base fee is

every time a transaction is put on the l1 chain by one of our trusted contracts it will it will essentially cause an update it will that will create a data point that the l2 can receive about what the l1 base fee was at some time now that is a lagging estimate it's a running average first of all of the past and it typically lags by minutes for technical reasons but it's at least a running estimate so if the l1 gas fee spikes base v spikes then um this is going to run behind and it will be low if the l1 base v dives this is going to run behind and it will be high but what we really need the

thing one thing we really want is for this to balance out over time the other thing that we do is we keep an automatically adjusted correction factor to correct for over or under collection over time you might think that you can keep a running base fee estimate and that you can make that average out over time because but that's only true if transactions come in evenly spaced over time but in fact when the base fee is higher you get fewer transactions and when the base fee is lower you get more and so we actually need to have an automatically adjusted correction factor then make sure that the books balance over time that the amount that is collected and sent as given as reimbursement to the sequencer matches the total amount that

transactions pay for l1 for l1 fees so this is what we do i think there's probably some room for improvement here too you might have a better predictive model we don't predict we just keep a trailing average based on measurement and you might also imagine trying to create some sort of market mechanism by which we could externalize the the risk associated with increase or decrease in the base fee those would be interesting things to do we don't know how to do those today but we would really be interested in hearing about ways to do those things it is not no

no um it's a relatively cute crude heuristic one of the things it uses is how compressible is this transaction just considered as a transaction just considered alone another thing that we are likely to do is have some kind of simple baseline dictionary and things that have patterns in that dictionary will get more credit and that we might adjust over time but there's a worry about the sort of trustlessness of that process right i mean there's a bunch more things you could do to try to maintain you could try to maintain compression state that gets in the issues because that has to live in the state and now the economics of that also get

complicated so there's a lot of complexity here i think there's a lot of room for improvement we have to ship something and so this is what we've built yes sorry why is it leg by minis yes so so here's the fundamental reason the reason is because of this determinism so we need two things we need that um we need to stay transition function to be deterministic and the sequencer needs to have enough control over the transaction sequence

that it can keep its promises about ordering and that means in practice that anything that comes in from the l1 chain that will be encoded in a transaction has to lag by the l1 finality time otherwise the sequencer could get burned by a l1 reorg and that causes basically the the flow of information from the l1 chain into the state transition function to lag by the l1 by an assumed l1 finality time so order of 10 minutes in the back over time yeah if the sequencer over

collects then the secret then um then the um automatically adjusted correction factor will cause the sequencer to under collect for a while going forward yeah the the goal is long-term balance we don't want to we don't want to put if the sequencer is under collected we don't want to put all of the extra charge on you know on the next few transactions you want to spread that out over time and you want to make the books balance over time yes but essentially the opposite imagine they don't want to the price will go up

some there's a couple things that help with this one is that the sequencer can actually wait wait a little bit longer before posting its batches the sequencer has some latitude and choosing when to post its batches there is a trade-off because users want finality and if you wait longer there um they have to wait longer for finality but if the if the base fee l1 base fee is really spiked or if you know if the l1 gas price has really spiked and you have to give a large tip in order to get your transaction in then the sequencer will actually wait a little bit longer so the sequencer will on average pay less than the sort of integrated l1 gas cost over time because it will withhold its

l1 transactions for a while when the when the price is high and has spiked it is not because of this correction factor right the correction factor will correct back to zero so that the book's balance the sequencer get the amount the sequencer gets is the amount of is basically the amount that it's paid plus a small increment no those are typical times yes let me move on to the next issue which is compression pricing of l2 gas right so l2 gas like like l1 gas um each

transaction uses some amount and in fact in our uh in the arbitrary nitro version uh we use exactly the same accounting of gas that ethereum uses just like on ethereum when there's high demand for gas we want to raise the price so that the demand and the capacity balance out over time okay so how do we do this well the first question you might ask is why don't we just use eip1559 we like eip1559 we think it's a great solution for ethereum but it's not quite right for us and that's because of some differences which i'll go through in a minute so what we do is one five five nine style but a little bit different because of

these differences so here's here's some differences that i think are relevant for this the first is because of the design of the system kind of the fundamental unit here is a transaction rather than a block so we don't do it per block transactions are time stamped in seconds and the time stamps advance in a way that is more continuous than on ethereum that is um right it's so it's more continuous the time stamp doesn't jump at the beginning of a block and by a exponentially distributed but unpredictable time they the timestamp of the transactions are spread out more over time the sequencer has a limited ability to manipulate the

timestamps and we don't want that we don't want the sequencer to be able to boost its fees much by by by tweaking timestamps a little bit forward or backward or trying to cluster them or something like that we run nodes closer to full speed than ethereum does ethereum runs say a geth node at only a small fraction of its capacity for good crypto economic reasons we run closer we don't run it we don't run at full speed but we run closer to full speed meaning that a node is spending more of its time computing the state transition function than an ethereum node would be and that puts some constraints because if traffic is coming in above capacity we need to uh we need to be more careful

and then finally nodes can run independently because of determinism nodes don't need to synchronize with each other through some protocol they can all run independently we don't need to synchronize and that means it might be okay if slower nodes fall behind a little bit for a short period um so all those things are differences okay so what do we do yes because of that unsynchronizing can then does that give the ability for notes to then have lower bandwidth over time so the difference is really kind of in surge capacity right we need to make sure that over time the amount of load on the system is low enough

that a typical node can handle it but there may be differences in surge capacity that is if there's a burst of traffic it may be that some nodes that some slower nodes or lower bandwidth nodes will fall behind a little bit for a little while but we need them to be able to catch up it needs to be only a surge right we need to make sure that we are not running above the capacity of the minimal node for very long and that if we do go above capacity that there will be enough of a lull that they can catch up right that's basically the principle but unlike ethereum where you want to be able to do that before before the next block we can we can afford to let slower nodes fall a little bit behind over longer time

periods uh you put the sequencer has limited ability to manipul timestamps and brackets could you elaborate it a bit more sure there are consistency properties on the on the sequencers timestamps that get enforced they can't go backwards um and so on and when the sequencer posts to the l1 chain there are some checks that are made that the time stamps on uh on things are um are consistent and haven't jumped by too much and so on uh this is actually complicated um so i didn't want to go into it in detail

but there are some checks the sequencer has some power to back date or forward date the timestamps on transactions timestamps can't decrease in the transaction sequence and but there are some checks to make sure that they don't get too far behind or too far ahead well they don't get ahead of real time and that they don't get too far behind so what do we do here what we do is what is what we call the gas pool algorithm but you might think of it as slow one five five nine that is it's like one five five nine except the time constants are longer so first we define a speed limit measured in gas per second this is like the equivalent of the gas limit so this is the maximum sustained average speed that a minimal node can do

right so the minimal node can sustain this much speed and so if we always ran with exactly that much gas per second then the minimal node could keep up comfortably um just like in one five five nine we're going to go above this sort of average target usage for short periods okay so that's so we have the speed limit which is kind of like the average gas limit we have this notion of the gas pool you can think of this as a tank of gas that is available to transactions and so it holds between zero gas and some amount max gas and whenever a transaction consumes l2 gas that gets subtracted from the gas pool and every time the clock ticks one second forward we add

uh we add a speed limit amount of gas to this so it fills at the rate of the speed limit it empties according to consumption and you can think of this sort of as a reserve capacity that can deal with surges and so the amount of surge that can happen is limited by max gas and in practice max gas over speed limit is around 10 minutes what that means is that you can have a surge that is say double the speed limit that lasts for 10 minutes we then run all the transactions in sequence in order as long as the pool isn't empty if the pool isn't empty there's if the pool empties there's a circuit breaker that triggers and we have to reject some transactions

but we adjust the base fee based on gas pool fullness 1559 style roughly so if the gas pool is entirely empty we will add 0.83 percent of the current gas pool per second if it's entirely full we'll subtract 0.83 percent and it's a linear interpolation in between why 0.83 percent well if you multiply that by 15 seconds you get 12 and a half percent which is a 1 5 5 9 rate so what this means is this won't change faster than people expect things to change under one five five nine which means people who write their code assuming one five five nine should be fine here because the rate base fee won't fluctuate faster than that

it can be empty because if transactions come in and are using more than the speed limit per second over a sustained time the pool will gradually decline so let me actually show you an example that maybe this will be clear in this example okay so we deployed this back in august and here's what we learned it worked okay but there were two problems the first it was slow to get started and i'll illustrate this uh with a story i have a graph here of time on the x-axis and the gas pool fullness on the y axis the blue line here is the full is the full gas pool um the line here in the middle is half full and we're going to decrease the

base fee if we're above half full and increase it if we're below and but you know by an amount that's linear in how far we are from that center point all right suppose that a surge comes in and we're getting traffic which averages one and a half times the speed limit over a period of time and so the gas pull fullness over time will go down right because on average every second we subtract one and a half speed limits for transactions and add just one speed limit and so the gas pull fullness will go down right and if if the traffic is one and a half times the gas limit then after 10 minutes we'll cross that center line and at that point the gas fee will start to go up

right and so when i say this is slow to get started there's really two reasons two things happening one is you and i can look at this curve and say look we're over capacity maybe we should start boosting the price but the algorithm will not do anything until that red curve crosses the midpoint and only then will it start its exponential increase and of course exponentials are relatively slow to get started and it looks like they're slow to get started and then they accelerate right so we can have an over capacity situation for a long time before we even start to move the base fee but also remember that l2 base fee is maybe a third of the total cost of the transaction so the

thing that we're boosting the price of is only a third of the total cost and so it has only a third of the incentive effect that you might expect and so we need that exponential to grow a fair amount say when that doubles then it's still only half the total cost and so as the exponential starts climbing its slow climb it doesn't really bite very much in terms of incentives for a while and so what we found is that when we had a surge that was sustained like this the system was relatively slow to start adjusting the price the other problem which is really an another version of the same problem is it tends to overshoot

so imagine a story like this where we have a surge it goes below half the price starts to escalate and either the surge subsides on its own or else people respond to the base fee boost we don't really know which but anyway the traffic goes down and the gas pool starts to refill now when you're on this upward climb over toward the right side here you and i would say well this looks pretty good we don't need to boost the price anymore but since we're below half we keep boosting the price we have boosted the price the exponential looks steep now and yet we're still continuing to go up and up and up even though it looks like it looks to our eyes like the problem has been solved so it tended to overshoot which meant when we had a surge and the base feed boost happened

it tend to tended to raise the base fee above where it looked like it really needed to be before things settled down so the fix for both of these is to say wait a minute we know about control theory let's think about this from a control theory standpoint control theory would say we should mix in a derivative term a term that looks at the derivative of the gas pool fullness and incorporates that so the way we do that is to have a sort of running average of what the gas pool usage has been over a time scale of about one minute and then that pulls up or down on the base fee depending on whether that whether that usage over the last minute running average is above or below the speed limit

and then the gas pool fullness pulls up or down as well by a smaller amount so the maximum change is still bounded by the one five five nine rate but these two factors pull polls separately that means that when things start heading down there will be something trying to pull the base fee up almost right away but of course because the gas pool is relatively large there'll be this other component saying don't panic we have a lot of gas left and but this will cause a faster reaction the other thing we do is we set the gas pool target the point at which we start escalating not at half full but at 80 percent full so we made this change a couple months ago and it seems to work really well this algorithm seems

in practice to do just about what we would like to do if there's a little surge the price will just inch up a little bit the base fee and then it will go back down if there's a big surge it seems to react in a reasonable way it will raise the base fee a bit it will generally stabilize as as the um as the gas pool starts to climb out of the trough and um this seems to behave really well we get the incentives uh that we get the behavior that looks to the eye uh relatively healthy and we get we don't get the huge spikes in base fee that we got before because of the overshoot so we're pretty happy with this obviously there's room for improvement here let me talk about the third issue which is storage bloat

okay storage economics first in ethereum storage is forever if you deploy a contract if the contract writes to storage ethereum the ethereum model says that um you says that nodes need to keep that storage forever just in case uh it matters later and that means your storage only grows and grows and grows there's that's one issue the second issue is that the fee for storage allocation is collected up front when you allocate but the cost is imposed on all nodes forever that means you don't forever is a long and you don't but that means you don't know how many nodes there will be or who they might be in the future the good news is moore's law helps

moore's law allows us to discount those future costs pretty rapidly but still this is an issue the cost function of that is what is the cost of running a node depending as a function of the of the size of storage is not linear it has steps in it and the reason for that is each storage technology will scale up to a certain capacity and above that you need to switch to a different storage technology that's more expensive and when that happens two things happen first of all the cost function takes a step upward and second people who already have a sunk cost in equipment with the old storage technology they can't run nodes anymore and that drives you towards centralization so both of those are things we want to

avoid and that so that's a complication because they're like cliffs we want to avoid going over in terms of the storage size storage can be hoarded right if storage is cheap now and it's going to be expensive in the future people can grab storage now allocate it and hold it and then they'll be able to use it later and so we should expect hoarding behavior if um if it's incented and then finally if you aspire to run a chain that is faster then your storage will bloat faster uh if arbor trim is running at 10x the capacity of ethereum then our storage will bloat at 10x the rate of ethereum's storage and our problem will be 10x worse but actually more than that because of the nonlinear cost function

is this a bubble that can burst a complicated question there are a bunch of things that are happening and i'm going to talk about two things one is technical changes in ethereum that may come that uh help to mitigate this problem in particular the storage's forever issue could be addressed by changing the model so that storage is not forever or maybe storage is forever but only if you keep paying that may change i'll talk a little bit about the prospects for that how that might change in the prospects for it in a minute preliminary approach so what can you do about this well you can change the model but we want to remain compatible with

ethereum as long as we can ethereum will probably change their model but it's frankly not close to the front of the queue in terms of changes for future hard forks so ethereum may change this in a few years we might need to change it sooner we'll see the other thing we can do is price storage right eventually if there's not a technical change to reduce storage growth the the other option is pricing so let me talk about storage pricing and vitalik has written some about this issue and i'd recommend his writings i'm going to sort of build out a little bit more a concrete model so here's one way to do it and this is sort of our preliminary thinking i'll emphasize we're not doing this currently or yet

but this is our thinking about where we may have to go first you set a storage size target which is defined something like this t0 is an amount of storage that a minimal node can comfortably hold now at time zero and then you're going to grow that exponentially uh because you're assuming a moore's law curve so that alpha defines sort of what moore's law growth rate you're assuming right so a nominal node will be able to hold more in the future than it can now and thank goodness for that because we'd be in big trouble otherwise right and so generally speaking we want to restrain the rate of growth of storage to be roughly the rate of growth of storage capacity as defined by this moore's law curve so this is how we

define we set a storage size target and then we have a pricing algorithm which uses the exponential pricing mechanism which vitalik has written about the justification for it but it looks roughly like this that the price is some base price which is relatively low times a term that's exponential in how far over the target you are so if you're below the target storage is super cheap if you are above the target then the price goes up quickly so the equilibrium here is one where the storage usage s is runs parallel to the growth in the target capacity and the distance vertical distance

between them is equal to the log of the equilibrium price so you have some demand curve for storage which may change over time and what this gives you is a price that's relatively stable over time and how stable it is depends on how you set this beta parameter but the equilibrium price over time is basically the um or the the capacity is close the usage is close to capacity and it's over by the log of the equilibrium price and you know because log is a nice function it's close to the target and so that means that unless people are willing to pay an astronomical amount for storage or even if they are actually that a nominal node will be able to hold all of

the storage within this model so this is kind of the first thing you might try to do but there's a problem with this and the problem is hoarding if we start below the target if storage use at time zero is below the target then the price of storage is very low and it's very low until the storage usage gets up to the target or indeed until it gets up to equilibrium and so this will induce hoarding behavior rational parties as soon as you turn this system on will grab as much storage as they can while it's essentially free and you will almost instantly get to get up to that capacity curve and so we don't want that so instead what we want to do is release the initial surplus storage the difference between the initial storage level of the

system and the target we want to release that into the market more slowly gradually and a way to do that is to modify the price um uh the um the target function so that in addition so that you take the initial target which is the true capacity of an assumed and you subtract off a term which is the storage you're holding out the initial surplus that you're holding out and the amount you're holding out decreases exponentially over time reflecting that release gradual release of that held out storage into the market so this is what we suggest this is really sort of back of the envelope economics and there might be better ways of doing this we would really be interested in understanding

better ways of doing this i hopefully you can understand the constraints and the motivations but there might be better ways ah all of these fees in our system are paid in eth um and so we don't have a separate coin that's used to uh to price we don't have a separate coin at all but uh in particular relevant here is that there's not a separate coin that the stock that these fees are denominated in they're all denominated in east potentially impacts the price it might impact the price of eth that's right would it make sense for us to tokenize

that's a complicated question um and it's one that my lawyers advised me not to answer so better yet maybe we could change the model the fundamental execution model of ethereum to try to reduce the storage footprint and there's a bunch of things that may happen to do that on their storage one thing you could do is what you could say first of all first thing to note is that regardless of what you do the storage footprint will always at least be proportional to the amount of current or recent activity because there's some working set that needs to be kept around in order to be able to service the things that are likely to happen next you could change it by adding storage rent so you have to pay rent or do

something that has an ongoing economic cost in order to maintain your storage then you're going to delete the storage if the rent isn't paid that is a big change in the in the model though because users of adap may worry that their state within that dap will evaporate if someone else doesn't pay rent you could try to reclaim or archive unused storage you could say if storage isn't touched for a year we'll delete it or more likely we'll archive it and replace it by a cryptographic commitment to it and then anyone can reconstitute that storage by providing it back and the system checks that against the cryptographic commitment that's the sort of that that there are live proposals to do that you could try to create stronger incentives to de-allocate but you have

to be careful because incentives to de-allocate make hoarding more attractive or you could switch to a multi-chain situation that is if one chain has its storage sort of maxed out and the price of storage is higher there now it now becomes attractive for someone to move a new application or new activity onto a separate chain which has its own low storage price right with separate chains there's separate sets of nodes and so those because of this because of the step functioning cost you're better off so into the multi-chain future if i had time for a fourth for a fourth topic and if i had better ideas about it

i would point to multi-chain the economics of multi-chain systems as relevant different chains you may have a main chain that has a higher cost you may have various chains off on the side with lower cost but more friction or higher cost to interoperate with the main chain and it's interesting to think about the economics of that and what you can do what you might do to incent people to move over onto another chain this of course connects with technical questions about cross-chain functionalities and bridging tons of interesting stuff there but don't have time for it okay that's all thanks very much do we have any time for questions remaining okay great thanks [Applause]

hi hi ed um so you mentioned you arbitrage might make changes before ethereum does just because of how things develop but if you do things a certain way and then that diverges from how ethereum does it uh so do you have any thoughts on how you'd handle that absolutely yeah so we are more likely to adopt a change if we think ethereum is likely to adopt the same change in the future right because the considerations here are if we adopt some change right we want to do it in an ethereum style and we want to take advantage of the ethereum brain trust the community that has thought a lot about these issues so we're not likely to do something that's different from what ethereum is contemplating the question is if ethereum is considering something if there's a well-vetted eip

that will probably eventually be included in a hard fork but you know not uh we would think about adopting that and then there are three outcomes right the best outcome is ethereum later adopts the very same thing the second best outcome is ethereum doesn't adopt it doesn't do anything conflicting but the worst thing that could happen is ethereum then does something that is in active conflict with the thing we adopted and we and we very much want to avoid that so we would be in dialogue with the ethereum community and the people who make decisions in ethereum to make sure that if we do something that we can stick steer clear of conte of conflicts

it is an interesting important issue but given that we expect to feel feel the pressure on some of these issues faster than ethereum and also that we are able to um to move faster than ethereum can to make changes not vastly faster because you know ethereum is slow because ethereum has a huge responsibility to its users and its community right we have a similar responsibility not as large because we don't have as much value on chain or as many as big a community but we also have a similar um responsibility so you know we for us the best situation would be to be ahead of a theory a thing that ethereum

is going to do but given the realities of hard fork politics we'll we'll do our best to navigate this yes so understanding that the objective where would be trying to minimize the the cost of the transaction in one yeah could it make in a scenario that you have even more fees in arbitrary than in ethereum or how can the manager can be even or it will be more secure in some way in terms of the fees could yeah could our fees be more expensive um i think really the only way that could happen is if we have a much higher level of congestion than ethereum has um so right now the biggest component of our

fees is l1 data costs so because of the compression and because we have some freedom to to vary the timing of when we post batches the sequencer posts batches on the l1 the l1 call data costs are substantially lower than on ethereum compression is the big win there so that part will always be significantly cheaper than ethereum if ethereum adopts changes like eip-4844 proto-dunk sharding or dunk sharding our fees will go our l1 gas cost will be even much lower than that so we're confident that the l1 call data portion of the fees will always be

significantly lower than on ethereum so the other component is basically the congestion driven gas component and we will have a higher gas capacity a higher speed limit or gas limit than ethereum by a substantial factor that's going to change over time that that gap will grow over time it certainly would be possible that if our say gas limit were 20x ethereums but we had 25x the demand that um that our fee would be higher that would only be the case if people find it more attract you know economics says that that's only that situation will only persist if people if the if the higher fee was worth it somehow

right um but i don't think that's likely to happen right i think i think with equal fees and equal latency and so on people would prefer ethereum and but a big part of the value proposition that we provide is is lower fees you know that said supply and demand are what they are and if there is much more demand for arbor trim than for ethereum then the prices will be higher um that's not really in our control i don't think that will happen that's a lot of time thanks everyone