Rooch Network: The Native Application Layer of Bitcoin and Future Ecosystem Builders

Author: Rooch Network

What is Rooch Network?

Rooch Network is the native application layer of Bitcoin, based on a stacked L2 solution, providing a launch platform for Bitcoin assets and the infrastructure for Bitcoin applications for users and developers.

Why do we need Rooch Network?

In 2023, the Bitcoin ecosystem has seen the emergence of various new asset protocols, characterized by the registration of asset ownership solely on Bitcoin, with validity verified off-chain, collectively referred to as client-side validation (Client side validation) assets. What does the vision of the Bitcoin ecosystem implied by these new asset protocols look like? There are differing opinions in the industry, but we believe that new asset protocols on Bitcoin herald a new paradigm for building application ecosystems.

Client-side validated assets place the validity of assets in off-chain verification, allowing for the design of a cross-layer asset migration protocol that truly realizes the migration of assets from on-chain to off-chain, simulating a "cash" effect in the digital world. This provides asset use cases that are no longer limited by the scalability challenges of the chain, representing a new scaling solution and offering infinite possibilities for applications.

At the same time, this model also suggests a possible launch mode for application ecosystems. By attracting users with in-app assets, building user communities, and then giving rise to applications within the community, it addresses the cold start problem of applications.

So, what kind of infrastructure is needed to support this model?

1. First, a scalable off-chain application environment is required. This environment can provide verification services and scalability for on-chain asset protocols, as well as run applications and provide use cases for assets.
2. Second, a protocol for cross-layer asset migration is needed to facilitate the migration of assets from on-chain to off-chain.
3. Finally, a network is needed to connect off-chain applications, ensuring interoperability between applications.

This is the direction that Rooch Network aims to explore and attempt.

Technical Solutions and Roadmap

Verifiable Application Container (VApp Container)

The off-chain application environment must first ensure verifiability, as verifiability is a prerequisite for decentralization. We refer to verifiable applications (Verifiable App) as VApp.

Smart contracts ensure the verifiability of computations, and state trees ensure the verifiability of states, combined they form the verifiable application container.

After a year of development, the Rooch team has completed the VApp container for the Move language, which includes the following modules:

1. MoveOS: Includes MoveVM and the stacked state tree, providing an execution environment for applications and storing application states, ensuring the verifiability of computations and states.
2. Move standard libraries and frameworks: Including Move Stdlib, MoveOS Stdlib, RoochFramework, BitcoinMove, etc., providing basic functionalities such as account abstraction, asset definition, and Bitcoin protocol execution for applications.
3. Basic development tools, RPC interfaces, indexing services, and SDKs.

Based on this application container, application developers can implement most Web2 applications using the Move language, transforming them into verifiable applications. Rooch also introduces a WASM virtual machine, where the Move virtual machine runs application logic and manages state, while the WASM virtual machine provides extensibility, allowing developers to reuse existing programming language libraries.

Root to Bitcoin

With the VApp container in place, we need to integrate it with Bitcoin. The solution adopted by Rooch is to execute all blocks on the Bitcoin network directly within the VApp container, verifying UTXOs and the extended protocols attached to UTXOs, converting them into Move Objects, providing a L2 solution that includes L1 state for Bitcoin.

This smart contract layer primarily offers three capabilities:

1. Provides state proof of Bitcoin for Bitcoin ecosystem applications. Since the state on Bitcoin, including UTXOs and Inscriptions, will be included in the state tree, writing the root of the state tree to the Bitcoin network allows us to provide state proof for Bitcoin ecosystem applications. It can prove whether a user owns a certain UTXO or a certain Inscription at a specific block height.
2. Provides extensibility for asset protocols on Bitcoin L1. New protocols can be extended based on existing asset protocols, with the main task being to define and implement the verification rules for the new protocol, which can be achieved through smart contract protocol plugins. This way, developers do not need to build new indexers.
3. Provides programmability for all data and assets on Bitcoin, creating application scenarios.

With the complete state of Bitcoin, we can stack another layer of L2 state on top, creating application scenarios based on data and assets on Bitcoin, with several main approaches:

Settlement with Bitcoin L1 assets

There are mainly three modes: "Atomic swaps", "PSBT", and "on-chain payments triggering off-chain settlements." These modes are suitable for exchange or payment scenarios, settling directly on Bitcoin, allowing developers to utilize the smart contracts provided by Rooch to implement transaction order display, matching, and simplify settlements with Bitcoin.

