Rollup Layer2 Modular Evolution: What is possible?

原文标题：《 Rollup Layer2 的模块化演进之路 》

Originally written by Jolestar, co-founder of Rooch

This paper attempts to discuss the development and evolution of Rollup Layer2 from the perspective of evolution, and mainly answers the following questions:

How Rollup works

Rollup Modular evolution

The possibilities of modularity

Technology trends in modular applications

summarize

How does Rollup work

The "Trilemma problem" of blockchain has always been a puzzle puzzling the industry. If we believe that Layer1 blockchain should first ensure "decentralization" and "security", then it is a natural choice to migrate the "scalability" solution from Layer1, thus Layer2. The new challenge is how to secure Layer2 with Layer1.

One of the initial ideas was to periodically write the state root of the Layer2 application to Layer1, so that the state of the application could be verified by a state proof, similar to a trading platform reserve proof. But this way there is no way for a third party to publicly verify that two state transitions are correct.

To explore this further, 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 Book, but it can represent any program. In this case, it's the program, it's the state. State t+1 is calculated by program Y from state t and transaction T. Transaction T represents the input to the program. At any time, if t is certain, if the program Y is certain, if T is certain, then t plus 1 is certain.

So to provide public verifiability, the key is for Y to be publicly available, for all T's in history to be publicly available and in order, and for states in between to be recalculated by 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. Naturally, the blockchain ledger is such a system, so the transactions of Layer2 are written back to Layer1 to ensure data availability, which is where the Rollup name comes from.

So the Layer2 system needs a role to collect user transactions, sort them, and write them to DA. This role is called   It is a Sequencer. The transaction sequence here is called   Canonical Transaction Chain.

To ensure the availability of data, everyone can run their own programs to execute transactions to get the final state. But there is no consensus, because everyone is not sure whether their results are consistent with those of others, after all, software or hardware failures can cause data discrepancies. Therefore, another role is needed to publish the state root of the transaction after execution, for everyone to check their own state, this role is called. A Proposer. Here, the states of each submission also constitute a state sequence, corresponding to the transaction sequence, called   State Commitment Chain.

At this point, we have reached the verifiability of the application. If someone runs something that doesn't match a Proposer's submitted state, and decides it's not their fault, they've cheated or made a mistake, how do they let someone know? This requires the introduction of the role of Arbitrator. The arbitrator needs to be a trusted third party, and an on-chain contract can fulfill that role.

There are two options for arbitration:

A Proposer provides Validity Proof of state transitions with the previous state each time it submits a state. The arbitration contract on the chain verifies this. Proof of validity is usually generated by Zero knowledge technology, which is called ZK Rollup.

The Proposer is assumed to get its results right, but if discrepancies are found, a Fraud Proof is filed, which is judged by the arbitration contract. If the arbitration contract determines that a Proposer cheated, it penalizes the Proposer and rolls back the State Commitment Chain to the state it was in before the fraudulent transaction. Of course, in order to ensure security, it is common to set a relatively long challenge cycle to achieve the final certainty of on-chain transaction settlement. It's called Optimistic Rollup.

We also need to implement asset interworking between Layer1 and Layer2. Therefore, a bridge between Layer1 and Layer2 is constructed, and assets are settled through state proof. The state of Layer2 in Layer1 is guaranteed by Layer1's arbitration contract, so we can assume that the security of this bridge is also guaranteed by the arbitration contract.

At this point, we have a Rollup Layer2 scheme that is secure by Layer1 and can communicate assets with Layer1.

Of course, the Rollup scheme also makes some compromises:

Writing transactions to Layer1 means that Layer2's scalability is still limited by the Layer1 block size. In Ethereum, for example, a Layer2 occupies all of Ethereum's blocks and can only provide hundreds of TPS on average. Scalability is limited by DA.

In order to save Gas fees, Sequencer writes transactions to DA in bulk, and it is possible that Sequencer cheats by adjusting the order of transactions before writing to DA.

Here's a summary of Layer2's security and the ultimate certainty of the transaction:

If a user runs a Layer2 node himself and faithfully follows the DA's order of transactions, the user can assume that the transaction is instantly confirmed and finalized, because if the user does not execute the same result as a Proposer, it means that a Proposer is cheating and needs to roll back the state on the chain. The result will be the same as the user's own node. The main risk point here is the aforementioned risk of Sequencer adjusting the order of transactions that have not yet been written into DA if data is synchronized in real time from Sequencer.

If the user cannot run the node himself and needs to rely on an RPC provider, the user takes some trust risk. But this risk is similar to the risk posed by users trusting Layer1's RPC nodes. The additional risk here is again that the Sequencer throws away the trade or rearranges the trade.

