Everything You Need to Know About Optimistic Rollups
Editor's Note: This article comes fromChain News ChainNews (ID: chainnewscom), published with permission.
Editor's Note: This article comes from
Chain News ChainNews (ID: chainnewscom)
Chain News ChainNews (ID: chainnewscom)
, published with permission.
Written by: Georgios Konstantopoulos, research partner at crypto venture capital firm Paradigm.
Compiler: Zhan Juan
Paradigm authorized Lianwen to translate and publish the Chinese version of the article.
In the Ethereum ecosystem, one of the biggest challenges is how to achieve low latency and high throughput under severe resource constraints (such as CPU, bandwidth, memory, disk space).
The decentralization of the system is determined by the ability of the weakest node in the network to validate the rules of the system. A high-performance protocol that can run on low-resource hardware can be called "scalable".
In this post, we'll dig into how current "layer 2 solutions" work, their corresponding security models, and how they address Ethereum's scalability issues.
If you are interested in learning more about the cutting-edge scalability technologies of Ethereum, and how to build and architect such systems, then this article may be helpful for you.
Throughout the article, important key words or concepts are highlighted in bold, these are words/terms that you will come across while learning about cryptocurrencies. This topic is complex. Maybe you will feel a little confused in the process of reading, but as long as you persist in reading it, I believe you will gain something.
Blockchain Resource Requirements
There are three factors that affect the resource requirements to run a node in a decentralized network such as Bitcoin and Ethereum:
Bandwidth: The cost of downloading and broadcasting any blockchain-related data.
Computation: The cost of running a computation in a script or smart contract.
Storage: The cost of storing transaction data for indexing, and the cost of storing "state" for continuing to process new transaction blocks. It's worth noting that storing "state" (account balances, contract bytecodes, nonce values) is more expensive than storing raw transaction data.
There are 2 ways to measure performance:
Throughput: The number of transactions a system can process per second.
Latency: The time required for transaction processing.
Decentralization is a desirable attribute of emerging crypto networks like Bitcoin and Ethereum, but what are the ingredients that make a network decentralized?
Low trust: This property allows any individual to verify that the number of bitcoins does not exceed 21 million, or that their bitcoins cannot be counterfeited. Someone independently running the node software computes the latest state and verifies that all rules are being followed in the process.
Low cost: If node software is expensive to operate, individuals will rely on trusted third parties to verify state. High cost means high trust requirements, which is what we want to avoid in the first place.
Another desired property is scalability: the ability to scale throughput and latency superlinearly to the cost of running the system. That's a good definition, but it doesn't include "trust". Thus, we define "decentralized scalability": achieving scalability without significantly increasing the system's trust assumptions.
To zoom in, the runtime environment of Ethereum is the Ethereum Virtual Machine (EVM). Transactions run through the EVM perform various operations at different costs, for example, a store operation is more expensive than an add operation. The calculation unit in a transaction is called "gas". The system parameters are set to process a maximum of 12.5m gas per block, and a transaction block is generated every 12.5 seconds on average. Therefore, Ethereum has a latency of 12.5 seconds and a throughput of 1 million gas per second.
You may ask: what benefit does 1 million gas per second bring?
~47 "simple transfer" transactions per second. These transactions consume 21,000 gas, are responsible for transferring ETH from A to B, and are the simplest type of transaction.
~16 ERC20 token transfers per second. Compared to ETH transfers, these methods involve more storage operations and thus cost ~60k gas each.
~10 Uniswap asset transactions per second. The average cost of a token-to-token transaction is about 102k gas.
…pick the gas cost of any transaction you like and divide it by 1m (12.5m / 12.5 /gas)
Note that as the transaction execution complexity increases, the throughput of the system decreases to very low values. There is still room for improvement!
Solution 1: Use an intermediary
We can use a trusted third party to facilitate all transactions. This way, we can achieve very high throughput, and the latency may only be sub-second. Great! This won't change any system-wide parameters, but we will opt-in to the trust model unilaterally set by the third party. They may choose to censor us or even confiscate our assets. This is not desirable.
Solution 2: Make blocks bigger and more frequent
We can reduce latency by reducing the time between two blocks, and we can increase throughput by increasing the block gas limit. This change will make it more expensive to operate a node, making it difficult for individuals to run a node (this has already happened with EOS, Solana, Ripple, etc.).
In Solution 1, the need for trust increases. In option 2, the cost increases. This eliminates them as a scalability option.
Starting from first principles, rediscover Optimistic Rollup
In the next section, we assume that the reader has some familiarity with hashes and Merkle trees.
Based on what we have learned so far, let's simulate a Socratic dialogue with the goal of discovering a protocol that increases the effective throughput of Ethereum without burdening users and node operators.
Q: We want to scale Ethereum without significantly changing trust and cost assumptions. how should I do it?
A: We want to reduce the system cost requirements for existing operations (see above for the three resource types). To understand why this is not easy to do, we need to first look at Ethereum's architecture:
Every node in Ethereum currently stores and executes every transaction submitted to it by a user. During execution, transactions run through the EVM and interact with the state of the EVM (such as storage, balances, etc.) - an operation that is very expensive. Common smart contract optimization techniques center on minimizing the number of interactions with state, but they only provide small constant improvements.
Q: Are you saying there is a way to do transactions without involving state, keeping resource costs low?
A: In the extreme case, can we move all execution off-chain while keeping some data on-chain? We can do this by introducing a third party called a "sequencer". They are responsible for locally storing and executing user-submitted transactions. To keep the system alive, orderers need to periodically commit the Merkle root of the transactions they receive and the state root generated on Ethereum. This is a step in the right direction, as we only store O(1) data in Ethereum's state for O(N) off-chain transactions.
Q: So we scale by having the sorter compute everything off-chain and only publish the Merkle root?
Answer: Yes.
Q: OK, so once you join, the orderer guarantees you cheap transfer fees. So how will deposits and withdrawals work?
Answer: Users will enter the system by depositing money on Ethereum, and then the orderer will credit the corresponding amount to the user's account. Users can propose such transaction content on Ethereum, for example, "I want to withdraw 3 ETH, my account currently has > 3 ETH, this is proof". Even if there is no actual user state at layer 1, the user can come up with the state root published by the orderer to show the relevant Merkle proof that they have sufficient funds in the current state.
Q: Now we know that users need Merkle proofs to withdraw their funds. How do users get the data to build Merkle proofs?
A: They can ask the sorter to give them data!
Q: What if the sorter is temporarily or permanently unavailable?
A: The sorter could be malicious, or it could simply be offline due to a technical issue, which would cause performance degradation (or worse, steal your assets!). Therefore, we must also require the orderer to submit complete transaction data on-chain for storage, but not execution. In this problem, the goal is to obtain data availability. Assuming all data is permanently stored on Ethereum, even if an orderer disappears, new orderers can retrieve all layer 2 related data from Ethereum, reconstruct the latest layer 2 state, and depart from their predecessors place to continue.
Q: If the orderer is online but refuses to provide me with Merkle proof data, can I download it from Ethereum?
A: Yes, you can sync an Ethereum node yourself, or connect to one of the many managed node services.
Q: One thing I still don't understand is how can you store something in Ethereum and not execute it? Doesn't every transaction go through the EVM?
Answer: Suppose you submit 10 transactions to transfer ETH from A to B. Executing each transaction will do the following: increase A's nonce, decrease A's balance, and increase B's balance. This involves quite a few writes and reads from Ethereum's world state. Instead, you can send encodings of all transactions to the smart contract's publish(bytes_transactions) public { } function. Note that the body of the function is empty! This means that the published transaction data is not interpreted, executed, or accessed anywhere, it is just stored in the history log of the blockchain (the cost of writing is very low).
Q: Can we trust the sorter? What if they issue an invalid state transition?
A: Any time the orderer publishes a batch of state transitions, there is a "dispute period" during which either party can issue a "proof of fraud" to show that one of the state transitions is invalid. This can be demonstrated by replaying on-chain the transaction that caused the state transition, and comparing the resulting state root with the state root published by the orderer. If the state roots do not match, the fraud proof succeeds, and the state transition is canceled. If there are more state transitions following the invalid state transition, they will also be canceled. But if transactions have passed the dispute period, they can no longer be challenged and they are considered final.
Q: Wait a minute! You said earlier that if it a) increases costs, or b) introduces new trust assumptions, then it doesn't qualify as scalability. In the scenario you describe, don't we additionally assume that someone will always report fraud?
Answer: Yes. We assume the existence of an entity called a "validator" who monitors for fraud and publishes proof of fraud if the state of layer 1 and layer 2 does not match. We also assume that validators can reliably obtain fraud proofs contained in Ethereum within the dispute period. We consider the existence of validators to be a "weak" assumption. Imagine having an application with thousands of users and you only need one person to run a validator. That doesn't sound too far off the mark! On the other hand, changing the trust model of Ethereum, or increasing the operating costs of Ethereum nodes are "strong" assumptions that we don't want to change. This is what we mean by "significantly changing the assumptions of the underlying system" when we define decentralized scalability.
Q: I agree that someone will run a validator because all parties benefit from the success of this new solution. But of course it also depends on the cost of the actual operation. So what are the resource requirements for running a validator and a sorter?
A: Orderers and validators must run an Ethereum full node (not an archive node), a full layer 2 node, in order to generate layer 2 state. The software run by verifiers is responsible for creating fraud proofs, and the software run by orderers is responsible for bundling user transactions and publishing them.
Q: Is that so?
Answer: Yes! congratulations! You've rediscovered Optimistic Rollup (Optimistic Rollup is a combination of "Optimistic Contracts" and "On-Chain Data Availability" (aka "Data Aggregation")), the most anticipated scaling solution of 2019-2021. It's easy to understand why, as it's the end product of a years-long research process by the Ethereum community, which you should have already experienced in this brief conversation above.
Optimistic Incentives
Layer 2 scaling is based on the fact that we try to minimize the number of on-chain transactions performed. We use fraud proofs to cancel any invalid state transitions that might occur. Since fraud proofs are on-chain transactions, we also want to minimize the number of fraud proofs issued on Ethereum. In an ideal world, fraud never occurs, and therefore, proof of fraud is never issued.
We curb fraud by introducing fidelity bonds. In order for a user to become a sorter, they must first post a bond on Ethereum, which they forfeit if proven fraudulent. To incentivize individuals to detect fraud, orderer bonds are distributed to validators after being slashed.
Loyalty Bonds and Dispute Periods
When designing incentives for fraud proofs, there are two parameters to tune:
Loyalty Bond Size: Orderers must publish the amount distributed to validators. The larger the scale, the greater the incentive to be a validator and the less incentive to cheat as an orderer.
Dispute Period Duration: The window of time within which fraud proofs can be issued, after which layer 2 transactions are considered safe on layer 1. A longer dispute period provides better security against censorship attacks. A shorter dispute period creates a good user experience for users withdrawing from layer 2 to layer 1, as they don't have to wait long to have their funds re-used on layer 1.
In our opinion, it is not possible to find an exact static value for both parameters. Maybe 10 ETH bonds and a 1-day dispute period would suffice. But maybe 1 ETH and 7 days is enough. The real answer is that it depends on the incentive to be a validator (which depends on running costs), and how easy it is to issue fraud proofs (which depends on layer 1 congestion). Both of these should be adjustable, either manually or automatically.
It’s worth mentioning that EIP1559 introduces a new BASEFEE opcode to Ethereum that can be used to estimate on-chain congestion and thus programmatically adjust the duration of the dispute period.
How to implement this penalty mechanism correctly is crucial, otherwise it will be abused in practice. Let me give an example to illustrate what is a naive and unrealistic implementation:
Alice posts a 1 ETH bond, which allows her to act as an orderer in the system
Alice posts a fraudulent status update
Bob notices this and publishes a controversy. If successful, this would award 1 ETH in Alice's bond to Bob, and cancel the fraudulent state update
Alice noticed the controversy and posted one too (challenging herself!)
ALice got her 1 ETH, and even though she tried to cheat, she actually got no penalty.
Alice can launch this attack by "running ahead", that is, broadcasting the same transaction as Bob, but with a higher gas price, causing Alice's transaction to be executed before Bob. This means Alice can keep trying to cheat with minimal cost (only Ethereum transaction fees).
The solution to this problem is simple: instead of awarding the entire bond to the disputant, burn X% of the bond. In the above example, if we burn 50%, Alice will only get 0.5 ETH, which is enough to stop her from trying to cheat in step 2. Of course, burning the bond reduces the incentive to run a validator (since the payout becomes less), so it needs to be ensured that the bond burnt is still sufficient to incentivize users to become validators.
Common criticisms of Optimistic Rollup and our responses
Now that we have completed the building blocks of Optimistic Rollup, let's explore and address the most popular criticisms of the mechanism.
Long withdrawal/dispute periods are fatal to adoption and composability
We mentioned above that long dispute periods are good for security. There seems to be an inherent trade-off here: a long dispute period is bad for users, who have to wait a long time if they want to withdraw their funds. A shorter dispute period certainly makes for a smooth user experience, but then you run the risk of fraud happening.
We don't think that's a problem. With the potential for lengthy withdrawal delays, we expect market makers to step in quickly and offer faster withdrawals. This is possible because the person validating the layer 2 state can correctly judge whether a withdrawal is likely to be fraudulent, and thus "buy" their service at a small discount. for example:
Participants:
Alice: There are 5 ETH on layer 2.
Bob: In the "market maker" smart contract, there is 4.95 ETH on layer 1, and there is a validator running on layer 2
step:
Alice lets Bob know she wants a "fast" withdrawal and pays him a fee of 0.05 ETH
Alice sends a cash request to Bob's "market maker" smart contract
Two things can happen at this point:
Bob checks that the withdrawal is valid on his layer 2 validator and approves the fast withdrawal. This will immediately transfer 4.95 ETH to Alice's layer 1 address. After the withdrawal period is over, Bob can claim the 5 ETH, making a net profit.Simple Fast WithdrawalsBob's validators alert him that the transaction is invalid. Bob disputes the state transition caused by the transaction, cancels the transaction, and earns his bond for allowing the malicious transaction to occur.
Alice can either be honest and take the money out immediately, or be dishonest and be punished. We expect the fees paid to market makers to compress over time, eventually making the process completely invisible to users if there is demand for the service.
The most important implication of this feature is that it enables composability with layer 1 contracts without having to wait for a full dispute period.
Note that this technique was first introduced in "
"(Simple and Quick Withdrawal)" described in the article.
Miners can bribe to censor withdrawals, breaking Optimistic Rollup security
In the post "Optimistic Rollup's Near-Zero-Cost Attack Scenario", some people believe that the incentives of miners are too large, which will cause the orderer to collude with Ethereum miners and be unwilling to review any disputed transactions. Of course, given the reliance of system security on dispute resolution, this is fatal to any Optimistic system.
Validator's Dilemma Inhibits Operating Validators, Breaking Optimistic RollupanalyzeandsolutionEd Felten wrote an excellent article on the validator's dilemma
analyze
and
solution
, we summarize as follows:
If the incentives of the system work as intended, no one will cheat
There's no point in running a validator if no one is cheating because you can't make money from operating it
The sorter cheated and the system no longer behaved as expected
in conclusion
This sounds important, almost paradoxically. Assuming a fixed reward size, more validators reduce the expected reward for a single validator. Also, with more validators, there seems to be less pie and less fraud, which further exacerbates the problem. In a follow-up analysis, Felten also provides a solution to the validator's dilemma.
I want to take the opposite stance here, and I don't think the plight of validators is as important as the critics say. In practice, there are non-monetary incentives to be a validator. For example, you might build a large application on a pooled platform, and you might hold tokens, and if the system fails, then your application won't work, or your tokens will lose value. Beyond that, the need for fast withdrawals creates an incentive for market maker validators to exist (as we saw in the previous section), which is not immune to fraud. To be more specific, Bitcoin does not provide any incentive to store the entire blockchain history or provide your local data to peers, yet people do so altruistically.
Even though running validators in a vacuum is not incentivized, it keeps the system secure, which is the most important thing for entities invested in the system's success. Therefore, we believe that in Layer 2 of an Optimistic system, there is no need to devise mechanisms to bypass the validator's dilemma.in conclusionWe analyze one of the technologies that will be crucial to Ethereum in 2021: Optimistic Rollup.
To summarize its benefits: Optimistic Rollup is an extension of Ethereum that carries the security, composability, and developer moat of Ethereum, while improving performance without materially impacting the cost or trust needs of Ethereum users . We explore the incentive structures that make Optimistic Rollups work and respond to common criticisms.BLS Signature Aggregationof), 2) have a big and cheap data layer (eg ETH2).As additional reading, we recommend Buterin's On Rollup and
