Vitalik: The Incomplete Guide to Rollups
Source | vitalik.ca
Author | Vitalik Buterin
Author | Vitalik Buterin
The Rollups solution is all the rage in the Ethereum community and is expected to become a key scaling solution for Ethereum in the future. But what exactly is the technology like? What can it bring us? How will we use this technology? This article will try to answer some of these key questions.
first level title
Background: What is Layer 1 and Layer 2 expansion?
There are two ways to expand the blockchain. First, it can increase the transaction capacity of the blockchain itself. The main challenge of this technology is that as the block size increases, the blockchain will become more and more difficult to verify and the degree of centralization will become higher and higher. To avoid such risks, developers can improve the efficiency of client software. Or choose another more sustainable way: use technologies such as sharding, so that the construction of blocks and verification work on the blockchain can be distributed to many nodes (this technology will be introduced to Ethereum in the Eth2 upgrade) .
State Channels vs Plasma vs Rollups
The three main types of Layer 2 scaling solutions are: state channels, plasma, and rollups. They are three different paradigms with different strengths and weaknesses. We can roughly classify all Layer 2 expansion solutions into these three categories (although some solutions have naming disputes due to vague classification, such as validium).
first level title
The principle of state channel
For more information, please refer to: https://www.jeffcoleman.ca/state-channels and statechannels.org
Suppose Alice is providing Bob with an Internet connection in exchange for Bob paying her $0.001 per megabyte. Instead of executing a transaction for every payment, they use a layer-2 solution below.
First, Bob deposits $1 (or the equivalent in ETH or stablecoins) into a smart contract. Bob signs a ticket with "$0.001" (an off-chain message) and sends it to Alice, thus completing the first payment to Alice. For the second payment, Bob signs another ticket with "$0.002" and sends it to Alice. And so on, making as many payments as you want. When they are done with the transaction, Alice can post the ticket with the highest value to the chain and sign it. A smart contract on the chain will verify Alice and Bob's signatures, then pay Alice the amount on Bob's note, and return the remaining money to Bob.
The technology is powerful: it can be tuned for two-way payments, for handling smart contract relationships (e.g., Alice and Bob enter into a financial contract in a channel), and for combining channels (e.g., when Alice and Bob, Bob and Charlie Alice and Charlie can also conduct trustless transactions when there is an open channel between them).
However, the role of state channels is limited: funds cannot be sent outside the chain to users who have not participated; channels cannot represent objects that do not logically have clear owners (such as Uniswap); and if more complex transactions are to be performed, A large amount of funds needs to be locked in the channel.
first level title
How Plasma works
http://plasma.io/plasma-deprecated.pdf
Plasma Cash：
https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298
For more information, please refer to 👇
Earliest Plasma papers:
The user sends an asset to the smart contract of a Plasma chain to complete the deposit. The Plasma chain assigns a unique ID (such as 537) to the asset. Every Plasma chain has an operator "operator" (who can be a centralized actor, a multi-signature, or something more complex like PoS/DPoS). Every so often (which can be anywhere from 15 seconds to an hour), the operator generates an aggregated transaction (consisting of all the Plasma transactions they have collected off-chain) waiting to be batched.
These operators will generate a Merkle tree. At each index X in the tree, if there is a transaction, the asset ID X of a transfer transaction will be displayed. If there is no transaction, the leaf value will be zero. They then send the Merkle root of that Merkle tree on-chain, along with the Merkle branch of each index X to the current owner of its asset.
If a user wants to make a withdrawal, then publish the Merkle branch of the transaction that most recently sent them assets. The smart contract will then initiate a challenge period, during which anyone can try to invalidate the withdrawal using other Merkle branches. At least one of these needs to be proven: (i) the sender was not the owner of the asset when it was sent; (ii) the sender later sent the asset to someone else. If no one proves that the withdrawal was fraudulent within a certain period of time (such as seven days), the user can withdraw his assets.
Again, both Plasma and channels have a key weakness: making both schemes secure requires logical "owners" of the objects controlled by both systems. If the owner of that asset doesn't care about their asset, then that could lead to proving that their asset is invalid. This is acceptable for many applications, but a deal-breaker for many others (like Uniswap). Even systems in which the state of an object can be changed without the consent of its owner (such as an account-based system where you can increase someone's balance without their consent) are not suitable for Plasma.
Rollups
This means that when deploying any actual plasma or channel, a lot of "reasoning about a particular application" is required, and it is not possible to create a plasma or state channel system that simulates the full Ethereum environment (or "EVM") . To solve this problem, various rollup schemes have emerged.
EthHub on optimistic rollups：
https://docs.ethhub.io/ethereum-roadmap/layer-2-scaling/optimistic_rollups/
ZK rollups：
https://docs.ethhub.io/ethereum-roadmap/layer-2-scaling/zk-rollups/
first level title
For other resources see 👇
Plasma and channel classes are "pure" layer 2 solutions in that they move both data and computation off-chain. However, fundamental game-theoretic issues surrounding "data availability" mean that these schemes are not necessarily safe for all applications. Plasma and channel solutions rely on full knowledge of the state by the owner, but this prevents such solutions from being fully generalizable. Rollups is a "hybrid" two-tier solution. Rollups move computation (and state storage) off-chain, but put some data about each transaction on-chain.
It's key that the data is on-chain (note: putting data "on IPFS" won't work because IPFS doesn't provide consensus on whether any given data is available; the data must be recorded on-chain). Putting the data on-chain and reaching consensus on it allows anyone to handle all operations in the rollup locally as needed, allowing them to detect fraud, initiate withdrawals, or start batching transactions themselves. Lack of data availability means that a malicious or offline operator can have even less impact (e.g. they can't cause a week's delay), opening up more design space for whoever has the power to issue batches of 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, which leads us to one of the key reasons why the Ethereum community expects rollups more than previous layer-2 scaling solutions: rollups are fully general , we can even run the EVM inside the rollup, so that existing Ethereum applications can be migrated to rollups with almost no need to write new code.
first level title
What exactly is the principle of Rollup?
There is a smart contract on the chain, which contains a state root, which is the Merkle root of the rollup state (that is, the account balance, contract code, etc. inside the rollup).
Anyone can publish a batch of aggregated transactions (batch), which is a highly compressed collection of transactions that contains the previous state root and the new state root (the new Merkle 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.
To support deposits and withdrawals, we've added the ability to import and export transactions that are "outside" the rollup state. If a batch contains inputs from outside, the transactions submitted to the batch also need to transfer assets to the rollup contract. If a batch contains outputs from outside, the smart contract will initiate a withdrawal when processing the batch.
This is how rollup works. But there is one more important detail: how do we know that the post-state root in the batches is correct? If someone can submit a batch with an arbitrary post-state root without any consequences, they can transfer all tokens in the rollup to themselves. This question is critical because it leads to two different solutions, which in turn lead to two different rollups.
Optimistic rollups and ZK rollups
The two rollups are:
1. Optimistic rollups, whose solution is fraud proofs: This type of rollup keeps track of all historical state roots and hash values for each batch. If anyone finds out that the post-state root of a certain batch is incorrect, he can post a proof to the blockchain that the batch was miscalculated. The contract verifies the proof and rolls back the batch and subsequent batches.
There are complex tradeoffs between these two types of rollups:
In general, my personal opinion is that in the short term, the significant advantage of optimistic rollup lies in its general-purpose EVM computation, while ZK rollup is more likely to be used for payments, transactions, and other specific use cases. But in the medium and long term, with the maturity of ZK-SNARK technology, ZK rollup will play an advantage in all use cases.
first level title
Deconstructing Fraud Proofs
In the diagram above, a fraud proof claiming that a batch is invalid would contain data in green: the batch itself is required (contrast that with the hashes stored on-chain to check) and parts of the Merkle tree. The yellow nodes in the graph do not need to be provided because they can be reconstructed by the green nodes. This data is enough to execute the batch and compute the post-state root (this is pretty much the same way a stateless client validates a single block). If the computed post-state root is inconsistent with the post-state root in the obtained batch, then the batch is invalid.
It is guaranteed that if a batch is incorrect, but all previous batches were correct, then a fraud proof can be created to indicate that the batch was incorrect. Note the declaration of previous batches: if more than one invalid batch is published to the 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 invalidate it.
first level title
How to do the compression?
A simple Ethereum transaction (sending ETH) is about 110 bytes in size. However, for ETH transfer on rollup, the size is only about 12 bytes:
Part of this is simply high-level encoding: Ethereum's RLP encoding wastes 1 byte per value. But it also includes some clever compression tricks:
➤ Nonce: The main purpose of this parameter is to prevent replay attacks. If an account's current nonce is 5, the next transaction for that account must contain a nonce of 5, but as soon as the transaction is processed, the nonce in that account is incremented to 6, so the transaction cannot be processed again. In rollup, we can omit the nonce entirely, since we can restore the nonce directly from the previous state; if someone tries to replay the transaction with the previous nonce, the signature will be unverifiable because the data containing the higher nonce will be relied upon. to check the signature.
➤ Gasprice: We can allow users to pay in 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 out of the rollup protocol completely, and let the trader use the channel to pay the corresponding fee to the batch creator.
➤ Gas: Similarly, we can set the total gas as multiple powers of 2. 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 Merkle tree, we only need to use index 4527 to represent it. Then add a "Subtree" (subtree) to store the mapping relationship between the index and the address itself).
➤ Value: We can store values in scientific notation. In most cases, transactions only require 1-3 significant digits.
➤ Signature: We can use BLS aggregated signatures to aggregate a large number of signatures into a signature of about 32-96 bytes (depending on the protocol). The aggregated signature can be checked at one time based on the message set and the sender set of the batch. The "~0.5" in the table indicates that there is a limit to the number of signatures that can be included in an aggregate signature because of the need to be able to verify the aggregate signature in a fraud proof.
Rollups with privacy protection are an important example: in optimistic rollups, the ZK-SNARK proofs for privacy protection in each transaction need to be on-chain and occupy about 500 bytes. In ZK rollup, the ZK-SNARK containing the entire batch has proved 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 network (although for some specific computing-intensive applications, the simple rollups scheme is sufficient), and the data is processed After compression, the scalability can be improved by more than 100 times for almost all applications.
first level title
Who can package transactions in batches and submit them?
There are many claims about the packaging rights of transactions in optimistic rollups and ZK rollups. Generally speaking, any user who wants to package a transaction and submit it must lock up a large deposit. If a user submits a batch containing fraudulent/invalid transactions (e.g., containing an invalid state root), then part of the user's deposit is destroyed and the other part is rewarded to the fraud prover. Besides that, other possibilities exist:
➤ Complete "anarchy": Anyone can batch and submit transactions at any time. This is the easiest way, but of course there are drawbacks. Especially when multiple participants try to submit at the same time but in the end only one batch can be successfully packaged. This results in a lot of wasted work to generate proofs and/or gas to issue batches.
➤ Centralized processing: There is an actor, the sequencer, who submits batches (but there is an exception for withdrawals: generally a user can submit a withdrawal request first, if the sequencer does not process the withdrawal in the next batch, then The user can submit a batch by himself). This is the most "efficient" way, but relies on a centralized role.
➤ Random selection of PoS set: Anyone can deposit ETH (or the token of the rollup protocol) into the rollup contract, and then randomly select the sorter of each batch among the depositors. The possibility of being selected is proportional to the locked assets Proportion. The main disadvantage of this approach is that a large amount of capital will be locked up unnecessarily.
➤ DPoS voting: A sorter is determined through an auction. If the actor does not perform well, token holders can vote to expel him and initiate a new auction.
first level title
Separate bulk packaging and state root handling
Some rollup projects currently under development adopt the method of "independent batch packaging", that is, the process of submitting the batch of the second-tier transaction and the process of submitting the state root is separated. The advantages of this approach are:
2. If a state root is invalid, we don't need to roll back the entire batch, we can just roll back the state root and wait for others to provide a new state root for the batch. This ensures that the sender's transaction will not be rolled back.
In summary, the trade-offs in efficiency, simplicity, and censorship resistance are complex, and many options are being explored. It's too early to tell which concepts are the best combination, and time will tell.
first level title
To what extent can rollup achieve expansion?
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 it is equivalent to packaging 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 a rollup of Ethereum transfer, 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 (compared to 12.5 million/21000/13~=45 transactions per second for direct transfers on Ethereum)
The following tables are examples of other use cases:
Now, it's worth noting that these numbers are far 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, utilization rates will be low, so fixed costs will dominate. But even with these factors taken into account, scaling levels of over 100x are expected to be the norm.
What if we want to achieve 1000-4000 transactions per second (depending on the specific use case)? This is where eth2 data sharding comes into play. The sharding protocol provides 16MB of space for any data every 12 seconds, and the system ensures a consensus on data availability. Data space can be used by rollup. This space of about 1398kb per second is 23 times higher than the current 60kb per second on the Ethereum chain, and in the longer term, the data capacity is expected to continue to increase. Thus, a rollup using eth2 sharded data can be batched at a throughput of about 100,000 transactions per second, and possibly more in the future.
first level title
What unresolved difficulties remain on Rollup?
Although the basic concepts of rollups are now well understood, we are confident that they are completely feasible and secure, and that multiple rollups have now been deployed on mainnet, there are still many areas of rollup design that are not fully explored, and the implementation of bridging the Ethereum ecosystem. There are difficulties in moving most of the activity to rollups to take advantage of their scalability. Some key difficulties include:
➤ Settling in of users and ecology - there are not many applications using rollup, users are not familiar with rollup, and only a few wallets have begun to integrate rollup. Merchants and charities do not yet support this payment method.
➤ Cross-rollup transactions—Efficiently move assets and data (eg, oracle output) from one rollup to another without incurring fees via the base layer.
➤ Audit Incentives - How to maximize the chance that at least one honest node will fully verify an optimistic rollup such that they will issue fraud proofs if something goes wrong? For small-scale rollups (up to hundreds of transactions per second), this problem is not a big problem, because it is just a piece of cake for miners, but for large-scale rollups, more reasons are needed to convince miners to do verification.
➤ 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 this data will produce useful things?
➤ Efficient ZK-VM - generate a ZK-SNARK proof that the general EVM code (or different VMs that some existing smart contracts can compile into) has been executed correctly and with a given result.
in conclusion
first level title
Original link:
Original link:https://vitalik.ca/general/2021/01/05/rollup.html
ECN's translation work aims to deliver high-quality information and learning resources for the Chinese Ethereum community. The copyright of the article belongs to the original author, and the source of the original text and the ETH Chinese website must be indicated when reprinting. For long-term reprinting, please contact eth@ecn.co for authorization.
Official Account: ETH Chinese Station
ECN's translation work aims to deliver high-quality information and learning resources for the Chinese Ethereum community. The copyright of the article belongs to the original author, and the source of the original text and the ETH Chinese website must be indicated when reprinting. For long-term reprinting, please contact eth@ecn.co for authorization.
