This article attempts to discuss the development and evolution of Rollup Layer 2 from an evolutionary perspective, mainly answering the following questions:

• How rollups work

• Rollup's Modular Evolution

• Modular Possibilities

• Summarize

• Summarize

How rollups work

The "trilemma" of the blockchain has always been a problem that plagues the industry. If we think that the Layer 1 blockchain should first ensure "decentralization" and "security", then the "scalability" solution will be migrated from the Layer 1 It is a natural choice, so there is Layer 2. The new problem is how to ensure the security of Layer 2 through Layer 1.

Initially, there was an idea to regularly write the state tree root of the Layer 2 application to Layer 1, so that the state of the application can be verified through the state proof, similar to the exchange reserve proof. However, in this way, the third party cannot verify the correctness of the two state transitions in a public way.

In order to explore this issue in more depth, let's abstract that the state of any program can be expressed by a state transition formula:

σt+ 1 ≡ Υ(σt, T)

This formula comes from the Ethereum Yellow Paper, but it can represent any program. Here Υ represents the program and σ represents the state. State σt+1 is calculated by program Y through state σt and transaction T. Transaction T represents the input to the program. At any time, if σt is deterministic, program Y is deterministic, and T is deterministic, then σt+1 is deterministic.

Therefore, to provide public verifiability, the key is that Y must be publicly available, all T in history must be publicly available and the order is determined, and the intermediate state can be recalculated through Y and T. The public availability of the program can be achieved through open source, the key is how to ensure the public availability of T, which introduces the concept of data availability (DA).

Data availability requires a public immutable ledger to record application transactions. It is natural to think that the blockchain ledger is such a system, so Layer 2 transactions are written back to Layer 1 to ensure data availability, which is the source of the name Rollup.

Therefore, there needs to be a role in the Layer 2 system to collect user transactions, sort them and write them to DA. This role is called a sequencer (Sequencer). The transaction sequence here is called Canonical Transaction Chain.

The availability of data is guaranteed, and everyone can get the final state by running the program to execute the transaction by themselves. But there is no consensus here, because everyone is not sure whether the results they get are consistent with other people's results. After all, software or hardware failures may also cause data inconsistencies. Therefore, another role is needed to regularly publish the status tree root after the transaction is executed for everyone to verify their own status. This role is called Proposer. The state submitted each time here also constitutes a state sequence, corresponding to the transaction sequence, called the State Commitment Chain.

At this point, we have reached the verifiability of the application. If the result of someone’s operation is inconsistent with the status submitted by the Proposer, and it is determined that it is not their own problem, it means that the Proposer cheated or made a mistake, so how can others know it? This requires the introduction of the role of **Arbitrator**. The arbitrator needs to be a trusted third party, and the contract on the chain can just take on this role.

There are two options for arbitration:

• Every time the Proposer submits a state, it also provides a valid proof of state transition (Validity Proof) with the previous state, and the arbitration contract on the chain verifies it. Valid proofs are generally generated through Zero knowledge technology, which is called ZK Rollup.

• Assume that the result of the Proposer is correct, but if it is found to be inconsistent, submit a Fraud Proof and the arbitration contract will make a judgment. If the arbitration contract determines that the Proposer is cheating, the Proposer will be punished and the State Commitment Chain will be rolled back to the state before the fraudulent transaction. Of course, in order to ensure safety, a relatively long challenge period is generally set to achieve the finality of transaction settlement on the chain. This is called Optimistic Rollup.

We also need to achieve asset interoperability between Layer 1 and Layer 2. So a bridge between Layer 1 and Layer 2 is built, and asset settlement is carried out through state proof. And the state of Layer 2 in Layer 1 is guaranteed by the arbitration contract of Layer 1. We can think that the security of this bridge is also guaranteed by the arbitration contract.

So far, we have obtained a Rollup Layer 2 solution that is guaranteed by Layer 1 and can communicate with Layer 1 for assets.

Of course, the Rollup scheme also made some compromises:

• Writing transactions to Layer 1 means that the scalability of Layer 2 is still limited by the block size of Layer 1. Taking Ethereum as an example, a certain Layer 2 completely occupies all the blocks of Ethereum, and the average TPS that can be provided is only a few hundred, and the scalability is limited by DA.

• In order to save Gas fees, Sequencer will write transactions to DA in batches, and before writing to DA, Sequencer may cheat by adjusting the order of transactions.

