Author: Davide Crapis, Ethereum researcher; Translation: Golden Finance xiaozou

In February 2022, Barnabé proposed a rollup economics framework for thinking about resource pricing and value flows in an L1-reliant economy. The framework introduces key concepts about L2 MEVs, the interaction of L1 and L2 fees, and operator revenues and costs. It's a simple framework for a simple world: centralized rollups that are constantly training and running in silos. A lot has changed in the past 18 months: shared ordering, decentralization, proof/data aggregation, rollup federation, governance, etc.

We propose a new framework that will help understand this new world, in which rollups are ready to scale. Many experiments are still ongoing, but some patterns are already visible. We will analyze key patterns and hope to provide a tool to help understand where things are going and help discover/answer currently unsolved problems. This article is the first in a series of articles called "Rollups are real." Subsequent articles in this series will explore aggregation and interoperability, decentralization and MEV resilience, governance, and resource allocation in greater depth.

1. Re-examining Rollup Economics 1.0

The original rollup economics framework contains three entities: users, rollup operators, and the base layer. It also has a similarly simplified view of the value stream: L2 fees and MEVs, operator costs, and data publishing costs. This is a simple framework, but it is important to understand it first because everything quickly becomes more complex and interesting from here.

(Economic flow in the rollup original framework)

From this basic flow, one can measure rollup protocol surplus and infer related concepts such as MEV extraction and allocation, L2 issuance, L2 congestion fee allocation, and the timeframe over which a rollup maintains a balanced budget or operating budget surplus (L2 ecosystems are growing economies and operating surpluses can be useful and allocated by the community to public goods funding, development, and growth).

Rollup protocol surplus = L2 fees - operating costs - data costs

Rollup protocols can control L2 fees (including congestion fees and MEV) and operating costs (including rewards and issuance to operators). Whether the protocol decides to target balance or surplus, L2 operations require technical coordination to support the optimal setting of L2 congestion fees, MEV extraction and redistribution, and reducing data costs through optimization and strategic release. These are the main economic designs that different L2 ecosystems are trying. In the future, protocols may want to reduce the uncertainty of data costs, for example using block space derivatives.

A big shift has occurred over the past 18 months. Similar to what happened with building L1 blocks, we’ve seen a breakdown of more specialized rollup operator roles. As the economy grows, operators will naturally become more specialized, which is a good thing because the dispersion of concerns will lead to a more resilient system if we can design around it. But the design space is much larger now, so we need a new roadmap to guide us through this process.

2. Rollups are growing

As rollups mature and begin to shake off their training wheels, complexity is growing both within rollups and between rollups of the same type (which we call “rollup federations”). Shared rollup architectures between rollups of the same type aim to improve “safety” (through shared governance and community alignment), “efficiency” (through shared functionality and economies of scale), and “user experience” (through better interoperability and less fragmentation). At the same time, independent providers are developing infrastructure to provide one or more of these benefits to any rollup (regardless of type) that decides to choose their service. We call these “rollup coops.” We’ll dive deeper into these models, starting with an update on individual rollup economics.

(An Ethereum rollup successfully got rid of the training wheels)

（1）Indy rollup

Rollups are getting rid of their training wheels, and are becoming more secure and decentralized. From an operational/economic perspective, the main costs include:

  • Sorting: This adds both operational costs and (decentralized) economic costs to incentivize sorters.

  • Data Availability (DA): Rollups must publish data to the base layer, incurring data costs, which is the main cost item discussed in the original framework.

  • State Verification (SV): directly increases the operating cost of zk rollup through proof costs.

In all of these cost areas, monolithic rollups face important tradeoffs between security and efficiency. For example, they may choose to use a less secure data availability tier at a lower cost. Data publishing costs (we simply call them data costs, although it includes the L1 compute costs associated with publishing) have historically been the highest cost item. EIP-4844 will soon be listed on Ethereum, after which this cost will be significantly reduced, giving rollup the cost efficiencies needed to scale and implement new use cases. In the long term, efficiencies in data costs and related services are likely to be achieved through aggregated offline innovation, unlocking economies of scale.

(Ethereum’s path to scaling is paved with (recursive) aggregation)

Specific examples of aggregation are: shared ordering services; for optimistic rollups, an interesting idea is "shared batch publishing" which can provide batch compression benefits faster, especially for small players, which can provide lower costs and higher security through faster data publishing; for zk rollups, shared provers that aggregate many SNARKs into a larger proof before publishing to L1 are one of the most exciting scaling benefits, especially because they can be recursively aggregated, providing huge benefits in terms of efficient utilization of L1 data markets, but at the cost of more off-chain computation. One thing that seems clear is that rollups will choose to adopt shared services sooner or later, either as part of a federation or as part of an economic union.

One direction the rollup ecosystem might take is to have more independent rollups that are tightly integrated with L1. We haven’t seen many deployments yet, but there are at least two interesting architectures. One is a based rollup that delegates its block ordering to L1, thereby extracting MEV using the L1 transaction supply network, but retains a proxy to set L2 congestion fees. A more extreme example is a rollup that is enshrine in the Ethereum protocol itself. We’ll dive deeper into the economics of these models when we discuss rollup MEV resilience and decentralization.

(2) Rollup Cooperatives

The first type of integration between two rollups is purely economic integration, such as an economic cooperative.

“A cooperative is a group of entities that share a common purpose or work together to achieve a common goal, such as profit or savings.” - Wikipedia

