What exactly is Rollup? how to use it
Original Title: "Introduction | Rollup Incomplete Guide"
Original Source: Ethereum Hobbies Author
Translator's Note: In the original text, Rollup appears multiple times in singular and plural forms at the same time, and it is uniformly determined as the first in the translation Capitalized Rollup.
Rollup is already very famous in the current Ethereum community. In the foreseeable future, Rollup is a key solution for scaling Ethereum . But what exactly is a Rollup? What can you get from this technology, and how can you use it? This article will attempt to answer some key questions.
Background knowledge: What is layer 1 expansion and what is layer 2 expansion?
There are two ways to achieve the expansion of the blockchain ecosystem. The first way to expand capacity is to allow the blockchain itself to have a higher transaction processing capacity. For example, make the block "bigger", but "big blocks" will make the verification process of the blockchain more difficult, and may make the nodes more centralized. To avoid such risks, developers can improve the efficiency of client software. A more sustainable expansion method is to use technologies such as sharding to distribute the work of building and verifying the blockchain to many different nodes- "eth4" is trying to use this method to upgrade the ether square.
The second way to expand capacity is to change the way blockchain is used. Users do not need to put all activities directly on the blockchain main chain, but perform most of the activities in the "second layer" protocol outside the main chain, and generate a proof that proves that All this activity that happens off-chain follows the rules. A smart contract is deployed on the main chain, which has only two tasks: processing deposits and withdrawals, and verifying the above proofs. There are multiple ways to implement proofs and verifications, but they all have a common property that verifying proofs on-chain is much less expensive than doing raw computation off-chain.
State channel vs plasma vs rollup
There are three main options for layer 2 expansion: state channel , Plasma and rollup. The three scenarios represent three different paradigms, each with its own advantages and disadvantages. All layer-2 capacity expansion roughly falls into these three categories (there is controversy over how to classify some compromise solutions, such as " validium ") (Editor's note: Chinese translation) .
How do state channels work?
See also https://www.jeffcoleman.ca/state-channels statechannels.org
Imagine Alice provides a network connection service to Bob. In exchange, Bob pays Alice $0.001/MB for the traffic generated online. Bob does not need to pay every fee on the first-tier main chain, and both parties use the following second-tier solution.
First, Bob deposits $1 (stablecoin, or the equivalent in ETH) into a smart contract. To make the first payment to Alice, Bob signs a "ticket" (an off-chain message) that 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, repeating this process for each payment (Translator's Note: State channel participants only need to keep a latest state change, so after a new ticket is signed, the previous ticket becomes invalid). After Alice and Bob complete the transaction, Alice can post the highest value bill package with her own signature on the main chain (close the channel). The smart contract verifies the signatures of both Alice and Bob, and after verification, pays Alice the amount marked on Bob's ticket, and returns the remaining amount (Translator's Note: $1 minus the former) to Bob. If Alice (due to malice or technical failure) is unwilling to close the channel, Bob can initiate a withdrawal challenge period (for example, 7 days) - if Alice cannot provide the bill paid by Bob within this period, then Bob can get back the previous All money stored in smart contracts.
The state channel technology is very powerful: the generalized state channel can support two-way payment, realize smart contracts (for example, Alice and Bob sign financial contracts in the channel), and have Composability (if there is an open channel between Alice and Bob, and an open channel between Bob and Charlie, then Alice can interact with Charlie trustlessly). But the role of the channel is limited: it cannot send funds off-chain to users who have not yet joined the channel; it cannot be used for objects that do not have a clear logical owner (such as Uniswap smart contracts). In addition, if the transaction processed by the channel is more complicated than the micropayment scenario, a large amount of funds need to be locked in the channel.
How Plasma Works
See also Plasma original white paper, Plasma Cash
To store assets from the main chain To enter the Plasma chain, users need to send assets on the main chain to the smart contract that manages the Plasma chain. The Plasma chain assigns the asset a new unique ID (eg 537). Every Plasma chain has an operator (this could be a centralized actor, or controlled by multisig, or something more complex like a PoS chain or DPoS chain). Every once in a while (could be 15 seconds, or an hour, or any amount of time in between), the operator generates a "batch" of the Transactions of all Plasma chains. The operator generates a Merkle tree, at the leaf node whose index is X , if the asset whose asset ID is X is in this batch If a transaction occurs during this time, the corresponding transaction exists on the leaf node, otherwise the leaf node is zero. The operator publishes the Merkle root of this tree to the main chain. The operator also needs to send the Merkle fork of each index X to the asset's current owner. If an asset needs to be extracted from the Plasma chain to the main chain, the user needs to send the Merkle branch corresponding to the last transaction of the asset to the smart contract of the main chain. The smart contract then begins a challenge period (e.g. 7 days) during which anyone can attempt to use other Merkle forks to prove that: (i) the user did not own the asset at the time of withdrawal, or (ii) the user was At some point the assets were sent to someone else, thereby invalidating the withdrawal application. If no one proves that the withdrawal was fraudulent within 7 days, the user can successfully get their assets back.
Plasma offers something stronger than state channels: you can send assets to users who have never joined layer 2, and the locked funds are much lower. But this comes at a price: state channels do not need to store any data into the main chain when they are "normal", but Plasma requires each chain to publish a hash value to the main chain every so often. In addition, the transactions in the Plasma chain have no immediacy, that is, they must wait for the proof of a batch of transactions (also called Plasma blocks) (that is, the Merkle root value) to be sent to the main chain.
Furthermore, both Plasma and state channels have an important flaw: the game theory underlying their security models relies on the idea that the assets controlled by the two systems There must be an "owner" at the logical level. As long as the asset owner cares about their asset, when a state change involving that asset is "invalid", the asset owner will find a way to show that the change is "invalid". This is irrelevant for some applications, but it is a problem for many other applications (such as Uniswap) The idea of assumption dependence contradicts). Even if the state of an object in the system can be changed without the consent of the system owner (e.g. in an account-based system, it is possible to increase ; its balance), also doesn't play well with Plasma. This means that when deploying plasma or state channels in reality, it is necessary to deduce the potential logic design customization scheme of "specific application", and it is impossible to make a plasma that can completely simulate the Ethereum operating environment (ie "EVM") Or a state channel system. Next let's see how rollup solves this problem.
Rollup
< /div>
See also:EthHub's introduction to optimistic rollup,EthHub's introduction to ZK rollup
Plasma and state channel solutions are both "full" layer 2 solutions because they will Both data and calculations are transferred off-chain (i.e. in its own layer-2 system). However, fundamental game-theoretic principles of data availability mean that such systems cannot safely implement all applications. Plasma and state channels solve this problem by making explicit the relationship between asset objects and owners, but this prevents them from being fully general. Rollup is different from the previous two in that it is a two-tier solution with a "hybrid nature". Rollup moves computation (and full state storage) off-chain, but keeps partial data information about each transaction on-chain. To improve efficiency, Rollup uses a series of fancy compression tricks and replaces data with computation whenever possible. As a result, the scalability of this system is still limited by the data bandwidth of the underlying blockchain, but the expansion multiple achieved on this basis is very impressive: executing an ERC-20 token transfer on the Ethereum main chain consumes about 45,000 gas, but in Rollup, each transaction only needs to store 16 bytes of data on the main chain, and the gas consumed is less than 300.
Data storage on the main chain is the key factor of Rollup (please note: this is different from storing data on "IPFS", because IPFS will not Data consensus, Rollup data must be stored on the blockchain). Storing data in the main chain and performing consensus allows anyone to locally process all operations in Rollup, including fraud detection, initiating withdrawals, generating batches, etc. Because there is no data availability issue, operators have relatively less damage if they do evil or go offline (for example, they cannot cause a 1-week exit delay), and provide a clearer view on who has the right to issue batches. More possibilities, but also make Rollup easier to understand. More importantly, the absence of data availability means that assets do not need to have a clear logical mapping relationship with their owners. Compared with other layer-2 expansion solutions, this is an important factor that makes the Ethereum community more excited about Rollup: Rollup is universal, for example, EVM can be run in Rollup, so that existing Ethereum applications can be implemented without writing new ones. Migrate to Rollup in the case of code.
How exactly does Rollup work?
There is a smart contract on the main chain, and there is a state root —a Merkle root representing the Rollup state. (Status content includes account balance in Rollup, contract code, etc.)
Anyone can initiate a batch process on the smart contract on the main chain Transaction (transaction), this batch is a highly compressed batch of Rollup internal transactions, including the old state root and the new state root (the new state root generated after the batch transaction is executed on the basis of the old state root). The main chain contract will check whether the old state root matches the new state root (Translator's Note: That is, whether the new state root can be generated by the state transition triggered by this batch of transaction sets). If the verification is passed, the old state root on the main chain will be updated to the new state root.
In order to support deposits (Translator's Note: Deposit assets into the Rollup contract from elsewhere in the main chain) and withdrawals (Translator's Note: Release the Rollup contract from controlling its own assets, Make it return to other places on the chain), the input or output of the transaction in the batch can be the state "outside" of the Rollup (Translator's Note: that is, elsewhere in the main chain). If there are transactions in the batch whose input comes from outside Rollup, then this batch operation will transfer assets from elsewhere in the main chain to the Rollup contract. If the output of a transaction in the batch comes from outside Rollup, then this batch will trigger a withdrawal operation in the smart contract to take the assets from Rollup back to the main chain.
The whole process is that simple! But there is one more detail. How do I know the status root is correct after the batch execution is complete? If someone could submit a fake state root without consequences, they could transfer all assets to themselves. This problem is critical because there are two distinct solutions to this problem, resulting in two types of Rollups.
Optimistic rollups vs ZK rollups
The two types of Rollup are:
- Optimistic Rollup, using Fraud Proof To solve the above problems: the Rollup contract of the main chain records the complete record of the internal state root change of the Rollup, as well as the hash value of each batch (triggering the state root change). If someone finds that the new state root corresponding to a batch is wrong, they can post a proof on the main chain that the new state root generated by the batch is wrong. The contract verifies the proof, and if the verification is passed, all batch transactions after the batch are rolled back.
- ZK Rollup, using validity proof to solve the above problems: Each batch contains a cryptographic proof called ZK-SNARK (for example, using the PLONK protocol to prove that the new state can be passed by the old state through this batch Converted after processing operations (Translator's Note: In ZK Rollup, the submitted cryptographic proof only needs to have the characteristics of small size and fast verification, and does not need to be zero-knowledge, so ZK Rollup can be realized only by SNARK, ZK-SNARK is not necessarily required. In fact, in ZK Rollup, because the batch transaction information is stored on the main chain, and this information is exactly what is proved in the cryptographic proof system, ZK Rollup itself does not have zero knowledge ZK Rollup with zero-knowledge property is called ZK ZK Rollup). Regardless of the amount of calculation in batch processing, the proof can be efficiently verified on the main chain.
The design trade-off between these two Rollups is more complicated
In general myself The point of view is that in the short term, Optimisitc Rollup is likely to win in the realization of general EVM, and ZK Rollup is likely to win in simple payment, transfer and other specific applications. But in the medium and long term, with the development of ZK-SNARK technology Improvement, ZK Rollup will win in all application scenarios.
Anatomy of Fraud Proof
Optimistic Rollup's security rests on the idea that if someone posts an invalid batch into the Rollup, any em> Anyone who has synchronized the chain can issue a fraud proof to the contract on the main chain as long as they find fraudulent behavior, proving that the batch is invalid and should be rolled back (Translator's Note: I don't know the "the Chain (the chain)" refers to the main chain or Rollup, although both are correct).
An assertion that a batch is invalid A fraud proof for , needs to include the data identified in green in the diagram above: the batch itself (which can be checked against the hash stored on-chain) and the Merkle tree path proving that the batch read or modified a particular account . Yellow nodes can be reconstructed by green nodes, so need not be included in the proof. This data is enough to perform batch processing and compute a new state root (note that this is exactly the same way a stateless client validates a single block). If the computed new state root is not the same as the one provided in the batch, then the batch is proven to be fraudulent.
You can ensure that if there is an error in a batch, all previous batches are correct, A fraud proof can then be created that proves that the batch was constructed incorrectly. Note that if there are multiple invalid batches in the Rollup, it is best to try to prove that the oldest batch is invalid. What is guaranteed of course is that if a batch is correct, it will never be possible to create a fraud proof that the batch is invalid.
How is compression achieved?
The simplest Ethereum transfer (send ETH) takes about 110 bytes, but in Rollup Only about 12 bytes are needed to realize ETH transfer:
Parameter (unit: number of bytes) Ethereum main chain Rollup contract Nonce (serial number)~30Gasprice~80- 0.5Gas30-0.5To (target address) 214Value (transfer value)~9~3Signature (signature)~68 (2+33+33)~0.5From (originating address)0 (restore from signature)4Total~112~12
Part of the reason for this is that Rollup can employ simpler advanced coding techniques, while currently Ethereum's RLP wastes 1 on the length of each value byte. Rollup also employs some very clever compression tricks.
- Nonce: The purpose of this parameter is to prevent replay. If the current nonce of an account state is 5, then the nonce parameter of the next transaction of the account must be 5, but once the transaction is processed, the nonce in the account state will be incremented to 6, so that the transaction with a nonce of 5 will be Will not be packed again. In Rollup, we can omit the nonce entirely, because we only need to restore the nonce from the pre-update state; if someone tries to replay the transaction with an earlier nonce, the signature will fail verification, because the signature verification will use a larger nonce data.
- Gas Price : We can allow users to pay with a fixed range of Gas prices, for example, the range is 0 - 2 to the power of 16 . Alternatively, we could just charge a flat fee per batch, or even move the gas payment out of Rollup entirely, letting traders pay the batch creator through a specific channel.
- Gas : We can also just choose the total Gas range as a power of 2. Alternatively, we can set gas limits only at the batch level. (Translator's Note: The Gas Price and Gas here are for comparing the amount of data generated by transfer through the rollup contract and the Ethereum network. It does not mean that a rollup protocol must include these concepts. For example, Fuel as an Optimistic Rollup The protocol, which is based on UTXO, does not contain these concepts at all.)
- To: We can use index< /em> instead of 20 bytes of address (for example, if an address is the 4527th address added to the tree, we would use index 4527 to represent it. We would add a subtree in the state to store the index to the address mapping).
- Value : We can use scientific notation to store Value. In most cases, only 1-3 significant digits are required for transfers.
- Signature : We can aggregate signatures using BLS so that many signatures are aggregated into one of about 32 - 96 bytes (size depends on protocol used). This signature can then be batch-processed for signature verification of the entire set of messages and senders at once. ~0.5 in the table means that the number of aggregated signatures that can be verified in a main chain block is limited, so if there are many transactions in the batch, it is necessary to generate an aggregated signature about every 100 transactions. (Translator's Note: The general idea is that the amount of computation required to verify aggregated signatures will increase as the number of aggregated original signatures increases, and the number of Gas that can be used by Ethereum main chain blocks is limited, so aggregated signatures cannot be aggregated at one time Too many original signatures.)
ZK Rollup has a special important compression trick: if part of the transaction is only used for If it is irrelevant, then this part of data may not be stored on the main chain. This cannot be done in Optimisitc Rollup, because the data still needs to be stored on the chain for the occasional need for subsequent fraud proof verification. In ZK Rollup, the SNARK proof that proves the correctness of a batch of data, It has been demonstrated that the parties involved have provided all data required for verification. An important example is the implementation of Rollup with privacy protection properties: to achieve privacy protection in Optimisitc Rollup, about 500 bytes of ZK-SNARK used to protect privacy in each transaction need to be uploaded to the chain, and to achieve privacy protection in ZK Rollup , the ZK-SNARK covering the entire batch can already prove that the "inner" ZK-SNARK is effective. (Translator's Note: Since SNARKs can be nested, to achieve privacy protection in ZK Rollup, you only need to submit the final generated outermost SNARK to the chain. When verifying the outer SNARK, the inner SNARK is valid. can be verified at the same time.)
These compression techniques are the key to Rollup’s expansion. Without these techniques, Rollup may only be based on the expansion of the main chain Achieve about 10 times expansion (although in some specific high-computation applications, the expansion achieved by simple Rollup is already very powerful), but after using compression techniques, the expansion factor of almost all applications can exceed 100 times.
Who can submit batches?
There are many schools of thought on who can submit batches in an Optimistic Rollup or a ZK Rollup. Generally speaking, it is believed that users who submit batches must pledge a large deposit, and if a user ever submits a fraudulent batch (such as submitting an invalid state root), then part of this deposit will be Burning and burning, another part is rewarded to users who submit fraud proofs. But in addition, there are many possibilities:
(Translator's Note, users who can publish batches to the main chain are called sequencers ), so-named because the role needs to sort transactions in a batch)
- A completely permissionless sorter: anyone Batches can be submitted at any time. This method is the simplest, but has some serious drawbacks, such as the problem that multiple participants simultaneously generate and attempt to submit batches, only one of which can be successfully included. This will result in a large amount of wasted computational overhead for generating proofs or Gas overhead for submitting proofs.
- Centralized sorter: Submit batches through roles such as sorter (except for withdrawal operations: in the withdrawal operation, first The withdrawal request is submitted by the user himself. If the sorter does not process the withdrawal transaction in the next batch, the user can personally submit a batch application containing only one withdrawal transaction). This method has the highest "efficiency", but it needs to rely on a centralized role.
- Sorter Auction: Auction (e.g. every day) to decide who has the right to be the next day's sorter. The advantage of this solution is that it can raise funds, and these funds can be distributed through Rollup's DAO (refer to MEV auction).
- Random selection from PoS collection: anyone can deposit ETH (or the token set by the Rollup protocol) into Rollup In the contract, each batch sorter will be randomly selected among these depositors, and the probability of being selected is proportional to the deposit amount. The main disadvantage of this scheme is the need to lock a large number of assets.
- DPoS Voting: Some sorters are chosen by auction to perform batch processing, but if they underperform, tokens are held Someone can vote to kick them out and hold a new auction to replace them.
Some Rollups currently under development use "split-batch "Split batch" mode, that is, the act of submitting a batch of Layer 2 transactions and the act of submitting a state root are performed separately. There are some key advantages to this.
- You can allow many sorters to issue batches in parallel to improve censorship resistance and mitigate for some batches due to Some other concerns that batches are packed ahead of time and not valid.
- If one state root is fraudulent, instead of rolling back the whole batch, you can just roll back the state root and wait for someone to provide a new state root for the same batch. This better ensures that the sender's transaction will not be rolled back.
Overall, this is a rather complex combination of technologies, yet to be found in complex trade-offs involving efficiency, simplicity, censorship resistance, and other goals. It's too early to say which combination will work best, and time will tell.
How much expansion will Rollup bring?
On the existing Ethereum main chain, the Gas line of each block is 12.5 million, and each byte of the transaction is stored on the chain and costs 16 Gas. This means that if a block contains only one batch (assuming ZK Rollup is used here, and the verification proof costs 500,000 Gas), then this batch can contain 12 million / 16 = 750,000 bytes of data. As mentioned above, each ETH transfer in Rollup requires only 12 bytes of storage, which means that each batch can contain 62,500 transactions. The current block interval of the Ethereum main chain is 13 seconds, which means that the achieved TPS is about 4807 (by comparison, the TPS for ETH transfers on the Ethereum main chain is about 1250000 / 21000 / 13 = 45).
The following table contains the expansion efficiency of some other application scenarios.
The calculation method of the maximum expansion multiple: the Gas consumption of the corresponding operation of the Ethereum main chain / (the corresponding operation in the Rollup needs to be number of bytes in the chain * 16) * 12 million / 12.5 million
It should be noted that, for some reason, these numbers are actually overly optimistic. The most important reason is that it is almost impossible to include only one batch in a block, because there will be multiple different Rollup systems. The second reason is that there will always be deposits and withdrawals. A third reason is that short-term usage of Rollup is likely to be low, so a fixed-cost charging model will dominate. But even taking these factors into account, more than 100 times expansion should not be difficult to achieve.
What if we want to achieve 1000-4000 TPS (depending on the specific application scenario)? This requires eth4 data sharding. In this proposal, a 16MB storage space is created every 12 seconds, which can be filled with any data, and the system will ensure a consensus on the availability of these data. This data space can be used by Rollup. This data throughput of about 1398 kB/s is 23 times higher than the current Ethereum main chain of about 60 kB/s, and in the long run, the data capacity is expected to grow further. Therefore, the TPS of Rollup implemented using eth4 data sharding can be as high as 100,000, and it will even be larger in the future.
What are the remaining unresolved challenges?
Although the basic concepts of Rollup are now well known, we are also sure that Rollup is inherently feasible, safe, and how many A Rollup is deployed on the Ethereum mainnet, but there are still many aspects of Rollup that have not been well explored at the design level. If most of the Ethereum ecosystem is to be fully introduced into Rollup to take advantage of its scalability, there are still many problems. challenge. Some key challenges include:
- Onboarding of users and ecosystem: Not many applications currently use Rollup, users are not familiar with Rollup, few Wallet started to integrate Rollup. Merchants and charities don't yet accept them for payments.
- Cross-Rollup Transactions: Efficiently transfer assets and data (such as oracle output) from one Rollup to another, There is no need to transfer through the main chain and generate corresponding fees.
- Audit incentive: How to maximize the probability that at least one honest node will fully verify the Optimistic Rollup, so as to ensure that when something goes wrong When does someone post a fraud proof? For small-scale Rollups (with a TPS of a few hundred or less), this is not an important issue and can be achieved simply by relying on altruism, but for larger-scale Rollups, it is necessary to study the incentive issue clearly.
- Explore the possibility of designing between Plasma and Rollup: Is there a technique to put parts< /em> Data related to state updates on-chain, but not all data on-chain? Will new and useful tools emerge from this technology?
- Maximize the security of pre-confirmation: Many Rollups provide a "pre-confirmation" in order to make the user experience better The concept of , that is, immediately after the transaction is completed, the orderer provides a promise that a certain transaction will be included in the next batch processing, and if the orderer reneges, their deposit will be destroyed. But the security of this scheme is limited at the economic level, because the sorter may make many commitments to many users at the same time. Can this mechanism be improved?
- Improving the response speed of the absent sorter: if a Rollup sorter is suddenly offline, how to maximize the speed and low To recover from this situation cost-effectively, either quickly and cheaply mass exit to another rollup, or replace the orderer. Quick response which is very valuable.
- Efficient ZK-VM: Generate a ZK-SNARK proof that proves that EVM code with generality (or existing contracts can Compiled to another VM) has executed correctly with a definite result.
Summary
Rollup is a new powerful two-layer scaling paradigm, which is expected to be the cornerstone of Ethereum's future short- and medium-term (and possibly long-term) expansion. The Ethereum community is very excited about Rollup, because unlike previous layer-2 expansion attempts, Rollup can support common EVM code, allowing existing applications to be easily migrated. Rollup achieves this by making a key compromise: instead of trying to move entirely off-chain, it keeps a small amount of data about each transaction on-chain. (Translator's Note: That is, there is no data availability problem mentioned above)
There are many kinds of Rollups, and there are many choices in design: Optimisitc Rollup, ZK Rollup using proof of validity. The orderer can be a centralized actor, a decentralized free actor, or many other options in between. Rollups are still an early-stage technology, and development is continuing at a rapid pace, but they work, and some (notably Loopring, ZKSync, and DeversiFi) have been running for months. Expect more exciting results in the Rollup space in the years to come.
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
Related Articles
