Partnered With:

Everything you need to know about Optimistic Rollup (Part 1)

Read this article in 18 Minutes

Rediscover Optimistic Rollup.

Original title: "Dry goods | Everything you need to know about Optimistic Rollup (Part 1)"

Original source: Ethereum enthusiasts

One of the biggest challenges of the Ethereum ecosystem is how to achieve low latency and high throughput with limited resources (eg, CPU, bandwidth, memory, disk space).

The degree of decentralization of the system depends on the ability of the weakest node in the network to verify the rules of the system. A high-performance protocol that can run on low-resource hardware is said to be "scalable".

In this article, we will delve into the principles of modern "Layer 2 schemes", the security models of these schemes, And its strategy to solve the scalability problem of Ethereum.

The intended audience of this article is those who are interested in cryptography. If you want to learn more about Ethereum's cutting-edge scalability technology, and how to design and build such systems, don't miss this article.

Blockchain resource requirements

In decentralized networks such as Bitcoin and Ethereum, there are three main resource requirements for running nodes [1]:

< p line="ZM8M">Bandwidth: The cost of downloading and broadcasting blockchain-related data.

Computation: The cost of running a computation in a script or smart contract.

Storage: the cost of storing transactional data for indexing purposes, and for continuing to process new transaction blocks" State" cost [2].

Factors affecting performance are:

Throughput: The number of transactions that the system can process per second.

Latency: The time it takes to process a transaction.

A desirable property of emerging cryptocurrency networks such as Bitcoin and Ethereum is decentralization. So the question is, how does the network achieve decentralization?

Low Trust: With this feature, anyone can self-verify that the total supply of Bitcoin will never More than 21 million, and the bitcoins they hold are not counterfeit. People who run the node software can independently calculate the latest state and verify that the block production process follows all the rules.

Low cost: If the node software is expensive to run, people will choose to rely on trusted third parties for verification state. High cost means high trust requirements, which is something we try to avoid.

Another desirable property is scalability: throughput (and latency) can scale with the cost of running nodes Superlinear growth (decrease). This definition is great, but it does not specify the inertia of "trust". Therefore, we additionally define "decentralized scalability": the ability to scale with little or no increase in system trust assumptions.

The runtime environment of Ethereum is EVM (Ethereum Virtual Machine). In the EVM, transactions carry different costs when performing different operations (for example, a store operation is more expensive than an add operation). The unit of calculation for a transaction is called "gas". In the Ethereum system, the gas limit for each block is set to 12.5 million gas. On average, a block can be mined every 12.5 seconds. From this, the latency of Ethereum is 12.5 seconds, and the throughput is 1 million gas per second.

You may ask a question: What can 1 million gas per second do?

About 47 Simple Transfer transactions per second. The so-called "simple transfer" transaction refers to the most basic transaction such as "A transfers a sum of ETH to B". Each transaction requires 21,000 gas.

Around 16 ERC20 token transfers can be done per second. Such transactions require more storage operations than ETH transfer transactions, so each transaction requires about 60,000 gas.

About 10 Uniswap asset exchange operations can be completed per second. The average cost of a token pair transaction is around 102k gas.

...Select the transaction you are interested in, divide 1 million gas by its gas consumption (12.5 million/ 12.5/gas).

Please note that as the transaction execution complexity increases, the throughput of the system drops sharply. There is still a lot of room for improvement!

Option 1: Use an intermediary

We A trusted third party can be used for all transactions. This way, we can get very high throughput with sub-second latency. a! This also doesn't change any system parameters, but we need to participate in a trust model unilaterally set by a third party. Third parties may censor us and even take our assets, which is not good.

Scheme 2: Expand block capacity and increase block frequency

We can reduce the delay by reducing the block generation time, and we can also increase the throughput by increasing the block gas upper limit. This change will likely result in higher node operating costs, discouraging people from running nodes (like EOS, Solana, and Ripple).

Option 1 would increase the need for trust and option 2 would increase the cost. Therefore, neither is an ideal scalability solution.

Re-acquaint Optimistic Rollup

Next, some knowledge about hash functions and Merkle trees will be involved.

After knowing so much, let's simulate a Socratic dialogue and see if we can find a A protocol that can increase the actual throughput of Ethereum without increasing the burden on users and node operators.

Q: We want to improve the scalability of Ethereum without changing its trust and cost assumptions. what should we do?

Answer: You can try to reduce the cost of existing operations (see the three types of operations above). However, this is easier said than done, let’s take a look at the architecture of Ethereum first:

In the Ethereum network Every node in the currently stores and executes every transaction from a user. Transactions are executed in the EVM and interact with the state of the EVM (e.g., contract storage items, balances, etc.) (this is expensive). Common smart contract optimization techniques focus on minimizing the number of interactions with state, but they do so to a limited extent.

