Understanding Rollup Economics from First Principles

In this article, we look at rollups from a "system" perspective, focusing on their overhead, benefits, and fees. Running a system incurs overhead, which act like "energy sinks" where value flows from within the system to the outside. On the other hand, the system will also gain benefits, which are "energy sources", and value flows from the outside of the system to the inside.

The fee bridges the "energy source" and the "energy reservoir", transferring value between the various components of the system so that each component is properly fulfill its function.

For example, an article I wrote before In the article about EIP-1559, I explain how to break down the transaction fees paid by users:

- Part of the cost of packaging transactions is owned by the operator: in the case of the PoW base layer, the miner's fee is compensation to the miners to hedge against the increased risk of uncle blocks. This fee covers the cost of issuing blocks to operators, making them part of the network. And this is currently the default when you send a transaction in 1 or 2 Gwei to pay the fee.

- The rest of the fee payment is used to make its transactions preferentially packaged into the blockchain, that is, pricing congestion. This fee makes the network and users suffering from congestion situations incentive-compatible in the system. This is what the basefee of L1 does under normal circumstances.

The good news is that we'll use some of the same ideas to understand rollup overhead. The overhead of EIP-1559 involves only two parts: user and base layer. Since the architectures of rollup and EIP-1559 are different, and the runner sits between the user and the base layer, then we have to separate the overhead of the runner from the overhead of the base layer. This is discussed below:

L2 operator costs

L1 data publication costs

Spend some time studying the data The overhead of posting is worth it because this is really a new type of overhead in the rollup economy. Once the operators have collected a large enough transaction set, they need to publish the compressed information of this transaction set on the base layer.

Currently, this process is not done in a particularly elegant way: the data is simply published as a "CALLDATA", which is a way to allow the sender Adds an arbitrary byte sequence transaction attribute.

Usually, CALLDATA contains a reference to the smart contract method being called by the transaction, and the input parameters for that method. It may be helpful to understand this: the rollup operator calls the L1 "rollup chain" smart contract's "registerCompressedData" method with a block of bytes representing the compressed transaction as an input parameter. Here is an example of Optimism's "Canonical Transaction Chain" contract.

Users send transactions, and the operator compresses these transactions and publishes them to the smart contract of the rollup chain at the base layer

The cost of publishing data is determined by produced by the base layer. In order to publish data on Ethereum, the current market price of data is controlled by EIP-1559, where each non-zero byte of CALLDATA consumes 16 gas, and each zero byte consumes 4 gas.

