Editor's Note: This article comes fromEthereum enthusiasts (ID: ethfans)Editor's Note: This article comes from
Ethereum enthusiasts (ID: ethfans)
- Ethereum enthusiasts (ID: ethfans)
, Author: Vitalik, translation & proofreading: Shengchao & A Jian, reproduced by Odaily with authorization.Translator's note:
In the original text, Rollup appears multiple times in singular and plural forms at the same time, and in the translation, it is uniformly determined as Rollup with the first letter capitalized.Rollup is already very famous in the current Ethereum community. In the foreseeable future, Rollup is the key solution for Ethereum to achieve expansion. 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?
The second way to scale 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 certificate to prove all the activities that occurred outside the chain All follow 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.Chinese translation）。State channel vs plasma vs rollup
There are three main solutions 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 expansions roughly fall into these three categories (there is controversy over how to classify some compromise solutions, such as "validium") (Editor's note:https://www.jeffcoleman.ca/state-channels ，statechannels.orgHow do state channels work?"see also"Imagine that 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 abill
(an off-chain message), the "ticket" 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). When Alice and Bob complete the transaction, Alice can post her signature on the most valuable bill package and publish it to the main chain (close the channel). The smart contract verifies the signatures of both Alice and Bob, and after the verification is passed, 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.State channel technology is powerful: generalized state channels can support two-way payments, implement smart contracts (for example, Alice and Bob sign a financial contract in the channel), and are composable (if there is an open channel between Alice and Bob, Bob There is also an open channel between Alice and Charlie, so Alice can interact with Charlie without trust). 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 without 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.To deposit assets from the main chain to the Plasma chain, users need to send assets on the main chain to the smart contract that manages the Plasma chain. The Plasma chain will assign a new unique ID (eg 537) to the asset. 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 with the index X, if the asset with the asset ID X has a transaction in this batch, 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 current owner of that asset. 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."owner"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 on the main chain every so often. In addition, the transactions in the Plasma chain have no immediacy, that is, they must wait for the evidence of a batch of transactions (also called Plasma blocks) (that is, the Merkle root value) to be sent to the main chain.Rollup
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 both systems must logically have. 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 (for example, in an account-based system, its balance can be increased without the owner's consent), it does not play well with Plasma compatible. 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.See also: EthHub's introduction to optimistic rollup, EthHub's introduction to ZK rollup
Both the Plasma and state channel schemes are "full" layer 2 schemes in that they move both data and computation off-chain (i.e. into their 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-layer 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 a key factor for Rollup (note: this is different from storing data on "IPFS", because IPFS does not have consensus on the stored data, and Rollup's data must be stored on the blockchain). Storing data in the main chain and conducting 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 - the Merkle root representing the Rollup state. (Status content includes account balance in Rollup, contract code, etc.)Optimistic rollups vs ZK rollups
Anyone can initiate a batch transaction (transaction) on the smart contract on the main chain. This batch is a highly compressed batch of Rollup internal transactions, including the old state root and the new state root (in the old state root based on the new state root generated after executing the batch transaction). 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: depositing assets into the Rollup contract from elsewhere in the main chain) and withdrawals (Translator's Note: releasing the Rollup contract from controlling its own assets and returning them to other places on the chain), batch processing The input or output of a transaction can be state "outside" the Rollup. 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 there are transaction outputs in the batch that come from outside Rollup, then this batch will trigger a withdrawal operation in the smart contract, taking assets from Rollup back to the main chain.
- ZK Rollup,The whole process is as simple as that! 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 their assets to themselves. This problem is critical because there are two distinct solutions to this problem, resulting in two types of Rollups.
The two types of Rollups include:
Optimistic Rollup uses fraud proofs to solve the above problems: the main chain’s Rollup contract records a complete record of the Rollup’s internal state root changes, as well as the hash value of each batch (triggering state root changes). 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.Use validity proofs 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 converted from the old state after this batch operation (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, and ZK-SNARK is not necessarily required. In fact, In ZK Rollup, because 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, and ZK Rollup with zero-knowledge is Called ZK ZK Rollup). Regardless of the amount of calculation in the batch, the proof can be efficiently verified on the main chain.
The design trade-offs between these two rollups are complexIn general, my own point of view is that in the short term Optimisitc Rollup is likely to win in the realization of a general-purpose EVM, and ZK Rollup is likely to win in simple payments, transfers, and other specific applications. But in the medium and long term, with the improvement of ZK-SNARK technology, ZK Rollup will win in all application scenarios.The security of Optimistic Rollup depends on the idea that if someone publishes an invalid batch into the Rollup, anyone who has synchronized the chain can issue a fraud proof to the contract on the main chain, proving that the batch The processing is invalid and should be rolled back (Translator's Note: It is not clear whether the author's "the chain" here refers to the main chain or Rollup, although both are correct).
A fraud proof asserting that a batch is invalid would need to include the data identified in green in the diagram above: the batch itself (checkable against a hash stored on-chain) and evidence that the batch read or modified a specific The account's Merkle tree path. 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.
What is ensured is that if there is an error in a batch, and all previous batches were correct, a fraud proof can 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 (sending ETH) takes about 110 bytes, but implementing an ETH transfer in Rollup only takes about 12 bytes:
- This is partly because Rollup can employ simpler advanced encoding techniques, whereas Ethereum's RLP currently wastes 1 byte on the length of each value. At the same time Rollup also uses 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 amount of Gas to be a power of 2. Alternatively, we can also 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 replace the 20 byte address with an index (for example, if an address is the 4527th address added to the tree, we will use index 4527 to represent it. We will add a subtree in the state to store the index to address mapping)."Value: We can store Value in scientific notation. 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 a single signature of about 32 - 96 bytes (depending on the 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 indicates 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 a part of the transaction is only used for verification and has nothing to do with computing state updates, then this part of the data does not need to 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 , a ZK-SNARK covering the entire batch can already prove thatinternal
The 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. Sex can be verified at the same time.)These compression techniques are the key to the expansion of Rollup. Without these techniques, Rollup may only be able to achieve about 10 times of expansion on the basis of the expansion of the main chain (although in some specific large-scale applications, simple Rollup can achieve Scaling is already powerful), but after using compression tricks, almost any application can scale by a factor of more than 100.- There are many schools of thought on who can submit batches in Optimistic Rollups or ZK Rollups. 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 beyond that, there are many possibilities:
- (Translator's Note, the user who can publish the batch to the main chain is called a sequencer (sorter), the reason for this term is that this role needs to sort the transactions in the batch)
- Completely permissionless sorter: anyone can submit batches 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 batch processing through a role such as a sorter (except for the withdrawal operation: in the withdrawal operation, the user submits the withdrawal request first, if the sorter does not process the withdrawal transaction in the next batch, then the user A batch request containing only one withdrawal transaction can be submitted in person). This method has the highest "efficiency", but it needs to rely on a centralized role.
Sorter Auction: Auction (for example, every day) to decide who has the right to be the next day's Sorter. The advantage of this scheme is that it can raise funds, and these funds can be distributed through Rollup's DAO (refer to MEV auction).
Random selection from the PoS collection: Anyone can deposit ETH (or the token set by the Rollup protocol) into the Rollup contract, and each batch sorter will be randomly selected among these depositors, and the probability of being selected is the same as The deposit amount is directly proportional. The main disadvantage of this scheme is the need to lock a large number of assets."split batch"DPoS Voting: Certain sorters are selected by auction to perform batch processing, but if they underperform, token holders can vote to kick them out and hold a new auction to replace them.- Separate batch and status root commits
- Some Rollups currently under development use "split-batch" (
) mode, that is, the behavior of submitting a batch of layer-2 transaction batches and the behavior 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 increase censorship resistance and alleviate concerns that some batches will be invalidated because some other batches were packed ahead of time.
If one state root is fraudulent, instead of rolling back the entire 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.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 costs 16 Gas on the chain. 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 only requires 12 bytes of storage, which means that each batch can contain 62,500 transactions. Currently, the block interval of the Ethereum main chain is 13 seconds, which means that the realized TPS is about 4807 (by comparison, the TPS of ETH transfer on the Ethereum main chain is about 1250000 / 21000 / 13 = 45).
The following table contains the expansion efficiency of some other application scenarios.Calculation method of the maximum expansion multiple: Gas consumption of the corresponding operation on the Ethereum main chain / (number of bytes to be uploaded to the chain for the corresponding operation in Rollup * 16) * 12 million / 12.5 million
It should be noted that, for several reasons, these figures 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. The third reason is that the usage of Rollup may be low in the short term, so the fixed cost charging model will dominate. But even taking these factors into account, more than 100 times expansion should not be difficult to achieve.- So what if we want to achieve 1000-4000 TPS (depending on the specific application scenario)? This requires eth2 data fragmentation. 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. In the long run, the data capacity is expected to grow further. Therefore, the TPS of Rollup implemented using eth2 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 concept of Rollup is well known to people, and we are sure that Rollup is essentially feasible and safe, and there are already multiple Rollups deployed on the Ethereum mainnet, there are still many places in the design of Rollup. Not well explored, there are still challenges in bringing large parts of the Ethereum ecosystem fully into Rollup to take advantage of its scalability. Some key challenges include:
- The entry of users and ecosystem: currently there are not many applications using Rollup, users are not familiar with Rollup, and few wallets have begun to integrate Rollup. Merchants and charities don't yet accept them for payments.
- Cross-Rollup Transactions: Effectively transfer assets and data (such as oracle machine output) from one Rollup to another without the need to transfer through the main chain and generate corresponding fees.
- Audit Incentives: How to maximize the probability that at least one honest node will fully validate an Optimistic Rollup, ensuring that someone issues fraud proofs if something goes wrong? For small-scale Rollups (with a TPS of several 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.
- Maximize the security of pre-confirmation: In order to make the user experience better, many Rollups provide a concept of "pre-confirmation", that is, after the transaction is completed, the sorter immediately provides a promise: a certain transaction will be included in the next In a batch, if a sorter 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?
Summarize
Improving responsiveness to absent sorters: If a rollup's sorter suddenly goes offline, how to recover from this situation as quickly and cheaply as possible, either by quickly and cheaply mass-exiting to another rollup, or Replace the sorter. Quick response which is very valuable.Efficient ZK-VM: Generate a ZK-SNARK proof to prove that the universal EVM code (or another VM that the existing contract can be compiled into) has been executed correctly and has a definite result.
