IOSG Ventures: An article discussing Rollup’s monetization design

Original author: Jiawei, IOSG Ventures

Is Rollup a good investment class in infrastructure?

Rollup’s investment logic ranges from the early ZK/OP narrative dispute, to the later practice of TPS and user experience competition, and then to the moat built around derivative tools such as OP Stack. For this issue, it may be at different stages of industry development. There are different answers.

But at the end of the day, what we need to answer is, is Rollup a profitable business? What are the economics of Rollup? This article attempts to study and discuss Rollup's business model and its Monetization design space.

Barry Whitehat first proposed the concept of Rollup in the Ethereum Research forum. When the concept of Rollup was in its infancy, we collectively called the role of Rollup as Relayer or Operator. With the refinement of infrastructure development, this role is decomposed into multiple entities: Sequencer is responsible for sorting transactions and writing to DA, Challenger is responsible for proposing challenges, and Prover is responsible for generating proofs. When we discuss the Rollup economy, we can basically sort out from these entities.

IOSG Ventures: An article discussing the monetization design of Rollup

Source: IOSG

This article mainly discusses several aspects of Rollup Monetization:

  • The reason and composition of Transaction Fee and the profit and loss of Rollup;
  • The form and Monetization of MEV in the context of Decentralized Sequencer;
  • Possibility of Monetization based on Fault Proof and Validity Proof.

Transaction Fee

Similar to other chains, users who send transactions in Rollup need to pay transaction fees.

From the perspective of Sequencer, this transaction cost mainly covers two parts of expenditure: execution overhead and security overhead.

Execution Cost (ution Cost)

IOSG Ventures: An article discussing the monetization design of Rollup

Source: John Adler

Rollup's execution overhead is inherited from Ethereum's model. In the abstract, each Ethereum node runs a replicated state machine. As shown in the figure above, nodes download and store transaction data, perform calculations, read and write memory and storage, and these operations correspond to physical resource consumption and consumption. Gas, as a unified resource pricing unit, is used to measure the resources behind these operations.

The same is true when it is extended to Rollup. Operating a Rollup node will generate a certain amount of execution overhead, which is the origin of the transaction fee paid by Rollup users. Due to subtle differences in EVM equivalence and different Rollup designs, different Rollups have slightly different prices for execution overhead (for example, zkSync Era provides native account abstraction, and some operations may require more Gas than EOA), but Generally, the Gas model of Ethereum is used.

IOSG Ventures: An article discussing the monetization design of Rollup

Source: Dune Analytics @springzhang

In addition to the execution overhead described above, congestion charges and minimum transaction fees should also be considered.

  • Congestion charges. It is reflected in the dynamic balance between Gas price and network traffic. For example, during the Arbitrum Odyssey, the surge in network traffic led to a sharp increase in Gas prices.
  • Minimum transaction fee. On a blockchain with extremely low network fees, in order to avoid Spam and DoS attacks, it is necessary to set a lower limit on transaction fees. Currently 0.1 gwei on Arbitrum One and 0.01 gwei on Arbitrum Nova. The value of the minimum transaction fee depends on the design of the network (0.001 gwei on Optimism).

Security Cost

IOSG Ventures: An article discussing the monetization design of Rollup

Source: Celestia Forum @adeets_ 22

The security overhead is the data availability (DA) cost we are discussing. DA is the guarantee that Rollup is equivalent to the security of Ethereum, ensuring that everyone can rebuild the state of Rollup based on the data published on Ethereum L1 (here we are talking about Ethereum Fang L1, of course there are other DA schemes). The DA cost contributed to Ethereum L1 occupies the vast majority of the total cost of Rollup. In May of this year, Arbitrum submitted about 3,927 MB of data to Ethereum, and paid 4,856 ETH for it, and the DA cost was about 1.24 ETH/MB. (Based on the S 3 Standard price of $0.023 per GB and the ETH price of $1800, the DA storage cost of Ethereum is about 100 million times that of AWS).