With multidimensional EIP-1559 (in the simple Sharding-format blob-carrying transactions (for sharding with blob-carrying transaction types)" there are examples), the price of CALLDATA can be set in its own EIP-1559 market identified in , combining data markets with traditional execution markets Separate pricing.

L2 congestion costs (L2 congestion costs)< /h4>

There is a third, more intangible overhead. As long as the supply of rollup block space cannot meet the existing demand, scarce resources must be allocated. In a spherical cow world of time-insensitive users, users simply wait in line. There is no loss of value from a congested system. But when users incur costs due to waiting, they should want to minimize transaction delays as much as possible. For users at the back of the queue, the reduction in their benefits is an added overhead to the overall rollup system.

Reliance on fee markets to enforce this distribution is typical (at least in the Ethereum world), making this overhead visible [1]. Without a fee market or some form of congestion pricing, users either "pay with time" (transactions are delayed for inclusion), bribe block proposers off-chain to include their transactions, or resend their transactions to secure one of the Transactions are selected for packaging. In all these cases, users are spending resources to prevent utility loss due to congestion.

Now that we know the overhead of rollup, we'll try to analyze the system benefits. Here we distinguish two main resources: transaction value and token issuance.

Users get value from transactions on rollup and nowhere else, so be prepared to pay for the service they get . The value here refers to the utility users get from having their transactions packaged on the rollup. I get $50 in utility if the transaction is included, and I am willing to pay that amount to have my transaction included.

If we end up paying $2, my surplus is $48. But from the perspective of the rollup system, no matter who gets $2, the value of the initial inflow is $50.

Second, as long as the transaction contains positive MEV, such as exchange transactions that can be sandwiched on some DEXs, this concept will also be added to our transactions in the concept of value. At this point, it doesn't matter who gets the value, whether it's the sequencer extracting the value, the user sandwiching the transaction, or something else. The only thing that matters here is that our original transaction brought more value to the whole system than the original user got from this transaction. In this way, we get:

The second source of income is "Token issuance". On the basic layer, the income obtained by the block creator is the newly minted Token, which is the original encrypted asset of the network that the block creator helps to maintain. These benefits offset their infrastructure overhead, and as long as it is profitable for them to do so, more and more block producers will join.

Assume rollups are able to mint their own Token, and this Token has non-zero value. Rollups can pay for part of their operations by issuing new tokens to fulfill their duties. The model here is a little fuzzy, there are different ways to use revenue sources for rollup overhead. For now, we only consider that it is possible to issue tokens of value, and by doing so bring more value to the system.

In summary, a rollup system includes three parties: users, rollup operators, and the base layer. Running this system incurs three types of overhead: running cost, overhead of publishing data at the base layer, and congestion overhead. This system obtains income in two forms: transaction value and Token issuance.

All that remains now is the game of matching who pays what, and when. Some pairings are easy to handle. The operator has to pay the base layer for L1 data publishing. They have to pay the moment they publish the data, and they pay as quoted at the base layer. [2]

When the pricing of fees is dynamic in the fee market, the cost of L2 congestion is also instant. Users observe the current demand for rollup block space and adjust their fees based on the available supply. For example, rollups may want to deploy an EIP-1559-style market mechanism on their network to manage the packaging of L2 transactions. Then the L2 base fee allows users to easily estimate the current L2 congestion cost.

The picture above is the overall picture of the system, inflow represents income (transaction value + Token issuance), outflow Represents overhead (L2 operator overhead, L1 data publishing overhead, and congestion overhead). Fees transfer value between different parties.

Budget Balance: Limits to Passing on Responsibilities

Let's add a new constraint to our system - operator budget balance. We assume that rollup operators cannot operate at a loss, i.e. their revenue must be at least equal to or greater than their costs.

This assumption may not always be true, but in my opinion, if we care about whether the operator set is sufficiently decentralized and open in the future, This is crucial.

If operators need to operate at a loss, this will crowd out participants with less capital and make the size of the operator set very limited. [3] A small set of operators weakens the censorship-resistant guarantees, and in the worst case, users are forced to package their transactions at the base layer, having to pay high fees.

Token issuance as a slack variable will come in handy sooner or later to ensure budget balance. Whenever a runner becomes "too unprofitable" they leave the system, which increases the distribution share of the remaining runners until equilibrium is reached again. Likewise, when the operator gets "too high" there are new entrants vying for a piece of the action until the operator reaches budget balance again.

Maintaining operator budget balance in the face of delayed payments

Under the rule of budget balance, we must consider the operator maintaining a non-negative balance. Their main outflow, i.e. L1 data publishing, is variable and its fees charged separately from their main inflow, i.e. transaction fees.

We assume that the operator is fully aware of their L2 running cost, and quote the exact price to the user at the time of transaction (similar to Uncle block rate in their cognition and the corresponding miner fee for compensation). But how are they supposed to provide users with a final L1 data release overhead quote, delaying implementation a bit?

Today, rollup applies heuristics to avoid the risk of L1 data publishing overhead variability. In one case, rollup observes the current L1 base fee (thanks to EIP-3198 !) and reported the fee a little higher as an additional buffer, that is, overcharging the user at the beginning, in case the operator later needs to pay more when publishing data. Alternatively, users are charged as a running average function of the L1 base fee to smooth out long-term fluctuations.

In my opinion, the reasonable solution is to call a derivative, i.e. Simple L1 base fee futures contract. At transaction time, users are charged a fee that locks in a future price to pay for publishing data on the base layer. By reducing pessimistic overpayments, the balance is sent back to the user. Current research is inconclusive regarding the optimal design of such derivatives.

Delay. It locks the records of the database for update access, and other users can only access the records in read-only mode or must wait for the records to be "unlocked". Source)

Assuming rollups price congestion charges perfectly when users transact, there will now be a benefit in the form of congestion charges. Today, on the Ethereum base layer, those fees are burned. The primary reason for this is incentive compatibility: if the congestion fee goes back to the block producer, the protocol's base fee offer is no longer binding, defeating the purpose of EIP-1559. But burning base fees is not the only option to maintain incentive compatibility.

It has been proposed that all "rollup exhaust", that is, the costs caused by economic externalities (such as congestion or MEV), be used to fund public goods. [4] This is not a bad solution. Congestion pricing in cities is often earmarked for improving public transport systems, that is, the money is used to compensate for the negative externalities that, when priced accordingly, lead to these benefits.

