Vitalik Buterin believes that Rollup is a powerful and novel two-tier expansion paradigm, which is expected to become the cornerstone of Ethereum’s short-term (or long-term) expansion.
Original Title: “Vitalik: An Incomplete Guide to Rollups”
Written by: Vitalik Buterin, co-founder of Ethereum Translation: ETH Chinese Station
The Rollups solution is all the rage in the Ethereum community and is expected to become a key expansion solution for Ethereum in the future. But what exactly is this technology? What can it bring us? How will we use this technology? This article will try to answer some of these key questions.
Background: What is the expansion of the first and second floors?
There are two ways to expand the blockchain. The first is to increase the transaction capacity of the blockchain itself. The main challenge of this technology is that as the block capacity becomes larger and larger, the blockchain will become more and more difficult to verify and the degree of centralization will become higher and higher. In order to avoid such risks, developers can improve the efficiency of client software. Or choose another more sustainable approach: using technologies such as sharding, so that the building blocks and verification work on the blockchain can be distributed to many nodes (the Eth2 upgrade will introduce this technology to Ethereum) .
The second is to change the way the blockchain is used. That is, users do not directly conduct all transactions on the blockchain, but execute most transactions off-chain through a two-layer protocol. For example, there is a smart contract on the chain. The contract only has two tasks: processing deposit and withdrawal transactions, and verifying the validity of all off-chain transactions. There are many ways to verify off-chain transactions, but they all have the same feature: the cost of verifying the proof on the chain is much lower than that of the original calculation off the chain.
State Channel vs Plasma vs Rollups
The three main types of Layer 2 expansion solutions are: State Channel, Plasma, and Rollups. They are three different paradigms with different advantages and disadvantages. We can roughly classify all two-layer expansion solutions into these three categories (although some solutions have naming disputes due to vague classification, such as validium).
Principle of state channel
For more information, please refer to
Suppose Alice is providing Bob with an Internet connection. In exchange, Bob pays her $0.001 per megabyte. They don’t need to execute the transaction every time they pay, but use the following two-tier solution.
First, Bob deposits 1 USD (or equivalent ETH or stablecoin) into a smart contract. Bob signs a ticket (an off-chain message) that says “$0.001”, and then sends it to Alice, thus completing the first payment to Alice. In the second payment, Bob signs another ticket with “0.002 USD” and sends it to Alice. By analogy, multiple payments can be made as needed. When they complete the transaction, Alice can post the ticket with the highest value to the chain and sign it. The smart contract on the chain will verify the signatures of Alice and Bob, then pay Alice the amount on Bob’s bill, and return the remaining money to Bob.
If Alice is unwilling to close the state channel between them (due to malicious behavior or due to technical failure), Bob can initiate a withdrawal period (withdrawal period), if Alice does not report to Bob within this period (for example, 7 days) Provide a ticket and Bob can get all his money back.
The technology is powerful: it can be adjusted to make two-way payments, process smart contract relationships (for example, Alice and Bob sign a financial contract in the channel), and combine channels (for example, when Alice and Bob, Bob and Charlie When there is an open channel between them, Alice and Charlie can also conduct trustless transactions).
However, the role of state channels is limited: funds cannot be sent outside the chain to users who are not involved; channels cannot represent objects that have no clear owner logically (such as Uniswap); and if more complex transactions are to be carried out, Need to lock a lot of funds in the channel.
Principle of Plasma
For more information, please refer to the earliest Plasma paper and Plasma Cash
The user sends an asset to a smart contract of a Plasma chain to complete the deposit. The Plasma chain assigns a unique ID (such as 537) to the asset. Each Plasma chain has an operator “operator” (he can be a centralized role, a multi-signer, or something more complex such as PoS/DPoS). At regular intervals (which can be 15 seconds to 1 hour), the operator will generate a summary transaction (consisting of all Plasma transactions they have collected off-chain) waiting for batch processing.
These operators will generate a Merkel tree. At each index X in the tree, if there is a transaction, the asset ID X of a certain transfer transaction will be displayed. If there is no transaction, the leaf value is zero. Then they send the Merkel root of the Merkel tree to the chain, and also send each Merkel branch of index X to the current owner of its asset.
If a user wants to make a withdrawal, then the Merkel branch of the transaction to which he recently sent assets is announced. Then the smart contract will initiate a challenge period, during which anyone can try to use other Merkel branches to prove that the withdrawal is invalid. At least one of them needs to be proved: (i) the sender was not the owner of the asset when sending the asset; (ii) the sender later sent the asset to other people. If no one proves that the withdrawal is fraudulent within a certain period of time (such as seven days), the user can withdraw his assets.
Plasma has more powerful performance than state channels: With Plasma, users can send assets to participants who have never joined their system; the capital requirements are also much lower. But Plasma also has disadvantages: During “normal operation”, the channel does not require any data to be transmitted on the chain, and Plasma requires each chain to periodically publish a hash. In addition, transfers on Plasma are not instant: users need to wait for a while and wait until the block is released.
Furthermore, both Plasma and channels have a key weakness: the premise to ensure the security of these two solutions is that the objects controlled by these two systems have logical “owners”. If the owner of the asset does not care about its assets, it may lead to the result of proving its assets are invalid. This is acceptable for many applications, but for many other applications (such as Uniswap) it breaks trading principles. Even in some systems if the state of an object can be changed without the consent of its owner (such as an account-based system, you can increase its balance without someone’s consent), these systems do not apply Plasma.
This means that when deploying any actual Plasma or channel, a lot of “inference of a specific application” is required, and it is impossible to create a Plasma or state channel system that simulates a complete Ethereum environment (or “EVM”) . In order to solve this problem, various Rollup schemes have appeared.
Rollups
For other resources, see EthHub on optimistic Rollups and ZK Rollups
Plasma and channel classes are “pure” two-tier solutions because they move data and calculations off-chain. However, the basic game theory issues surrounding “data availability” mean that these solutions are not necessarily safe for all applications. Plasma and channel solutions rely on the owner to fully understand the state, but this makes such solutions unable to be fully generalized. Rollups is a “hybrid” two-tier solution. Rollups moves calculations (and state storage) off-chain, but puts some data for each transaction on-chain.
In order to improve efficiency, this type of program uses many complex compression techniques to use calculations instead of data as much as possible. The result is that the scalability of the system is still limited by the data bandwidth of the underlying blockchain, but it is still very advantageous in comparison: the transfer cost of the ERC20 token in the Ethereum base layer is about 45,000 gas, while the ERC20 token in Rollup only transfers and occupies 16 bytes of on-chain space cost less than 300 gas.
The fact that the data is on the chain is critical (please note: “putting data on IPFS” is not feasible, because IPFS cannot provide consensus on whether any given data is available; the data must be recorded on the chain). Putting data on the chain and reaching a consensus on this allows anyone to process all operations in Rollup locally as needed, allowing them to detect fraud, initiate withdrawals, or personally start batch generation transactions. The lack of data availability means that a malicious or offline operator can have even less impact (for example, they cannot cause a week’s delay), thus opening up more design space for those who have the right to issue bulk transactions, and Make Rollup easier to follow.
More importantly, the lack of data availability means that there is no longer a need to map assets to owners, so we can draw one of the key reasons why the Ethereum community expects Rollups more than the previous two-tier expansion plan: Rollups are completely universal , We can even run EVM inside Rollup, so that existing Ethereum applications can be migrated to Rollups almost without writing new code.
What is the principle of Rollup?
There is a smart contract on the chain, which contains a state root , that is, the Merkel root of the Rollup state (that is, the account balance inside Rollup, contract code, etc.).
Anyone can publish a batch of aggregated transactions (batch) , which is a highly compressed transaction set that contains the previous state root and the new state root (the new Merkel root after processing the transaction). The contract will check whether the old state root in the batch matches its current state root, and if it matches, the contract will update the state root.
In order to support deposits and withdrawals, we have added the function of importing and exporting transactions that are “external” in the Rollup state. If a batch contains external input, the transactions submitted to the batch also need to transfer assets to the Rollup contract. If a batch contains external output, the smart contract will initiate a withdrawal when the batch is processed.
This is how Rollup works. But there is another important detail: how do you know that the post-state root in batches is correct? If someone can submit a batch with any post-state root without any consequences, they can transfer all the tokens in Rollup to themselves. This problem is critical, because two different solutions were born from this, and these two solutions gave rise to two different Rollups.
Optimistic Rollups and ZK Rollups
The two types of Rollups are:
Optimistic Rollups , whose solution is fraud proofs: This type of Rollup will track all historical state roots and the hash value of each batch. If anyone finds that the post-state root of a batch is incorrect, he can issue a proof to the blockchain to prove that the batch is calculated incorrectly. The contract verifies the proof and rolls back the batch and subsequent batches.
ZK Rollups , its solution is validity proofs: each batch contains a cryptographic proof called ZK-SNARK (for example, using the PLONK protocol) to prove that the post-state root is the result of the correct execution of the batch. Regardless of the amount of calculation, the proof can be verified extremely quickly on the chain.
There are complex trade-offs between these two types of Rollup:
In general, my personal opinion is that in the short term, the significant advantage of Optimistic Rollup lies in its general EVM calculation, and ZK Rollup is more likely to be used for payments, transactions, and other specific use cases. But in the medium and long term, as the ZK-SNARK technology matures, ZK Rollup will give full play to its advantages in all use cases.
Deconstruct fraud proof
Optimistic Rollup’s security guarantee mainly comes from: if someone publishes an invalid batch in Rollup, any other users who follow up on the chain to detect fraud can issue a fraud certificate to prove the invalidity of the batch to the contract, and Roll back.
In the above figure, a fraud proof claiming that a batch is invalid will contain green data: if you want to prove that a particular account is read and/or modified by the batch, you need the batch itself (which can be compared to the hash value stored on the chain) Check) and parts of the Merkle tree. There is no need to provide the yellow nodes in the graph because they can be reconstructed by the green nodes. This data is enough to execute the batch and calculate the post-state root (this is almost the same as the way a stateless client verifies a single block). If the calculated post-state root and the post-state root in the obtained batch are inconsistent, then the batch is invalid.
It can be guaranteed that if a batch is incorrect, but all previous batches are correct, then a fraud proof can be created to indicate that the batch is incorrect. Please pay attention to the statement of the previous batch: if more than one invalid batch is posted to Rollup, it is best to try to prove the earliest invalid batch. It can also be said that if a batch is correct, then a fraud proof can never be created to indicate its invalidity.
How to compress?
A simple Ethereum transaction (sending ETH) is about 110 bytes in size. And for ETH transfer on Rollup, the size is only about 12 bytes:
Part of it is just a simple high-level encoding: Ethereum’s RLP encoding method wastes 1 byte on each value. But it also includes some clever compression techniques:
Nonce: The main purpose of this parameter is to prevent replay attacks. If the current random number of the account is 5, the next transaction record of the account must contain the random number 5, but once the transaction is processed, the random number in the account will increase to 6, so the transaction cannot be processed again. In Rollup, we can completely omit the random number because we can directly recover the random number from the previous state; if someone tries to replay the transaction using the previous random number, the signature will not be verified because it will be based on the data containing the higher random number To check the signature.
Gasprice: We can allow users to pay according to a fixed gas price range, such as 2 to the 16th power. Or we can charge a fixed gas fee in each batch, or even move the gas fee payment completely out of the Rollup protocol, allowing the trader to use the channel to pay the corresponding fee to the batch creator.
Gas: Similarly, we can set the total gas to a power of two. Or we also limit the gas to the batch level.
To: You can use index to replace the 20-byte address (for example, if an address is the 4527th address added to the Merkel tree, we only need to use index 4527 to indicate it. Then add a ” “Subtree” (subtree) to store the mapping relationship between index and address itself).
Value: We can store the value in scientific notation. In most cases, transactions only require 1-3 valid bits.
Signature: We can use BLS aggregation signatures to aggregate a large number of signatures into a signature of about 32-96 bytes (depending on the protocol). The aggregate signature can be checked at one time based on the message set and batch sender set. “~0.5” in the table indicates that the number of signatures that can be included in an aggregate signature is limited, because it is necessary to be able to verify the aggregate signature in a fraud proof.
An important compression technique unique to ZK Rollups is: if part of the transaction information is only used for verification and not used to calculate status updates, then this part can be moved off-chain. Optimistic Rollup cannot do this because the data still needs to be on-chain in case it needs to be checked in the fraud proof. In ZK Rollup, SNARK has proven the correctness of batch, which means that the data required for verification is complete.
Rollups with privacy protection functions are an important example: In optimistic Rollup, the ZK-SNARK proof used for privacy protection in each transaction needs to be on the chain and needs to occupy about 500 bytes. In ZK Rollup, the ZK-SNARK including the entire batch has proven the effectiveness of the “internal” ZK-SNARK.
These compression techniques are the key to the scalability of Rollups, otherwise the scalability of Rollups can only be increased by about 10 times compared with the underlying connection (although for some specific computationally intensive applications, the simple Rollups solution is sufficient), and the data is After compression, for almost all applications, the scalability can be improved by more than 100 times.
Who can package transactions in batches and submit them?
There are many opinions about the packaging rights of optimistic Rollups and ZK Rollups. Generally speaking, any user who wants to package a transaction and submit it must lock a large amount of deposit. If a user submits a batch that contains fraud/invalid transactions (for example, contains invalid state roots), part of the user’s deposit will be destroyed, and the other part will be used as a reward for the fraud prover. In addition, there are other possibilities:
Complete “anarchy”: Anyone can package transactions in batches and submit them at any time. This is the simplest way, and of course there are drawbacks. Especially when multiple participants try to submit at the same time but only one batch can be successfully packaged. This will result in a lot of work to generate proofs and/or gas to release batches to be wasted.
Centralized processing: There is an actor, the sequencer, who submits batches (but there are exceptions for withdrawals: usually a user can submit a withdrawal request first. If the sequence is not processed in the next batch, then the Users can submit a batch by themselves). This is the most “efficient” way, but it relies on a centralized role.
Sorter auction: Regular auctions are used to determine who has the right to become the sorter in the next cycle. The advantage is that it can raise funds and distribute them through mechanisms such as DAO controlled by Rollup. (See MEV auction)
PoS set random selection: anyone can deposit ETH (or Rollup protocol tokens) into the Rollup contract, and then randomly select the sorter of each batch among the depositors, and the probability of being selected is proportional to the locked assets . The main disadvantage of this approach is that a large amount of capital will be locked up, which is unnecessary.
➤ DPoS voting: Determine a sorter through auction. If the actor performs poorly, then the token holders can vote to expel him and initiate a new auction.
Separate batch packaging and state root processing
Some Rollup projects currently under development use the “independent batch packaging” method, which separates the batch submission of the second-level transaction from the submission of the state root. The advantages of this approach are:
- This allows multiple sequencers to publish batches at the same time to improve reviewability, and avoid the problem that some batches are first packaged and other batches are invalid.
- If a state root is invalid, we do not need to roll back the entire batch, we can just roll back the state root and wait for others to provide the new state root of the batch. This ensures that the transaction of the transaction sender will not be rolled back.
In short, the trade-offs in terms of efficiency, simplicity, and censorship resistance are very complex, and many options are also being explored. It is still too early to judge which concepts are the best combination, time will tell.
To what extent can Rollup expand?
On the existing Ethereum chain, the upper limit of gas is 12.5 million. In a transaction, each byte of data costs 16 gas. This means that if a block contains only one batch (we say that it is equivalent to packing a zk Rollup and spending 500,000 gas on proof verification), that batch can contain (12 million / 16) 750,000 bytes of data. As shown above, for an Ethereum transfer Rollup, each user operation only needs 12 bytes, which means that the batch of transactions can contain up to 62,500 transactions. Now the average block time is 13 seconds, which is equivalent to about 4807 transactions per second (in contrast, the current direct transfer on Ethereum is 12.5 million/21000/13~=45 transactions per second)
The following table is an example of other use cases:
The highest level of expansion is calculated as follows: (gas consumption of the first layer)/(bytes occupied by Rollup 16) 12 million/1250 million
Now, it is worth noting that these figures are too optimistic for several reasons. Most importantly, it is almost impossible for a block to contain only one batch, because at least there will be multiple Rollups. Second, deposits and withdrawals will always exist. Third, in the short term, the utilization rate will be relatively low, so fixed costs will dominate. But even if these factors are taken into account, the expansion level of more than 100 times is expected to become the norm.
What if we want to achieve 1000-4000 transactions per second (depending on the specific use case)? This is when eth2 data sharding comes into play. The sharding protocol provides 16 MB of space every 12 seconds to accommodate any data, and the system ensures the consensus of data availability. The data space can be used by Rollup. This space of approximately 1398kb per second is 23 times higher than the current approximately 60kb per second on the Ethereum chain, and in the longer term, data capacity is expected to continue to increase. Therefore, Rollup using eth2 sharded data can process batches at a throughput of about 100,000 transactions per second, which may be more in the future.
What are the unresolved difficulties on Rollup?
Although the basic concepts of Rollup are now well understood, we are convinced that they are completely feasible and safe. Now a variety of Rollup has been deployed on the mainnet, but there are still many areas of Rollup design that have not been fully explored, as well as in the realization of bridging the Ethereum ecosystem. There are still many difficulties in using most of the activities on Rollup to take advantage of their scalability. Some key difficulties include:
The entry of users and ecology-there are not many applications that use Rollup, and users are not familiar with Rollup. Only a few wallets begin to integrate Rollup. Businesses and charities do not yet support this payment method.
Cross-Rollup transactions -efficiently move assets and data (for example: oracle output) from one Rollup to another without incurring fees through the base layer.
Audit incentives -how to maximize the chances of at least one honest node fully verifying an optimistic rollup, so that they will issue fraud proofs when problems arise? For small-scale Rollup (up to a few hundred transactions per second), this is not a big problem, because it is just a small effort for miners, but for large-scale Rollup, more sufficient reasons are needed to convince miners to verify.
Explore the design space between plasma and Rollup -is there a technology that can put some state update related data on the chain instead of all the data, and these data will produce useful things?
Maximize the security of advance confirmation -many Rollups will provide “pre-confirmation” for faster user experience (UX), where the sequencer will immediately promise that a certain transaction will be packaged under In a batch, if this promise is not fulfilled, the sorter will lose its margin. But the economic security of this scheme is limited, because the sequencer can make a lot of promises to a lot of people at the same time. Can this mechanism be improved?
Improve the response speed of absent sorters-if a Rollup sorter suddenly goes offline, it is important to recover from this situation in the shortest time and at the lowest cost. The method is not to quickly and low-cost large-scale exit to Another Rollup is to change a sorter.
Efficient ZK-VM -Generate a ZK-SNARK proof to prove that the general EVM code (or some existing smart contracts can be compiled into different VMs) has been executed correctly and has a given result.
in conclusion
Rollup is a powerful and novel two-tier expansion paradigm, and is expected to become the cornerstone of Ethereum’s short- to medium-term (or long-term) expansion. The Ethereum community has shown a strong interest in Rollup, because unlike previous attempts to expand at the second layer, they can support common EVM codes, making existing applications easy to migrate. Rollup has an important compromise: transaction processing is not done completely off-chain, but each transaction leaves a small part of the data on the chain.
There are many types of Rollup, and there are many choices in the design space: it can be an optimistic Rollup that uses fraud proofs, or a ZK Rollup that uses validity proofs (ie ZK-SNARKs). The sorter (the user who can release the packaged batch to the chain) can be a centralized actor, a laissez-faire person, or many possibilities in between. Rollup is still an early technology, and its development is proceeding rapidly, but they are feasible, and some of them (the more famous ones are Loopring, ZKSync, and DeversiFi) have been running for several months. I look forward to more exciting results from Rollup this year.
Source link: vitalik.ca
