Partnered With:

Ethereum Extensibility Solution Rollup

Read this article in 41 Minutes

Which of the three scalability solutions does God V prefer?

原文标题：《 An Incomplete Guide to Rollups 》

原文作者： VitalikButerin

0x33, beat BlockBeats

Rollup is very popular in the Ethereum community and will be a key scalability solution for Ethereum for the foreseeable future. But what exactly is the technology, what can you expect from it, and how will you use it? This article will attempt to answer some of these key questions.

Background: What are Layer1 and Layer 2 extensions?

There are two ways to scale the blockchain ecosystem. First, you can make the blockchain itself have a higher transaction capacity. The main challenge with this technology is that blockchains with "larger blocks" themselves will be harder to verify and may become more centralized. To avoid such risks, developers can make the client software more efficient, or more sustainably use techniques such as sharding, which splits the work of building and validating chains across multiple nodes; As we all know, "ETH2.0" is currently working hard to build an upgrade to Ethereum.

Second, you can change the way you use blockchain. Instead of putting all of their activities directly on the blockchain, users perform most of their off-chain activities in the Layer 2 protocol. There is a smart contract on a chain that has only two tasks: processing deposits and withdrawals, and verifying that everything that happens down the chain is following the rules. There are several ways to implement these proofs, but they all have the common property that verifying the proofs on the chain is much cheaper than doing the original calculation down the chain.

State channels versus Plasma versus Rollup

Layer 2 can be extensible in three main ways: State channels, Plasma, and Rollup. They are three different approaches, each with its own strengths and weaknesses, and at this point we are fairly confident that all Layer 2 extensions fall into these three categories. (though there are disputes over nomenclature, such as "validium").

How do State channels work?

You can see it here: https://www.jeffcoleman.ca/state-channelsAs well asstatechannels.org

Suppose Alice provides Bob with an Internet connection and in exchange Bob pays her $0.001 per Megabyte. Alice and Bob use the Layer 2 scheme below, instead of making a transaction for every payment.

First, Bob puts $1 (or some ETH or stablecoin equivalent) into the smart contract. In order to pay his first payment to Alice, Bob signs a "ticket" (an out-of-chain message) that simply says "$0.001" and sends it to Alice. To make the second payment, Bob signs another note that says "$0.002" and sends it to Alice. And so on, you pay as much as you need. When Alice and Bob complete the transaction, Alice can post the highest value note on the chain, wrapped in another signature from herself.

The smart contract verifies Alice's and Bob's signatures, pays Alice the amount on Bob's ticket, and sends the rest back to Bob. If Alice is unwilling to close the channel (due to malicious or technical failure), Bob can initiate an exit period (for example, 7 days); If Alice does not provide a new note within that time, Bob gets all his money back.

The technology is powerful: it can be tuned to handle two-way payments, smart contract relationships (e.g. Alice and Bob make a financial contract inside the channel), and composition (if Alice and Bob have a public channel, and Bob and Charlie also have one, then Alice can interact with Charlie without trust).

But the role of channels is limited. Channels cannot be used to send money out of the chain to people who have not yet participated. Channels cannot be used to represent objects that have no clear logical owner (for example. Uniswap). Channels need to lock up a lot of money when they are used to do something more complex than simple recurring payments.

How does Plasma work?

Click here to see:original Plasma paper And & have spentPlasma Cash.

To store the asset, the user sends it to a smart contract that manages the Plasma chain.

The Plasma chain assigns a separate ID (such as 537) to the asset. Each Plasma chain has an operator (this can be a centralized role, or a multi-signature, or something more complex, such as POS or DPOS). Every once in a while (which can be 15 seconds, or an hour, or any time in between), the operator generates a "batch process" containing all the Plasma transactions they have received down the chain.

