Author: Cointime.com 237

Rooch: A Web3 Native Application Infrastructure Solution

Rooch is an efficient, secure, modular, developer-friendly Web3 native application infrastructure solution.

The mission of the Rooch project is to build an infrastructure that can host Web3 native applications and revolutionize the current centralized landscape of Internet applications.

Rooch wants to build a great infrastructure product and speak for itself through the great performance of that product.

The Rooch project currently builds two core products:

1) Rooch

Rooch is a modular DApp container (a decentralized Docker)

2) Rooch Network

Rooch Network is a deployment platform for Rooch instances. (decentralized cloud)

Next, we will introduce each of these two core products.

Core product one: modular DApp container - Rooch

1、Function introduction

When Rooch is a smart contract execution container, it has the following functions:

1）MoveVM

Rooch embeds a complete MoveVM for developers to write smart contracts using the Move language.

2) Scalability

Rooch is a fast execution environment that can achieve 100,000 peak TPS when composed into a network.

3) Modular

Rooch has an abstract interface that allows access to different DA, settlement and arbitration layers.

2、Product Architecture

1）RPC

RPC component provides access endpoints for users and developers to upload Move modules and send transactions to call contracts and native functions.

RPC Proxy The RPC Proxy is a special component designed to interpret different transaction structures into native mode to allow users to send transactions directly from various wallets in the marketplace. For example, a user can send a transaction directly from MetaMask to call a Move contract on Rooch.

2) MoveOS

MoveOS is the component that performs all the computation and storage work. It consists of three main parts: OMO, MoveVM, and State Storage.

A. OMO is a generic MIPS simulator used to generate fraud proofs for execution.

B. MoveVM is a complete functional Turing-complete VM for executing smart contracts written in the Move language.

C. State Storage contains all user and contract states.

3) Role Specific Modules

Role-specific modules are functional modules that allow node operators to configure their nodes as different roles in a hierarchical network.

4) Interfaces

Rooch has built-in interfaces that can be used with different layers; the interfaces need to be abstract enough to ensure that Rooch can adapt to different ecosystems

Core Product Two: Deployment Platform - Rooch Network

Rooch Network provides a powerful all-in-one service for Web3 DApps, making them easy and flexible to deploy. This allows Web3 developers to focus more on building more personalized products without infrastructure concerns.

Specifically, Rooch Network consists of the following main component tiers:

1. Execution Layer

The execution layer consists of Rooch as a container and a Dapp as a smart contract execution environment. Depending on the scenarios and resource requirements, there are three types of Rooch usage:

1) Generic Platform

The Rooch team will launch and maintain a Rooch instance as a generic smart contract platform, and DApps and developers will be able to deploy their smart contracts directly to the existing platform. The development experience will be the same as working on the Layer1 blockchain, but with higher TPS, lower Gas fees, and larger and more convenient storage space.

2) DApp Dedicated Platform

DApps that want to have a custom platform can launch a dedicated instance of Rooch where developers can customize personalized and special features such as a pass-through economic model.

3）Sector Dedicated Platform

Web3 developers who want to use multiple DApps to develop and extend their ecosystem can also launch a Rooch instance, where the assets and features of different DApps will be seamlessly interoperable and users can share accounts and profiles between DApps of different ecosystems.

2. Network Middleware

The Rooch Network has several key middleware services that handle the transactions and state of all Rooch instances on the execution layer. All services are based on the same core Rooch implementation.

1) Sequencer

Sequencer is responsible for validating incoming transactions and sorting them. The sorted transactions are submitted to the DA Chain and Proposer.

2) Challenger

Challenger is the guardian of the Rooch Layer2 network. It continuously monitors the transaction flow and executes transactions to compute state transitions. If the computed state result does not match the proposed state, Challenger requests fraud proof and submits it to arbitration.

3) ZK Prover

ZK Prover generates a ZK proof of the state transition based on the batch transaction. The proofs are sent to the arbitration layer to optimize the challenge period required for the security mechanism.

4) Proposer

The Proposer is responsible for executing all sorted transactions and submitting the generated state to the arbitration layer.

3. DA Layer

The importance of DA (Data Availability) is to ensure that anyone can access all transactions that occur in the offline environment.

The Rooch network will use third-party solutions to ensure transaction availability and maintain high TPS. the Rooch team is still working on different options, including Celestia, Eigenlayer, Polygon Avail, and Arweave.

4. Arbitration Layer

The arbitration layer acts as a "court of law" for arbitrating and verifying all state transitions that occur in different Rooch instances containing different DApps.

In the Rooch network, Ether takes on the role of the arbitration layer and will be the only source of security for all DApps in the Rooch ecosystem, because Ether currently has the highest token market cap, which means it has the highest cost of attack.

On Ether, there are three smart contracts that serve different roles:

1) Fraud Proof Arbitration Contract

This contract accepts fraud proofs and simulates the execution of state transitions to make reduction decisions.

2) ZK Verifier Contract