If a Proposer makes a mistake but no node initiates a challenge and the challenge period is passed, the error state cannot be rolled back and can only be fixed by a social consensus hard fork.

Rollup Modular evolution

Based on the previous analysis, in a Rollup solution, multiple contracts on the chain perform different functions and represent different modules. The natural question is whether the module can be split into multiple chains for greater scalability. That's the idea behind modular blockchain and modular Rollup.

Modularity here has two meanings:

By modular design, the system becomes a pluggable system. Developers can meet the requirements of different application scenarios through module assembly.

Based on the capabilities provided by 1, the implementation of the module layer is not bound to the same Layer1 for better scalability.

We can think of three main module layers:

Data Availability: Ensure that transaction data at the execution level is available in a public way, and ensure the sequence of transactions.

Settlement: Settlement of assets and status between Layer1 and Layer2. It contains the State Commitment Chain and Bridge.

Arbitration: Verify the fraudulent evidence and make an Optimistic judgment or verify the valid evidence. The arbitration layer must be able to control the State Commitment Chain.

DA modularization

The primary benefit of migrating DA functions out of a standalone solution is that Layer2's transaction Gas costs are reduced by at least an order of magnitude.

From the perspective of security, even though the decentralization of DA chain is weaker than that of Ethereum, the security guarantee of DA layer is mainly the transaction during the challenge period. After the challenge period, DA is mainly for the convenience of other nodes to synchronize data, which has no guarantee effect on security. Therefore, the requirement of decentralization can be lowered by one level.

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

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

In the figure above, DA holds the Canonical Transaction Chain and leaves Layer1 with an L1ToL2 Transaction Queue to communicate messages between Layer1 and Layer2. Users can also write transactions directly to this Queue, ensuring that Layer2's Permissionless, Sequencer does not audit users or transactions.

But this introduces a new conundrum. If the sequence of trades written by a Sequencer to a DA is inconsistent with the sequence of trades executed by a Proposer, how does the arbitration contract decide? One solution is that there is a cross-chain bridge between DA chain and arbitration chain to verify the data proof provided by DA chain in arbitration contract. However, this scheme depends on the realization of cross-chain Bridges between DA and other chains, so the selection of DA schemes will be limited. Another option is to introduce ordering proofs.

Sequence Proof

We can assume that Sequencer actually belongs to the DA scheme, which is equivalent to an App-Specific DA, mainly for the following reasons:

Sequencer needs to provide DA guarantees for the period before bulk writing to DA chains.

Sequencer is responsible for verifying, sequencing, and ultimately writing transactions into the DA.

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

The guarantee is provided for the transactions not yet written into DA chain, so that Sequencer dare not 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 data can be guaranteed through the challenge mechanism of Sequence Proof.

Sequence Proof  It has the following characteristics:

It carries the signature of a Sequencer, proving that it was issued by a certain Sequencer. It can prove a transaction's position in the overall transaction sequence. It is a kind of Accumulator proof. Each transaction adds up to a new cumulative result that relates to all historical transactions prior to that transaction, making it difficult to tamper with. One of the optional schemes of Accumulator is Merkle Accumulator, and the accumulator result is expressed as the root of the Merkle tree.

How Sequence Proof works:

The user or the executing node submits the transaction to Sequencer, which 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 them to DA, users or other nodes may submit Sequence Proof to the arbitration contract, thus punishing Sequencer. Arbitration contracts need to verify Sequence Proof by reading the root of the trade accumulator from the State Commitment Chain contract.

Discuss the following scenarios:

Sequencer discards or rearranges user transactions. This causes the Sequencer to generate two Sequence Proof at the same location. The user submits Sequence Proof to the arbitration contract, and Sequencer is required to provide proof that the trade is included in the root of the latest trade accumulator, or penalize Sequencer if it cannot.

Sequencer did not write the deal into the DA chain correctly and conspired with Proposer to hide it. If the arbitration chain and DA chain have Bridges, the Sequencer is punished by the bridge. Otherwise, users can challenge Sequencer to give the proof and original information of the transaction at a certain location. However, in this case, the arbitration contract cannot judge whether the user is a malicious challenge, so if Sequencer gives data, it will not punish Sequencer. And for users, malicious challenges are harmful to others and themselves, and lack of economic incentives.

We made Layer2's protocol more secure by introducing Sequence Proof.

Transaction Pipeline and Parallel Execution

Another benefit of dividing Sequencer into DA, which is only responsible for the verification and sequencing of transactions, is that it is easy to realize the pipeline of transactions and parallel execution.