Since DA on the chain is very expensive, each Rollup adopts a data compression method. Arbitrum and Optimism Bedrock use open source data compression libraries Broti and zlib respectively to compress data published to Ethereum L1. StarkNet and zkSync Era compress data by publishing a State Diff (the difference between the previous state and the new state) instead of the entire data. (PS: The Optimism Bedrock upgrade also adopts various methods to compress transaction costs, here we can see more data indicators).

IOSG Ventures: An article discussing the monetization design of Rollup

Source: IOSG

It is worth looking forward to that the high DA cost of Ethereum L1 will be greatly alleviated after Decun Upgrade introduces EIP-4844. Also, the "security overhead" discussed here actually implies different levels of security. In addition to the DA guaranteed by Ethereum L1, solutions such as DAC, Celestia, and EigenDA provide a variety of "security-cost" trade-offs, providing a variety of options for the DA demand side. Some low-frequency, high-value DeFi applications need more security guarantees, while some high-frequency, relatively low-value applications (such as games) can pay more attention to cost; each takes what it needs.

IOSG Ventures: An article discussing the monetization design of Rollup

Source: Dune Analytics @optimismfnd

To sum up, simply look at it from the perspective of Sequencer: Sequencer collects transaction fees from the user side and pays DA fees to Ethereum. Then Sequencer's profit can be calculated as above. At present, most Sequencers are operated by the Rollup team. If a series of details such as token issuance income and inflation are ignored, Rollup's income can also be roughly measured in this way.

IOSG Ventures: An article discussing the monetization design of Rollup

Source: Token Terminal

IOSG Ventures: An article discussing the monetization design of Rollup

Source: IOSG

Taking Optimism as an example, in the past 30 days, Optimism's daily profit is about 20k US dollars. According to the data from Token Terminal, Optimism’s profit since its launch is about 10.9 M USD.

MEV

MEV is an important way Rollup builds its business model. It doesn't make much sense to talk about MEV in the context of a centralized single sequencer, so we'll start with a decentralized sequencer and then explore Rollup's MEV economy.

Decentralized Sequencer (DS)

As of now, Arbitrum ($5.87 b), Optimism ($2.14 B), and zkSync Era ($649 M) rely on a centralized Sequencer/Operator for transaction sorting, batch submission, and other operations.

Decentralization is a complicated matter. The process of introducing multiple participants needs to be carefully polished, and it is not necessary to complete it in one step. From the perspective of security, competition situation, and developer resources, it makes sense to adopt a centralized Sequencer early in the project. However, the centralized Sequencer has at least two obvious flaws (which are also the flaws of most centralized methods).

  • Transaction review: that is, to review the transactions of specific users, including blackmail attacks and so on. In order to solve this problem, Arbitrum and Optimism provide the option of mandatory inclusion of user transactions. For example, all users of Arbitrum can call the forceInclusion method to force the inclusion of transactions; StarkEx implements the escape hatch (Escape Hatch) mechanism to achieve partial anti-censorship.
  • Liveness Guarantee: Can the Sequencer stay online continuously? If a centralized service had a single point of failure (such as a hardware failure or software misconfiguration), the entire network would go down. The likelihood of this is small, but if it happens it could have wide-ranging negative repercussions.

IOSG Ventures: An article discussing the monetization design of Rollup

Source: Taiko

Currently, Sequencer actually plays the role of Builder and Proposer on Ethereum L1: it is responsible for both transaction sequencing and submitting Batches - the process of implementing DS is a bit like taking the old path of Ethereum PBS.