Q: Is there a way to achieve interaction without interacting with the state, thereby reducing resource costs?

Answer: In extreme cases, can we move all execution off-chain and keep the data on chain? We can introduce a third party, namely, a sequencer, to do this. The orderer is responsible for locally storing and executing user-submitted transactions. To maintain the liveness of the system, orderers periodically commit the Merkle root and state root of the transactions they receive to Ethereum. This idea is correct, because O(N) off-chain transactions only need to store O(1) state data on Ethereum.

Q: By using a sorter to perform off-chain computations and only post Merkle roots on-chain, we Will it enhance the scalability of Ethereum?

Answer: Yes.

Q: That is to say, as long as we choose the sorter, the transfer cost can be greatly reduced. How do users save money?

Answer: You can join such a contract by depositing money into a contract on the Ethereum blockchain system. The sorter will credit the corresponding deposit in your name. The user only needs to send a transaction saying "I want to withdraw 3 ETH, my current account balance is greater than 3 ETH, this is proof", and the funds can be withdrawn. Even if there is no actual state of the user on L1, the user can provide a Merkle proof and refer to the state root issued by the orderer to prove that he has enough funds in the current state.

Q: We have determined that users need to provide Merkle proof in order to withdraw funds. How do users get the data needed to build Merkle proofs?

Answer: Users can ask the sorter to provide data!

Q: What should I do if I can’t always contact the sorter?

Answer: This situation may be caused by the sorter acting maliciously or being disconnected due to technical problems, which will cause performance Degradation (even theft). Therefore, we must require the orderer to submit the complete transaction data to the chain, only for storage, not for execution. The purpose here is to achieve data availability. Since all data is permanently stored on Ethereum, even if a sorter falls down, the new sorter can retrieve all Layer2-related data from Ethereum, rebuild the latest L2 state, and take over from the previous one. The job of the sorter.

Q: If the sorter is online but refuses to provide me with Merkel proof data, can I Is it right to download this data?

Answer: Yes, you can sync an Ethereum node yourself, or from a host of node hosting providers Choose one of them.

Q: I still don't understand...how to store data on Ethereum without executing it? Isn't every transaction going through EVM execution?

Answer: Suppose you submit 10 transactions from A to B to ETH. Execution of each transaction requires the following actions: increase A's nonce, decrease A's balance, and increase B's balance. This requires multiple writes and reads to the world state. You can send encodings of all transactions to the smart contract's publish(bytes _transactions) public { } function. Note that the body of this function is empty! That is, transactional data so published is not interpreted, executed, or accessed. It is only stored in the history log of the blockchain (writing to the log is cheap).

Q: Can we trust the sorter? What if the orderer issues an illegal state transition?

Answer: Whenever the orderer publishes a batch of state transitions, there will be a "dispute period". During the "dispute period", anyone can issue a "fraud proof" proving that one of the state transitions is invalid. Fraud proof is to replay the transactions that lead to state transitions on the chain, and compare the obtained state root with the state root issued by the orderer. If the two state roots are different, the fraud proof is successful and the state transition is canceled. State transitions following the invalid state transition are also canceled. Once the dispute period has passed, the transaction can no longer be disputed, ie, the transaction is finalized.

Q: Wait! You clearly stated earlier that any scalability solution that (a) increases costs, or (b) introduces new trust assumptions, is not feasible. Doesn't the scheme you mention here assume that at any moment someone will report fraud?

Answer: Yes. We assume that there is a group of entities called "validators" responsible for monitoring fraud. If there is a state mismatch between Layer 1 and Layer 2, the verifier issues a fraud proof. We also assume that validators are able to publish their fraud proofs on the Ethereum blockchain during the dispute period. In our opinion, the existence of validators is a weak assumption. Imagine if tens of thousands of users adopt this scheme, you only need 1 person to act as the validator. Doesn't sound so unrealistic! Also, changing Ethereum's trust model, or increasing the cost of running an Ethereum node is a strong assumption and would make changes we don't want. This is what our centralized scalability definition means by "minimally changing assumptions about the underlying system".

Q: I agree that there will be someone in the validator role because this new solution involves a lot of people Benefit. However, how exactly depends on the actual cost. So, how much resource does it take to run validators and orderers?

Answer: Orderers and validators must run an Ethereum full node (not an archive node), and an L2 full nodes to generate L2 state. Validators run software that creates fraud proofs, and orderers run software that packages and publishes user transactions.

Q: Is that all?

Answer: Yes! Congratulations! You have rediscovered Optimistic Rollup [3], the most promising scalability scheme for 2019-2021. I'm not talking big, this is the result of years of research by the Ethereum community. That's what you heard in this brief conversation.