The Complete Guide to Optimistic Rollups: Here's Everything You Need to Know

Original title: "The most complete guide to Optimistic Rollup: Here is everything you should know"

Original source: Babbitt

Note: The original author is Georgios Konstantopoulos, a researcher at Paradigm Fund.

One of the biggest challenges facing the Ethereum ecosystem is low latency under tight resource constraints such as CPU, bandwidth, memory, and disk space and high throughput.

The degree of decentralization of a system depends on the ability of the weakest node in the network to verify the rules of the system. We believe that high-performance protocols that can run on low-resource hardware are "scalable".

In this article, we will delve into the principles of modern "Layer 2 solutions", their corresponding security models, and how they address Ethereum's scalability question.

The target audience for this article is curious individuals interested in learning more about advanced Ethereum scaling techniques, and motivated to build and architect population of such systems.

Blockchain resource requirements

There are three factors that will affect the Resource requirements for running 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 computations in scripts or smart contracts;

Storage: the cost of storing transaction data for indexing purposes, and storing the "state" in order to continue processing new transaction blocks "the cost of.

Performance is measured in two ways:

Throughput: system per second The number of transactions that can be processed;

Latency: the time it takes to process a transaction;

Ideal for emerging crypto networks such as Bitcoin and Ethereum The characteristic is decentralization. But what makes the web decentralized?

Low trust: This property allows anyone to verify that the total amount of bitcoins is not 21 million BTC, or that there are no counterfeit bitcoins. Individuals who run the node software independently calculate the latest state and verify that all rules have been followed in the process;

Low cost: If the node software is expensive to operate, the individual will rely on a trusted third party to verify state. High costs imply high trust requirements, which we want to avoid in the first place.

Another desirable property is scalability: the ability to scale throughput and latency super-linearly to the cost of running the system. That's a good definition, but it doesn't include "trust". Therefore, we designate "decentralized scalability": that is, to achieve scalability without significantly increasing the system's trust assumptions.

Zooming 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 costs more than an add operation). The calculation unit in a transaction is called "gas", and the system is parameterized to process a maximum of 12.5 million Gas per block, with an average transaction block generated every 12.5 seconds. Therefore, Ethereum has a latency of about 12.5 seconds and a throughput of 1 million gas per second.

You may encounter such a problem: 1 million gas per second, what can you use it for?

About 47 simple transfer transactions per second, these transactions cost 21000 gas each, they are the simplest transaction types, such as transferring ETH from address A to To address B;

About 16 ERC20 token transfers per second, compared with ETH transactions, these transactions involve more storage operations, so each time will cost about 60000 gas;

and so on;

Please note that as transaction execution complexity increases, the throughput of the system decreases to very low values. There is still room for improvement!

Solution 1: Use mediation

We can utilize a trusted third party to facilitate all our transactions. In this way, we can get very high throughput and possible second-level latency, which is great! This doesn't change any system-wide parameters, but we do opt into a trust model unilaterally set by third parties. They may choose to censor us, or even seize our assets, which is not desirable.

Solution 2: Make the block bigger and shorten the block interval< /p>

We can reduce latency by shortening the time between two blocks, and we can increase throughput by increasing the block gas limit. But this change will make node operation more expensive, thereby preventing individuals from running nodes (such as EOS, Solana, Ripple, etc. are using this method).

We can see that solution 1 increases the trust requirement, while solution 2 increases the cost. This makes neither solution a good choice for scalability.

From first principles Understanding Optimistic Rollup

In this part, we assume The reader understands the concept of hashes and merkle trees.

Based on what we've learned so far, let's simulate some Socratic dialogue with the goal of discovering a protocol that increases the effective throughput of Ethereum without increasing the burden on users and node operators.

Q: So...we want to scale Ethereum without changing trust and cost assumptions. what should we do?

Answer: We want to reduce the system cost requirements of our existing operations (see three resource types above). In order to understand that it is not an easy task to implement it, we first need to understand the architecture of Ethereum:

Each node in Ethereum currently stores and executes every transaction that a user submits to it. During execution, transactions run through the EVM and interact with the state of the EVM (such as storage, balances, etc.), which is very expensive. Common smart contract optimization techniques focus on minimizing the number of interactions with state, but they only provide small constant factor improvements.

