L2 — My Summary

Layer2 is a huge topic. Decentralization, safety concerns, and asset status confirmation time are the main dicussions about Layer2. Here is a summary of my understanding and a few thoughts of Layer2 during my free time.

Layer2 Interaction model

Layer2, compared to Layer1, based on Layer1 it provides more functions and better user experience. We can abstract the Layer2 implementation logic and its interaction model as follows:

Besides Layer1 transactions(payment), other Layer2 transactions execute at Layer2. In order for Layer2 to reactivate the transaction status, all Layer2 transaction data needs to be saved securely. For the sake of simplicity, as well as keeping same level of security as Layer1, all Layer2 transaction data usually saves at Layer1. These transaction data can be visited at any time, which is referred to as “Data Availability”. All Layer2 transactions execute at Layer2, and synchronizeded to Layer1. How to prove the correctness of Layer2 synced state, different implementations exist for different layer2 methodologies.

Layer2 implementation categories

Layer2 can be categorized into two types based on its synchronization method: Side Chain and Rollup. Side Chain in to synchronize from Layer2 to Layer1 through different Consensus. With this method, the security of entire side chain is reduced to security of Layer2 Consensus only. Rollup breaks into two types: one is zkRollup, the other is Optimistic Rollup. Optimistic Rollup, on the other hand, expects most of the time Rollup syncs states to Layer1 correctly. At the same time, in order to prevet synchronization error, it provides the challenge mechanism. Optimistic Rollup has a small chance of challenge. When challenge is required, Layer1 can determine the correct state. zkRollup is the most straight forward way of state synchronization. Through zero knowledge proof technic, the proof of state change is submitted at the same time as state submitted to Layer1. Layer implements the categorization as follows:

There are three types of zkRollup according to its zero knowledge proof agreement: 1/ Groth16 2/ PLONK 3/ STARK. Groth16 agreement requires Trusted Setup for every circuit. PLONK agreement requires only one Trusted Setup for circuit of certain size. STARK agreement does not require Trusted Setup. However, compared to the other two algorithms, STARK agreement has large amount of proof data and long validation time. In general, under Layer2 scenario, PLONK is the most used algorithm currently.

STARK aggrement compared to SNARK(Groth16/PLONK agreement comparison (source from Matter Labs’ github link):

https://github.com/matter-labs/awesome-zero-knowledge-proofs

To conclude, from security perspective, Layer2 algorithms have following rank: zkRollup, optimistic Rollup, side chain. Prooving its security from the cashing time, zkRollup cashing is still counted on minutes level. The other two methods are counted by hours, or even days. zkSync is a very complete open source zkRollup project. If you are interested, check out the previous blogs of related zkRollup analysis.

Though having the mentioned benefits and advantadages, zkRollup currently has a huge down side: bad programmability.

Detailing zkRollup

Compared to other Rollup methods, zkRollup has implemented the zk proof system in addition. That is to say, besides executing each Layer2 transaction, a proof is required for correctness of execution process. For those of you familiar with zero knowledge proof technics, it should be fairly straight forward that the security of zero knowledge proof is the security of “circuits”. For Layer2, each transaction process is “solidified” as circuit, and the circuit logic is completely public. For each circuit, there exists an unique verification key. Verification key is used for Layer1 validation state proof. Through the verified state proof, it therefore proofs the “solidified” circuit logic.

The key is to check whether Layer2 transaction and solidified circuit syntax are consistent. Public circuit is a consensus method, for everyone to check the circuit logic. In short, implementing the corresponding circuit of Layer2 execution is required to implement zkRollup. As a matter of fact, the process of circuit implementation is rather complex, without high-level langauge but just manual R1CS script. Furthermore, in order to utilize zk proof system and to optimize system and circuit implementation, the entire Layer2 state is usually optimized into circuit-fiendly merkle tree. Therefore, zkRollup system requires to reconsider the circuit structure, which constrains Layer2 transaction and the account model. If you look carefully enough you can find that only specific transaction scenarios are addressed, no matter it is zksync/zkswap/loopring.

To the contrary, if a transaction execution requires zkRollup to support EVM, then we need to abstract the EVM transaction into a circuit-friendly account model. Such abstraction is not easy. Moreover, this abstraction is not so easy. Additionally, EVM descriptive circuit has high predictability. Looking from the performance of zero knowledge proof perspective, this will largely constrain the performance of entire zkRollup.

Then let us take a look at the gas burnt at Layer1 of a zkRollup method. Entire zkRollup method mainly comsumes gas on following three areas (without considering withdraw scenario):

• Transaction Raw Data: pub data in zksyn. To ensure data availability, all Layer2 transactions will be submitted to Layer1 as raw data.
• Layer2 Block management: before submitting block state at Layer2, Layer1 maintians block structure and state of Layer2.
• To validate Layer2 Block state: when submitting proof at Layer2, Layer1 needs validation state proof.

Take 350 transactions per block, each Transaction Raw Data size about 20 bytes as an example, gas consumption lists as follows for one block process:

Even though the numbers mentioned above are not 100% accurate, it is enough to support the argument that raw transaction data takes up a large portion of gas comsumption in entire zkRollup method. From this standpoint, some projects of Layer2 choose to save transaction data via other off-chain methods.

Optimism vs. Arbitrum

Optimistic Rollup supports EVM. That is to say, Layer2 is programmable, and migrates almost seamlessly on Etherum programs. In order to ensure the block states are correct, these two solutions both offer challenging mechanism in certain time period. Challeger provides support for challenging, and Layer1 decides it’s right or wrong.

Optimism executes Layer2 transaction via OVM. The name OVM is to differentiate from the Layer1 EVM. Since the state submitted to Layer1 needs to be validated its correctness, Layer1 needs to “replay” Layer2 transaction. That is to say, Layer1 requires OVM transaction execution under certain circumstances. This is the most complicated point about Optimistic Rollup — to simulate OVM with EVM, and to execute Layer2 transactions. It is easy to imagine that such simulation comes with high complexity and high consumption.

Arbitrum also takes the challenging mechanism. To prevent low gas fee in a challenge, Arbitrum imports the AVM:

Compared to EVM, AVM is a relatively simple virtual machine. Arbitrum simulates the EVM execution environment on AVM. That is to say, all Layer2 transactions happen on AVM, the transaction execution state can be represented with AVM state. When there are conflicts in the submitted states to Layer1, both (Asserter and Challenger) first divide the state, then find the “conflicting point”. After determining the conflicting point, asserter and challenger can provide execution environment, and Layer1 executes related operations to ensure the previous submitted states are correct. The state chllenged at Layer1 is the AVM status, and the AVM command execution at conflicting point.

To conclude, in order to save the gas fee for a challenge, Arbitrum utilizes a lightweight AVM (for the ease of state representation). One command required to be executed on the chain, with the fast dividing, then we can determine if the excution is correct. Arbitrum documentation has mentioned that entire challenge includes about 500 bytes data and 9w gas. Based on AVM, Arbitrum has designed the mini language and compiler to simulate EVM execution environment, in order to support EVM.

Summary

Layer2 provides more functions and better user experience, compared to Layer1. The time needed to validate asset state, security, and programmability are the hot topics at the moment. zkRollup is the fastest solution for checking asset status. optimistic Rollup/side chain has programmability support. zkRollup supporing EVM proof is a development direction with high expectation.