To implement DS, Rollup usually has several options.

  • Leader Election/Rotation (Leader Election/Rotation) mechanism, plus local block construction, which is the case of non-PBS on Ethereum L1. Vitalik proposed several election/rotation methods in his An Incomplete Guide to Rollups: Sequencer auction, PoS-based random selection, DPoS voting, etc. According to the practice of Ethereum, it is obvious that PBS will be a better solution.
  • Leader election/rotation mechanism, plus an open block construction market, that is, Enshrined PBS or Proposer on Ethereum L1 adopts MEV-Boost.
  • Some specific mechanisms, such as FCFS (First Come First Serve). FCFS will eventually lead to a delay race, similar to Colocation in traditional high-frequency trading. Arbitrum currently uses FCFS and is working on variants such as Time-Boost. Time-Boost introduces a priority fee based on FCFS, which can be paid to speed up the transaction by up to 0.5 seconds. This is a two-dimensional tradeoff between latency and cost.

The Rollup team can use the above options to build DS internally, or consider outsourcing Sequencing:

  • Projects such as Espresso/Astria proposed their DS/SS services;
  • Flashbots is building SUAVE, an encrypted memory pool common across domains;
  • The Based Rollup proposed by Justin Drake directly uses the L1 consensus, and the Proposer of the Ethereum L1 includes the Rollup block into the L1 block, inheriting the same level of decentralization and activity guarantee as the L1.

Choosing to build in-house or outsource has some trade-offs, which are discussed further later in this article.

Rollup MEV in DS context

IOSG Ventures: An article discussing the monetization design of Rollup

Source: odos.xyz/arbitrage

If we have a DS market with open block construction, then the MEV supply chain on Ethereum will be reproduced on Rollup. Among them, Intradomain MEV (Intradomain MEV) refers to the MEV that occurs inside Rollup, which is not much different from the MEV of Ethereum L1. For example, sandwich attacks in DEX, cross-DEX arbitrage, etc. Because Rollup has not yet implemented DS, the above figure uses the cross-DEX arbitrage on Ethereum L1 as an example.

More interesting may be cross-domain MEV (Cross-domain MEV). We divide cross-domain MEV into common cross-domain MEV and cross-domain MEV under Shared Sequencer (SS).

  • General field MEV

IOSG Ventures: An article discussing the monetization design of Rollup

Source: odos.xyz/arbitrage

Ordinary cross-domain MEV happens between Ethereum L1 and Rollup, Rollup and Rollup. In the context of DS, each domain has its own MEV pipeline, covering different roles. The image above is an example of cross-domain arbitrage.

On the Searcher side, cross-domain MEV involves complex execution risks, because different domains have different confirmation times and finality, and it is impossible to determine whether the transaction will be included as desired. To this end, Primev is building a communication network where Searchers can submit bids to multiple Builders in multiple domains to obtain pre-confirmation guarantees for their Bundles. This way Searcher can quantify and manage their execution risk.

There is a trend of centralization in cross-domain MEV. As pointed out by Flashbots, a Builder that builds blocks on multiple chains at the same time has a greater advantage in cross-domain MEV than a Builder that builds blocks on only one chain, thus easily leading to centralization. Under the Rollup-centric Roadmap, this is a topic that needs to be faced in the next few years.

  • MEV under SS

The situation is different if multiple Rollups use the same SS.

IOSG Ventures: An article discussing the monetization design of Rollup

Source: IOSG

One of the characteristics of SS is that it can realize cross-Rollup atomic arbitrage. Originally, when Searcher submitted transaction 1 and transaction 2 separately, it was not sure whether the two transactions would be included as it expected (for example, included just in the next block). With SS, Searcher can submit a Bundle similar to the above figure, and execute it only when transaction 1 and transaction 2 can be satisfied at the same time, otherwise neither transaction will be executed (of course, the transaction that needs to be satisfied is not an invalid transaction). This implementation reduces the execution risk of Searcher.

Ideally, SS will achieve "the whole is greater than the sum of its parts". For example, the information covered by a transaction may not be valuable on a single Rollup, but it can be arranged and combined with transactions on other Rollups when multiple Rollups share sorting, so as to make full use of some "invalid information" and realize positive sum games.

Although there are many benefits, Sequencing involves complex business issues. Therefore, the author believes that SS will not be adopted by the head Rollup in the short term, but may be implemented and verified first in the long-tail App-specific Rollup, or as a Rollup-as- The options of the a-Service project are provided for developers to use.