Q: Are you saying that there is a transaction method that does not affect the state, thereby reducing resource costs?

Answer: In the limit case, we can move all execution off-chain and keep 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. In order to keep the system alive, sequencers need to periodically commit the merkle root of their received transactions and the state root generated on Ethereum. This is a step in the right direction, because for O(N) off-chain transactions, we only store O(1) Ethereum state data.

Q: So we do this by having the serializer count everything off-chain and only publish the merkle root To achieve expansion?

Answer: Yes.

Q: Ok, once you join the sequencer will guarantee your transfers are cheap , how do deposits and withdrawals work?

Answer: Users will enter this system by making deposits on Ethereum, and the sequencer will credit the corresponding amount to the user's account. A user withdraws funds back to the Ethereum mainnet by doing a transaction "I want to withdraw 3 ETH, my account currently has >3 ETH, this is its proof". Even if L1 has no actual user state, **users can prove that they have sufficient funds in the current state by showing a merkle proof referencing the state root issued by the sequencer.

Q: We determined that users need a merkle proof to be able to withdraw their Funds, how do users obtain data to construct merkle proofs?

Answer: They can ask the serializer to give them data!

Q: But what if the sequencer is temporarily or permanently unavailable?

Answer: The sequencer could be malicious, or simply offline due to a technical issue, which would cause performance degradation (or worse Funds stolen!) Therefore, we must also require sequencers to submit full transaction data on-chain for storage but not execution. The purpose here is to obtain data availability. Assuming all data is permanently stored on Ethereum, even if a sequencer disappears, a new sequencer can retrieve all Layer 2 related data from Ethereum, reconstruct the latest L2 state, and continue from where it left off.

Q: So if the sequencer is online but refuses to give me the merkle proof data, can I Download it via ethereum?

Answer: Yes, you can sync the Ethereum node yourself, or you can connect to one of the many hosted node services.

Q: So I still don't get it...how can you store something on Ethereum while Do not implement it? Doesn't every transaction go through the EVM?

Answer: Assuming you submit 10 transactions to transfer ETH from address A to address B, executing each transaction will do the following: Increase A's nonce, decrease A's balance, and increase B's balance. That's quite a few writes and reads from the world state. Instead, you can send the encoding of all transactions to the smart contract's publish(bytes_transactions) public{} function. Note that the body of this function is empty! This means that published transaction data is not interpreted, executed, or accessed anywhere: it is simply stored in the blockchain's history log (which is cheap to write).

Q: Can we trust the sequencer? What if they issue an invalid state transition?

Answer: Whenever the sequencer releases a batch of state transitions, there will be a "dispute period". can issue a "fraud proof" to show that one of the state transitions is invalid. Proof by rebroadcasting the transaction that caused the on-chain state transition, and comparing the resulting state root with the state root published by the sequencer. If the state roots do not match, the fraud proof succeeds and the state transition is canceled. If there are more state transitions after the invalid state transition, they will also be canceled. Transactions beyond the dispute period will no longer be disputed and will be considered final.

Q: Wait a minute! You said before that you can't really scale if a) it adds cost, or b) it introduces new trust assumptions. So in the scenario you describe, don't we additionally assume that someone is always reporting fraud?

Answer: Yes, we assume that there are entities called "validators" who are responsible for monitoring fraudulent behavior, if Layer 1 and Layer 2 state No match, and they issue a fraud proof. 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 tens of thousands of users, and you only need one person to run one validator. This still sounds very possible, on the other hand, changing Ethereum's trust model or increasing the cost of operating an Ethereum node are "strong" hypothetical changes that we don't want to make. This is what is meant by "intentionally changing the assumptions of the underlying system" when we define decentralized scalability.

Q: I agree that someone will come and run a validator because many participants are interested in this new solution The success of the program has vested interests. But for sure, it also depends on the actual cost. What are the resource requirements for running validators and sequencers?

Answer: The sequencer and validator must run an Ethereum full node (not an archive node), a complete L2 node, to generate L2 state. The software run by validators is responsible for creating fraud proofs, while the software run by sequencers is responsible for bundling user transactions and publishing them.