They generate a Merkle tree, where at each index X in the tree, if there is a trade, there is a trade that transfers asset ID X, otherwise it is zero. They send this merk root up the chain. They also send the Merkle branch of each index X to the current owner of the asset. In order to withdraw assets, users publish a Merkle branch that sends assets to their latest transaction.律动注： Merkle tree，中文称为默克尔树或哈希树。在密码学And in computer science is a tree data structure in which every leaf node is labeled with a hash of the data block, and every node other than the leaf node is labeled with an encrypted hash of its child node label.One obvious benefit of Merkle Tree is the ability to take out a single branch (as a small Tree) to verify part of the data, which in many cases provides a convenience and efficiency that hash lists cannot match.

The contract begins with a challenge period, during which anyone can try to invalidate an exit by using other Merkle branches, either by proving that (1) the sender did not own the asset at the time it was sent, or (2) they sent the asset to someone else at a later point. If no one proves that the exit is not genuine within, say, 7 days, the user can withdraw the asset.

Plasma offers more powerful properties than a state channel: You can send assets to participants who were never part of the system, and the capital requirements are much lower. But this comes at a cost: channels do not need any data to run on the chain during their "normal operation," while Plasma requires each chain to periodically publish a hash value. Also, waiting for Plasma transfer is not immediate: you have to wait for the interval to end and the block to be published.

Furthermore, Plasma and state channels share a common weakness: why are they secure? The game theory behind this relies on the idea that every object controlled by two systems has some logical "owner". If the owner does not care about their asset, it can lead to "invalid" results involving that asset. This is acceptable for many applications, but for many others (e.g. Uniswap). Even for systems where the state of the sending asset object can change without the owner's consent, (e.g. Account-based systems, where you can increase someone's balance without their consent, do not work well with Plasma either.

All of this means that a lot of "application-specific reasoning" is required in any real-world Plasma or state channel deployment, and it's impossible to make a Plasma or channel system that simulates the entire Ethereum environment (or "EVM").

To solve this problem, we can look at... The rollup.

Rollup

The details can be viewed here:EthHub on optimistic rollups And & have spentZK rollups.

Plasma and state channels are complete Layer 2 plans that attempt to move both data and calculations out of the chain. However, basic game theory issues around data availability mean that it is not possible to do this safely for all applications. Plasma and channels rely on a clear concept of ownership to solve this problem, but this prevents them from being universal. Rollup, on the other hand, is a "mixed" Layer 2 solution.

Rollup moves computation (and state storage) out of the chain, but keeps some data on the chain for each transaction. To improve efficiency, they use a whole host of fancy compression techniques, replacing data with calculations whenever possible. As a result, the scalability of the system is still limited by the underlying blockchain data bandwidth, but at a very favorable rate: an Ethereum underlying ERC20 token transfer costs about 45,000 gas, while an ERC20 token transfer in a rollup takes up 16 bytes of on-chain space and costs less than 300 gas.

The facts on the data link are key (note: putting the data "on IPFS" is not feasible, because IPFS does not agree on whether any particular data is provided; Data must be on the blockchain) putting data on the chain and agreeing on the fact that it allows anyone to handle all operations in the aggregate locally (if they wish), thus allowing them to detect fraud, start withdrawals, or start producing transaction batches themselves. The lack of data availability issues means that malicious or offline operators can do less harm (e.g. They do not cause a 1-week delay), thus opening up a larger design space for those who have the authority to issue batches, and making summaries easier to reason about.

Most importantly, the lack of data availability problem means that no longer need to map the assets to the owner, that is why the etheric lane community compared with the previous Layer 2 expanded form, more intent on key reason of rollup: rollup is entirely general, even can run in the rollup EVM entry, allowing existing Ethernet fang application is migrated to a rollup, almost don't need to write any new code.

好的，那么 rollup 的工作有多棒呢？

链上有一个智能合约，它维护一个状态根：rollup 状态的 Merkle 根 (意思是，账户余额、合约代码等，位于 rollup「内部」)。

Anyone can publish batch processing, which is a set of transactions in a highly compressed form, as well as the previous state root and the new state root (Merkle root after processing the transaction). The contract checks whether the previous state root in the batch matches the current state root; If so, switch the state root to the new state root.

