Understanding Rollup Economics from First Principles

Rollup is an amazing primitive. Rollup will be the preferred solution for future scaling of Ethereum and provide a broad design space for operations on Ethereum.

In general, rollups extend the protocol on which they are built and retain most of the protocol’s properties. The most important thing in the whole process is to ensure the correctness of off-chain execution and the availability of data behind the execution. How to achieve these two points is up to the designer.

I’ve recently become interested in understanding rollups from an economics perspective. This is not just a theoretical question. Fees for the base layer (L1) are high, and we should aggressively provide some space so that users can afford transaction fees here. Better economics means better pricing and happier users.

So how should we specifically think about the economics of rollup? This article will first identify the various parts of the rollup system, their roles and responsibilities. It then teases out the various overheads, benefits, and expenses in the rollup system, giving us some clues as to how to explore this broad design space.

Characters in the Rollup game

To put it simply, we will ideally divide into three roles:

Users : Users can send transactions on the L2 network, just like on L1. They hold assets on L2 and interact with contracts deployed on rollup.

Rollup Runner : This role contains many other roles. Rollup runners represent all the infrastructure needed to process L2 network transactions. We now have sequencers that issue batches of transactions, executors that issue assertions, challengers that make fraud proofs, provers that compute validity proofs 

Base Layer : A protocol that provides security for the data published by the rollup. Such a protocol could just guarantee data availability without settlement functionality (e.g., a “template” bridge contract deployed on its execution layer), but could also be a general-purpose settlement engine like Ethereum.

Understanding Rollup Economics from First Principles

The operation of these three roles: the user conducts transactions at L2, and the operator connects the user and the base layer (the data is finally published on the base layer).

Rollup overhead

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

Fees provide a bridge between “energy sources” and “energy reservoirs”, transferring value between the various components of the system so that each component performs its function correctly.

For example, in a previous article I wrote about EIP-1559 , I explained how to break down the transaction fees paid by users:

– Part of the fee for packaging transactions is owned by the runner: in the case of the PoW base layer, the miner fee is a compensation to the miner to hedge the increased risk of uncle blocks. This fee covers the overhead of runners publishing blocks, making them part of the network. And this is currently the default fee you pay by 1 or 2 Gwei when you send a transaction.

– The rest of the fee payments are used to prioritize their transactions into the blockchain, i.e. pricing congestion. This fee makes the network and users suffering from congestion situations incentivized in the system compatible. 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: the user and the base layer. Since the architecture of rollup and EIP-1559 is different, and the runner is located between the user and the base layer, we must separate the overhead of the runner from the overhead of the base layer. We discuss this below:

L2 operator costs

Rollup must find runners willing to spend computing resources to process rollup data, such as maintaining a transaction pool, sorting transaction batches, computing state roots/state differences/validity proofs, etc. This is a tangible overhead used to quantify how much it would cost an operator to run the infrastructure.

L1 data publication costs

It’s worth spending some time studying the overhead of data publishing, as this is really a new type of overhead in the rollup economy. Once the runners have collected a large enough transaction set, they need to publish the compressed information for that transaction set on the base layer.

Currently, this process cannot be done in a particularly elegant way: data is simply published as “CALLDATA”, a transaction attribute that allows the sender to add an arbitrary sequence of bytes.

Typically, CALLDATA contains a reference to the smart contract method called by the transaction, and the method’s input parameters. It might be helpful to understand this: the rollup runner calls the L1 “rollup chain” smart contract some “registerCompressedData” method with the 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, the runner compresses these transactions and publishes them to the rollup chain smart contract at the base layer

The overhead of publishing data is incurred by the base layer. To publish data on Ethereum, the current market price of data is governed by EIP-1559, where each non-zero byte of CALLDATA consumes 16 gas and each zero byte consumes 4 gas.

With multi-dimensional EIP-1559 (example in the simple ” Sharding-format blob-carrying transactions for sharding” by Vitalik), CALLDATA can be priced in its own EIP -1559 Determined in the market , pricing the data market separately from the traditional execution market .

In this Dune analytics dashboard, I’m trying to organize data published by several major rollups. I’m not sure I’ve captured the full information, especially for zk-rollup. If you find something that doesn’t match, please let me know! :)

Also refer to Aditi’s recent articles  Ethereum Rollup Call Data Pricing Analysis  and L2fees.info

L2 congestion costs

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