Q: Is this the case?

Answer: Yes! congratulations! You have rediscovered Optimistic Rollup [3], the most anticipated scaling solution for 2019-2021. It is the culmination of years of research by the Ethereum community, which you can experience in the brief conversation above.

Incentives in Optimistic Summary

Layer 2 scaling is based on the fact that we try to minimize the number of transactions executed on-chain. 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 would never happen, so fraud proofs would not need to be published.

We are eliminating fraud by introducing a loyalty guarantee. In order for a user to be able to set up a serializer, they must first post a bond on Ethereum, and if the fraud is proven, the funds are forfeited. To incentivize individuals to find fraudulent behavior, the security deposit of sequencers is slashed and distributed to validators who find fraudulent behavior.

Loyalty Deposit and Dispute Period

When designing incentives for fraud proofs, two parameters need to be adjusted:

Loyalty deposit size: that is, the establishment of a sequencer must The amount of funds locked, which are also the targets for validators to pursue. Obviously, the larger this amount, the greater the incentive to become a validator and the less incentive for a sequencer to commit fraud.

Dispute Deadline: The window of time in which fraud proofs are issued after which L2 transactions are considered safe to settle on L1. The long dispute period is to provide better security against censorship attacks. A shorter dispute period creates a better experience for users as they don't have to wait long to have their funds re-used on L1.

In our opinion neither parameter has correct static value, maybe 10 ETH deposit and 1 day dispute period is enough. Maybe a 1 ETH bond and a 7 day dispute period would be okay too. The real answer is that it depends on your motivation as a validator (which depends on the cost of running a validator) and how easy it is to issue fraudulent proofs (which depends on how congested L1 is). Both of these should be adjustable, either manually or automatically. It is worth mentioning that EIP1559 introduces a new BASEFEE opcode for Ethereum that can be used to estimate on-chain congestion and thus programmatically adjust the duration of the dispute period.

The correct implementation of this penalty mechanism is crucial, otherwise it will be exploited in practice. Here's an example of a simple implementation that doesn't work:

Alice stakes a 1 ETH deposit, which allows her to build a sequencer;

Alice posts a fake status update;

Bob notices this and initiates a dispute challenge, which, if successful, causes Alice's 1 ETH deposit to be transferred to Bob's account, and Cancel the fraudulent status update;

Alice noticed the dispute challenge, she also launched a dispute challenge (challenge herself!);

Alice received her own 1 ETH, in fact she did not did not pay the penalty, even though she tried to cheat;

Alice can attack by "front-running", broadcasting the same transaction as Bob, but paying a higher The gas fee, which causes Alice's transaction to execute before Bob's. This means Alice can always try to cheat with minimal cost (only Ethereum transaction fees).

The solution to this problem is simple: instead of awarding the entire bond to the dispute challenger, burn X% of it. In the example above, if we burned 50%, Alice would receive 0.5 ETH in return, which would be enough disincentive to prevent her from trying to cheat a second time. Of course, this burning mechanism will reduce the incentive for users to run validators (because the rewards become smaller), so the bond reward after burning should be enough to attract validators.

Criticisms of Optimistic Aggregation and Our Responses

Now that we have completed the fundamental building blocks of optimistic aggregation, let's explore and address some of the criticisms against the mechanism.

Issue 1: Long exit/dispute periods are bad for adoption and composability Yes, this is fatal

As we mentioned above, a long dispute period is of great benefit to security, but here it seems There is an inherent trade-off problem: long dispute periods are bad for adoption, because any user who wants to withdraw funds from it will have to wait a long time, say 7 days. And a shorter dispute period, although it can have a smoother experience for users, but it needs to take the risk of fraud, and no dispute will be included in time.

We don't see this as an issue and with this potentially massive delisting delay we expect market makers to step in and offer faster delisting Serve. This is possible because someone who verifies the L2 status, can correctly determine whether a withdrawal is fraudulent, and thus buy their services at a small discount. Here is an example:

Participants:

Alice has 5 ETH on L2; Bob: "Market Maker" smart contract 4.95 ETH on L1 and validator running on L2;