Here is a summary of the security of Layer 2 and the finality of transactions:

• If the user runs a Layer 2 node and executes it faithfully in accordance with the transaction sequence of DA, the user can think that the transaction is instantly confirmed and finalized, because if the result of the user's execution is different from that of the Proposer, it means that the Proposer is cheating and needs to The state on the rollback chain will eventually be the same as the execution result of the user's own node. The main risk point here lies in the aforementioned risk that if data is synchronized from Sequencer in real time, Sequencer will adjust the order of transactions that have not been written into DA.

• If the user cannot run the node by himself and needs to rely on an RPC provider, the user needs to bear certain trust risks. But this risk is similar to the risk brought by users trusting Layer 1 RPC nodes. The additional risk here is still the risk brought by Sequencer discarding or rearranging transactions.

• If the Proposer makes an error, but no node initiates a challenge, and the challenge period expires, the wrong state cannot be rolled back at this time, and the state can only be repaired through a social consensus hard fork.

Rollup's Modular Evolution

According to the previous analysis, in the Rollup solution, multiple contracts on the chain undertake different functions and represent different modules. It is natural to think whether the module can be split into multiple chains to obtain higher scalability. This is the idea of ​​modular blockchain and modular Rollup.

Modularity has two meanings here:

• Through the modular design, the system becomes a pluggable system. Developers can assemble modules to meet the needs of different application scenarios.

• Based on the capabilities provided by 1, the implementation of the module layer is not bound to the same Layer 1, resulting in better scalability.

We can think of three main module layers:

• Data availability layer (Data Availability): To ensure that the transaction data of the execution layer can be obtained through public means, and to ensure the sequence of transactions.

• Settlement layer (Settlement): realize asset and state settlement between Layer 1 and Layer 2. It contains State Commitment Chain and Bridge.

• Arbitration layer (Arbitration): verify the fraud proof, and make a decision (Optimistic) or verify the valid proof (ZK). The arbitration layer must have the ability to manipulate the State Commitment Chain.

DA Modular

The primary benefit of migrating the DA function out and using an independent solution is that the transaction gas fee of Layer 2 is reduced by at least an order of magnitude.

From the perspective of security, even though the decentralization of the DA chain is weaker than that of Ethereum, the security guarantee of the DA layer is mainly the transactions during the challenge period. After the challenge period, DA is mainly for the convenience of other nodes to synchronize data. Security is not guaranteed, so the requirement for decentralization can be lowered by a level.

The DA dedicated chain can provide higher storage bandwidth and lower storage cost, and is specially designed for sharing DA with multiple applications. This is also the foothold of current DA chains such as Celestia and Polygon Avail.

After splitting the DA layer, we get the following architecture:

In the above figure, DA is responsible for saving the Canonical Transaction Chain, and a L1 To L2 Transaction Queue is left for Layer 1 to realize message communication between Layer 1 and Layer 2. Users can also directly write transactions to this Queue to ensure Permissionless at Layer 2, Sequencer cannot audit users or transactions.

But a new problem will be introduced here. If the transaction sequence written by Sequencer to DA is inconsistent with the transaction sequence executed by Proposer, how will the arbitration contract decide? One solution is to have a cross-chain bridge between the DA chain and the arbitration chain to verify the data proof provided by the DA chain in the arbitration contract. However, this scheme relies on the realization of cross-chain bridges between DA and other chains, and the selection of DA schemes will be limited. Another solution is to introduce sorting proofs.

Sequence Proof

We can think that Sequencer is actually part of the DA solution, which is equivalent to an App-Specific DA, mainly based on the following reasons:

• Sequencer needs to provide DA guarantee during the period before batch writing to DA chain.

• Sequencer needs to be responsible for transaction verification, ordering, and final writing to DA.

If Sequencer is required to generate a Sequence Proof for each transaction, two problems can be solved:

• Guarantees are provided for transactions that have not been written into the DA chain, so that Sequencer does not dare to adjust the order of transactions or discard transactions at will.

• If there is no cross-chain bridge between the DA chain and the arbitration chain, the challenge mechanism of Sequence Proof can be used to ensure the availability of data.

Sequence Proof has the following properties:

• It carries the signature of the Sequencer, which proves that it was sent by a Sequencer.

