The main benefit is to reduce the amount of data stored on Ethereum, thereby reducing the cost for users to transact on L2.
**Written by: **OneTrueKirk
Compiled by: Yvonne, MarsBit
Original post from OneTrueKirk on ethresear.ch
This is my first time posting on a topic here, so I apologize if I offend you in any way. I've been thinking about this idea (Stateless Rollups), mostly dedicated rollups for our lending protocol, but hopefully it can be generally applicable, any feedback is appreciated.
TLDR：
Only the status root is published, not the calldata.
(MarsBit note: Calldata is the value of the data part in the contract transaction and cannot be modified.)
detail
What if instead of using Ethereum as a data availability layer, by publishing the full state as calldata, and only publishing the state root to mainnet? The main benefit is to reduce the amount of data stored on Ethereum, thereby reducing the cost for users to transact on L2. Even with EIP-4844, blobace is not free.
The main risk is a Data Withholding Attack, where a proposer publishes a valid state root but withholds full data from other rollup nodes to monopolize future block production or hold funds hostage. To prevent this, honest nodes must question any state update for which no peer can provide data. Arbitrum-style interactive fraud proofs can be used to force proposers to disclose the full state on mainnet, but still cause the challenge to fail if the root is valid, so even in the case of failure, the cost of the challenge is low.
(MarsBit Note: Data Withholding Attack refers to the attacker deliberately not returning all data or returning wrong data when accessing protected data, in order to achieve the purpose of deception or destruction.
If the cost of a challenge failure is low, honest proposers could be made miserable by forcing them to pay for posting all of their state data to the mainnet in defense of the challenge, even if they propagated state data point-to-point correctly . The cost of initiating a challenge must be proportional to the cost of defending to ensure that honest proposers cannot be attacked in this way.
In the worst case, if an attacker can spend $1 to cost an honest proposer $1, they can force the proposer to give up and get their block back. A new honest proposer can then bid, and unless the attacker can repeat the attack on all potential honest proposers, which includes everyone with funds, they cannot cause a permanent downtime. It is possible to add another clause, where the cost of the challenge rises when too long has passed since a valid block was finalized. This way, it is easy to challenge a dishonest proposer, but impossible to stop state transitions for long.
More optimistically, if nodes spread data between peers, they can decide their own data backup and accessibility solutions, and users are better off locally storing the data they need for their own state transitions. In the context of one particular application, I thought about encoding the rollup state in a completely different way than the EVM to optimize for this. All state associated with a particular user account can be encoded into the same hash, so users can more easily verify changes to their account without knowing the global state (i.e. confirming that you received the number of tokens without worrying about where they came from).
Summarize
I'd love to hear your thoughts, and would appreciate links to related work. Unlike ordinary optimistic rollup, in optimistic rollup it is easy to determine whether the submitted calldata matches the state root of the main network, and whether both are valid, but it is impossible to know whether an update is valid from the state root alone, so it is necessary to Carefully consider the economics of challenge periods and griefing (i.e. malicious behavior).
View Original
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
A Quick Look at the Advantages and Potential Problems of Stateless Rollup
**Written by: **OneTrueKirk
Compiled by: Yvonne, MarsBit
Original post from OneTrueKirk on ethresear.ch
This is my first time posting on a topic here, so I apologize if I offend you in any way. I've been thinking about this idea (Stateless Rollups), mostly dedicated rollups for our lending protocol, but hopefully it can be generally applicable, any feedback is appreciated.
TLDR：
Only the status root is published, not the calldata.
(MarsBit note: Calldata is the value of the data part in the contract transaction and cannot be modified.)
detail
What if instead of using Ethereum as a data availability layer, by publishing the full state as calldata, and only publishing the state root to mainnet? The main benefit is to reduce the amount of data stored on Ethereum, thereby reducing the cost for users to transact on L2. Even with EIP-4844, blobace is not free.
The main risk is a Data Withholding Attack, where a proposer publishes a valid state root but withholds full data from other rollup nodes to monopolize future block production or hold funds hostage. To prevent this, honest nodes must question any state update for which no peer can provide data. Arbitrum-style interactive fraud proofs can be used to force proposers to disclose the full state on mainnet, but still cause the challenge to fail if the root is valid, so even in the case of failure, the cost of the challenge is low.
(MarsBit Note: Data Withholding Attack refers to the attacker deliberately not returning all data or returning wrong data when accessing protected data, in order to achieve the purpose of deception or destruction.
If the cost of a challenge failure is low, honest proposers could be made miserable by forcing them to pay for posting all of their state data to the mainnet in defense of the challenge, even if they propagated state data point-to-point correctly . The cost of initiating a challenge must be proportional to the cost of defending to ensure that honest proposers cannot be attacked in this way.
In the worst case, if an attacker can spend $1 to cost an honest proposer $1, they can force the proposer to give up and get their block back. A new honest proposer can then bid, and unless the attacker can repeat the attack on all potential honest proposers, which includes everyone with funds, they cannot cause a permanent downtime. It is possible to add another clause, where the cost of the challenge rises when too long has passed since a valid block was finalized. This way, it is easy to challenge a dishonest proposer, but impossible to stop state transitions for long.
More optimistically, if nodes spread data between peers, they can decide their own data backup and accessibility solutions, and users are better off locally storing the data they need for their own state transitions. In the context of one particular application, I thought about encoding the rollup state in a completely different way than the EVM to optimize for this. All state associated with a particular user account can be encoded into the same hash, so users can more easily verify changes to their account without knowing the global state (i.e. confirming that you received the number of tokens without worrying about where they came from).
Summarize
I'd love to hear your thoughts, and would appreciate links to related work. Unlike ordinary optimistic rollup, in optimistic rollup it is easy to determine whether the submitted calldata matches the state root of the main network, and whether both are valid, but it is impossible to know whether an update is valid from the state root alone, so it is necessary to Carefully consider the economics of challenge periods and griefing (i.e. malicious behavior).