Steps:

Alice lets Bob know she wants "fast" Withdraw, and offer him a fee of 0.05 ETH;

Alice initiates a withdrawal transaction to Bob's "market maker" smart contract;

Two things may happen : (1) Bob checks on the L2 validator that the withdrawal is valid and approves the quick withdrawal. This immediately transfers 4.95 ETH to Alice's L1 address. After the withdrawal period ends, Bob can claim 5 ETH, making a tidy profit.

(2) Bob's validator reminds him that the transaction is invalid, Bob disputes the state transition caused by the transaction, cancels the transaction and wins A sequencer bond that allows malicious transactions to occur.

Alice can either be honest and take out her funds immediately, or be dishonest and be punished. If there is demand for this service, we expect the fees paid to these market makers to compress over time, eventually rendering the program completely invisible to users.

The most important implication of this feature is that it can be combined with L1 contract implementations without having to wait for the entire dispute period.

Please note that this technology was first introduced in the "Easy and fast withdrawal".

Question 2: Miners may be bribed to review withdrawals, breaking OR security

span>

In the Optimistic Aggregation Near-Zero-Cost Attack Scenario, one could argue that miners are so incentivized that sequencers are It is trivial for miners to conspire to censor any disputed transaction. Given the reliance on security, this is fatal to any optimistic system.

We disagree with this view, we believe that honest parties will always be willing to bribe miners, even more than malicious parties. Additionally, miners pay an additional price each time they deviate from "honest" behavior by helping a malicious party win. Such behavior destroys the value of Ethereum, which may increase the cost of miners participating in Ethereum.

In fact, this situation has been studied in the academic literature, demonstrating that "this threat of counterattack leads to a subgame perfect equilibrium in which No one will attack first."

We would like to thank Hasu for his thesis evidence.

Problem 3: The dilemma of the verifier, which creates obstacles that hinder the operation of the verifier

Ed Felten has written some excellent analysis and solutions to the validator's dilemma, which we summarize below:

If the incentives of this system work as intended, no one will cheat;

If no one cheats, then there is no point in running validators, because running validators does not make money ;

Because no one is running a validator, the sequencer will eventually have a chance to cheat;

The sequencer cheats and the system no longer behaves as expected;

< br>

Sounds like this is important, and almost paradoxical! Assuming the size of the reward is fixed, more validators reduce the expected payout for a single validator. Additionally, more validators seem to shrink the reward size, since less fraud occurs, further exacerbating the problem. In a follow-up analysis, Felten also provides a solution to the validator's dilemma.

I would like to take the opposite position and say that the plight of validators is not as important as the critics say. In practice, there are non-money-related incentives to be validators. For example, if you are a large app provider built on rollup, or you are a token holder, if the system fails, then your app will not work, or your tokens will be worth less. Beyond that, the need for fast withdrawals creates an incentive for the presence of market maker validators (as discussed in the previous section), independent of fraud. To put this in more concrete terms, Bitcoin does not provide an incentive to store the entire blockchain history or to provide your local data to peers, but people will do so altruistically anyway.

Even if running validators in a vacuum is incompatible with incentives, it keeps the system secure, which is the best option for entities invested in the system's success important. Therefore, we see no need to devise mechanisms to address the validator's dilemma in optimistic second-layer systems.

Conclusion

Consistent with the title of the article, we analyze one of Ethereum's most important technical solutions in 2021: Optimistic Rollup.

To summarize the benefits of this solution: OR, as an Ethereum expansion solution, inherits the security, composability and developer moat while improving performance without materially impacting cost or trust requirements for Ethereum users. We explore the incentive structures that make optimistic aggregation work and respond to common criticisms.

As additional reading, we recommend Vitalik's "An Incomplete Guide to Rollup and Trust Models" article, and we also recommend researching OR's close relative ZK Rollup, our friends at StarkWare built this type of solution. Finally, there are other approaches to decentralized scalability, such as sharding and state channels, which also have their own pros and cons.

We would like to thank Hasu, Patrick McCorry, Liam Horne, Ben Jones, Kobi Gurkan, and Dave White for their valuable feedback on this article.

Original link

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia