Layer2 is a big topic. Whether it is decentralized, whether it is safe, and the time to confirm the status of funds are the main topics of discussion for Layer2. Recently, I have some time to summarize the understanding and thinking of Layer2.
Layer2 interaction model
Layer2, compared to Layer1, provides richer functions and better user experience on the basis of Layer1. Abstract the logic and interaction model of Layer 2 as follows:
Except for the transactions of Layer1 (deposit), other transactions of Layer2 are executed in Layer2. In order for Layer 2 to restore the transaction status when necessary, all Layer 2 transaction data needs to be stored securely. For simplicity, and to maintain the same security as Layer 1, all transaction data of Layer 2 is generally stored in Layer 1. This kind of transaction data can be accessed at any time, called “Data Availability”. All Layer 2 transactions are executed in Layer 2 and synchronized to Layer 1. How to prove that the layer 2 synchronization state is correct? Different layer 2 schemes have different implementation methods.
Layer2 implementation classification
From the Layer 2 state synchronization method, Layer 2 is divided into two categories: one is Side Chain implementation (Side Chain), and the other is Rollup. The side chain is to synchronize the state of Layer 2 to Layer 1 through a consensus different from Layer 1 . From this point alone, the security of the entire side chain is reduced to the security of the Layer 2 consensus. Rollup is divided into two types: one is zkRollup and the other is Optimistic Rollup. The so-called Optimistic Rollup, optimistic Rollup, expect Rollup to correctly synchronize to Layer1 in most cases. At the same time, in order to prevent the synchronization error state, a challenge mechanism is provided. Optimistically, the chance of challenge is relatively small. In the case of a challenge, Layer1 can determine the correct state. zkRollup is the most direct way of state synchronization. Through zero-knowledge proof technology, it provides proof of state change while submitting the state to Layer1. Layer implementation classification is as follows:
zkRollup is divided into three categories according to the adopted zero-knowledge proof protocol: 1/Goth16 2/PLONK 3/STARK. The Groth16 protocol requires an initial setup (Trusted Setup) for each circuit. The circuit of the PLONK protocol under a certain scale only needs to be initially set up once. The STARK protocol does not require initial setup. However, compared with the other two algorithms, the STARK protocol proves that the amount of data is large and the verification time is long. Relatively speaking, in the Layer 2 scenario, PLONK is currently a widely used algorithm.
Comparison of STARK protocol and SNARK (Groth16/PLONK) protocol (from the github link of Matter Labs):
To sum up, from a security perspective, the various Layer 2 sorts are as follows: zkRollup, optimistic Rollup, and sidechain. The security is also confirmed from the withdrawal time. The withdrawal of zkRollup is at the minute level, and the other two schemes are at the hour or even day level. zkSync is a relatively complete zkRollup open source project. Interested partners can check the previous analysis articles:
zkRollup, although good, currently has a big flaw: poor programmability.
Take a closer look at zkRollup
Compared with other Rollup schemes, zkRollup scheme has more zk proof system. In other words, in addition to “execution”, each transaction in Layer 2 also needs to generate a certificate to prove the correctness of the execution process. Friends who are familiar with zero-knowledge proof technology know that the safety of zero-knowledge proof lies in the safety of the “circuit”. For Layer 2, the processing of each transaction is “solidified” as a circuit, and the circuit logic is completely open. Corresponding to each circuit, there is a unique verification key. The verification key is used to verify the status of Layer1. The verified status proves that it conforms to the logic of the curing circuit.
The key is whether the execution of Layer 2 transactions is consistent with the semantics of the solidified circuit. Making the circuit public is a way of consensus for everyone to check the circuit logic. Simply put, in order to implement zkRollup, you need to implement Layer 2 to execute the corresponding circuit. In fact, the realization of the circuit is relatively complicated, there is no high-level language, in many cases R1CS is written by hand. Further, in order to use the zk proof system, in order to optimize the realization of the circuit, the state of the entire Layer 2 is often optimized to a circuit-friendly structure (merkle tree). Therefore, the zkRollup system needs to consider the structure of the circuit, thereby constraining Layer 2 transactions and account models. Attentive friends can find that no matter it is zksync/zkswap/loopring, only specific transaction scenarios are realized.
Conversely, if you need to support EVM transaction execution through zkRollup, you need to abstract EVM transactions into a circuit-friendly account model. This kind of abstraction is not easy. Moreover, the description circuit of EVM can be predicted to be larger. From the performance of zero-knowledge proof, this aspect will limit the performance of the entire zkRollup.
Let’s take a look at the gas consumption of the zkRollup scheme in Layer 1. The main gas consumption of the entire zkRollup solution is three parts (withdraw not taken into account):
- Transaction Raw Data: called pub data in zksync. In order to ensure data availability, all Layer 2 transactions will be submitted to Layer 1 in the form of bare data.
- Layer2 Block management: When Layer2 submits the block status, Layer1 maintains the block structure and status of Layer2.
- Verify the status of Layer 2 Block: When Layer 2 submits the proof, Layer 1 needs to verify the status proof.
Taking 350 transactions in a block and the Transaction Raw Data size of each transaction is 20 bytes as an example, the gas consumption of a block processing:
Although the above data is not an accurate value, it is enough to show that the gas consumption of the original transaction data in the entire zkRollup scheme is very high. From this perspective, some projects in Layer 2 choose to store transaction data through other off-chain methods.
Optimism vs. an arbitrator?
Optimistic Rollup is compatible with EVM. In other words, Layer 2 supports programmability, and programs on Ethereum migrate almost seamlessly. In order to ensure that the status on the chain is correct, both of these solutions provide a challenge mechanism for a period of time. The challenger provides evidence of the challenge, and Layer 1 decides whether it is correct or not. For an in-depth understanding of Optimism and Arbitrum, you can check the previous article:
Optimism uses OVM to execute Layer 2 transactions. The name OVM is to distinguish the EVM of Layer1. Because the status submitted to Layer1 needs to be checked for correctness, Layer1 needs to “replay” Layer2 transactions, that is, Layer1 needs to execute OVM transactions in some cases. The most complicated part of Optimistic Rollup is also here. It uses EVM to simulate OVM and executes Layer 2 transactions. It is conceivable that the implementation of EVM simulation of OVM in Layer 1 is more cumbersome and consumes more operations.
Arbitrum also uses a challenge mechanism. In order to avoid the challenge of low gas cost, Arbitrum introduced AVM:
Compared with EVM, AVM is a relatively simple virtual machine. Arbitrum simulates the EVM execution environment on the AVM virtual machine. In other words, all Layer 2 transactions are executed in AVM, and the execution status of the transaction can be represented by the AVM state. When there is a disagreement in the state submitted to Layer 1, the challengers (Asserter and Challenger) first divide the state to find the “point of divergence”. After clarifying the points of divergence, both challengers can provide an execution environment, and Layer 1 performs related operations to determine whether the previously submitted status is correct. The challenge in Layer 1 is the state of AVM, and the execution of AVM instructions at the point of difference.
Simply put, in order to save the gas cost of the challenge, Arbitrum uses a streamlined AVM (very convenient state representation). Through fast segmentation, only one instruction needs to be executed on the chain to determine whether the state is executed correctly. As mentioned in the Arbitrum introduction document, the entire challenge requires about 500 bytes of data and about 9w of gas. On the basis of AVM, Arbitrum has designed a mini language and compiler to simulate the execution environment of EVM, so as to be compatible with EVM.
to sum up:
Layer2, compared to Layer1, provides richer functions and better user experience on the basis of Layer1. The deterministic duration, security, and programmability of the funding status are currently the focus of discussion. zkRollup is the most deterministic solution for the state of funds. The optimistic Rollup/side chain is programmable. The proof of zkRollup’s support for EVM is an expected direction.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/l2-understanding-and-thinking/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.