Rollups and similar L2 systems face some unique challenges in designing fair and incentive compatible fees.  L2 transactions incur costs at both L1 (such as recording data and settling transaction results) and L2 (computing and storage), and the demand at the two levels may vary independently.  The underlying costs of resources such as computation and storage will also be different at L2 than at L1. This talk will discuss issues around the design of L2 fees, based on experience designing and operating the Arbitrum One chain.

The talk will consider in detail the tradeoffs around two more specific questions: how to control the L2 base fee, and approaches to the pricing of L2 storage in a sustainable and future-proof manner.

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 Arbitrum.

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-based L2 systems, Arbitrum is the 1 with the largest and longest track record.

So arguably, we have learned more about this, perhaps, than others.

Just for some level setting, when I say fair, the definition of fair that I'm going to use is that the transaction fee for a transaction approximates the cost that that transaction has imposed on the system as a whole.

So this of course makes sense from an economic standpoint because this will align incentives well, but also I'm gonna 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 1 of the goals.

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.

But here I want to talk about what is sustainable for the long run.

And in the long run, I think that means 2 things.

1 is that the revenue has to match the cost over time, number 1.

And number 2, 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?

So you see examples of these principles playing out as I go on.

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 Arbitrum works.

This applies, the parts I'll describe should apply to most or all of the major L2s, but I need to lay a little bit of technical groundwork so that you can understand the constraints that we're under in setting these policies.

And then I'll dig into 3 particular challenges that we have identified.

I'll talk about how we are thinking about each 1, what we've done, and what we've learned.

Okay, so first, a little bit of how it works.

1 of the key components from the standpoint, from our standpoint today, probably the key component in the system is the sequencer.

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.

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 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 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.

But that deterministic nature is also going to be a constraint, as we'll see.

So this is logically what happens, but how do people find out the sequence?

First, the sequencer very quickly, after it puts a transaction into the sequence, will publish that transaction on the sequencer feed.

And if you submit a transaction, normally in less than 1 second, your transaction will be in the sequence and in the sequencer feed.

I've labeled this a soft guarantee because this is the sequencer 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 the outcome of your transaction, but others in less than 1 second.

That response time is really important to users.

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 a state-of-the-art General purpose compression algorithm and then it will take that and it will write it on to 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 and official history.

And that is the 1 that will govern what the outcome of your transaction is.

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 L2 transactions get finality kind of in 3 stages.

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.

And the guarantee is that this is the correct result of the transaction if the sequencer's 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 – there, you just wait for the L2 blocks to be confirmed on the L1.

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 2 phases are the ones that matter.

Okay, now with that background, let me talk about, let me talk about some things that, that, some complexities that arise out of this.

Actually, yeah, let me talk about sort of first, sort of 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.

And that is part of the state transition function.

1 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 transactions.

Now there are 2 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 incurred 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 Arbitrum 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.

So the state transition function will collect fees from the user and credit those to the sequencer's account on L2.

So the sequencer will be reimbursed for those costs.

Social economists, You talk about the sequencer as if it were a human being, but of course it is not.

Currently, the sequencer is a machine run by us.

And eventually, the sequencer will be a distributed system where the sequencer nodes are run by a variety of parties in our community.

Now, the algorithm, we do not trust the sequencer to decree how much it should be paid.

The sequencer is trusted only to order transactions.

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.

And so the sequencer is trusted to put transactions in order, but otherwise it's not trusted for anything.

I have a friend that's running a full RPC node that's taking about 15 gigs

Is that coming from the state transition function?

And that number will be much lower after our next upgrade, I have to say.

And that's 1 reason why we want to charge people if they grow the state.

So there's 3 economic issues or pricing issues that I want to talk about that arise out of this system and I'll go through them 1 by 1 in the rest of the talk.

First there's how do you charge for the L1 gas costs?

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.

OK, now there are a bunch of issues here that arise.

1 of the issues is spillover is having to do with compression.

So the way data compression works is you have a big 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 2 different sections in that data stream, 2 transactions that are similar, then the second 1 will compress very effectively because it can just be expressed as a diff from the first 1.

So there are obvious spillovers here because the compressibility of 1 transaction depends on other transactions.

Also, if you have multiple transactions that are very similar, the first 1 will not compress much at all, because compression runs linearly through there.

And later ones will compress much better because of the first 1.

And we need to be careful not to punish people for being the first 1.

And 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 1 here.

Interesting issue number 2 has to do with time and what information is available when.

So suppose that the sequencer gets your transaction at time T and it publishes on the sequencer feed at time t what your transaction is.

And by the way, that includes a timestamp, 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 system, 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.

This batched compressed the compression happens at time maybe T plus 2 minutes typically.

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 2.

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 3, 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 Arbitrum about this?

For the spillover and compression issue, 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 that has obtained in the recent past.

And that allows us to figure out 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.

Well there are other approaches you could take.

1 approach might be to take a larger deposit from every transaction 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 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 2 things there.

First the L2 state keeps a running estimate of what the L1 base fee is.

Every time a transaction is put on the L1 chain by 1 of our trusted contracts, it will essentially cause an update.

That will create a data point that the L2 can receive about what the L1 base fee was at some time.

It's a running average, first of all, of the past, and it typically lags by minutes for technical reasons.

So if the L1 gas fee spikes, base fee spikes, then this is going to run behind and it will be low.

If the L1 base fee dives, this is going to run behind and it will be high.

But what we really need, the thing, 1 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, 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 is given as reimbursement to the sequencer matches the total amount that transactions pay for L1 fees.

I think there's probably some room for improvement here, too.

You might have a better predictive model.

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 risk associated with increase or decrease in the base fee.

We don't know how to do those today, but we would really be interested in hearing about ways to do those things.

Like, do you see a lot of site drive transfers with update heuristics?

1 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 over time.

That gets in the issues because that has to live in the state and now The economics of that also get complicated.

I think there's a lot of room for improvement.

We have to ship something, and so this is what we've built.

The reason is because of this determinism.

We need the state 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 flow of information from the L1 chain into the state transition function to lag by an assumed L1 finality time.

If the sequencer overcollects, then the automatically adjusted correction factor will cause the sequencer to under collect for a while going forward.

If the sequencer is under collected, we don't want to put all of the extra charge on the next few transactions.

You want to spread that out over time, and you want to make the books balance over time.

Is that like a strict integral control function that guarantees that the discrepancy tends to 0?

Imagine there's an enormous base-speed spike and

Could that then mean that the system locks up because the subsequent invectors have to pay for that and they don't want to?

There's a couple things that help with this.

1 is that the sequencer can actually wait a little bit longer before posting its batches.

The sequencer has some latitude in choosing when to post its batches.

There is a trade-off because users want finality, and if you wait longer, they have to wait longer for finality.

But if the L1 base fee is really spiked, or if the L1 gas price is 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 price is high and has spiked.

It is not because of this correction factor.

The correction factor will correct back to 0 so that the book's balanced.

See all ETHconomics Devconnect transcripts on Youtube

Ed Felten — Fair and sustainable fees for L2 (ETHconomics @ Devconnect 2022)