<p><strong>There are two ways to expand the blockchain ecosystem. The first way to expand is to allow the blockchain itself to have a higher transaction processing capacity</strong> . For example, making blocks “bigger”, but “big blocks” will make the verification process of the blockchain more difficult and may make the nodes more centralized. In order 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 spread the work of building and verifying the blockchain among many different nodes-"eth2" is trying to upgrade Ethereum in this way.</p>
<p><strong>The second way to expand capacity is to change the method of using blockchain</strong> . Users do not need to put all activities directly on the blockchain main chain, but perform most activities in the "two-layer" protocol outside the main chain, and generate a certificate to prove all the activities that occur outside the chain 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 many ways to achieve proof and verification, but they all have a common feature, that is, verifying the proof on the chain is much less expensive than doing the original calculation off the chain.</p>
<p><br/></p>
<h2><strong>State channel vs plasma vs rollup</strong></h2>
<p><br/></p>
<p>There are three main options for layer 2 expansion: state channel, Plasma and rollup. The three schemes represent three different paradigms, and each scheme has its own advantages and disadvantages. All the second-tier expansions generally fall into these three categories (there are disputes about how to classify some compromise solutions, such as "validium")
<p><br/></p>
<h3><strong>How does the status channel work</strong></h3>
<p>See also https://www.jeffcoleman.ca/state-channels, statechannels.org</p>
<p>Imagine that Alice provides Bob with a network connection service. In exchange, Bob pays Alice $0.001/MB for the traffic generated by the Internet. Bob does not need to pay every fee on the first-level main chain. Both parties use the following two-tier scheme.</p>
<p>First, Bob deposits 1 USD (stable currency, or equivalent ETH) into a smart contract. In order to make the first payment to Alice, Bob signs a "ticket" (an off-chain message) with "$0.001" written on the "ticket" and sends it to Alice. To make the second payment, Bob signs another note with "$0.002" and sends it to Alice. By analogy, this process is repeated for each payment (Translator's Note: The state channel participants only need to keep one latest state change, so after the new bill is signed, the previous bill becomes invalid). When Alice and Bob complete the transaction, Alice can wrap the most valuable ticket with her signature and publish it on the main chain (close the channel). The smart contract verifies the signatures of Alice and Bob. After the verification is passed, the amount marked on Bob's bill is paid to Alice, and the remaining amount (translator's note: 1 dollar minus the former) is returned to Bob. If Alice (due to malicious 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 during this period, then Bob can get back the previous All the money stored in the smart contract.</p>
<p>The state channel technology is very powerful: a broad state channel can support two-way payment, implement smart contracts (for example, Alice and Bob sign a financial contract in the channel), and have composability (if there is an open channel between Alice and Bob, Bob There is also an open channel with Charlie, so Alice can interact with Charlie without trust). However, the role of the channel is limited: it cannot send funds off-chain to users who have not 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.</p>
<h3><strong>How Plasma works</u></strong></h3>
<p>See also the original Plasma white paper, Plasma Cash</p>
<p>To deposit assets from the main chain into the Plasma chain, users need to send the assets on the main chain to the smart contract that manages the Plasma chain. The Plasma chain will assign a new unique ID to the asset (for example, 537). Each Plasma chain has an operator (this may be a centralized role, or controlled by multi-signature, or it may be more complex, such as a PoS chain or DPoS chain). Every time (it can be 15 seconds, it can be an hour, or any time in between), the operator will generate a "batch" (batch), including the received within this period of time All transactions on the Plasma chain. The operator generates a Merkle tree. At the leaf node with index X, if the asset with asset ID X has a transaction in this batch, the corresponding transaction is stored 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 each Merkle branch of index X to the current owner of the asset. If assets need to be extracted from the Plasma chain to the main chain, users need to send the Merkle branch corresponding to the most recent transaction of the asset to the smart contract of the main chain. The smart contract immediately begins a challenge period (for example, 7 days), during which anyone can try to use other Merkle branches to prove: (i) the user does not own the asset when withdrawing the asset, or (ii) the user is At a certain point in time the asset was sent to someone else, thereby invalidating the withdrawal request. If no one proves that the withdrawal is fraudulent within 7 days, the user can successfully retrieve the assets.</p>
<p>Plasma provides more powerful features than state channels: you can send assets to users who have never joined the second layer, and the locked funds are much lower. But this comes at a price: the state channel does not need to store any data in the main chain during "normal operation", but Plasma requires each chain to publish a hash value on the main chain at regular intervals. In addition, transactions in the Plasma chain are not instantaneous, that is, it is necessary to wait for a batch of transactions (also known as Plasma blocks) evidence (that is, the Merkle root value) to be sent to the main chain.</p>
<p>In addition, both Plasma and state channels have an important flaw: the game theory corresponding to their security model relies on the idea that the assets controlled by both systems must have "owners" at the logical level. As long as the asset owner cares about his own assets, when the status change of the asset is “invalid”, the asset owner will find a way to show proof that the change is “invalid”. This is irrelevant for some applications, but it is a problem for many other applications (such as Uniswap) (Translator's Note: For DEX trading applications such as Uniswap, the smart contract does not belong to anyone, and the above security Suppose the idea of dependence is contradictory). 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 consent of the owner), it cannot be matched well with Plasma compatible. This means that when deploying plasma or state channels in reality, it is necessary to deduce the potential logic design customized solution of the "specific application", and it is impossible to make a plasma that can completely simulate the Ethereum operating environment (ie "EVM") Or state channel system. Next let us see how rollup solves this problem.</p>
<h3><strong>Rollup</strong></h3>
<p>See also: EthHub's introduction to optimistic rollup, EthHub's introduction to ZK rollup</p>
<p>Both Plasma and state channel solutions are "complete" layer 2 solutions, because they transfer data and calculations off-chain (ie, their own two-layer system). However, the basic game theory principles of data availability mean that such a system cannot safely implement all applications. Plasma and state channels solve this problem by clarifying the relationship between asset objects and owners, but this prevents them from being fully universal. Rollup is different from the previous two in that it is a two-tier solution with "hybrid nature". <strong>Rollup transfers calculations (and complete state storage) off-chain, but saves part of the data for each transaction on-chain</strong> . In order to improve efficiency, Rollup uses a series of fancy compression techniques and <strong>replaces data with calculations</strong> as much as 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: the transfer of an ERC-20 token on the Ethereum main chain will consume approximately 45000 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.</p>
<p>Data storage on the main chain is a key factor for Rollup (please note: this is different from storing data on "IPFS", because IPFS does not agree on the stored data, and Rollup data must be stored on the blockchain). Storing data in the main chain and performing consensus allows anyone to process all operations in Rollup locally, including fraud detection, initiating withdrawals, and batch processing. Because there is no data availability issue, operators who do evil or go offline will cause relatively less losses (for example, they cannot cause a one-week exit delay). It also provides information on who has the right to issue batch processing. More possibilities, but also makes Rollup easier to understand. More importantly, the absence of data availability problems means that assets do not need to have a clear logical mapping relationship with their owners. Compared with other two-tier 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 written without writing new ones. Migrate to Rollup in case of code.</p>
<p><br/></p>
<h2><strong>How exactly does Rollup work?</strong></h2>
<p><br/></p>
<p>There is a smart contract on the main chain, and there is a <strong>state root</strong> -the Merkle root that represents the state of Rollup. (Status content includes account balance in Rollup, contract code, etc.)</p>
<p><img src="https://hx24.huoxing24.com/image/crawler/2021/01/24/1611493480486585.jpg"/>Anyone can initiate a <strong>batch</strong> transaction for 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). The new state root generated after the batch transaction is executed on the root basis). 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 check passes, the old state root on the main chain will be updated to the new state root.</p>
<p><img src="https://hx24.huoxing24.com/image/crawler/2021/01/24/1611493480489514.jpg"/>In order to support deposits (translator's note: deposit assets from other places in the main chain into the Rollup contract) and withdrawals (translator's note: remove Rollup contract's control of their assets and return them to other places on the chain), batch processing The input or output of the transaction can be the "external" state of Rollup (translator's note: that is, elsewhere in the main chain). If the input of a transaction in the batch comes from outside of Rollup, then this batch operation will transfer assets from other parts of the main chain to the Rollup contract. If the output of a transaction in the batch comes from outside of Rollup, then this batch will trigger the withdrawal operation in the smart contract to retrieve assets from Rollup to the main chain.</p>
<p>The whole process is that simple! But there is one more detail. <strong>How to know that the state root after batch execution is correct? </strong>If someone can submit a fake state root without any consequences, they can transfer all their assets to themselves. This problem is critical, because there are two completely different solutions to this problem, resulting in two types of Rollup.</p>
<h3><strong>Optimistic rollups vs ZK rollups</u></strong></h3>
<p>The two types of Rollup include:</p>
<ol><li><strong>Optimistic Rollup</strong> uses <strong>fraud proof to</strong> solve the above problems: The Rollup contract of the main chain records the complete record of the internal state root change of the Rollup, and the hash value of each batch (that triggers the state root change). If someone finds that the new state root corresponding to a batch is wrong, they can publish a certificate on the main chain to prove that the new state root generated by the batch is wrong. The contract verifies the proof, and if the verification passes, all batch transactions after the batch are rolled back.</li><li><strong>ZK Rollup</strong> , using the <strong>validity certificate to</strong> solve the above problems: Each batch contains a cryptographic certificate 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 certificate only needs to have the characteristics of small size and fast verification, without zero knowledge, so only SNARK is required to implement ZK Rollup, not necessarily ZK-SNARK. In fact, in ZK Rollup, because batch transaction information is stored on the main chain, and this information is exactly what is certified in the cryptographic certification system, ZK Rollup itself is not zero-knowledge, but has zero-knowledge. ZK Rollup is called ZK ZK Rollup.) No matter how large the batch calculation is, the proof can be efficiently verified on the main chain.</li></ol>
<p>The design trade-offs between these two types of Rollup are more complicated</p>
<p>The fixed gas cost <strong>of</strong> each batch of Optimistic Rollup ZK Rollup on the main chain is <strong>about 40,000</strong> (the cost is relatively lightweight, and the main operation is to change the value of the state root) about 500,000 (the verification cost for ZK-SNARK is relatively large) The withdrawal cycle is about 1 week (you need to allow time to see if someone submits a fraud proof to cancel the invalid withdrawal application) <strong>very fast</strong> (it can be completed in the next batch after the withdrawal application is submitted) <strong>low</strong> technical complexity (ZK-SNARKs technology is relatively new , Relatively more complicated at the mathematical level) It is <strong>relatively easier to</strong> achieve universality (Rollup that implements universal EVM will soon be deployed in the main network) is relatively more difficult (use ZK-SNARK to prove universal EVM to perform operations It is much more difficult than proving simple calculation operations. Of course (Cairo, etc.) are working hard to simplify the process) The cost of each transaction in Rollup is relatively higher and <strong>relatively lower</strong> (if some part of the transaction data is only used to verify the transaction This part of the data does not need to be stored on the main chain, and all the data needs to be stored in Optimisitc Rollup for subsequent fraud proof generation and verification.) The cost of off-chain calculations is <strong>relatively higher. Low</strong> (although more full nodes are required for recalculation) Relatively higher (generating ZK-SNARK proofs, especially the cost of generating general-purpose calculation proofs may be very large, thousands of times larger than direct calculations)</p>
<p>In general, my own opinion is that in the short term, Optimisitc Rollup is likely to win in the realization of a universal 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 improvement of ZK-SNARK technology, ZK Rollup will win in all application scenarios.</p>
<h3><strong>Analysis of fraud proof</u></strong></h3>
<p>The security of Optimistic Rollup depends on the idea that if someone publishes an invalid batch to Rollup, anyone who synchronizes the chain can issue a fraud proof to the contract on the main chain as long as they discover fraud, proving 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).</p>
<p><img src="https://hx24.huoxing24.com/image/crawler/2021/01/24/1611493480484269.jpg"/>A fraud proof that asserts that a certain batch is invalid needs to include the data marked in green in the above figure: the batch itself (which can be checked with the hash value stored on the chain) and proof that the batch has read or modified a particular batch The Merkel tree path of the account. The yellow nodes can be reconstructed from the green nodes, so they do not need to be included in the proof. This data is enough to perform batch processing and calculate a new state root (note that this is exactly the same way a stateless client verifies a single block). If the calculated new state root is not the same as the new state root provided in the batch, then the batch is proved to be fraudulent.</p>
<p>What can be ensured is that if there is an error in a batch, and all the batches before that are correct, then a fraud proof can be created to prove that the construction of the batch is wrong. Note that if there are multiple invalid batches in Rollup, it is best to prove that the earliest batch is invalid. Of course, it can be ensured that if a batch is correct, it will never be possible to create a fraud proof to prove that the batch is invalid.</p>
<h3><strong>How is compression achieved?</u></strong></h3>
<p>The simplest Ethereum transfer (sending ETH) requires about 110 bytes, but the realization of ETH transfer in Rollup only requires about 12 bytes:</p>
<p>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 (restoring from signature) 4 total ~112~12</p>
<p>Part of the reason for this is that Rollup can use simpler advanced coding techniques, while the current Ethereum RLP wastes 1 byte on the length of each value. At the same time, Rollup also uses some very clever compression techniques.</p>
<ul><li><strong>Nonce</strong> : The purpose of this parameter is to prevent replay. If the current nonce of an account status 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 status will be incremented to 6, so a transaction with a nonce of 5 is Will not be packaged again. In Rollup, we can completely omit the nonce, because we only need to restore the nonce from the state before the update; if someone tries to replay the transaction with an earlier nonce, the signature will not be verified, because the signature verification will use a nonce larger data.</li><li><strong>Gas Price</strong> : We can allow users to pay with a fixed range of Gas prices, for example, the range is 0-2 to the 16th power. In addition, we can also charge a fixed fee for each batch, or even move the gas payment completely outside of Rollup, allowing traders to pay the batch creator through a specific channel.</li><li><strong>Gas</strong> : We can also just choose the range of the total amount of Gas to a power of 2. In addition, we can also set the Gas limit only at the batch level. (Translator's Note: Gas Price and Gas here are both to compare the amount of data generated through rollup contracts and the Ethereum network. It does not mean that a rollup protocol must include these concepts. For example, Fuel is an Optimistic Rollup The protocol is based on UTXO and does not contain these concepts at all.)</li><li><strong>To</strong> : We can use an index instead of a 20-byte address (for example, if an address is the 4527th address added to the tree, we use the index 4527 to represent it. We will add a subtree to the state to store the index to Address mapping).</li><li><strong>Value</strong> : We can store Value in scientific notation. In most cases, only 1-3 valid digits are required for transfer.</li><li><strong>Signature</strong> : We can use BLS to aggregate signatures, so that many signatures are aggregated into a signature of about 32-96 bytes (the specific size depends on the protocol used). Then, this signature can perform batch signature verification on the entire message set and the sender at one time. The ~0.5 in the table indicates that the number of aggregate signatures that can be verified in a main chain block is limited. Therefore, if there are many transactions in the batch, it is necessary to generate an aggregate signature about every 100 transactions. (Translator's Note: The general idea is that the amount of calculation for verifying aggregated signatures will increase as the number of aggregated original signatures increases, and the amount of gas that can be used by the Ethereum main chain block is capped, so aggregated signatures cannot be aggregated at once. Too many original signatures.)</li></ul>
<p>ZK Rollup has a special important compression technique: if a part of the transaction is only used for verification and has nothing to do with the calculation of the status update, then this part of the data may not be stored on the main chain. This is impossible in Optimisitc Rollup, because the data still needs to be stored on the chain to prepare for subsequent fraud proof verification. In ZK Rollup, the SNARK certificate that proves the correctness of a batch of processed data, It has been proved that the relevant parties have provided all the data required for verification. An important example is the implementation of Rollup with privacy protection: privacy protection is implemented in Optimisitc Rollup, about 500 bytes of ZK-SNARK used to protect privacy in each transaction needs to be chained, and privacy protection is implemented in ZK Rollup , ZK-SNARK, which covers the entire batch, can already prove that the "internal" ZK-SNARK is effective. (Translator’s Note: Since SNARKs can be nested, privacy protection is implemented in ZK Rollup. You only need to submit the finally generated outermost SNARK to the chain. When verifying the outer SNARK, the inner SNARK is valid Sex can be verified at the same time.)</p>
<p>These compression techniques are the key to Rollup's expansion. Without these techniques, Rollup may only be able to achieve about 10 times the expansion based on the main chain expansion (although in some specific applications with large amounts of calculation, simple Rollup can achieve Expansion is already very powerful), but after using compression techniques, the expansion coefficient of almost all applications can exceed 100 times.</p>
<h3><strong>Who can submit batches?</u></strong></h3>
<p>There are many genres for who can submit batch processing in Optimistic Rollup or ZK Rollup. Generally speaking, everyone thinks that the user who submits the batch must pledge a large deposit. If a user has submitted a fraudulent batch (for example, submits an invalid state root), then part of the deposit will be Burn and destroy, and the other part is rewarded to users who submit fraud proofs. But in addition, there are many possibilities:</p>
<p>(Translator's note, the user who can publish batches to the main chain is called sequencer (sequencer), the term is named because the role needs to sort the transactions in the batch)</p>
<ul><li><strong>Completely unlicensed sorter</strong> : anyone can submit batch processing at any time. This method is the simplest, but has some serious shortcomings. For example, there is a problem: multiple participants generate and try to submit batches at the same time, and only one batch can be successfully included. This will result in a large amount of waste in the calculation cost of generating the certificate or the gas cost of submitting the certificate.</li><li><strong>Centralized sorter</strong> : submit batch processing through the role of sorter (except for withdrawal operations: in the withdrawal operation, the user first submits the withdrawal request, if the sorter does not process the withdrawal transaction in the next batch, then the user You can personally submit a batch application containing only one withdrawal transaction). This method is the most "efficient", but it needs to rely on a centralized role.</li><li><strong>Sorter auction</strong> : through auction (such as every day) to determine who has the right to be the next day's sorter. The advantage of this scheme is that funds can be raised, and these funds can be distributed through Rollup's DAO (refer to MEV auction).</li><li><strong>Randomly selected from the PoS set</strong> : anyone can deposit ETH (or tokens set by the Rollup protocol) into the Rollup contract, and each batch sequencer will be randomly selected from these depositors, and the probability of being selected is proportional to The deposit amount is directly proportional. The main disadvantage of this scheme is the need to lock a large amount of assets.</li><li><strong>DPoS voting</strong> : Some <strong>sorters</strong> perform batch processing after being selected through auctions, but if they perform poorly, token holders can vote to kick them out and hold a new auction to replace them.</li></ul>
<p><strong>Separate batch processing and state root submission</strong></p>
<p>Some Rollups currently under development adopt the "split batch" mode, that is, the behavior of submitting a batch of two-level transaction batches and the behavior of submitting a state root are carried out separately. There are some key advantages.</p>
<ol><li>You can allow many sorters to publish batches in parallel to improve the anti-censorship capability and alleviate the worry that some batches will be packaged in advance and invalidated by other batches.</li><li>If a state root is fraudulent, there is no need to roll back the entire batch. You can roll back only the state root and wait for someone to provide a new state root for the same batch. This can better ensure that the sender's transaction will not be rolled back.</li></ol>
<p>In general, this is a fairly complex technology combination, and a balance is also found in the complex trade-offs involving efficiency, simplicity, censorship resistance, and other goals. It is too early to say which combination is the most effective. Time will tell.</p>
<p><br/></p>
<h2><strong>How much expansion will Rollup bring?</strong></h2>
<p><br/></p>
<p>On the existing Ethereum main chain, the gas online 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 (here assume that ZK Rollup is used, 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 space, which means that each batch can contain 62500 transactions. At present, the block interval of the Ethereum main chain is 13 seconds, which means that the realized TPS is about 4807 (in contrast, the TPS for ETH transfer on the Ethereum main chain is about 1,250 000 / 21,000 / 13 = 45).</p>
<p>The following table contains the expansion efficiency of some other application scenarios.</p>
<p>Application Scenario The number of bytes that need to be chained for a single corresponding operation in Rollup The maximum expansion multiple of gas consumption for the corresponding operation of the Ethereum main chain ETH transfer <strong>12</strong> 21,000105xERC20 transfer <strong>16</strong> (the extra 4 bytes are used to represent the token) ~50, 000187xUniswap transaction <strong>~14</strong> (4 bytes for sender + 4 bytes for receiver + 3 bytes for transaction amount + 1 byte for maximum price + 1 byte for miscellaneous items) ~100,000428x withdrawing operations with privacy protection (Optimisic Rollup) <strong>296</strong> (root index 4 bytes + nullifier 4 bytes + receiver 4 bytes + ZK-SNARK proof 256 bytes) ~380,00077x withdrawing operations with privacy protection (ZK Rollup) <strong>40</strong> (root index 4 bytes + nullifier 32 bytes + receiver 4 bytes) ~380,000570x</p>
<p>Maximum expansion multiple calculation method: Gas consumption of the corresponding operation of the Ethereum main chain / (the number of bytes that need to be connected to the chain in the corresponding operation in Rollup * 16) * 12 million / 12.5 million</p>
<p>It should be noted that for some reasons, these figures are actually too 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 deposit and withdrawal operations will always exist. The third reason is that the usage of Rollup may be low in the short term, so the fixed-cost charging model will dominate. However, even if these factors are taken into consideration, an expansion of more than 100 times should not be difficult to achieve.</p>
<p>What if we want to achieve 1000-4000 TPS (depending on specific application scenarios)? This requires eth2 data fragmentation. In this proposal, a 16MB storage space is opened every 12 seconds. This storage space can be filled with any data, and the system will ensure that a consensus is reached on the availability of these data. This data space can be used by Rollup. The data throughput of about 1398kB/sec is 23 times higher than the current Ethereum main chain of about 60kB/sec. In the long run, the data capacity is expected to increase further. Therefore, the TPS of Rollup implemented using eth2 data fragmentation can be as high as 100,000, and it will be even larger in the future.</p>
<p><br/></p>
<h2><strong>What are the outstanding challenges?</strong></h2>
<p><br/></p>
<p>Although the basic concepts of Rollup are now well known, we are very sure that Rollup is essentially feasible and safe, and there are already multiple Rollup deployments on the Ethereum mainnet, but Rollup still has many areas in the design level. It has not been well explored. If most of the Ethereum ecosystem is to be completely introduced into Rollup to take advantage of its scalability, there are still many challenges in this regard. Some key challenges include:</p>
<li>Entry of <strong>users and ecosystem</strong> : There are not many applications using Rollup at present, users are not familiar with Rollup, and few wallets have begun to integrate Rollup. Merchants and charities have not yet accepted them for payment.</li><li><strong>Cross-Rollup transaction</strong> : effectively transfer assets and data (such as oracle output) from one Rollup to another Rollup, without the need to transfer through the main chain and incur corresponding fees.</li><li><strong>Audit incentives</strong> : How to maximize the probability that at least one honest node will fully verify the Optimistic Rollup, so as to ensure that someone issues a fraud proof when something goes wrong? For small-scale Rollups (with TPS less than a few hundred), this is not an important issue and can be achieved simply by relying on altruism, but for larger-scale Rollups, the incentive problem needs to be studied clearly.</li><li><strong>Explore the possibility of designing between Plasma and Rollup</strong> : Is there a technology that can put part of the data related to status updates on the chain, but not all the data? Will new useful tools be born through this technology?</li><li><strong>Maximize the security of pre-confirmation</strong> : In order to make the user experience better, many Rollups provide a "pre-confirmation" concept, that is, after the transaction is completed, the sequencer immediately provides a promise: a certain transaction will be included in the next During batch processing, if the sorter breaks his promise, their deposit will be destroyed. However, the economic security of this solution is limited, because the sequencer may make many promises to a large number of users at the same time. Can this mechanism be improved?</li><li><strong>Improve the response speed to the absent sequencer</strong> : If a Rollup sequencer is suddenly offline, how to recover from this situation as quickly and cost-effectively as possible, either quickly and cheaply withdraw to another Rollup on a large scale, or Change the sorter. It is very valuable to respond quickly.</li><li><strong>Efficient ZK-VM</strong> : Generate a ZK-SNARK certificate to prove that the universal EVM code (or another VM that can be compiled into the existing contract) has been executed correctly and has a definite result.</li></ul>
<p><br/></p>
<h2><strong>to sum up</strong></h2>
<p>Rollup is a new and powerful two-tier expansion paradigm, which is expected to become the cornerstone of Ethereum's future short- and medium-term (or long-term) expansion. The Ethereum community is very excited about Rollup, because unlike the previous two-tier expansion attempts, Rollup can support common EVM codes, allowing existing applications to be easily migrated. Rollup achieves this goal by making a key compromise: instead of trying to move completely off-chain, it keeps a small amount of data for each transaction on-chain. (Translator's Note: The problem of no data availability mentioned above)</p>
<p>There are many kinds of Rollup, and there are many choices in design: Optimisitc Rollup that uses fraud proof, ZK Rollup that uses validity proof. The sorter can be a centralized role, it can be a decentralized free role, or many other choices in between. Rollup is still an early stage technology, and development is continuing fast, but they are effective, and some (especially Loopring, ZKSync, and DeversiFi) have been running for several months. I look forward to more exciting results in the Rollup field in the next few years.</p>