Rollup economy around MEV

IOSG Ventures: An article discussing the monetization design of Rollup

Source: IOSG

After DS is implemented, the question returns to how to build economic models and value capture mechanisms around MEV.

Above we discussed the overhead of Rollup. The source of this overhead is the DA resources and the physical resources to operate the Rollup itself. These limited resources constitute the scarcity of block space. MEV reflects dominance over the scarcity of block space. Rollup can price that dominance.

Fuel Network believes that an optimized token model should reasonably capture the value of the block space. Users use Rollup tokens to pay transaction fees, which is one of the ways of value capture (ie endowed with token Utility). But this also introduces additional user-side friction. The idea of Fuel is also to tokenize the scarcity of block space, but what is tokenized is "the right to charge fees in the block space." This is from the perspective of block producers and MEV, and does not affect end users.

Corresponding to the above options of DS, the author thinks that there may be the following design space:

*MEV Auction (MEVA). Sequencer participates in the auction to determine the transaction ordering rights of a specific block, or a block within a specific time. The auction bids serve as Rollup's revenue.

  • PoS. Pledge Rollup tokens and randomly select a Sequencer; the more you stake, the greater the probability of becoming a Sequencer. Note that Rollup is still secured by Validity/Fault Proof and Ethereum, and does not need to rely on the economic security provided by PoS. PoS is only used as a way to choose a leader. Staking tokens provide value capture for Rollup, and this lockup is essentially a reflection of the scarcity of block space. *SS. Compared with the above two points, SS is an interesting new topic, and there is no conclusion yet. Assuming that Rollup chooses to outsource Sequencing to SS, it also means giving up its right to capture MEVs in the domain - although the advantage of this is that multiple domains will have network effects, thus forming a positive sum. But from another perspective, Rollup can choose to keep its own MEV inside its own ecology, capture it by itself or tokenize the MEV in the domain.

Therefore, the author believes that SS should somehow redistribute the captured MEVs among its various domains. This redistribution incentive is especially important in situations where multiple SSs compete for their Rollup clients. In this case, the redistributed MEV can serve as Rollup's income.

Fault Proof

(The community proposed to change the name of Fraud Proof to Fault Proof, because even honest parties may submit wrong state transitions due to software configuration errors and other reasons. The word "fraud" actually implies evil motives, so the description is not accurate enough)

The general design of fraud proofs is that during the challenge period, people (called challengers) can challenge the state transition; once the challenge is verified as correct, the perpetrators will be confiscated, and the challenger will get part of the confiscated funds as a reward. The remaining forfeited funds may be destroyed, and if the forfeited funds are Rollup tokens, this is considered a compensation for all token holders (not for the victims of the attack). Both Arbitrum and Optimism Cannon currently employ interactive fraud proofs.

The party that observes state transitions and proposes challenges on Arbitrum is called a validator, and the party that observes state transitions is called observers (Watchtower Validators). The main difference between the two is that the former can pose a challenge, while the latter can warn in any way (for example, through the community or social media). Becoming a validator requires whitelist permissions. Observers do not need permission.

Arbitrum may decentralize the role of validators (aka challengers) in the future. But actually the challenger only needs 1 of N trust assumptions, one honest challenger is enough for the network. Therefore, the author believes that decentralized challengers only meet the requirements of decentralization. Except for the above-mentioned challengers getting part of the confiscated funds, there is not much room for design in economics, and it is more likely to be due to design Redundancy considerations.

Prover Network/Market

IOSG Ventures: An article discussing the monetization design of Rollup

Source: Figment Capital

Figment Capital made a conceptual distinction between Prover Network and Prover Market in its article: Prover Network is a collection of Prover that only provides services for a single application (such as Scroll). The Prover Market is an open market where multiple applications (such as Scroll, Succinct) can submit proof requests to the market. This article has already summarized all aspects of Decentralized Prover, so this article will not add too much ink.