When verifying a transaction, you need to verify the signature and the sufficient Gas fee, and the verification of the Gas fee depends on the state. In order to ensure that the authentication transaction will not be blocked by the execution of the transaction, if we allow a certain delay (second level) between the state on which the Sequencer authentication transaction depends and the latest state, Gas verification will be inaccurate and there will be the risk of DDoS attack.

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

Sequencer orders transactions and outputs them into a pipeline, which is then synchronized to Proposer and the other nodes. Each node can choose a parallel scheme based on its own server situation. Each node needs to ensure that only transactions without causality are conducted in parallel. Transactions with causality must be executed in the order of Sequencer, so that the final result is consistent.

A Proposer needs to periodically submit the roots of the State tree, and the roots of the accumulator, into a State Commitment Chain contract on the chain.

So we get a lower Gas rate, higher TPS, and more secure modular Layer2. Rooch.

MoveOS: This includes MoveVM and StateDB, which are the system's execution and state storage engines. StateDB is constructed by a two-layer sparse Merkle tree, which can provide state proof. Based on the previous analysis, state trees and state proofs are integral components of Rollup applications.

RPC: Provides external query, transaction submission, and subscription services. It can be compatible with RPC interfaces of other chains by proxy.

Sequencer: Verifies transactions, ranks them, provides Sequence Proof, streams transactions to Transaction Pipeline.

Proposer: A company that obtains transactions from a Transaction Pipeline, executes them in bulk, and submits them periodically to a State Commitment Chain on the chain.

Challenger: Acquire deals from a Transaction Pipeline, execute in bulk, compare them with the State Commitment Chain, and decide whether to launch a challenge.

DA & Settlement & Arbitration Interface: Abstraction and encapsulation of different module layers, ensuring that switching between different implementations does not affect the upper layer of business logic.

Support for multi - chain interactive fraud proof

Optimistic Rollup is an optimistic rollup scenario in which an on-chain arbitration contract determines that an underchain trade is executed incorrectly. The original idea was to re-execute the Layer2 trade on Layer1, but the problem with this solution was that the Layer1 contract had to simulate the trade execution of Layer2, which was costly and limited the complexity of the Layer2 trade.

Finally, the industry has explored an interactive proof scheme. Because any complex transaction will eventually be translated into machine instruction execution, if we find the divergent instruction, we just need to simulate the execution of the instruction on the chain.

Also use the state transition formula above:

t+1 (t, T)

Here is the instruction, T is the instruction input, and t is the memory state that the instruction depends on. If during execution, generate a state proof for each. The prosecution and defense parties can find the bifurcation point m through interaction, submit the state of M-1 and instruction m to the arbitration contract on the chain for simulation execution, and the decision can be given after the execution of the arbitration contract.

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

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

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

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

ZK + Optimistic combination

There has been a debate in the industry about the merits of Optimistic Rollup versus ZK Rollup, but we think combining the two gives us the best of both scenarios.

Based on Optimistic plan, we introduce a new character, ZK Prover. It generates a valid certificate of the status of a deal submitted in bulk to Proposer, which is submitted to an arbitration contract. After the arbitration contract is verified, it can be determined that the transaction has reached the final certainty on Layer1, and the settlement of the withdrawal transaction from Layer2 to Layer1 can be carried out.

The advantages of this scheme are:

Performance issues with ZK will not limit Layer2's overall throughput. ZK can shorten Optimistic challenge cycle and improve user experience.

Before ZK's plan and hardware acceleration mature, we can first build an Optimistic ecosystem, and the modular plan allows ZK to be seamlessly integrated into it.

Multi-chain settlement

If we think further about the modularity trend, the natural question is, since DA can be migrated to another chain, can the clearing layer be deployed to another chain?

Asset settlement between Layer1 and Layer2 mainly depends on two components, one is Bridge and the other is State Commitment Chain. When settling assets from Bridge, You need to rely on the State Commitment Chain to verify the state proof of Layer2. A Bridge can of course be deployed to multiple chains, but there can only be one authoritative version of a State Commitment Chain, which is secured by an arbitration contract.

More research is needed in this direction, but there is a tentative plan. State Commitment chains on other chains are mirrors on Ethereum. This image does not need to synchronize all Layer2 State Root to other chains, but rather users map on demand using Ethereum state proofs.

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

This gives us a Layer2 solution that supports multi-chain clearing, but is secured by Ethereum.

The difference between this scheme and cross-chain:

In the case of a cross-chain solution that relies on the trunk chain, Layer2 can be considered to replace the trunk chain as a trunk layer whose security is guaranteed by arbitration contracts.