Atomic binding

By atomically binding UTXOs and Move Objects, L2 assets are bound to Bitcoin L1 assets, ensuring that the ownership of assets on L2 transfers along with Bitcoin L1 assets. For example, if there is an Inscription on L1 representing a piece of land, and a house is built on L2, the ownership is bound to the land on L1; when the land is transferred, the house is also transferred.

Derivative assets

New assets can be derived from Bitcoin L1 assets, essentially a model for issuing new assets based on existing assets. For instance, holding a certain L1 asset could grant access to a certain L2 asset.

Props and identity markers

In applications, Bitcoin L1 assets can serve as props or identity markers. For example, a certain Inscription could represent equipment in a game, used directly in the game on L2, or L1 assets could be used for voting governance.

Programming Bitcoin scripts

Generate Bitcoin scripts and transactions within smart contracts, ensuring that users must sign these transactions and include them in L1 blocks through the constraints built on L2 (governance or collateral), or face penalties. This feature allows for the construction of on-chain multi-signature wallets, DAOs, and provides additional security guarantees for multi-signature bridges.

More models still need to be explored; we refer to this model as "stacked" application building mode, where applications stack a layer of state on top of the chain's state to reuse existing data and assets. For detailed plans regarding the "stacked" model, please refer to Stackable L2. For programming documentation and cases related to Bitcoin and Move, please see Extending Bitcoin.

Distributed State Tree Protocol (DSTP)

VApp containers are independent; how do we connect them into a network? And achieve state and asset interoperability? This is the problem that the Distributed State Tree Protocol needs to solve.

The idea of the Distributed State Tree Protocol is to distribute different subtrees of the stacked state tree across nodes in a P2P network to achieve scalability and parallel computation. Through the Distributed State Tree Protocol, the entire network can support an unlimited number of applications, achieving parallel horizontal scalability while sharing data and assets through a global state and enabling application interoperability.

Based on the "stacked" state model, each VApp node will contain the states of Bitcoin and Rooch, which are global states. The application state is a subtree of the global state tree and can exist only on specific nodes. If a transaction only modifies the application state without altering the global state, that transaction does not need to be broadcasted to the network; the application only needs to periodically synchronize its state root to the global state, akin to an application-based sharding.

This forms a distributed state tree with the root on Bitcoin and data dispersed across application nodes. Assets within applications can move between state trees and interact with assets on Bitcoin.

The Distributed State Tree Protocol can also extend in two directions:

1. Integrating state channels. State channels can be understood as a special type of state tree with a lifecycle. When a multi-party participant state channel is opened, a state tree is created; when the state channel settles, the application can discard or settle the state in the state tree to the previous layer. This scenario, combined with P2P networks, is very suitable for applications requiring real-time interaction among multiple users (games).
2. Supporting other formats of state trees. Theoretically, existing state trees can be mounted as subtrees in the distributed state tree, such as git repositories. This allows applications to directly read files from git repositories.

Asset Leap Protocol

Settling directly on Bitcoin L1 still presents user experience issues such as high transaction costs and long confirmation times. How to migrate assets from Bitcoin to L2? Currently, there are several solutions in the industry:

1. Custodial cross-chain bridge model. This model is widely used, and exploring how to utilize Bitcoin to ensure the security and decentralization of the bridge remains a direction of exploration. Rooch will collaborate with specialized cross-chain bridge projects to achieve asset bridging and enhance the security of the bridge through the programming capabilities provided by Rooch.
2. Non-custodial model: This is the primary direction Rooch is exploring, such as statechains.

For the new protocol assets on Bitcoin, we will attempt an asset leap protocol. If a large number of new asset types are issued on Bitcoin in the future, a protocol will be needed to facilitate the migration of assets between the Bitcoin network and L2, reducing the storage pressure of states on Bitcoin. At the same time, new asset types on L2 should also be able to migrate to Bitcoin to gain higher security and broader circulation capabilities.

Core Idea of the Asset Leap Protocol

Assets based on client-side validation, such as RGB/Ordinals, utilize Bitcoin to register asset ownership, but their validity is verified on the client side. If we define a leap instruction at the protocol level to express the migration of assets from L1 to L2 or from L2 to L1, and then the client can verify on both layers simultaneously, we can achieve cross-layer migration of assets.