Prover Network

Scroll came up with the idea of a decentralized Prover two years ago.

IOSG Ventures: An article discussing the monetization design of Rollup

Source: Scroll

Prover (Scroll is called Roller) needs to pledge tokens to obtain an initial reputation, which is proportional to the pledged tokens. When the network needs to generate proofs, the Sequencer randomly selects multiple Provers according to their reputations, and requires them to generate proofs within time T—if the proofs are invalid, they will be fined; if the proofs are valid but later than time T, their reputation will be reduced; if If the proof is valid and within time T, there is a chance to get a reward.

The introduction of a time-limited T design, rather than simply using "fastest" to measure, is to avoid the winner-take-all situation of the fastest Prover, because as long as it can be completed within time T, the fastest Prover and the slower Prover Prover has the same probability of getting the reward. This mechanism encourages the fastest Provers to generate proofs for other blocks in parallel to maximize profits.

Prover Market

IOSG Ventures: An article discussing the monetization design of Rollup

Source: =nil;

=nil; Provides generalized services for building circuits and proving the market. The developer who builds the circuit and the Prover who generates the proof each get a portion of the revenue.

As an open market, =nil; is similar to the spot market, with two roles: proof requesters and proof producers. The former can issue buy orders, and the latter can issue sell orders. The parameters of the pending order include Statement (such as Mina or Solana's state proof circuit), cost, order timeout period and proof generation time.

=nil; A similar reputation system is also adopted, and the Prover who fails to generate proofs on time or generates wrong proofs will be reduced in rating or even fined.

Scroll and =nil; both adopt the design of staking-slashing and reputation system, the difference is that they target different demand-side groups. The former serves ZKRollup itself, and the latter serves multiple ZK applications. These two examples correspond to the two forms of internal construction Prover and outsourcing Prover respectively.

Closing Thoughts

Based on the above discussion, the author puts forward several points of view:

  • Transaction fees are a simple and effective business model, and one of the main selling points of Rollup's expansion of Ethereum is low fees, so they don't do much about transaction fees. With the adoption of EIP-4844 and the maturity of various DA schemes (Celestia, EigenDA, etc.), Rollup transaction fees will be further reduced. This is a good thing for users.
  • In terms of Rollup, the author believes that mainstream Rollup will gradually move towards DS in two to three years, and some long-tail Rollups may be one step faster. As a relatively obscure business model, MEV will become the main growth point of Rollup's revenue. Among them, if DS is built internally, it is related to the design of token economics; if DS & SS is selected, how to reasonably allocate the MEV in it is a point that both Rollup and DS & SS projects need to consider. The importance of MEV on Rollup is currently grossly underestimated.
  • Decentralization is often a gradual process, and there are different degrees of decentralization. Regardless of the decentralized Sequencer or Prover, there are two main options: internal construction by the team or outsourcing. The former has a wider design space, mainly based on the encryption economic primitives of staking-slashing, and there are already some mature mechanism designs for reference. The author speculates that the latter may rely on a payment model similar to DA.
  • DS may be more complex in mechanism design, while Prover is relatively intuitive. Because it is difficult for us to say that the transaction sequence returned by Sequencer is correct or wrong, and mathematical proof is a deterministic thing that can be measured quantitatively, such as time, cost and other parameters. DS is considered more from the perspective of MEV economy.
  • How Rollup chooses the above two methods varies according to the stage of the project. At least capital efficiency, developer resources and other factors need to be considered. For early Rollups, including some App-specific Rollups, outsourcing this decentralized work may be the best solution (via DS & SS or EigenLayer) for fast Bootstrap. On the one hand, the relatively mature Rollup has more sufficient developer resources and funds, on the other hand, it will pay more attention to token value capture and resource connection, and use this to build a moat and flywheel effect.
View Original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
  • Reward
  • Comment
  • Repost
  • Share
Comment
0/400
No comments
Trade Crypto Anywhere Anytime
qrCode
Scan to download Gate App
Community
English
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)