Relying on a fee market to perform this distribution is typical (at least in the Ethereum world), making this overhead manifest  [1]. Without a fee market or some form of congestion pricing, users either “pay with time” (transactions are packed late), bribe block proposers off-chain to pack their transactions, or re-send their transactions to guarantee one of them The transaction will be selected for packaging. In all of these cases, users are preventing the loss of utility from congestion by expending resources.

Rollup revenue

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

transaction value

Users get value from transactions on the rollup and nowhere else, so are prepared to pay for the services they get. The value here refers to the utility users get from their transactions being packaged on the rollup. I can get $50 in utility if the transaction is packaged, and I’m willing to pay that amount to have my transaction packaged.

If we end up paying $2, my surplus is $48. But from the perspective of the rollup system, whoever gets the $2 gain, the initial inflow is worth $50.

Second, as long as the transaction contains a positive MEV, such as exchange transactions that can be sandwiched on some DEXs, this concept is also added to our concept of transaction 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 initial transaction brings more value to the entire system than the initial value that this user gets from this transaction. Thus, we get:

Transaction Value = User Value + MEV

Token issuance

The second source of revenue is “Token issuance”. On the base layer, the income obtained by the block producer is the newly minted Token, which increases the native encrypted assets of the network that the block producer helps maintain. These gains offset their infrastructure overhead, and as long as it is profitable for them to do so, more and more block producers will join.

Assume that rollups can mint their own Token, and this Token value is not zero. A rollup can pay for part of its operations by issuing new tokens to perform its duties. The model here is rather vague, and there are different ways of using revenue streams for rollup expenses. For now, we only consider that it is possible to issue valuable tokens, and by doing so, we can bring more value to the system.

Passing responsibility: rollup version

To sum up, a rollup system consists of three parties: the user, the rollup operator, and the base layer. Running this system incurs three types of overhead: running costs, overhead of publishing data at the base layer, and congestion overhead. This system earns revenue in two forms: transaction value and token issuance.

All that’s left now is the game of matching who pays what, and when. Some pairings are easy to handle. Runners must pay the base layer for L1 data publishing. They have to pay the moment they publish the data, and pay as the base layer offers. [2]

While the pricing of fees in the fee market is dynamic, the cost of L2 congestion is also immediate. 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. The L2 base fee then allows users to easily estimate the current L2 congestion cost.


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

Budget Balancing: Limits on Passing Responsibility

Let’s add a new constraint to our system – runner budget balance. We assume that rollup operators cannot operate at a loss, that is, their revenue must be at least equal to or greater than their expenses.

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

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

Token issuance as a slack variable will come in handy sooner or later to keep the budget balanced. Whenever a runner is “too unprofitable,” they leave the system, which increases the remaining runners’ distribution share until equilibrium is reached again. Likewise, when a runner is “too high”, new entrants vie for a piece of the pie, until the runner reaches a balanced budget again.

Maintaining operator budget balance in the event of late payments

Under the rule of budget balance, we must consider the operator to maintain a non-negative balance. Their main outflow, ie L1 data publishing, is variable and their fee collection is separate from their main inflow, ie transaction fees.

We assume that the runners are fully aware of their L2 running costs, and quote the exact price to the user at the time of the transaction (similar to their perception of the uncle rate and its corresponding miner fee for compensation). But how are they supposed to offer users the final L1 data publishing overhead offer, delaying the implementation a bit?

Today, rollup applies heuristics to avoid the risk of L1 data publishing overhead variability. In one case, the rollup looks at the current L1 base fee (thanks EIP-3198!) and bills the fee a bit higher as an extra buffer, i.e. overcharging the user at the beginning, in case the runners later release it Pay more for data. Alternatively, users are charged as a function of the moving average of the L1 base fee to smooth out long-term volatility.

In my opinion, the logical solution is to call derivatives, ie simple L1 base charge futures contracts. At transaction time, users are charged a fee that is locked in to pay for the overhead of publishing data at the base layer at a future price. Balances are sent back to users by reducing pessimistic overpayments. Current research is inconclusive about the optimal design for such a derivative.

(Translator’s Note: Pessimistic Approach is a method of concurrency control algorithms, that is, if there is a conflict at some point in the future, the transaction is delayed. It locks the database’s records for update access, and other users can only access it with Read-only access to the record or must wait for the record to be “unlocked”. Source)


The user pays the operator for the transaction, but the operator must pay the data publishing fee according to the quotation of the base layer, which is not fixed.

How to deal with congestion charges?