This contract is responsible for verifying the ZK proofs submitted by ZK Prover.

3) State Commitment Chain

This contract keeps a chain of records of all states submitted by the Proposer.

5. Settlement Layer

The settlement layer provides state settlement for all Rooch-based DApps. Each DApp that uses Rooch as its execution environment can migrate assets between its DApp and different Layers1.

Rooch Network supports the integration of any Layer1 into the settlement layer, all using Ether as the source of security assurance.

Technical Highlights

1. Move Language

Move is an open source smart contract programming language originally designed and developed by Diem.

Named after the move semantics in C++, Move is used to move resources from one object to another without copying them. This design purpose fits perfectly into the context of the smart contract language and makes it an excellent choice for implementing flexibility and security for crypto assets.

2. Proof of Fraud

Rooch Network uses proof of fraud based on the Optimistic Rollups mechanism to ensure the security of the Rooch DApp.

Rooch will also support hybrid security enabled by ZK Proof.

Fraud proof generation is based on a multi-round interactive proof process. The goal is to find the exact instruction step that leads to a divergent state between the challenger and defender.

Fraud proof generation is a key part of securing the off-chain system in the Optimistic Rollup system. To this end, Rooch designed OMO, a general-purpose simulator that provides single-step proofs.

OMO is designed to be a generic bytecode simulator with single-step state proofs. Its generic goal provides two advantages for Rooch's implementation:

A. Compatibility with any Layer1 Any Layer1 that supports the MIPS instruction set can arbitrate the proofs generated by OMO. This makes Rooch a Layer2 for any Layer1.

B. Easy to maintain, debug and upgrade OMO can quickly accommodate major upgrades to MoveVM in the future.

3. Hybrid security with zero-knowledge proofs

Rooch will use zkMove to generate zero-knowledge proofs to optimize the challenge period of the fraud proof mechanism and create a hybrid security mechanism with both fraud proofs and zero-knowledge proofs.

zkMove is a zero-knowledge Move language runtime environment that enables bytecode-level compatibility. zkMove is a partnership between Rooch Network and zkMove, and the two projects will collaborate on technology development and application scenarios.

4、Multi-chain Settlement

Multi-chain settlement is one of the most important features of Rooch Network.

The responsibility of the settlement layer is to perform state migration and asset settlement between Layer1 and the execution layer.

The security of the cross-layer bridge in the multi-chain settlement scheme is protected by the arbitration layer (i.e. Ether), and the execution layer inherits the security of the arbitration layer. Therefore, it has stronger security.

In Rooch's multi-chain settlement scheme, the cross-layer is realized by a common state migration model, and the state can be used to represent the future application state of Token, NFT, digital contract, etc., without the need to design a special protocol for the new state type.

5. Pipeline-based parallel transaction processing

Optimizing the transaction processing flow and related components is the key to increasing the throughput rate of the whole system. To this end, Rooch leverages pipeline architecture to enable parallel transaction execution.

The roles of Sequencer and Proposer are decoupled into two distinct nodes:

1) Sequencer is primarily responsible for validating and sorting all incoming transactions; the output is formed into a transaction stream, which is then sent to Proposer

2) Proposer is responsible for executing all transactions received from Sequencer, packing them into blocks and calculating the final state of each block

Proposer executes all the transactions in a block in parallel using a similar approach introduced by BlockSTM.

6. Sequence Proof of Transactions

Sequence Proof proves whether a transaction is in a specific position in the sequence. In Rooch, it is used to provide users with more secure confirmation of transactions.

1) Without Sequence Proof

In Layer2 networks, the Sequencer cannot change the content of a transaction without facing a penalty, due to the restrictions of Fraud Proof or Zero Knowledge Proof. However, the Sequencer can reject a user's transaction (by not sending it to DA and Layer1), or change the location of the transaction to gain indirect benefits by colluding with third parties. (e.g. rejecting margin trades for liquidation profits, or changing trade orders for MEV profits)

2) Cases with sequencing proofs

With sequencing proof, once a user submits a trade to the sequencer, the sequencer needs to return confirmation as well as sequencing proof that the trade is contained somewhere in the sequence of trades. If the sequencer later removes the transaction from the sequence and does not submit it, the user can use the sequencing proof to arbitrate to penalize the sequencer.

This mechanism ensures that the sequencer creates a counter-incentive for such behavior and that the sequencer does not gain any profit from rejecting certain transactions.

Conclusion

Rooch aims to revolutionize decentralized applications. By providing an efficient, secure and developer-friendly infrastructure solution, Rooch hopes to drive the transformation of the Internet from centralized to decentralized.

Over time, Rooch will provide developers with more opportunities for innovation, personalization and autonomy, while creating a more secure, convenient and flexible Web3 experience for users. Its goal is to break down centralized monopolies and create an open, inclusive and transparent ecosystem for the digital economy.

With the continued efforts of the Rooch team and community, Rooch may become an important part of building the next generation of the Internet, creating a more free, secure and just digital world for people.