Quick overview of the advantages and potential issues of stateless Rollup

Advantages and potential issues of stateless Rollup.

Original author: OneTrueKirk

Original source: ethresear.ch

Original title: Stateless Rollups

Translation: Yvonne, MarsBit

• Following the Crypto Narrative: Understanding 5 Protocols Set to Receive Major Updates
• Analysis of Contango, the expiring contract platform: What are its advantages compared to perpetual contract platforms?
• Study on Dilation Effect: Contract Authorization Risks of Major Wallets such as Binance. Are Big Institutions Really Safe?

Note: The original article was posted by OneTrueKirk on ethresear.ch.

This is my first time posting a topic here, so I apologize if I offend anyone in any way. I’ve been thinking about this idea (Stateless Rollups), mainly for a dedicated rollup for our lending protocol, but I hope it can be universally applicable and appreciate all feedback.

TLDR:

Only the state root is published, not the calldata.

(MarsBit’s note: Calldata is the value of the data part in a contract transaction and cannot be modified.)

Details

What if, instead of using Ethereum as a data availability layer, we published only the state root to the mainnet by publishing the full state as calldata? The main advantage is to reduce the amount of data stored on Ethereum, thereby reducing the cost of transactions on L2 for users. Even with EIP-4844, blobace is not free.

The main risk is the data withholding attack, where the proposer publishes a valid state root but withholds the full data from other rollup nodes in order to monopolize future block production or hijack funds. To prevent this, honest nodes must question any state update that cannot be provided with data by a peer. An Arbitrum-style interactive fraud proof can be used to force the proposer to disclose the full state on the mainnet, but if the root is valid, the challenge will still fail, so the cost of the challenge must be low even in the event of failure.

(MarsBit’s note: A data withholding attack refers to when an attacker, when accessing protected data, intentionally does not return all data or returns incorrect data in order to deceive or disrupt.)

If the cost of a failed challenge is low, even honest proposers who correctly propagate state data point-to-point may be forced to pay the cost of publishing all state data to the mainnet to defend against challenges, causing pain for honest proposers. The cost of initiating a challenge must be proportional to the cost of defense to ensure that honest proposers cannot be attacked in this way.

In the worst case, if an attacker can spend $1 to make an honest proposer lose $1, they can force the proposer to give up and revert their blocks. Subsequently, a new honest proposer can bid, and they cannot cause permanent downtime unless the attacker can repeat the attack on all potential honest proposers, including everyone with funds. It is possible to add another clause that raises the cost of challenges if an effective block has been stuck for too long. This makes it easy to challenge a dishonest proposer, but impossible to permanently stop state transitions.

More optimistically, if nodes propagate data between peers, they can decide on their own data backup and accessibility solutions, while users are best off storing the data they need for their own state transitions locally. In the context of a specific application, I have considered encoding rollup states in ways entirely different from the EVM to optimize for this. All state relevant to a particular user account can be encoded as the same hash value, so users can more easily verify changes to their own account without needing to know the global state (i.e. confirm that you received the amount of tokens you wanted in an exchange without worrying about where exactly they came from).

Summary

I would love to hear people’s thoughts and for people to provide links to relevant work. Unlike regular optimistic rollups, it is easy in optimistic rollups to determine whether submitted calldata matches the state root of the mainnet, and whether both are valid, but it is impossible to know from the state root alone whether an update is valid, so careful consideration of the economic issues of the challenge period and griefing is necessary.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!