Note that I actually slipped in MEV...why should we think of MEV like a congestion charge? First, because MEV is as much an externality as congestion. The simple act of issuing a transaction with MEV creates a positive externality for those who want to capture it. [5]

Externalities are "unmatched value", that is, they arise from some primitive economic activity that balances useful work with compensation ( For example, users pay L2 operators overhead; operators pay L1 publishing overhead), but they create or destroy some additional value in the process.

This is at MEV auction, a design in which operators base miner mining on how much they can extract from mined blocks value to compete for the right to package a block.

This value implies congestion overhead, which users express by competing with each other for bids. More obvious is the MEV itself, which operators will compete for.

Again, assuming runners are not allowed to operate at a loss, their bids must reflect their true ability to extract value from blocks, i.e. runners will Bid on the sum of user fees in their transaction batch plus the MEV they withdraw from the transaction batch.

At the same time, assuming that all operators must pay the same amount of L2 operator overhead, and the L1 data publishing overhead is accurately charged to users, we will have Output:

User Fee = L1 Data Release Fee + L2 Operator Fee + L2 Congestion Fee

Runner Overhead = L2 Runner Overhead + L1 Data Release Overhead

Operator Profit = User Fee + MEV

Operator Profit = Operator Benefit - Operator Overhead = L2 Congestion Charge + MEV

When the operator is in an efficient market In an environment that competes to win the right to propose blocks, operators must simultaneously bid for their entire profit, namely the congestion fee and the available MEV in their transaction batch. [6] This is the implicit value of the system:

The first item comes from the fees paid by users to avoid the loss caused by congestion, and the second item comes from The ripple effect from the initial transaction. These values belong to no one in the first place, so why can't they be captured and redistributed?

Users are willing to pay up to their transaction value for packaging. Externalities are indicated by dashed rectangles.

This article makes a lot of assumptions. For example, I assume "runner budget balance" because I believe the community should look critically at rollups run by runners at a loss, which may not be suitable for decentralization yet. Token issuance helps re-establish budget balance, although this relies on an exogenous price signal (token value) to align operator incentives.

In this view, operators prefer to price as accurately as possible what they can price, namely their L2 operator overhead and L1 data Publishing costs. This avoids a misallocation of future benefits where operators would expect a higher token price to pay for their operations. [7]

This is not advocating a particular form of  rollup  economics. The design space is still broad. Exploring L2 operator overhead uncovers more complexities that we haven't explored, e.g. market institutions supporting a decentralized infrastructure to generate proofs of validity for zk-rollups.

Focus on specific types of users on rollup (eg fast withdrawal service from L2 to L1 or bridge across L2) will also discover different facets of user needs . With the concepts of overhead, benefit, and expense clear, hopefully it is now easier to analyze what outcomes and business goals a rollup should achieve, and the means to achieve them.

John Adler's "Wait, it's all resource pricing?” (here is slides and video) gives background on the separation of L2 runner overhead, execution and data availability overhead.

Patrick McCorry, Chris Buckland, Bennet Yee, Dawn Song, SoK: Validating Bridges as a Scaling Solution for Blockchains

Many thanks to Anders Elowsson, Vitalik Buterin, Fred Lacs and Alex Obadia Very useful comments.

[1] Vitalik also argues that this overhead is an opportunity cost for the blockspace provider. In this reading, if your transaction is included, you should at least pay the provider what they would have earned from including other transactions.

[2] This means we can further unlock our model. The data release cost is quoted by predicting and quoting the congestion situation of the base layer, which forms a whole with the operator of the base layer, that is, the block producer.

[3] The centralization of the rollup operator set may not be as bad as the base layer centralization of block producers, but the evaluation of the rollup network decentralization trade-off is left for the future.

[4] At the time of writing, even those mismatched fees, such as those collected from users to pay for data publishing overhead, are used to fund some public goods, like Optimism initiated A retrospective public goods financing scheme.

[5] Interestingly, gas price auctions, the competition to capture positive externalities, create negative externalities for the network as a whole, making the network have to deal with more severe congestion.

[6] Note that invalidation efficiency is no longer a fair assumption in cases where some operators have access to private transaction order flow, or participate in cross-domain MEV (courtesy Alex Obadia!). In the latter case, market efficiencies in cross-domain extractors can be recreated in single-domain builder auctions.

[7] By the way, this mode is not terrible! This is mostly how miners have always operated. However, we must remember that any additional risk borne by the operator is a centralized pressure unless there are risk management primitives such as derivatives available. Even with such options for hedging risk, the knowledge required to run a good business can be high, which can discourage less-skilled operators.

Original link