Loom Network CTO Steve Guo: What kind of Layer 2 network is the true future?

Source: BeWater Community

At the BeWater DevCon 2021 global developer conference on September 4, Loopring CTO Steve Guo, who previously served as a senior R&D engineer at Intel and a senior R&D director at Cheetah Mobile, shared a keynote speech titled "What Does a Truly Future Layer 2 Network Look Like?" with the developers present.

The summary of the presentation is as follows: 1) A truly defined layer 2 network should rely on the mainnet for security. 2) The evolution of layer 2 networks has progressed from state channels to Plasma, and then to the currently popular Rollup, which has split into two branches: Optimistic Rollup and zkRollup. 3) The ultimate form of layer 2 networks is zkEVM, where users do not need to change their code and can directly run existing contracts on zkEVM. Hello everyone, I am Steve Guo, the CTO of the Loopring protocol. I am glad to be invited to participate in BeWater's developer conference. Today, I want to discuss what kind of layer 2 network is truly the future.

1. What is a Layer 2 Network?

Let's start with this slide, which defines what a layer 2 network is. In my opinion, sidechains like Polygon, xDai, and BSC do not strictly qualify as layer 2 networks. A truly defined layer 2 network should have its security guaranteed by the mainnet.

From a technical and evolutionary perspective, the earliest layer 2 technology was called state channels, which then evolved into Plasma, and more recently into the popular Rollup technology, which further split into two branches: Optimistic Rollup and zkRollup.

My upcoming presentation will guide everyone through the entire history of the development of layer 2 networks, focusing on the evolution of these technologies.

1. State Channels Next, let's look at the first type of layer 2 network technology, called state channels.

The earliest origin of state channels should be the Lightning Network in Bitcoin, and then on Ethereum, the earliest project I remember was called "Raiden Network," which attempted to replicate the Lightning Network technology from Bitcoin.

The core idea of state channels is that if Alice and Bob frequently need to transfer funds offline, they agree to deposit a certain amount of money into a contract, for example, Alice deposits 5 and Bob also deposits 5. After that, Alice and Bob can transfer funds back and forth off-chain. For instance, in this slide, if B transfers 1 to A, A will have 6 coins and B will have 4 coins. Then A transfers 3 coins back to B, and in the end, A has 3 coins and B has 7 coins.

When it comes time to settle on-chain, only the final state is submitted to the chain, allowing everyone to exit with the final amounts, as shown in the diagram where A has 3 coins and B has 7 coins.

The core concept is that after going off-chain, they can perform unlimited transfers simply by confirming with signatures.

What is its biggest drawback? A and B must first deploy a definitive contract on the mainnet.

Subsequently, projects like Raiden Network and CelerNetwork have made some extensions, allowing A and B to settle through a Hub, where A connects to a Hub, B also connects to this Hub, and C connects to the Hub, creating a centralized hub-like method to facilitate point-to-point transfers into a point-to-network transfer.

However, this still has limitations. First, it requires pre-locked funds in the smart contract, and second, this entire technology only addresses the "transfer payment" aspect. But as we all know, the greatest significance of blockchain lies in programmable applications, not just payments, leading to the natural evolution of layer 2 network technology into the second generation, Plasma.

2. Second Generation Plasma The layer 2 network technology shown above is called Plasma. In my view, it attempts to solve the problem of needing to lock funds in advance, which I just mentioned in the "state channels" solution.

What is its solution? Its approach is quite simple: there still needs to be a smart contract on-chain, but anyone can deposit or withdraw from this on-chain contract, interacting with it.

Correspondingly, there is a concept called Plasma Chain off-chain. Once funds enter this contract, transfers can be initiated off-chain. The Plasma Chain continuously aggregates and packages all transactions that occur off-chain, then submits the final state Merkle root to the main chain contract for record-keeping.

If no one raises an objection within a certain period, say 7 days, the historical records cannot be changed. If anyone raises an objection to a transaction within those 7 days, they can submit a challenge to prove that a particular transaction was processed incorrectly, thereby retrieving the assets. This approach solves the problem of needing to pre-lock funds in state channels.

Initially, it only supported transfer payment scenarios, such as the early Plasma MVP, which then evolved into Plasma Cash and Plasma Debit, among others. Ultimately, people found that Plasma was still quite difficult to use.

First, it has a challenge period of about seven days or two weeks for withdrawals.

Second, what does its security depend on? The Plasma Chain only submits a Merkle root to the main chain, meaning that all transaction information occurring on the Plasma Chain is recorded off-chain. What does this imply? It implies that I must rely on the Relayers submitting this Merkle root to be accurately performing their duties.

3. Optimistic Rollup To solve the problems of Plasma, the natural evolution leads us to the currently popular Optimistic Rollup.

