Partnered With:

The Dilemma of Optimistic Rollup

Read this article in 13 Minutes

Improving capital efficiency necessarily reduces safety.

Original Title: "The Dilemma of Optimistic Rollup"

Original Source: Ethereum Enthusiast

Three sentences are finished

We believe that liquidity providers will prefer ZKR-Uniswap (Uniswap built on ZK-Rollup), Instead of OR-Uniswap (Uniswap built on Optimistic Rollup), because the former is more capital efficient.

If you want to improve the capital efficiency of OR, you need to shorten its challenge period (Dispute Time Delay, DTD), so as to reduce the "fraud + review" attack on Layer 1 the cost of.

Fundamentally, this is OR's dilemma between capital efficiency and safety: increasing capital efficiency necessarily reduces safety.

Background

In recent months, the gas price increase on Ethereum has caused Interest in scalability solutions, especially Layer 2 scalability solutions. Such schemes can be roughly divided into two categories: validity proofs vs. fraud proofs. We previously covered this article (Chinese translation) and This article (Chinese translation) compared these two types of schemes.

Validity proof schemes include ZK-Rollups (providing on-chain data availability) and Validium (only guaranteeing off-chain data availability). Similar systems have been deployed on the Ethereum mainnet, including our own StarkEx.

Fraud proof schemes include Optimistic Rollups (OR). Some of these proposals are about to go live on public testnets. OR is the latest generation of fraud proof designs, and its predecessors are Lightning Network and Plasma. OR is attractive to dapp developers who suffer from Ethereum congestion because such solutions can keep the Solidity code unchanged and migrate dapps to low-cost and On the OR with scalability.

The basic concept behind OR: only send transaction data to the main chain. Computation and state storage no longer occur on the main chain, but are transferred to Rollup, where block producers and verifiers on Rollup perform the computational work. The scheme assumes that at least one user will detect the fraud in time [within the challenge period (DTD)] and report it to the main chain, thus ensuring the integrity of the system. When the challenge period of an OP block (Translator's Note: that is, a batch of OP transaction data sent to the Ethereum blockchain) ends, the block is recognized as final.

Analysis

Next, we will analyze from the perspective of liquidity providers and users Analyze OR.

Assume that an application as large as Uniswap can be easily migrated to OR seamlessly by porting existing Solidity code. Let's analyze OR from the perspective of liquidity providers and users.

Liquidity Provider

As stated above, OR defines a challenge period in order to detect and report fraud. The wait time for withdrawals must be longer than the DTD, otherwise the system could easily become insolvent due to theft.

For security reasons, it would be better to extend the DTD, thus increasing the cost of the following attack:

< /p>

OR validator detects fraud and sends fraud_detected transaction to mempool. At this point, the OR validator has fulfilled its duty: found and "reported" the fraud. However, this complaint is only valid if the fraud_detected transaction is on-chain.

Assume that during the DTD, the attacker rents enough computing power (Currently cost about $300,000 per hour) to replace blocks containing fraud_detected transactions. This move can be seen as a silent attack on fraud_detected transactions. Why do you say it is silent? Because from the perspective of an innocent bystander, the entire network appears to be safe and sound. If the transaction containing the fraud proof fails to be uploaded to the chain, of course no transaction rollback will occur.

In order to prove our point: there is a trade-off between capital efficiency and safety, we will explain its origin and impact next. Assume the DTD has a period of one week (it has been proposed to set the DTD to 4.5 hours (Chinese translation); Some believe too little time is too risky). Based on our analysis, whether the DTD is 1 day or 2 weeks is just two different points on the trade-off curve between security and capital efficiency. Depending on the length of the DTD, the cost to the attacker can range from $1 million to $10 million. The cost incurred by the attacker does not directly depend on the interests they are after, and if the OR holds billions of dollars in assets, the cost of attacking up to millions of dollars will not stop them.

Opportunity cost has a large impact on decentralized applications due to the actions of liquidity providers. During this time, we have seen liquidity flow from Uniswap to SushiSwap and back to Uniswap. Contrast OR-Uniswap (Uniswap built on OR) with ZKR-Uniswap (a fork of Uniswap built on ZK-Rollup). Liquidity providers can now choose to lock funds on OR-Uniswap for a week, or on ZKR-Uniswap for 30 minutes (proof generation period). ZKR-Uniswap has one fundamental advantage. In the long run, it is difficult for token economy or other incentive mechanisms to defeat this advantage.

We are often asked: Fast Withdrawal can solve this problem? Can a level playing field be created between OR and ZK-Rollup?

No. Fast withdrawals only improve user experience by reducing withdrawal times, not capital efficiency: enough funds must be locked in the Layer 1 smart contract to support withdrawals throughout the DTD period.

In addition, quick withdrawals can only be used for homogeneous assets, and it is useless when encountering non-homogeneous assets (NFT). Even for homogeneous assets, the greater the demand, the higher the opportunity cost. In fact, when many people want to trade homogeneous assets that are in short supply, the opportunity cost is very high: just imagine, when users in the entire DeFi field want to trade YFI, how much it costs to lock up enough YFI to pay for a week's withdrawal in advance. When the rate of return is skyrocketing like this, if you are asked to lock in YFI, how much return do you hope to get?

Some people may say that there is no need to worry about liquidity providers, because the entire DeFi field will be concentrated on the same OR, reducing the user's withdrawal frequency and transaction cost.

Please note that this assumption assumes that no decentralized application runs outside OR, including Layer 1 and ZK-Rollup etc.

We believe that even in this scenario, as the throughput of the OR increases, the safety decreases. Why? Let's think from the perspective of the user (Alice).

User

< p> trust: Alice may trust OR, or more specifically, at least one party will verify the current state of OR. This means that, from Alice's point of view, OR is essentially a trusted system. Trusted systems operate at staggering scale and are often the foundation of high-value businesses such as Coinbase, Binance, and traditional banks. These businesses are working hard to live up to the trust as their reputations get stronger.

No trust: Alice can verify the state of OR herself. Unfortunately, the cost of validating an OR is directly proportional to the OR's throughput: for example, if OR increases Ethereum's scalability by 20x, the validation cost will also increase by 20x. Over time, only a wealthy few can afford the verification cost of high-throughput OR.

From today's point of view, this worry is not unfounded: currently, verifying Ethereum is an altruistic behavior. Some people believe that the current verification cost of Ethereum is so high that it will damage decentralization: affected by the cost, there are fewer network participants to verify the integrity of Ethereum. In other words, less decentralization and less security is the real problem.

Conclusion

OR faces a dilemma: it cannot achieve the capital efficiency of ZK-Rollup , as this would reduce its security. This is an inherent problem with OR, not a design detail. Therefore, when choosing whether to run on OR or ZK-Rollup, any application will prefer the latter, because the latter will attract liquidity providers.

Thanks Dan Robinson Suggestions for an early draft of this article.