In its simplest form, a rollup has a joint purchase agreement for a service. Assume there is a shared batch publishing service that a rollup can subscribe to and receive lower costs for publishing data. There can also be deeper economic integration, for example, a shared ordering service that can both improve cost efficiency and make it easier for trades to be automatically settled between rollups, thereby reducing barriers to trading across rollups. The mindset is like an economic association such as the European Economic Community (i.e., the European Union before it became a polity) or other similar common market associations.

(Economic flow of a rollup community using shared services)

We can extend the simple model of a standalone rollup economy by using intermediary service providers, such as shared sorters, publishers, or even prover services. In this case, there are two new economic implications for the rollup ecosystem.

  • Cost structure: Rollup operator costs now include operating costs, service costs, and data publishing costs.

  • Shared services economy: New entities need to achieve a balanced budget.

Shared service surplus = rollupA service cost + rollupB service cost - operating cost - shared service data cost

An example of such a service is the Espresso Sorter, a shared service for sorting and publishing, sharing only batch publishing or sharing proofs. In all of these cases, sharing the service also raises two important economic issues.

  • L2 service cost sharing: The total service cost needs to be shared in an economical and fair manner among rollups that adopt shared services.

  • Decentralization of shared services: Depending on the specific service, achieve a level of decentralization that strikes an appropriate balance between performance and robustness. The threshold is lower than the base layer, but it includes incentives and the management of MEV.

(3) Rollup Federation

Rollup federations are different from economic cooperatives because they have both economic integration and some form of political integration. Their mindset is that of a federation of nations.

“A federation is a group of states that transfers some of its sovereignty to a central authority that enforces certain laws and regulations.” - Wikipedia

Technically, political integration is achieved through a shared bridge, but it also requires a shared governance system (a central authority for the federation). Here, we will set aside political and administrative considerations, we will assume the existence of a shared bridge, and focus on the economic relationships it implies. This rollup federation architecture is emerging on all major rollup systems, which are becoming platforms for deploying interoperable rollups (as opposed to dependent rollups, see RaaS and L3 in the next section).

(Emerging architectures of major L2 ecosystems)

For example, Optimism Superchain, Polygon 2.0, StarkWare SHARP, zkSync Hyperchains, and other related projects share similar patterns in their architectures. We distilled it into the following figure. To isolate the impact, we made a realistic assumption that the federated rollup automatically selects shared services and does not incur direct data publishing costs.

(Rollup federation shared services and bridge to the base layer)

Shared bridges introduce additional economic variables. In particular, native L2 tokens such as OP in the Optimism ecosystem provide important decision-making power through governance, which can allocate resources, roles, and economic flows within the ecosystem (for example, OP governance is a governance experiment based on hybrid token identities). Once the rollup technology stack matures and the primary security issues are resolved, the next issue is robustness, which may involve some degree of decentralization.

When rollups consider building decentralized services (for ordering, proving, or validating), they will need to run a consensus protocol. At this point, ecosystems with sufficient scale see an opportunity to “upgrade” their native tokens to productive assets, which is the POL upgrade planned for Polygon 2.0. This is not the only way to decentralize L2 services, as Ethereum L1 can leverage better security properties to achieve this. However, using native tokens may be an attractive direction for larger ecosystems as they wish to retain more internal control/governance of their services, as well as the associated reward/incentive mechanisms.

Change in native token value = Change in demand - Net issuance

The native token is an important economic tool to help bootstrap the L2 ecosystem/economy. Token issuance can be used to reward service operators, fund ecosystem support projects or public goods. However, when the native token is used to support decentralization through the native proof-of-stake protocol, its security may decrease with more dilution. Even if the native token is only used for governance, excessive dilution may cause more budget-constrained holders to sell tokens, which may lead to concentration of ownership. Therefore, it seems important to have a token issuance schedule that is coordinated with the growth of demand. Finally, another important consideration is that making the L2 economy more dependent on the native token (relative to ETH) also makes it less robust to certain failure modes, as exiting L1 may not be an option. In the extreme case, L2 is still secured by Ethereum, but loses the security provided by ETH as external funding.

3. More layers

There is also a lot of active development activity around specific applications or custom execution environments (settled at the base layer). These development activities are generally targeted at applications that require low execution costs and ease of deployment and are willing to sacrifice security. Think games, social media, and NFT products that do not need to bootstrap their own service economy or attract/secure a lot of liquidity.

There are different areas of development, including L3, validums, and rollup as a service (RaaS) platforms. For example, Arbitrum Orbit is a platform that enables the deployment of L3 chains on Arbitrum L2 (One or Nova), with certain configurability, such as choosing Arbitrum's authorized data availability committee (DAC) instead of Ethereum L1 as the data availability layer. StarkNet and other zk rollup projects have also been trying to deploy L3. An extreme example in the direction of easy deployment is AltLayer or Caldera, which deploy "customizable" rollups through no-code solutions and give users agency functions to make their own security-efficiency trade-offs.

(Economic flow of L3 system)

We focus on the L3 system. This is actually an additional layer on top of L2. From the perspective of L2 rollup, this is an additional source of L2 fees. L3 is a new entity in the rollup ecosystem and has its own budget balance constraints:

  • L3 revenue can come from game fees and subscriptions, or other mechanisms such as NFT revenue sharing.

  • L3 costs include the operational costs of the system as well as L2 charges for compute/data. These costs can be borne directly by L3 or, in the case of managed services, paid by the RaaS platform, another service provider that must balance a budget.