To support deposits and withdrawals, we added the ability to make the input or output of a transaction "out" of the rollup state. If the batch has input from an external source, the transaction that commits the batch also needs to transfer these assets to the ROLLUP contract. If the batch has output to the outside, then the smart contract starts the extract while the batch is being processed.

So, only this has one major detail: how do you know that the post-state root in batch processing is correct? If someone can commit a batch with any post-state root without consequences, then they can transfer all the tokens in the rollup to themselves.

This issue is critical because there are two very different sets of solutions to this problem, and these two sets of solutions result in two types of rollups.

Optimistic rollup versus ZK rollup

These two types of ROLLUP are Optimistic ROLLUP and ZK ROLLUP.

Optimistic Rollup, they use proof of fraud: the Rollup contract tracks the entire history of its state root and the hash of each batch. If someone discovers that a batch process has an incorrect post-state root, they can issue a certificate to the chain that the batch calculation was incorrect. The contract will validate the certification and restore that lot and all subsequent lots.

ZK Rollup, Using Proof of Validation: Each batch contains an encrypted proof called ZK-snark (for example, using the Plonk protocol) that the post-state root is the correct result of performing batch processing. No matter how computationally intensive, the proof can be quickly verified on the chain.

There is a complex tradeoff between these two types of rollups:

Overall, my view is that Optimistic Rollup has a good chance of winning multi-purpose EVM computing in the near term, while ZkRollup has a good chance of winning on the simple payment layer, trading platform, and other application-specific use cases. In the medium to long term, however, ZK Rollup will win out in all the useful cases as the ZK-Snark technology improves.

Dissecting evidence of fraud

The security of Optimistic Rollup depends on whether an invalid batch has been published to the Rollup. Anyone who tracks the chain and detects fraud can issue a certificate of fraud to prove to the contract that the batch is invalid and should be restored.

Fraud proofs that claim batches are invalid will contain data in green: the batch itself (which can be checked against hashes stored on the chain) and the part of the Merkle tree that only needs to prove the specific account that the batch read and/or modified.

Nodes in the yellow tree can be refactored from the green nodes, so there is no need to provide. This data is sufficient to perform batch processing and compute the post-state root (note that this is exactly the same way a stateless client validates a single block). Batch processing is fraudulent if the post-state root calculated in the batch is not the same as the post-state root provided.

It is guaranteed that if one batch was built incorrectly and all previous batches were built correctly, then it is possible to create a fraud certificate showing that the batch construction is incorrect. Note the statement about previous batches: If there are multiple invalid batches published to Rollup, it is best to attempt to prove that the earliest batch is invalid. Of course, if a batch processing is constructed correctly, it is never possible to create evidence of fraud that the batch processing is invalid.

How does compression work?

A simple Ethereum transaction (sending ETH) requires about 110 bytes. However, a single ETH transfer on Rollup requires only about 12 bytes:

Part of the reason is more advanced coding: Ethereum's RLP wastes 1 byte on the length of each value. But there are also some very clever compression tricks going on:

Nonce:Prevent replay. If an account's current nonce is 5, then the next transaction for that account must have nonce 5, but once the transaction is processed, the nonce in the account will increase to 6, so the transaction cannot be processed again. In Rollup, we can completely ignore the nonce because we are only restoring the nonce from pre-state; If someone tries to replay the transaction with an earlier nonce, the signature will not be verified because the signature will be checked against the data that contains the new, higher nonce

Gas prices: We can allow users to pay within a fixed gas price range, for example, for 2 to the 16th power. Alternatively, we could set a fixed fee level for each batch, or even move GAS payments completely out of the ROLLUP protocol and have the transaction person pay the batch creator through a channel.

Gas:Similarly, we can write the total amount of gas as a power of 2. Alternatively, we can set the GAS limit on lots only.

To:We can use an index instead of a 20-byte address. If an address is address 4527 added to the tree, we simply refer to it using the index 4527. We will add a subtree to the state to store the index-to-address mapping).

Value:We can store value using scientific enumeration. In most cases, only 1-3 significant digits are required for transmission

