Looking back at the works of V God Rollups, explain in detail why Ethereum needs a two-layer expansion plan?
Original author:Vitalik
Original author:TinTinLand
Rollups are all the rage in the Ethereum community and are expected to become a key scalability solution for Ethereum in the future. But what exactly is this technology, and what to expect from it? How will it be used? This article attempts to answer some key questions related to Rollups on the basis of analyzing several important expansion schemes of Ethereum.
first level title
Background: What are L1 and L2?
Second, the way the blockchain is used can be changed. Instead of having all their activities directly on the blockchain, users perform most of their activities off-chain, in a "layer 2" protocol. There is a smart contract on-chain that has only two tasks: process deposits and withdrawals, and verify evidence that everything that happens off-chain follows the rules. There are various ways to do these proofs, but they all share the property that it is much cheaper to verify the proofs on-chain than to do the raw computation off-chain.
first level title
There are three main types of L2 layer schemes: state channel, Plasma and Rollups. They belong to different paradigms and have different advantages and disadvantages. The operation methods of these three different schemes will be described below.
secondary title
How state channels work
Assume a concrete case where Alice provides Bob with an Internet connection, and Bob pays for it at $0.001 per megabyte. Instead of paying each time, their transactions use the following L2 scheme.
First, Bob puts $1 (ETH or stablecoin equivalent) into the 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 ticket that says "$0.002" and sends it to Alice. And so on, making as many payments as you need. When Alice and Bob complete the transaction, Alice can post the highest value note to the chain and wrap it in another signature of her own. The smart contract verifies both Alice and Bob's signatures, pays Alice the amount on Bob's ticket, and returns the rest to Bob. If Alice is unwilling to close the channel (due to malicious intent or technical failure), Bob can initiate an exit period (say 7 days); if Alice does not provide a ticket within this period, then Bob gets all his money back.
The power of this technology lies in the fact that it can adjust the smart contract relationship that handles two-way payments. For example Alice and Bob enter into a contract within a channel, and if Alice and Bob have an open channel, so does Bob and Charlie, Alice can have a trustless interaction with Charlie.
See also: https://www.jeffcoleman.ca/state-channels and statechannels.org
secondary title
How plasma works
To deposit an asset, a user sends it to a smart contract that governs 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 a multisig, or something more complex like PoS or DPoS). Every interval (maybe 15 seconds, or an hour, or anything in between), the operator generates a "batch" containing all the Plasma transactions they've received off-chain. They generate a Merkle tree where at each index in the tree there is a transaction transferring the asset ID if such a transaction exists, otherwise the leaf is zero.
They also send the Merkle fork of each index to the asset's current owner. To withdraw an asset, a user publishes a Merkle fork of the most recent transaction, and the asset is sent to them. The contract begins a challenge period, during which anyone can try to use other Merkle branches to prove that the exit is invalid, either by (i) the sender not owning the asset when they sent it, (ii) they at some later time Click to send assets to others. If no one proves that the withdrawal was fraudulent within 7 days, the user can withdraw the assets.
Plasma offers stronger properties than state channels: assets can be sent to participants who have never participated in the system, and capital requirements are low. The trade-off is this: during "normal operation" channels don't require any data to be on-chain, but Plasma requires each chain to periodically publish a hash. Also, Plasma body transfers are not instant and must wait until the interval expires and the block is publicly on-chain.
See also: http://plasma.io/plasma-deprecated.pdf
secondary title
How Rollups work
About Rollups
Plasma and channels are "full" L2 solutions in that they attempt to move both data and computation off-chain. However, fundamental game-theoretic issues surrounding data availability mean that it is impossible to do this safely for all applications. Plasma and channels solve this problem by relying on the owner concept, but this affects their scope of application. However, Rollups is a "hybrid" L2 solution. Rollups move computation (and state storage) off-chain, but keep parts of each task's data on-chain. To improve efficiency, they use a lot of complex compression tricks, replacing data with computation whenever possible. The result is that the scalability in the system is still limited by the data bandwidth of the underlying blockchain, but to a lesser extent: the cost of ERC20 token transfer in the base layer of Ethereum is about 45000 gas, while the ERC20 token transfer in Rollups takes up 16 bytes of space on the chain, the cost is less than 300 gas.
It's worth noting that putting data "on IPFS" won't work because IPFS doesn't have a consensus on whether any given piece of data is usable, and the data must be on the blockchain. With the consensus of putting data on-chain, Rollups allows anyone to process any operation locally as they want, allowing them to detect fraud, initiate withdrawals, or start generating batches of transactions themselves. The lack of data availability concerns means that malicious or offline operators can do less harm (eg they can't cause 1 week delays), and Rollups are easier to reason about, opening up more room for use by those who have permission to issue batches. On top of that, the lack of data availability issues means that there is no need to map assets to owners anymore, which has made the Ethereum community very interested in Rollups scaling solutions. Some Ethereum applications migrate to Rollups with almost no new code writing.
See also: https://docs.ethhub.io/ethereum-roadmap/layer-2-scaling/optimistic_rollups/
How rollups work
There is a smart contract on the chain that maintains a state root: the Merkle root of the Rollups state (meaning account balances, contract code, etc., "inside" Rollups).
Anyone can publish a batch, a highly compressed set of transactions, along with the previous state root and the new state root (the Merkle root after processing the transaction). The contract checks whether the previous state root in the batch matches its current state root; if it does, it switches the state root to the new state root.
How do you know that the post-state root in the batch is correct? If someone can submit a batch with any post-state root without consequences, they can transfer all coins in Rollups to themselves. This problem is critical, for which two distinct families of solutions have arisen, resulting in two different Rollups.
first level title
Optimistic Rollups and ZK Rollups
The two types of Rollups are:
Optimistic Rollups, using fraud proofs: The Rollups contract tracks the entire history of its state root and hashes for each batch. If someone finds a batch with an incorrect post-state root, they can post a proof to link that the batch was computed incorrectly. The contract will verify the proof, and restore that batch and all subsequent batches.
ZKRollups (Zero-Knowledge Rollups), using proofs of validity: each batch contains a cryptographic proof called a ZK-SNARK (for example using the PLONK protocol), which proves that the post-state root is the correct result of executing the batch. Proofs can be verified very quickly on-chain, no matter how computationally intensive.
Overall, in the short term, Optimistic Rollups are likely to win in general EVM computations, while ZK Rollups are likely to win in simple payments, exchanges, and other application-specific use cases.
secondary title
Anatomy of a Fraud Proof
The security of Optimistic Rollups depends on the assumption that if someone posts an invalid batch into a Rollup, anyone else who detects fraud can post a proof of fraud, proving to the contract that the batch is invalid and should be reinstated.
Certainly, if a batch is constructed incorrectly, and all previous batches were constructed correctly, it is possible to create fraud proofs that the batch was constructed incorrectly. Note the statement about previous batches: if multiple invalid batches are released into Rollups, it is best to try to prove that the oldest batch is invalid. Of course, if the batch is constructed correctly, it will never be possible to create fraud proofs that the batch is invalid.
secondary title
Data Compression Principle
A simple Ethereum transaction (sending ETH) takes about 110 bytes. However, ETH transfers in Rollups only take about 12 bytes:
Part of this is just high-level encoding: Ethereum's RLP wastes 1 byte on the length of each value. But it also contains certain compression techniques:
Nonce: The purpose of this parameter is to prevent replay attacks. If an account's current Nonce is 5, the next transaction for that account must have a Nonce 5, and once the transaction is processed, the nonce in the account will increase to 6, so the transaction cannot be processed again. In Rollups, we can omit the nonce entirely since we are just restoring the nonce from the previous state; if someone tries to replay the transaction with an earlier nonce, the signature will not be verifiable because the signature will be against data containing a higher nonce Check.
Gasprice: We allow users to pay in a fixed range of Gasprice, such as 2 to the 16th power. Or it is possible to have a fixed fee per batch, or even move the gas payment out of the Rollups protocol entirely, and have transaction participants pay the batch creator the fee via state channels.
Gas: We can also limit the total gas to multiple powers of 2. Or set the gas limit at the batch level.
To: We can replace the 20 byte address with index. If an address is the 4527th address added to the tree, we just use index 4527 to refer to it, and a subtree will be added to the state to store the index to the address.
Value: We can store values in scientific notation. In most cases, only 1-3 significant digits are required for transfers.
Signature: We can use BLS aggregated signatures, which allow a large number of signatures to be aggregated into a single signature of about 32-96 bytes (depending on the protocol). This signature can then be checked against the entire set of messages and senders in a batch. "About 0.5" in the table indicates that there is a limit to the number of signatures that can be combined in an aggregate that can be verified in a single block, so large batches require about one signature every 100 transactions.
These compression tricks are the key to the scalability of Rollups. Without them, Rollups are probably only about 10 times the scalability of the base chain (although there are certain compute-intensive applications where even simple Rollups are powerful), and with data compression, the scalability of almost all applications Both can achieve more than 100 times improvement.
secondary title
Who can submit batches?
There are many arguments as to who can submit batches in Optimistic or ZKRollups. In general, everyone agrees that in order to be able to submit a batch, a user has to pay a large deposit; if that user ever submits a fraudulent batch (e.g. with an invalid state root), this deposit is partially destroyed and partially given as a reward Fraud Prover. But beyond that, there are many possibilities:
Complete anarchy: anyone can submit a batch at any time. This is the easiest method, but it has some important disadvantages. Once there are multiple participants, generate and try to submit batches in parallel, but in the end only one batch can be successfully packaged. This leads to a lot of wasted effort in generating proofs, as well as a waste of gas publishing batches to the chain.
Centralized processing: there exists a sequencer to submit batches (except for withdrawals: the usual technique is that users can first submit a withdrawal request, and then if the sequencer does not process the withdrawal in the next batch, then the user can submit it himself single operation batch). This is the most "efficient", but it relies on a core actor to operate.
Sorter Auction: An auction is held (e.g. every day) to determine who has the right to be the next day's sorter. The advantage of this technology is that it can raise funds for further distribution through a DAO controlled by Rollups. (See: MEV Auction)
DPoS Voting: Serializers are selected in an auction, but if they underperform, token holders can vote to kick them out and hold a new auction.
secondary title
Split Batch and State Root Supply
Rollups currently under development uses a "split-batch" approach, that is, submitting a batch of L2 operations and submitting state roots is done separately. This has some key advantages:
Many sorters can be allowed to publish batches in parallel for increased censorship resistance without worrying that some batches will be invalidated because some other batches were included first.
All in all, it's a fairly complex technique that attempts to strike a complex balance between efficiency, simplicity, censorship resistance, and other goals. It's too early to say which combination of these ideas will work best. Time will prove everything.
first level title
How much scaling can Rollups bring?
Here are diagrams for some other example use cases:
image description
The maximum scalability gain is calculated as (L1 gas cost) / (bytes in Rollups * 16) * 12 million / 12.5 million.
Now, what if we want to exceed ~1000-4000 TPS? This is where Eth2 data sharding comes in. The sharding proposal provides 16 MB of space every 12 seconds, which can accommodate any data and ensure the availability of that data. If this data space is used by Rollups, the space of about 1398kb per second is 23 times higher than that of the existing Ethereum chain. In the long run, the data capacity is expected to grow further. Therefore, Rollups using Eth2 shard data can jointly process up to about 100,000 transactions, and even more in the future.
first level title
What challenges does Rollups have that haven't been fully resolved?
While the basic concepts of Rollups are now well understood, they are feasible and secure, and there have been multiple Rollups deployed to mainnet, there are still many areas of Rollups design that have not been fully explored, leaving much of the Ethereum ecosystem There are many challenges in getting content fully into Rollups. Some key questions include:
User and Ecosystem Entry - There are not many projects using Rollups, users are not familiar with it, and few wallets integrate Rollups. Merchants and charities do not yet support this payment method.
Cross-Rollups Transactions - Efficiently move assets and data from one Rollups to another without incurring L1 fees.
Audit Incentives - How to maximize the chance that at least one honest node fully validates an Optimistic Rollup, so that they broadcast fraud proofs when problems arise? For small-scale Rollups (up to hundreds of transactions per second), this problem is not a big problem, because it is just a matter of effort for miners, but for large-scale Rollups, more reasons are needed to convince miners to do verification.
Exploring the design space between Plasma and Rollups - are there techniques for putting some, but not all, of the data associated with a state update on-chain, that would result in something useful?
Maximum pre-confirmation safety - Many Rollups offer the concept of "pre-confirmation" for a faster user experience, where the orderer immediately provides a promise that the transaction will be included in the next batch, and if the orderer violates promise, the depositor's deposit will be destroyed. But the economic security of this scheme is limited, since it is possible to make many commitments to many actors at the same time. Can this mechanism be improved?
Efficient ZK-VM - Generate a ZK-SNARK that proves that the generic EVM code (or some different VM to which an existing smart contract can compile) has executed correctly with a given result.
first level title
in conclusion
From the perspective of technical design, there are many types of Rollups, such as Optimistic Rollups using fraud proofs and ZK Rollups (ZK-SNARKs) using validity proofs. Rollups are still an early, rapidly developing technology and expect to see many more exciting projects in the Rollups space in the coming years.