If it is cross-chain verification state proof scheme, multi-chain settlement scheme and its shared state root synchronization technical scheme, but simplified a lot. Because in the multi-chain settlement scheme, the synchronization demand of the state root is unidirectional, and only needs to be synchronized from the arbitration chain to other chains, rather than each other in pairs.

The possibilities of modularity

With modularity, developers can create different applications through Rooch.

Rooch Ethereum Layer2  = Rooch + Ethereum(Settlement+Arbitration) + DA This is the network Rooch runs on first. Provide a Move platform that is secure with Ethereum and can communicate with Ethereum assets. It can be extended to multi-chain settlement in the future.

Rooch Layer3 Rollup DApp  = Rooch + DApp Move Contract + Rooch Ethereum Layer2(Settlement + Arbitration) + DA If an app moves its settlement and arbitration to Rooch Layer2, It's a Rooch Layer3 application.

XChain Rollup DApp  = Rooch + DApp Move Contract + XChain(Settlement + Arbitration) + DA Any chain can use Rooch to provide developers with a Rollup DApp based on the Move language Tool kit. Developers simply need to write their own application logic in the Move language to run a Rollup application in a separate environment with Xchain-secure, Xchain-interoperable assets. Of course, this needs to be developed in collaboration with the developers of various public chains.

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

Arweave SCP DApp  = Rooch + DApp Move Contract + DA (Arweave) SCP and Sovereign Rollup have a similar idea. SCP requires application code to be saved to DA. In Rooch, contract deployment and upgrade are transactions, and the contract code is 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 a standalone Move runtime environment in any chain 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 to make a local blog system, data structure and business logic through the Move expression. When the infrastructure is mature in the future, it can be directly connected with the blockchain ecosystem. For example, it can be used to do cloud computing FaaS service, developers through the Move to write FaaS Function, platform hosting state, Function between users can also be called each other. More possibilities need to be explored.

Rooch's modular approach can be adapted to different types and phases of application. For example, developers can first validate their ideas on Rooch Ethereum Layer2 by deploying contracts, then migrate their applications to a separate Rooch-based App-Specific Rollup once they grow up.

Alternatively, developers can launch applications directly through Sovereign Rollup, as the application has low security requirements and no need to interact with other chain-link assets in the early days, so it can be verified first. When applications grow up and there is a demand for interworking assets, security requirements become higher. At this time, settlement and arbitration modules can be used to ensure the security of assets.

Technology trends in modular applications

The potential of DA layer remains to be explored

From the previous analysis, you can see that either combination depends on DA. In decentralized applications, DA plays a similar role to the log platform of Web2 system, which can be used for auditing, big data analysis, AI training, etc. There will be many applications and services built around DA in the future. Currently there are Celestia, Polygoin avail, in the future there will be EigenLayer, Ethereum danksharding and so on.

Based on the previous analysis, we draw the conclusion that the role of Sequencer should be a part of DA. If the DA layer can provide transaction verification capability for applications and has sufficient performance, in fact, DA can fully assume the responsibilities of Sequencer, and users directly write transactions to DA. Of course, whether the Token of the application can be used to pay the Gas fee of DA is another problem to be solved.

The DApp programming language will explode

New forms of application can lead to an explosion of new programming languages, as demonstrated in the Web2 era. Move would be the best language for building Web3 Dapps. In addition to the language features of Move itself, it is based on the following reasons:

Using the same language, DApps can quickly accumulate the basic libraries needed by applications and form an ecological aggregation effect. So supporting multiple languages is not a good strategy at first.

At the very least, a decentralized application needs to be verifiable, and a smart contract language allows developers to reduce a lot of the mental burden of ensuring verifiability.

The platform independence of Move makes it easy to adapt to different platforms and different applications.

The state of Move is structured, which is conducive to DApp data structure expression and storage retrieval.

summarize

I entered the blockchain field at the end of 2017, when there were a lot of teams trying to build applications in the blockchain field. Unfortunately, the infrastructure wasn't there yet, the industry hadn't yet figured out a replicable model for building apps, and most app projects failed, crushing developers and investors. How should applications be built on blockchain? I've been thinking about this for five years.

Now, with the maturation of Layer1, Layer2, and smart contracts, modular infrastructure, the answer is becoming clear.

Hopefully, Rooch will give developers a leg up in the coming explosion of Web3 Dapps, allowing them to build faster and get their apps off the ground.

Original link

欢迎加入律动 BlockBeats 官方社群：

Telegram 订阅群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方账号：https://twitter.com/BlockBeatsAsia