Looking at this diagram of Optimistic Rollup, the only difference from Plasma, in my opinion, is that it submits not only the Merkle root of the world state to the main chain but also all transaction data that occurred off-chain, allowing anyone to challenge based on the publicly recorded information on the blockchain.

For example, when transitioning from state S2 to state S3, if someone has a challenge, they can refer to some historical information recorded on the blockchain to argue that the processing was incorrect.

Thus, while Plasma evolved into Optimistic Rollup, its security still relies on the "exit challenge mechanism," which remains unchanged, but it solves a data availability issue, allowing people to challenge directly on-chain based on existing data rather than needing to combine off-chain data for a challenge. This is its greatest improvement.

In addition, Optimistic Rollup can also support scenarios beyond transfers; it can support general programming.

Currently, there are two projects pursuing this path: one is Optimism, and the other is Arbitrum.

4. Optimism

Let me first talk about Optimism, as it was the first to propose implementing Optimistic Rollup. This team is also closely related to Plasma, so Uniswap was initially said to be deployed on Optimism first.

Its core idea is about how to solve challenges. If someone discovers that you have not accurately processed a transaction on the layer 2 network, how can I challenge this? They abstract this challenge into what?

They deployed a contract on Ethereum layer 1 that accepts what? It accepts a defined instruction set called OVM. You can use the publicly submitted information to the main chain to drive the execution of this OVM. If the OVM execution determines that these values are incorrect, then your challenge is successful.

Basically, the idea of Optimism is to keep the OVM instruction set as consistent as possible with the EVM, but it has not achieved 100% compatibility; some instructions have been modified.

Because these instructions need to be modified, it makes it quite difficult to achieve 100% compatibility with EVM, which may also be one reason why it has been delayed and has not yet launched on the mainnet.

5. Arbitrum I believe Arbitrum saw this opportunity, stating that executing something similar to the EVM instruction set within a layer 1 smart contract is quite challenging.

Can I redefine the EVM into my own VM instruction set, which they call the Arbitrum instruction set, or AVM? Therefore, the execution within the layer 1 smart contract is actually the AVM instruction set, which fundamentally allows for potentially more efficient execution than OVM.

At the same time, it addresses a significant issue in the OVM's Optimism challenge mechanism, which is the high gas consumption for challenges. Their solution is to use a sharding challenge, similar to a binary search.

I first let you prove that executing up to 1,000 steps is correct, then narrow it down to 512, then to 256, gradually allowing you to shard the execution of a series of instruction sequences to produce a challenge output, whether successful or failed.

Arbitrum's mainnet officially launched on August 31, and several projects have already migrated to Arbitrum, such as Sushi and MCDex.

However, people have found some issues; originally, it was believed that such a layer 2 network would significantly reduce costs, but the actual situation is that a transaction on Arbitrum's mainnet is reduced to about 1/5 to 1/10 of the mainnet, which is still far below our expectations. I think it may need to improve by another order of magnitude to truly be a layer 2 network.

2. zkRollup Next, let's talk about the second major branch, zkRollup.

1. What is ZKP?

When discussing zkRollup, we must first explain what ZKP is. ZKP, as the name suggests, stands for Zero-Knowledge Proof. What does Zero-Knowledge Proof do?

For example, if we take f(X)=Y, it means I can prove that I know an X value that, when processed through function f, outputs Y, but I cannot tell you what X is, and I need you to believe this. This is called a zero-knowledge proof. The function f is public, the result Y is also public, but my X is private and not disclosed to you. Let me give a more intuitive example to help everyone understand zero-knowledge proof. This image is called "Where's Waldo," and the problem is to find the position of the little person in the large image.

To perform a zero-knowledge proof, I need to let you know that I know the position of the little person in this large image, but I cannot let you know the exact position of the little person.

The general solution approach is to transform the problem. The essence of zero-knowledge proof is to transform the problem; I convert problem A into an equivalent proof of problem B in another domain. For the zero-knowledge problem of finding Waldo, for example, I can take a large black cloth and cut out Waldo beforehand.

Then I cover the large black cloth over the image, only revealing the little person. This way, I have performed a zero-knowledge proof that I can find the little person in the image, but you still do not know the exact position of the little person because it is covered by the entire black cloth.

2. Introduction to zkRollup Next, I will discuss the concept of ZKRollup, which is a technical umbrella term. Its core idea is represented in this diagram, where the world state is abstracted into a Merkle tree composed of all accounts, with each account containing some information related to itself. This Merkle tree has a unique root that represents the current world state.

When I make changes to accounts off-chain, such as any transaction that modifies some account information, this is called transaction Tx information. Once I have collected all Tx information off-chain, I can create a zero-knowledge proof for the world state transition caused by processing each Tx.

First, I need to prove that this Tx is real, then prove that the Tx can transition from the previous world state to the next world state, and the final world state information is recorded on-chain.