Signature:We can use BLS aggregate signatures, which allow many signatures to be aggregated into a single ~ 32-96-byte (depending on the protocol) signature. This signature can then be checked at once for the entire message set and sender in the batch. The ~0.5 in the table indicates that there is a limit to how many signatures can be included in an aggregate, since signatures need to be verified in a single proof of fraud.

An important compression technique specific to ZK Rollup is that if part of a transaction is used for validation only and is not relevant to calculating status updates, then that part can be left out of the chain. This optimistic rollup cannot be achieved as the data still needs to be included on the chain in case it needs to be checked in the fraud certificate at a later date, and in ZK rollup, the SNARK that proves the correctness of the batch has proven to provide the data needed for any validation.

An important example is the ollps total for privacy protection: in the optimistic rollup, approximately 500 bytes of ZK-snark for privacy of each transaction need to be placed on the chain, whereas in the ZK rollup, covering the entire batch of ZK-snark has shown unquestionably that the "internal" ZK-snark is valid.

These compression techniques are key to Rollup's scalability; Without them, Rollup would probably only improve the scalability of the basic chain by about a factor of 10 (although there are some computation-heavy applications where even simple Rollup is powerful), while using compression techniques, almost all applications can achieve a scaling factor of over 100.

Who can submit batches for review?

There are many opinions about who can submit a batch of trades in Optimistic or ZK Rollup. In general, everyone agrees that in order to be able to submit a batch, a user must submit a large deposit. If the user has ever submitted a fraudulent batch of transactions (for example, invalid status root), part of that deposit is burned and part is rewarded as proof of fraud. But there are many possibilities beyond this approach:

Completely disorderly manner:Anyone can submit a batch of transactions at any time. This is the simplest approach, but it has some serious drawbacks. In particular, there is a risk that multiple participants will generate and attempt to submit batches of transactions together, and only one of those batches can be successfully processed. This leads to a lot of wasted effort in generating certificates, and it also leads to wasted gas due to the need to chain batches of transactions.

Centralized Sequencers:There is a single participant: the sorter. He can submit a batch transaction (except for withdrawals: the usual technique is that the user can submit a withdrawal request first, and then submit a single-operation batch processing himself if the sorter does not process the withdrawal request in the next batch). This is the most "efficient," but it relies on a centralized role to keep things going.

Sorter Auction:The advantage of this technique is that the money raised can be allocated by DAOs controlled by, for example, Rollup (see :MEV auction).

