Capital Efficiency vs. Security
TL;DR
- We claim that Liquidity Providers will necessarily prefer a ZKR-Uniswap (Uniswap over a ZK-Rollup) to an OR-Uniswap (Uniswap over an Optimistic Rollup), as the ZKR-Uniswap will be *far* more capital efficient.
- Improving capital efficiency in an OR requires shortening its Dispute Time Delay (DTD), thus making a Fraud+Censor attack on L1 cheaper.
- That is the fundamental OR dilemma between capital efficiency and security:
Improving capital efficiency must decrease security.
Background
The increase of gas price on Ethereum in recent months has generated plenty of interest in scaling solutions, and in particular in Layer-2 (L2) scaling solutions. These can be broadly divided into two families: Validity Proofs vs. Fraud Proofs. We’ve compared these previously here and here.
Validity Proofs include ZK-Rollups (on-chain data availability) and Validium (off-chain data availability). Several such systems are already deployed on Ethereum Mainnet, including our own StarkEx.
Fraud Proofs include Optimistic Rollups (OR), and some of these are approaching public testnets. OR are the latest generation of Fraud Proof designs, and they follow in the footsteps of Lightning and Plasma. OR are attractive to any dApp developer suffering from congestion on Ethereum, as they promise the ability to take Solidity code “as is”, and move the dApp to a scalable and inexpensive OR.
The basic concept behind OR: only tx data is sent to the main chain. Computations and storage are no longer done on the main chain; instead, they are moved to the Rollup, where block producers and validators perform this computational work. System integrity is ensured by assuming at least one user will both detect and report fraud to the main chain in a timely fashion i.e. within a block’s Dispute Time Delay (DTD). Once the DTD is over, the block is considered finalized.
Analysis
Below we will analyze OR from the perspective of Liquidity Providers (LPs) and users.
Assume that an application as big as Uniswap migrates to an OR seamlessly, by easily porting their existing Solidity code. Let us consider this OR from the perspective of LPs and users.
Liquidity Providers (LPs)
As mentioned above, ORs define a Dispute Time Delay (DTD), to allow for frauds to be detected and reported. Withdrawal times need to extend beyond the DTD, otherwise the system could easily become insolvent as a result of theft.
Security considerations motivate extending the DTD, in order to make attacks such as the following, more expensive:
- An OR Validator detects fraud, and sends a fraud_detected tx to the mempool. They’ve supposedly filled their role: the fraud was detected and “reported”. But in order to be truly reported, fraud_detected needs to be mined.
- An attacker rents sufficient hash power (currently estimated at $300K/hour) for the duration of the DTD. The attacker works to mine blocks so as to replace any block presented that includes fraud_detected. Think of this as a silent attack on fraud_detected. Why silent? Because from the perspective of an innocent bystander, the network appears uneventful as ever — there were no $B tx mined, certainly no such tx reverted.
We claim that a tradeoff exists between capital efficiency and security. We will describe why it arises, and explain its implications. We will assume the duration of the DTD is 1 week (a proposal for a DTD of only 4.5 hours was proposed; some consider that dangerously short) — our analysis holds whether the DTD is 1 day or two weeks — it simply translates to a different point in the tradeoff curve between security and capital efficiency. Depending on the duration of the DTD, the attacker would have to spend anywhere between $Ms-$10Ms. The amount they would have to spend does not depend directly on the bounty the attacker is going after — if the OR holds $Bs, spending $Ms on an attack is a rational thing to do.
Opportunity cost dramatically impacts dApps, due to LPs actions — we’ve seen liquidity move from Uniswap to SushiSwap, and back again, in a matter of days. Compare OR-Uniswap, Uniswap on an OR, to ZKR-Uniswap, a Uniswap-fork on a neighboring ZK-Rollup. An LP now has the choice of locking their funds in OR-Uniswap for a week, or in ZKR-Uniswap for about 30 minutes (the proof generation cycle). ZKR-Uniswap has a fundamental advantage, one which tokenomics or other incentives will have a hard time beating in the long term.
We’re often asked: Wouldn’t Fast Withdrawals solve the problem? Doesn’t that level the playing field between OR and ZK-Rollups?
No. They would merely improve the UX by shortening the withdrawal time, without improving capital efficiency: sufficient funds would have to be locked in an L-1 smart contract to fund any withdrawal expected to occur during the entire DTD.
Furthermore, Fast Withdrawals can only be used for fungible assets, not NFTs. Even for fungible tokens, the opportunity cost of a token in demand could be prohibitively high. In fact, the opportunity cost is high exactly when many people want to trade a fungible asset in short supply: imagine the cost of provisioning enough YFI for a week’s worth of withdrawals, during that week when the entire DeFi space is hoping to trade them. If you were offered to lock your YFI for that peak-interest week, what return would you expect?
Some may claim LPs should not be concerned, as all of DeFi will simply gravitate to a single OR, allowing users to withdraw from it infrequently, and to transact there inexpensively.
Note this makes the strong assumption that no dApps would live outside this OR: not on L1, not on ZK-Rollups, etc.
We argue that even in this scenario, as the OR’s throughput increases, its security decreases. Why? Let’s consider the situation from the perspective of Alice, a user.
Users
- Trust: Alice may trust the OR, or more specifically, that there is at least one party that validates the current state of the OR. This means that from Alice’s perspective, the OR is essentially a trusted system. Trusted systems work at astonishing scale, and are often the foundation of very valuable businesses (e.g. Coinbase, Binance, and conventional banks) — these businesses work hard not to betray trust, as their reputation is on the line.
- Trustless: Alice can validate the state of the OR herself. Unfortunately, the cost of validating an OR scales linearly with its throughput: if the OR scales Ethereum by 20X, for example, the computational load for validating the OR’s state will also increase 20X, as will the cost of validation. Validation of a high throughput OR will become an exercise for the rich and interested few.
This is not an abstract concern even today: validating Ethereum currently is an altruistic activity. Some consider current validation costs on Ethereum to be non-negligible, to the point they hurt decentralization: fewer network participants validate its integrity because of the expense. In other words, reduced decentralization and reduced security are in this regard a real concern.
Conclusion
ORs face a dilemma: They cannot match the capital efficiency of ZK-Rollups, as this will hurt the OR’s security. This is an inherent problem of OR, not a design detail. Because of this, any application faced with the choice of running on an OR or a ZK-Rollup, will prefer the latter, as that is where its Liquidity Providers will go.
Thanks to Dan Robinson for commenting on a draft of this post.