Therefore, once a historical state is confirmed on-chain, it can never be changed. I can then use the unchangeable historical records along with subsequent Tx to prove and derive the next new world state, continuously updating the latest world state on-chain. This entire system is called the ZKRollup solution.

3. Loopring Protocol Our Loopring protocol is the world's first application of ZKRollup on the mainnet. We have extended the ZKRollup concept to Dex trading.

We have further abstracted the Dex trading model based on the previously introduced ZKRollup Account model; for example, we abstracted Balance under Account, and Trade History under Balance, but fundamentally it still represents a large Merkle tree, continuously updating the world state represented by the entire Merkle tree on-chain.

Additionally, there is the well-known ZKSync solution from Matter Labs, which has now evolved to version 2.0. Version 1.0 is quite similar to our Loopring protocol, only solving scenarios for transfers, transactions, and payments. In terms of ZKRollup technology, they are essentially the same, but they use different zero-knowledge proof algorithms.

Our Loopring protocol uses the Groth16 algorithm, while ZKSync uses the Plonk zero-knowledge proof algorithm. Subsequently, ZKSync released ZKPorter, which is called ZKSync 2.0.

What is the difference? In ZKSync 1.0, remember that all transaction data is submitted on-chain. However, in ZKPorter, to improve TPS, all off-chain transaction information is not submitted on-chain, and the off-chain transaction information is maintained by a small group similar to PoA to accurately preserve off-chain transaction data.

I believe the ZKPorter solution cannot be entirely classified as Z KRollup; the ZKRollup concept must submit all Tx information on-chain. ZKPorter is somewhat similar to the StarkEx solution I will discuss next.

Returning to the StarkEx solution introduced by StarkWare, this diagram provides an overall introduction to StarkEx. Its core internally is still organized into a Merkle tree, using the ZKRollup concept to continuously update the world state.

However, it defines its own programming language, Cairo, from the outset, and everyone must use this language to write. It then generates zero-knowledge proofs for the programs executed using the Cairo language. But StarkWare differs from Loopring and ZKSync in that it uses a zero-knowledge proof algorithm called zkStark.

The core differences among these three zero-knowledge proof algorithms are… Groth16 requires a trusted setup to be run every time there is any change to the circuit, which makes programmability relatively poor. However, its advantage is that the proof size is the smallest, and the verification workload on-chain is also minimal, giving it a significant cost advantage.

Plonk supports a concept called universal setup, meaning that I only need to run a trusted setup once globally, and any subsequent changes to the circuit do not require running the trusted setup again.

ZKStark goes even further; it does not require a trusted setup at all, allowing me to change the circuit at any time, but this comes at a cost: its proof size is the largest, and the verification workload on-chain is also relatively high.

This may also be why StarkWare initially did not put transaction data on-chain; otherwise, the on-chain costs would be quite high.

This summarizes all current layer 2 solutions, but I believe we are far from the ultimate layer 2 network I envision.

4. zkEVM The final form of a layer 2 network, in my opinion, is a universal zk virtual machine, which I define as zkEVM. Several companies have started working on zkEVM, such as Hermez and Matter Labs, which also aim to create a universal zkEVM. StarkWare's Cairo essentially supports programmability and can also be considered a type of zkEVM.

However, I believe the best solution in the Ethereum ecosystem is still to allow everyone to run the compiled code of smart contracts directly on the zkEVM virtual machine without changing the code. This approach may be the ultimate future.

The Ethereum Foundation is currently working on such a project, and this diagram attempts to summarize the Ethereum Foundation's zkEVM concept.

In the upper right corner of this diagram, you can see a classic von Neumann computer model. The computer includes a CPU processor, and outside the processor, there are memory, storage, hard drives, and peripherals.

The storage, CPU, and peripherals communicate through a bus to retrieve and store data. This is the classic von Neumann computer model.

The zkEVM borrows from this model; the instruction set in the zkEVM virtual machine is directly defined by the EVM instruction set. After each segment of program code is executed, there will be a trace, and I will create a proof for all traces, proving that these traces were executed according to the program code's instructions.

This involves:

First, I need to prove that each EVM instruction execution is correct and that the execution sequence is correct; this is called EVM Proof.

Second, during the execution of the EVM, there will be interactions involving storage values, accessing variables in memory, and even in the stack. These three—storage, memory, and stack—are collectively called state, and the storage and retrieval of these states also require corresponding zero-knowledge proofs to prove that my storage and retrieval actions are correct.

There is a bridge called Bus Mapping between EVM Proof and State Proof, which is the concept of a bus that describes which specific states the EVM instructions need to access and proves that these accesses are correct.

Once this system is deployed, all smart contracts can seamlessly migrate over, and I believe this may be the true ultimate form of a layer 2 network.

Thank you all. If you have any questions, feel free to contact me. If you are interested in the Loopring code, you can also visit our GitHub. You can also reach out to me via email. Thank you.