• It can prove the position of a certain transaction in the entire transaction sequence.

• It is a type of accumulator proof. After each transaction is accumulated, a new accumulation result is generated, which is related to all historical transactions before the transaction, making it difficult to tamper with. One of the alternatives to the accumulator is the Merkle Accumulator, and the accumulated result is represented as the root of the Merkle tree.

How Sequence Proof works:

The user or the execution node submits the transaction to the Sequencer, and the Sequencer returns the Sequence Proof to the user and synchronizes it to other nodes. If Sequencer discards or tampers with the order of transactions before submitting to DA, users or other nodes can submit Sequence Proof to the arbitration contract to punish Sequencer. The arbitration contract needs to read the root of the transaction accumulator from the State Commitment Chain contract to verify the Sequence Proof.

Let’s discuss by scenario:

• Sequencer discarded or reordered user transactions. This will cause Sequencer to generate two Sequence Proofs at the same location. The user submits the Sequence Proof to the arbitration contract, and the Sequencer needs to provide proof that the transaction is included in the root of the latest transaction accumulator. If it cannot be given, the Sequencer will be punished.

• The Sequencer did not correctly write the transaction into the DA chain, and conspired with the Proposer to hide the transaction. If there is a bridge between the arbitration chain and the DA chain, it will be verified through the bridge and the Sequencer will be punished. Otherwise, the user can initiate a challenge, asking the Sequencer to give a proof of the transaction at a certain location, as well as the original information. But in this case, the arbitration contract cannot judge whether the user is a malicious challenge, so if the Sequencer gives the data, the Sequencer will not be punished. For users, malicious challenges harm others and themselves, and lack economic motivation.

We made the Layer 2 protocol more secure by introducing Sequence Proof.

Transaction Pipeline and Parallel Execution

Assigning Sequencer to DA is only responsible for the verification and sequencing of transactions. Another benefit is that it is easy to implement transaction pipelines and parallel execution.

When verifying a transaction, it is necessary to verify the signature and whether there is enough Gas fee, and the verification of Gas fee depends on the state. If we allow the Sequencer to have a certain delay (seconds) between the state that the verification transaction depends on and the latest state in order to ensure that the verification transaction will not be blocked by the execution transaction, the Gas verification will be inaccurate and there is a risk of being attacked by DDoS .

But we think that Sequencer belongs to DA is a correct direction, so it is worth our further research. For example, the DA part of the transaction fee can be split out and expressed through UTXO (Sui Move Object), which can reduce the cost of Gas fee detection.

The Sequencer sorts the transactions and outputs them into a transaction pipeline, which is then synchronized to the Proposer and other nodes. Each node can choose a parallel solution according to its own server situation. Each node needs to ensure that only transactions without causality are parallelized, and transactions with causality must be executed in the order of Sequencer, so the final result is consistent.

Proposer needs to regularly submit the root of the state tree and the root of the accumulator to the State Commitment Chain contract on the chain.

So we got a low Gas fee, high TPS, and more secure modular Layer 2: Rooch.

• MoveOS: It includes MoveVM and StateDB, which are the execution and state storage engines of the system. StateDB is built from two layers of sparse Merkle trees, which can provide state proofs. According to the previous analysis, it can be concluded that state tree and state proof are indispensable components of Rollup application.

• RPC: Provide external query, submit transaction, and subscription services. It can be compatible with RPC interfaces of other chains through proxy.

• Sequencer: Verify transactions, sort transactions, provide Sequence Proof, and stream transactions to Transaction Pipeline.

• Proposer: Obtain transactions from the Transaction Pipeline, execute them in batches, and submit them to the State Commitment Chain on the chain periodically.

• Challenger: Get transactions from the Transaction Pipeline, execute them in batches, compare them with the State Commitment Chain, and decide whether to initiate a challenge.

• DA & Settlement & Arbitration Interface: Abstraction and encapsulation of different module layers to ensure that the upper-layer business logic is not affected when switching between different implementations.

Interactive fraud proofs supporting multiple chains

In the Optimistic Rollup scheme, how the arbitration contract on the chain determines that the transaction execution error under the chain has always been a difficult problem. The original idea was to re-execute Layer 2 transactions on Layer 1, but the problem with this solution is that Layer 1 contracts have to simulate Layer 2 transaction execution, which is very costly and will also limit the complexity of Layer 2 transactions.