This protocol has several advantages over current bridge models:

1. It does not concentrate large amounts of assets in the bridge, avoiding centralization risks; the risks of asset migration are distributed. The migration of assets out and in is triggered by users, and the client tracks ownership. As long as the destruction operation during migration out and the reissuance operation during migration in are matched, the assets are secure.
2. Assets can migrate between various networks like "cash." By separating asset storage from asset application scenarios, it can solve the state explosion problem and the large-scale issuance problem of new asset types.
3. This model requires wallets to play an important role, rather than just being the current "dumb" wallets that only trust RPC; they need to be more "intelligent."

To this end, the Rooch team has designed the SFT protocol based on Ordinals Bitseed, and will explore asset migration protocols based on the Bitseed protocol in the future. For more detailed content, please refer to the asset leap protocol section of the client-side validation protocol.

Security Issues

The previous solution descriptions did not address security solutions. In the Rooch network, security mainly includes two aspects:

1. Application-side security solutions, primarily concerning the update permissions of application state roots.
2. Client-side security solutions, where clients need to have state verification capabilities.

Application-side security needs to be customized by applications based on scenarios and development stages, with several options available:

1. Bitcoin-based time-slice rotating nodes + data availability layer + fraud proofs: Achieving multi-node switching through time-slice rotation ensures high availability and decentralization of applications, while fraud proofs are used to penalize malicious nodes. This is the solution Rooch Network will adopt, and we will explore how to utilize Bitcoin as a security source with partners.
2. PoA nodes + data availability layer: This type of application can ensure data verifiability, allowing anyone to run an independent node to verify the data.
3. PoA nodes: This type of application can provide state proofs externally, allowing user wallets to verify their own data, but due to the lack of a data availability layer to ensure transaction availability, there is a risk of data concealment. It can serve as an intermediate transition from Web2 applications to Web3 applications.
4. Multi-signature by all participants: Suitable for state channel applications.

Client-side validated assets require wallets to no longer fully trust RPC nodes but to possess certain verification capabilities, which can be termed smart wallets.

1. Client wallets need the capability to connect to the P2P network, discover application nodes in the network, and verify the application state tree roots through a random sampling mechanism, even running a smart contract virtual machine locally to verify their own transactions.
2. Client wallets need the ability to track asset migrations, at least to verify the validity of asset migrations.

This forms a game-theoretic mechanism among infrastructure, applications, and users, seeking a balance between scalability and security. Applications can first validate the market through a semi-decentralized solution, then gradually transition, relinquishing permissions and adopting a progressive decentralization route.

Phased Roadmap

The development of the Rooch VApp container is about to release a new stable version, and we will launch the pilot network of Rooch Network based on this version.

In the pilot network, we will first attempt the design of cross-layer asset protocols, mainly including two directions:

1. Issuing a new off-chain asset through a self-locking warehouse derivative asset model and attempting to migrate from off-chain to on-chain.
2. Attempting to migrate assets based on Bitseed from on-chain to off-chain, including NFT and FT assets issued using the Bitseed SFT standard.

At the same time, we will explore games based on Bitcoin assets and encourage developers to build games and applications, creating an application ecosystem in the VApp model, distributing option assets of Rooch Network's mainnet tokens to users through games and applications, which can be used to redeem mainnet tokens in the future.

Then we will connect to the P2P network, integrate the data availability layer, achieve decentralization of nodes, seek partners to co-develop security solutions based on Bitcoin, and upgrade the pilot network to the mainnet. For detailed roadmap information, please refer to Roadmap.

Conclusion

This article introduces the blueprint and goals of Rooch Network, as well as the paths attempted for validation; it is not a complete white paper.

VApp provides a runtime environment for applications, the Distributed State Tree Protocol connects applications through a P2P network, and the asset migration protocol allows assets to flow between Bitcoin and applications, giving us a complete Bitcoin application layer blueprint.

Of course, there are still many issues to be resolved before this blueprint can be realized, but we believe that many technical solutions evolve from practice rather than being planned and designed. We are like explorers of the Age of Discovery, roughly knowing the direction and value of the treasure, but the specific paths need to be sought and explored. We can only make some assumptions, then design minimal protocols and products, validate them in the market, solve problems, adjust directions, and continuously iterate, ultimately leading us to that One Piece.