Assuming the rollup perfectly priced the congestion charge when the user transacted, there would now be a benefit in the form of a congestion charge. Today, on the Ethereum base layer, these fees are burned. The primary reason for this is incentive compatibility: if congestion fees are returned to block producers, the protocol’s base fee offer is no longer binding, defeating the purpose of EIP-1559. But burning the base fee is not the only option for keeping incentives compatible .

It has been proposed that all “rollup exhaust”, ie costs caused by economic externalities (eg congestion or MEV), be used to finance 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 negative externalities that, when priced accordingly, bring these benefits.

Mind you, I actually sneaked MEV into it… Why should we think about MEV like congestion pricing? First, because MEV is an externality like congestion. The simple act of issuing a transaction with an 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 rewards (e.g., users pay L2 runners; runners pay L1 publishing costs), but in They create or destroy some additional value in the process.

This is most clearly illustrated in the concept of MEV auctions, in which runners compete for the right to pack a block based on how much value they can extract from the packed block.

This value implies congestion overhead, which users express by bidding against each other. More obvious is the MEV itself, which the operator will have to compete for.

Again, assuming the runners are not allowed to operate at a loss, their bids must reflect their true ability to extract value from the block, i.e. the runners will add to the sum of their fees to users in their batches of transactions plus what they get from this The MEV extracted from the transaction batch is used for bidding.

At the same time, assuming that all runners have to pay an equal amount of L2 runner overhead, and L1 data publishing overhead is precisely charged to users, we get:

User fee  = L1 data release fee + L2 operator fee + L2 congestion fee

Runner overhead  = L2 runner overhead + L1 data publishing overhead

Operator revenue  = user fee + MEV

Operator Profit  = Operator Revenue – Operator Overhead  = L2 Congestion Charge + MEV

In an environment where runners compete in an efficient market to win the right to propose blocks, runners must simultaneously bid for their entire profit, namely the congestion fee and available MEV in their transaction batch. [6] This is the value implied by the system:

The first comes from the fees users pay to avoid losses from congestion, and the second comes from the ripple effect caused by the initial transaction. These values ​​don’t belong to anyone 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 represented by dashed rectangles.

Explore Rollup Economics

This article makes a lot of assumptions. For example, I’m assuming a “balanced runner’s budget” because I believe the community should look critically at rollups run by runners that are losing money, which may not yet be suitable for decentralization. Token issuance helps to re-establish budget balance, although this relies on an exogenous price signal (token value) to coordinate runner incentives.

In this view, runners prefer to price as accurately as possible what they can price, namely their L2 runner overhead and L1 data publishing costs. This avoids a mismatch of future returns, and operators will expect higher token prices to pay for their operations. [7]

But this is not advocating a particular form of rollup economics. The design space is still wide. Exploring L2 runner overhead uncovers more complexities we haven’t explored yet, such as market institutions supporting a decentralized infrastructure to generate proofs of validity for zk-rollup.

Focusing on a specific type of user on a rollup (eg, fast withdrawal service from L2 to L1 or bridging across L2) will also find different aspects of user needs. With the concepts of overheads, benefits, and fees clear, hopefully it’s now easier to analyze what results and business goals a rollup should achieve, and the means to achieve those goals.

Other resources

John Adler’s “Wait, it’s all resource pricing?” (slides and video here) gives context for L2 runner overhead, execution separated from 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 for their many helpful comments.

[1] Vitalik also argues that this overhead is an opportunity cost for block space providers. In this reading, if your transaction is packaged, you should pay the provider at least what they could have earned from packaging other transactions. [2] This means we can further unlock our model. The data release overhead is quoted by predicting and summing up 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 set of rollup runners may not be as bad as the centralization of the set of block producers at the base layer, but the evaluation of the decentralization tradeoffs of the rollup network is left for the future. [4] At the time of writing, even those mismatched fees, such as those charged from users to cover the cost of data distribution, are used for some public goods fundraising, like the retroactive public goods fundraising program initiated by Optimism.[5] Interestingly, the competition for gas price auctions to capture positive externalities creates a negative externality for the entire network, making the network have to deal with more severe congestion.

[6] Note that failure efficiency is no longer a fair assumption in cases where some runners have access to private transaction order streams, or participate in cross-domain MEVs (thanks to Alex Obadia!). In the latter case, the market efficiency in the cross-domain extractor can be reconstructed in the single-domain builder auction.

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

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/understanding-rollup-economics-from-first-principles/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-03-07 08:31
Next 2022-03-07 08:33

Related articles