Finally, the industry worked out an interactive proof solution. Because any complex transaction will eventually be converted into machine instructions for execution, if we find instructions that diverge, we only need to simulate and execute the instructions on the chain.

Also use the state transition formula above:

σt+ 1 ≡ Υ(σt, T)

Here Υ represents the instruction, T represents the instruction input, and σ represents the memory state that the instruction depends on. If during execution, a state proof is generated for each σ. The prosecution and the defense can find out the divergence point m between the two parties through interaction, and submit the state σ of m-1 and the instruction m to the arbitration contract on the chain for simulation execution. After the arbitration contract is executed, a judgment can be given.

So the remaining question is how to generate the proof. There are two main options:

• It is directly implemented in the contract language virtual machine, such as Arbitrum's AVM and Fuel's FuelVM.

• Implement a simulator based on an existing instruction set, and provide proof capabilities in the simulator. Such as Optimism's cannon based on MIPS instructions, Arbitrum's new Nitro based on WASM instructions, and Rooch's OMO based on MIPS instructions.

OMO is a general-purpose bytecode emulator with single-step state proof capability, designed for multi-chain execution environments. With the support of OMO, the modularization of the arbitration layer can be realized. Any chain that supports Turing's complete contract can simulate OMO instructions in the contract as an arbitration layer.

ZK + Optimistic Combination Solution

The industry has been arguing about the advantages of Optimistic Rollup and ZK Rollup, but we believe that combining the two can take advantage of both solutions.

Based on the previous Optimistic solution, we introduce a new role, ZK Prover. It generates valid proofs for the transaction status submitted by the Proposer in batches and submits them to the arbitration contract. After the arbitration contract is verified, it can be determined that the transaction has reached finality on Layer 1, and the settlement of the withdrawal transaction from Layer 2 to Layer 1 can be performed.

Advantages of this scheme:

• The overall throughput of Layer 2 will not be limited due to ZK performance issues.

• ZK can be used to shorten the Optimistic challenge cycle and improve user experience.

Before ZK's solution and hardware acceleration mature, we can first build an ecosystem through Optimistic, and the modular solution can allow ZK to be seamlessly connected in the end.

Multi-chain settlement

If we further think about the trend of modularization, it is natural to think that since DA can be migrated to other chains, can the settlement layer also be deployed to other chains?

The asset settlement between Layer 1 and Layer 2 mainly relies on two components, one is Bridge and the other is State Commitment Chain. When settlement is made from Bridge, it needs to rely on State Commitment Chain to verify the state certificate of Layer 2. Of course, Bridge can be deployed to multiple chains, but the State Commitment Chain can only have one authoritative version, which is guaranteed by the arbitration contract.

This direction still needs in-depth research, but there is a preliminary plan. The State Commitment Chain on other chains are all mirrors on the arbitration chain (Ethereum). This mirroring does not need to synchronize all Layer 2 State Roots to other chains, but the user needs to map through Ethereum's state proof.

Of course, other chains also need to be able to verify the status certificate on Ethereum, so they need to know the status root on Ethereum. Currently, there are two options for synchronizing the state root on Ethereum to other nodes: 1. Rely on Oracle. 2. Embed the Ethereum light node and verify the block header of Ethereum.

In this way, we can get a Layer 2 solution that supports multi-chain settlement, but the security is guaranteed by Ethereum.

The difference between this solution and cross-chain:

• If it is a cross-chain solution that relies on the relay chain, it can be considered that Layer 2 replaces the relay chain and is a relay layer whose security is guaranteed by the arbitration contract.

• If it is a cross-chain scheme that checks the state certificates between chains, the multi-chain settlement scheme and its shared state root synchronization technical scheme are much simplified. Because in the multi-chain settlement scheme, the synchronization requirement of the state root is one-way, it only needs to be synchronized from the arbitration chain to other chains, not two-by-two.

Modular Possibilities

Through modularization, developers can combine different applications through Rooch.

• Rooch Ethereum Layer 2  = Rooch + Ethereum(Settlement+Arbitration) + DA
  This is the network on which Rooch will operate in the first place. Provide a Move operating platform that is guaranteed by Ethereum security and can communicate with assets on Ethereum. In the future, it can be extended to multi-chain settlement.

