Author: Rooch Network
What is Rooch Network?
Rooch Network is the native application layer of Bitcoin. Based on the stacked L2 solution, it provides users and developers with a launching platform for Bitcoin assets and Bitcoin application infrastructure.
Why do we need Rooch Network?
In 2023, various new asset protocols emerged in the Bitcoin ecosystem. The characteristics of these new assets are that the ownership of assets is only registered on Bitcoin, and the validity is verified off-chain. They can be collectively referred to as assets based on client side validation. What is the vision of the Bitcoin ecosystem indicated by these new asset protocols? There are different views in the industry. We believe that the new asset protocols on Bitcoin indicate a new paradigm for building an application ecosystem.
Client-side verification of assets verifies the validity of assets off-chain, so a cross-layer asset migration protocol can be designed to truly realize the migration of assets from on-chain to off-chain, simulating the "cash" effect in the digital world. This provides asset usage scenarios that are no longer limited by the scalability problem of the chain. It is a new expansion solution and provides unlimited possibilities for applications.
At the same time, this model also indicates a possible startup model for the application ecosystem. First, users are attracted through in-app assets, a user community is built, and then applications are born in the community, solving the problem of cold start of applications.
So what kind of infrastructure does this model need to support?
First, an off-chain scalable application environment is needed. This environment can provide verification services and scalability for on-chain asset protocols, and can also run applications and provide application scenarios for assets.
Secondly, a protocol for cross-layer asset migration is needed to achieve the migration of assets from on-chain to off-chain.
Finally, a network is needed to connect off-chain applications to each other to ensure interoperability between applications.
This is the direction that Rooch Network wants to explore and try.
Technical solutions and roadmap
Verifiable Application Container (VApp Container)
The off-chain application environment must first be verifiable, which is a prerequisite for decentralization. We refer to Verifiable App as VApp.
Smart contracts are used to ensure the verifiability of calculations, and the state tree is used to ensure the verifiability of states. The combination of these two forms a verifiable application container.
After a year of development, the Rooch team completed the VApp container of the Move language, which includes the following modules:
MoveOS: includes MoveVM and stacked state trees, which provide an execution environment for applications and save application states to ensure the verifiability of calculations and states.
Move basic library and framework: including Move Stdlib, MoveOS Stdlib, RoochFramework, BitcoinMove, etc., providing applications with basic functions such as account abstraction, asset definition, Bitcoin protocol execution, etc.
Basic development tools, RPC interface, indexing service, and SDK.
Based on this application container, application developers can implement most Web2 applications through the Move language and turn them into verifiable applications. Rooch also introduced the WASM virtual machine. The Move virtual machine runs application logic and manages status. The WASM virtual machine provides expansion capabilities, making it easier for developers to reuse libraries of existing programming languages.
Root to Bitcoin
With the VApp container, we need to combine it with Bitcoin. Rooch's solution is to execute all blocks on the Bitcoin network directly in the VApp container, verify UTXO and the extended protocol attached to UTXO, convert them into Move Objects, and provide Bitcoin with an L2 solution that includes L1 status.
This smart contract layer mainly provides three capabilities:
Providing Bitcoin status proof to Bitcoin ecosystem applications. Because the status on Bitcoin, including UTXO and Inscription, is included in the status tree, we write the root of the status tree to the Bitcoin network, and can provide Bitcoin status proof to Bitcoin ecosystem applications. It can prove whether a user owns a certain UTXO or Inscription at a certain block height.
Provide extensibility for Bitcoin L1’s asset protocol. To expand a new protocol based on an existing asset protocol, the main work is to define and implement the verification rules of the new protocol, which can be achieved through smart contract protocol plug-ins. In this way, developers do not need to build a new indexer.
Provide programmable capabilities for all data and assets on Bitcoin to create application scenarios.
With the full state of Bitcoin, we can stack a layer of L2 state on top and create application scenarios based on the data and assets on Bitcoin. There are several main solutions:
Settlement with Bitcoin L1 assets
There are three main modes: "Atomic Swap(opens in a new tab)", "PSBT(opens in a new tab)", and "On-chain Payment Triggers Off-chain Settlement". These modes are suitable for exchange or payment scenarios, and are settled directly on Bitcoin. Developers can use the smart contracts provided by Rooch to display and match transaction orders, as well as simplify settlement with Bitcoin.
Atomic Binding
Through the atomic binding of UTXO and Move Object, the assets of L2 are bound to the assets of Bitcoin L1, so that the ownership of the assets on L2 is transferred along with the transfer of Bitcoin L1 assets. For example, there is an Inscription on L1 to express a piece of land. Then a house is built on L2, and the ownership is bound to the land of L1. When the land is transferred, the house is also transferred.
Derivative Assets
Deriving new assets through Bitcoin L1 assets is equivalent to a model of issuing new assets based on existing assets. For example, holding a certain L1 asset can obtain a certain L2 asset.
Props and Identity Tokens
Use Bitcoin L1 assets as props or identity symbols in applications. For example, an Inscription represents equipment in the game, which can be used directly in the game in L2. Or use L1 assets for voting and governance.
Programming Bitcoin Script
Generate Bitcoin scripts and transactions in smart contracts, and use the constraints (governance or mortgage) built on L2 to ensure that users must sign the transaction and include it in the L1 block, otherwise they will be punished. Through this feature, you can build on-chain multi-signature wallets and DAOs on Bitcoin, and provide additional security guarantees for multi-signature bridges.
More models need to be explored. We call this model the "stacked" application building model. The application stacks a layer of state on top of the chain state to reuse existing data and assets. For detailed solutions to the "stacked" model, please refer to Stackable L2. For programming documentation and examples about Bitcoin and Move, please refer to Extending Bitcoin.
Distributed State Tree Protocol (DSTP)
VApp containers are all independent. How to connect them into a network? And achieve intercommunication of states and assets? This is the problem that the distributed state tree protocol needs to solve.
The idea of the distributed state tree protocol is to achieve expansion and parallel computing by distributing different subtrees of the stacked state tree to the nodes of the P2P network. Through the distributed state tree protocol, the entire network can support an unlimited number of applications and achieve parallel horizontal expansion, but at the same time, it can share data and assets through the global state and achieve 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 only exist on a specific node. If a transaction only modifies the application state but not the global state, the transaction does not need to be broadcast to the network. The application only needs to synchronize its state root to the global state at regular intervals, which is equivalent to an application-based sharding.
This forms a distributed state tree with its root on Bitcoin and data scattered across application nodes. Assets within the application can be moved between state trees and can also communicate with assets on Bitcoin.
The distributed state tree protocol can also be expanded in two directions:
Fusion state channel. The state channel can be understood as a special state tree with a life cycle. When the state channel of multiple participants is opened, the state tree is created. When the state channel is settled, the application can discard the state in the state tree or settle it to the previous layer. This scenario, combined with the P2P network, is very suitable for multi-person real-time interactive applications (games).
Support state trees in other formats. In theory, any existing state tree can be mounted as a subtree into a distributed state tree, such as a git repository. This way, the application can directly read files in the git repository.
Asset Leap Protocol
Direct settlement on Bitcoin L1 still has high transaction costs and long waiting time for confirmation. There are several solutions in the industry for transferring assets on Bitcoin to L2:
The model of hosting cross-chain bridges. This model is widely used, and how to use Bitcoin to ensure the security and decentralization of the bridge is still a direction of exploration. Rooch will cooperate with specialized cross-chain bridge projects to achieve asset bridging and enhance the security of the bridge through the programming capabilities provided by Rooch.
Non-custodial mode: This is the main direction that Rooch is exploring, such as statechains (opens in a new tab).
As for assets of new protocols on Bitcoin, we will try an asset migration protocol. If a large number of new assets are issued on Bitcoin in the future, a protocol is needed to achieve the migration of assets between the Bitcoin network and L2 to reduce the state storage pressure on Bitcoin. At the same time, new assets on L2 must also be able to be migrated to Bitcoin to obtain higher security and wider circulation capabilities.
The core idea of the asset transfer protocol
Client-side validation assets such as RGB/Ordinals use Bitcoin to register the ownership of assets, but their validity is verified on the client side. If we define a leap instruction at the protocol layer to express the migration of assets from L1 to L2, or from L2 to L1, and then the client can verify at both layers at the same time, we can achieve cross-layer migration of assets.
This protocol has several advantages over the current bridge model:
A large amount of assets will not be gathered in the bridge, avoiding the risk of concentration, and the risk of asset migration mode is dispersed. Asset migration and migration are triggered by users, and the client tracks ownership. As long as the destruction operation at the time of migration and the re-issuance operation at the time of migration are verified to match, the assets are safe.
Assets can be migrated between various networks like "cash". Separating the storage of assets from their application scenarios can solve both the state explosion problem and the large-scale issuance of new assets.
This model requires wallets to play an important role, and not just the current "dumb" wallets that only trust RPC, but need to be more "intelligent".
To this end, the Rooch team designed the Ordinals-based SFT protocol Bitseed(opens in a new tab). In the future, they will explore asset migration protocols based on the Bitseed protocol. For more details, please refer to the asset migration protocol section of the client verification protocol.
Security Question
The previous solution description does not involve security solutions. In the Rooch network, security mainly includes two aspects:
The security solution on the application side mainly focuses on the update permissions of the application state root.
For the client security solution, the client needs to have state verification capability.
Application security needs to be customized by the application based on the scenario and development stage. There are several main options:
Based on Bitcoin's time slice rotation node + data availability layer + fraud proof: multi-node switching is achieved through time slice rotation to ensure high availability and decentralization of applications, and fraud proof is used to punish nodes that do evil. This is the solution that Rooch Network will adopt, and we will try to explore with partners how to use Bitcoin as a security source.
PoA Node + Data Availability Layer: This type of application can ensure the verifiability of data, and anyone can run an independent node to verify the data.
PoA node: This type of application can provide external proof of status, and the user wallet can verify its own data, but because there is no data availability layer to guarantee the availability of transactions, there is a risk of data hiding. It can serve as an intermediate transition from Web2 applications to Web3 applications.
Multi-signature for all participants: suitable for state channel applications.
Client-side asset verification requires that the wallet no longer completely trusts the RPC node, but instead requires the wallet to have a certain level of verification capabilities, which can be called a smart wallet.
The client wallet needs to be able to access the P2P network, discover the application nodes in the network, and verify the root of the application's state tree through a random sampling mechanism. It can even run the smart contract virtual machine locally to verify its own transactions.
Client wallets need to be able to track the migration of assets, or at least verify the validity of asset migration.
This forms a game mechanism among infrastructure, applications, and users, seeking a balance between scalability and security. Applications can first verify the market through a decentralized solution, and then gradually transition and transfer authority, taking a progressive decentralization route.
Phased route
The research and development of Rooch VApp container will soon release a new stable version, and we will launch the pilot network of Rooch Network based on this version.
On Xianxing.net, we will first try to design a cross-layer asset protocol, which mainly includes two directions:
Through the model of self-locked derivative assets, a new off-chain asset is issued, and an attempt is made to migrate from the off-chain to the on-chain.
Try to migrate Bitseed assets from on-chain to off-chain, including NFT and FT assets issued using Bitseed's SFT standard.
At the same time, we will try games based on Bitcoin assets, and encourage developers to build games and applications, build an application ecosystem in the VApp model, and distribute Rooch Network mainnet token option assets 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, access the data availability layer, realize the decentralization of nodes, seek partners to jointly develop Bitcoin-based security solutions, and upgrade the pilot network to the main network. For a detailed roadmap, please refer to the Roadmap.
Summarize
This article introduces the Rooch Network blueprint and goals, as well as ways to try to verify it. It is not a complete white paper.
VApp provides a running 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. We now have a complete Bitcoin application layer blueprint.
Of course, there are still many problems to be solved before this blueprint can be realized, but we believe that many technical solutions are evolved from practice rather than planned and designed. We are like explorers in the Age of Exploration. We roughly know the direction and value of the treasure, but the specific path needs to be found and explored. We can only make some assumptions first, then design the minimum protocol and product, verify it in the market, solve problems, adjust the direction, and keep repeating. Eventually, we will find the One Piece.