Select randomly from the POS set:Anyone can deposit the ETH(or Rollup's own protocol token) into a Rollup contract, and the sorting of each lot is randomly selected from one of the depositors, with the probability of being selected proportional to the amount deposited. The main drawback of this technique is that it leads to a large number of unnecessary capital lock-ins.

DPoS vote:A separate sorter is selected through an auction, but if they don't perform well, token holders can vote them out and a new auction is held to replace them

Share batch processing and state root supply

Some Rollups currently under development use a "shared batch processing" approach, where committing a batch of Layer 2 transactions is done separately from committing the state root. This approach has some key advantages:

You can allow many collators to publish batch transactions in parallel to increase resistance to review without the fear that some batches will fail because other batches are included first.

If a status root is fraudulent, you don't need to restore the whole batch, you can just restore the status root and wait for someone to provide a new status root for the same batch processing. This gives transaction senders better assurance that their transactions will not be restored.

So all in all, there is a fairly complex technology park, trying to strike a balance between complex tradeoffs of efficiency, simplicity, censorship resistance, and other goals. It is too early to say which combination will work best; Time will tell.

How much scalability does Rollup give you?

On the existing Ethereum chain, the cap on gas is 12.5 million, and each byte of data in a transaction costs 16 gas. This means that if a block contains only a single lot (we say a ZK rollup was used and 500K of gas was spent on certification verification), then that lot (12M / 16)= 750000 bytes of data.

As shown above, the total amount of ETH transfers is only 12 bytes per user operation, which means that batch processing can contain up to 62,500 transactions. At an average block time of 13 seconds, this means about 4807 TPS(compared to 12.5 million TPS / 21000/13 ~= 45 TPS for ETH transfers directly on the Ethernet).

Here is a diagram of some other use cases:

The maximum scalability gain is calculated as (L1 gas cost)/(rollup bytes * 16)* 12 million / 12.5 million.

Now, it's worth remembering that these numbers are overly optimistic, for several reasons. Most importantly, a block will almost never contain only one batch, or at least multiple rollups. Second, deposits and withdrawals will continue to happen all the time. Third, usage will be low in the short term, so fixed costs will dominate. But even taking these factors into account, 100-fold scalability is expected to become the norm.

Now, what if we want to go beyond 1000-4000 TPS(depending on the use case)? This is where eth2 data sharding comes in. The sharding scheme opens up 16MB of space every 12 seconds, which can be filled with any data, and the system guarantees an agreement on the availability of the data. This data space is available for ROLLUP. That's about 1398K bytes per second, a 23-fold increase over the existing Ethereum chain's roughly 60KB per second, and data capacity is expected to grow further in the long term. As a result, a rollup that uses eth2 to sharde data can handle up to 100K TPS, and even more in the future.

What are some of the challenges in Rollup that haven't been fully solved yet?

Although rollup can be easy to understand the basic concepts of now, we are convinced that they are essentially is feasible and safe, multiple rollup solutions have been deployed to the individual, but the rollup design there are still many areas has not developed very well, if you want to completely moved the most etheric fang ecosystem and a rollup to use their scalability, there are still quite a challenge.

Some of the key challenges include:

Adaptation of users and ecosystems:Few applications use Rollup, users are unfamiliar with Rollup, and few wallets start to integrate Rollup. Merchants and charities do not yet accept payment this way.

Cross Rollup Transaction:Efficient movement of assets and data (for example via predictive output) from one Rollup to another without going through the base layer.

Audit incentive mechanism:How to maximize the likelihood that at least one honest node will actually fully validate optimistic rollup so that evidence of fraud can be issued in the event of a problem? For small scale rollups (up to a few hundred TPS), this is not an important issue, and one can simply rely on altruism, but for large scale rollups, more explicit reasoning is needed.

Explore the design space between Plasma and Rollup:Is there a technique to put some, but not all, of the data related to status updates on the chain and draw any useful conclusions from it?

Maximize pre-confirmed security:Many Rollups offer the concept of "pre-validation" for a faster user experience, where the Sorter immediately provides a promise that the transaction will be included in the next batch, and if they break their promise, the Sorter deposit will be destroyed. But the economic security of the program is limited because it is possible to make many commitments to many participants at the same time. Can this mechanism be improved?

Improved response time to absent sorters:If a Rollup Sorter suddenly goes offline, it is valuable to restore the Sorter function as quickly and cheaply as possible, either by quickly and cheaply exiting a large number of Rollup Sorters to a different Rollup, or by quickly switching to a different Sorter.

Efficient ZK:Generate a ZK-Snark proof that the generic EVM code (or some different VM that an existing smart contract can compile to) has been executed correctly and has the given result.

conclusion

Rollup is a powerful example of a new Layer 2 extension that is expected to be a cornerstone of Ethereum expansion in the short and medium term (and possibly the long term). They've seen a lot of interest in this from the Ethereum community, and unlike previous Layer2 extension attempts, they can support generic EVM code, allowing existing applications to be easily migrated. To do this, they made a key compromise: not to try to get off the chain entirely, but to leave a small amount of data on each transaction on the chain.

There are many types of ROLLUP, and there are many options in the design field: for example, using fraudulent proof of optimistic ROLLUP, or proof of validity of ZK ROLLUP (i.e., ZK-snarks). The collator (a user who can post transaction batches to the chain) can be a centralized participant, a free participant, or many other choices in between. Rollup is still an early stage technology and development is still going fast, but they do work and some of them (notably Loopring, ZKSync and Deversifi) have been running for a few months. Rollup Space will see more exciting work in the coming years.