• Rooch Layer 3 Rollup DApp = Rooch + DApp Move Contract + Rooch Ethereum Layer 2(Settlement + Arbitration) + DA If the application deploys its settlement and arbitration to Rooch Layer 2, it is a Rooch Layer 3 application.

• XChain Rollup DApp = Rooch + DApp Move Contract + XChain(Settlement + Arbitration) + DA Any chain can provide developers with a Rollup DApp toolkit based on the Move language through Rooch. Developers only need to write their own application logic through the Move language to run a Rollup application in an independent environment whose security is guaranteed by XChain and whose assets can communicate with XChain. Of course, this requires collaborative development with the developers of the public chains.

• Sovereign Rollup DApp = Rooch + DApp Move Contract + DA The application can also use Rooch as the Sovereign Rollup SDK without deploying the Bridge and Arbitration contracts. The State Commitment Chain is also stored in DA to ensure verifiability and security by social consensus.

• Arweave SCP DApp = Rooch + DApp Move Contract + DA (Arweave) SCP is similar to Sovereign Rollup, and SCP requires that the code of the application should also be saved to DA. In Rooch, the contract deployment and upgrade are both transactions, and the contract code will be written to the DA layer in the transaction, so we think it meets the SCP standard.

• Move DApp Chain = Cosmos SDK + MoveOS + DApp Move Contract MoveOS can be embedded as an independent Move operating environment into any chain operating environment to build application chains or new public chains.

• Non-blockchain projects Non-blockchain projects can use MoveOS as a database with data verification capabilities and storage proof capabilities. For example, use it as a local blog system, and the data structure and business logic are expressed through Move. When the future infrastructure is mature, it can be directly connected to the blockchain ecology. For another example, it can be used as a FaaS service in cloud computing. Developers can write functions in FaaS through Move, and the platform hosts the status. Functions between users can also be combined and called. More possibilities need to be explored by everyone.

Rooch's modular solution can be adapted to different types and stages of application. For example, developers can first verify their ideas on Rooch Ethereum Layer 2 by deploying contracts, and after they grow up, migrate their applications to an independent App-Specific Rollup based on Rooch.

Or the developer directly starts the application through the Sovereign Rollup method, because the application does not have high security requirements in the early stage, and there is no need to exchange assets with other chains, so it must be verifiable first. When the application grows, there is a demand for interoperable assets, and the security requirements become higher. At this time, the settlement and arbitration modules can be enabled to ensure the security of assets.

Technology Trends for Modular Applications

The potential of the DA layer has yet to be tapped

It can be seen from the previous analysis that no matter which combination is used, it depends on DA. The role of DA in decentralized applications is similar to the log platform of the Web2 system, which can be used for auditing, supporting big data analysis, AI training, etc. In the future, many applications and services will be built around DA. At present, Celestia and Polygoin are available, and there will be EigenLayer, Ethereum darksharding, etc. in the future.

According to the previous analysis, we conclude that the role of Sequencer should be a part of DA. If the DA layer can provide transaction verification capabilities for applications and has sufficient performance, DA can actually assume the responsibility of Sequencer. Users can directly write Trade to DA. Of course, whether you can use the application's Token to pay the Gas fee of DA is another problem that needs to be solved.

DApp programming language will explode

New application forms will prompt the explosion of new programming languages, which has been verified in the Web2 era. And Move will become the best language to build Web3 DApp. In addition to the language features of Move itself, it is also based on the following reasons:

• DApp can quickly accumulate the basic library required by the application with the same language, forming an ecological aggregation effect. So it's not a good strategy to support multiple languages ​​in the first place.

• Decentralized applications must at least guarantee verifiability, and smart contract languages ​​can reduce a lot of mental burden for developers in ensuring verifiability.

• Move's platform independence makes it easy to adapt to different platforms and different applications.

• Summarize

Summarize

I entered the blockchain field at the end of 2017. At that time, there were many teams in the industry trying to build applications in the blockchain field. It is a pity that the infrastructure was not complete at that time, and the industry had not yet figured out a replicable application building model. Most application projects ended in failure, which hit developers and investors. How should applications on the blockchain be constructed? This question has been on my mind for five years.

Now, with the maturity of Layer 1, Layer 2, smart contracts, and modular infrastructure, the answer to this question is gradually becoming clear.

It is hoped that in the upcoming wave of Web3 DApp explosion, Rooch can help developers to build applications faster and truly land.