rooch-network · jolestar · May 8, 2024 · May 4, 2024 · May 7, 2024 · May 7, 2024
@@ -18,7 +18,7 @@ Rooch Network is the Application Layer of Bitcoin, an Asset-Centric infrastructu
 
 ## Why Rooch Network?
 
-In 2023, the Bitcoin ecosystem saw the emergence of various new asset protocols, characterized by registering asset ownership on Bitcoin with validity verified off-chain, collectively known as [client-side validation](https://docs.rgb.info/distributed-computing-concepts/client-side-validation) assets. What future does this suggest for the Bitcoin ecosystem? Opinions vary, but we believe **these new asset protocols on Bitcoin signify a new paradigm for building application ecosystems**.
+In 2023, the Bitcoin ecosystem saw the emergence of various new asset protocols, characterized by registering asset ownership on Bitcoin with validity verified off-chain, collectively known as [client-side validation](/learn/core-concepts/client-side-validation) assets. What future does this suggest for the Bitcoin ecosystem? Opinions vary, but we believe **these new asset protocols on Bitcoin signify a new paradigm for building application ecosystems**.
 
 Client-side validation assets validate asset validity off-chain, thus allowing for the design of a cross-layer asset migration protocol that truly enables the migration of assets from on-chain to off-chain, simulating a "cash" effect in the digital world. This provides usage scenarios for assets that are no longer limited by the scalability issues of the chain, offering a new scaling solution and infinite possibilities for applications.
 
@@ -98,32 +98,30 @@ The Distributed State Tree Protocol can be extended in two directions:
 1. Integration with state channels. State channels can be understood as a special kind of lifecycle-managed state tree. When state channels involving multiple participants open, the state tree is created; when the channels settle, the application can discard or settle the states in the state tree. This scenario, combined with a P2P network, is highly suitable for multiplayer interactive applications (such as games).
 2. Support for other types of state trees. In theory, existing state trees can be mounted as sub-trees within the distributed state tree, such as git repositories. This allows applications to directly read files from git repositories.
 
-### Cross-Layer Asset Migration Protocol
+### Asset Leap Protocol
 
-Settling directly on Bitcoin L1 still faces issues with high transaction costs and long confirmation times. How to migrate assets from Bitcoin to L2 is a current industry challenge:
+Settling directly on Bitcoin L1 still faces issues with high transaction costs and long confirmation times. How to bridge assets from Bitcoin to L2 is a current industry challenge:
 
 1. Custodial bridge models are widely used. How to use Bitcoin to ensure the bridge's safety and decentralization is still an area of exploration. Rooch will collaborate with dedicated cross-chain bridge projects to implement asset bridging and enhance the bridge's security through Rooch's programming capabilities.
 2. Non-custodial models: This is the main direction Rooch is exploring, such as the [statechains](https://bitcoinops.org/en/topics/statechains/).
 
-For the Client-side validation assets, we will try to design a cross-layer asset migration protocol. 
-
-Off-chain smart contracts can provide computational scalability for Bitcoin, while the asset migration protocol aims to achieve state scalability.
+For the Client-side validation assets, we will try to design a asset leap protocol. 
 
 If a large number of new assets are issued on Bitcoin in the future, a protocol to facilitate asset migration between the Bitcoin network and L2 is needed to reduce the state storage pressure on Bitcoin. Also, new assets issued on L2 should be able to migrate to Bitcoin, thereby gaining higher security and broader circulation capabilities.
 
-The core idea of the asset migration protocol is as follows: 
+**The core idea of the asset leap protocol is as follows**: 
 
 Assets like RGB/Ordinals that are based on client-side validation use Bitcoin to register ownership, but their validity is verified by the client.
 
-If we define a protocol instruction to migrate assets from L1 to L2, or vice versa, and then enable clients to verify on both side, we can facilitate cross-layer asset migration.
+If we define a protocol instruction `leap` to migrate assets from L1 to L2, or vice versa, and then enable clients to verify on both side, we can facilitate asset migration.
 
 This protocol has several advantages over the current bridge models:
 
 1. It does not concentrate large amounts of assets in the bridge, thus avoiding centralization risks. The risk associated with asset migration is distributed. Both the migration out and migration in are triggered by users, and the client tracks ownership. As long as the destruction operation when migrating out and the reissuance operation when migrating in are matched, the assets are secure.
-2. Assets will truly migrate between networks like "cash." Separating the storage of assets from their application scenarios can solve the state explosion problem as well as issues related to the massive issuance of new assets.
+2. Assets can migrate between networks like "cash." Separating the storage of assets from their application scenarios can solve the state explosion problem as well as issues related to the massive issuance of new assets.
 3. This model requires wallets to play a significant role, not just as the current "dumb" wallets that only trust RPC, but rather more "smart" ones.
 
-To this end, the Rooch team has designed the SFT protocol based on Ordinals, [Bitseed](https://bitseed.pro/), and will explore asset migration protocols based on the Bitseed protocol in the future.
+To this end, the Rooch team has designed the SFT protocol based on Ordinals, [Bitseed](https://bitseed.pro/), and will explore asset migration protocols based on the Bitseed protocol in the future. For more details, please refer to the asset leap protocol section of the [Client-side validation protocol](/learn/core-concepts/client-side-validation/).
 
 ### Security Issues
 

@@ -18,7 +18,7 @@ Rooch Network 是 Bitcoin 的应用层，给 Bitcoin 上的所有资产提供索
 
 ## 为什么需要 Rooch Network？
 
-2023 年 Bitcoin 生态涌现出了各种新型资产协议，这些新型资产的特点是只在 Bitcoin 上登记资产的所有权，有效性在链下验证，可以统称为基于客户端验证（[Client side validation](https://docs.rgb.info/distributed-computing-concepts/client-side-validation)）的资产。而这些新资产协议预示的 Bitcoin 生态的远景是什么？业界存在着不同的看法，我们认为 **Bitcoin 上的新型资产协议预示着一种新的应用生态构建范式**。
+2023 年 Bitcoin 生态涌现出了各种新型资产协议，这些新型资产的特点是只在 Bitcoin 上登记资产的所有权，有效性在链下验证，可以统称为基于客户端验证（[Client side validation](/learn/core-concepts/client-side-validation)）的资产。而这些新资产协议预示的 Bitcoin 生态的远景是什么？业界存在着不同的看法，我们认为 **Bitcoin 上的新型资产协议预示着一种新的应用生态构建范式**。
 
 客户端验证资产将资产的有效性放在链下验证，所以可以设计出一种跨层资产迁移协议，真正实现资产从链上到链下的迁移，在数字世界模拟出“现金”效果。这样为资产提供使用场景不再受限于链的可扩展性难题，是一种新的扩容方案，也为应用提供了无限可能。
 
@@ -98,32 +98,26 @@ VApp 容器都是独立的，如何将它们连接成一个网络？并且实现
 1. 融合状态通道。状态通道可以理解成一种特殊的有生命周期的状态树。当多方参与者的状态通道开启的时候，状态树创建，状态通道结算的时候，应用可以将状态树中的状态丢弃或者结算到上一层。这种场景配合 P2P 网络，非常适合多人即时交互类的应用（游戏）。
 2. 支持其他格式的状态树。理论上已有的状态树都可以作为子树挂载到分布式状态树中，比如 git 仓库。这样应用可以直接读取 git 仓库中的文件。
 
-### 跨层的资产迁移协议（CrossLayer Asset Migrate Protocol）
+### 资产跃迁协议（Asset Leap Protocol）
 
-直接在 Bitcoin L1 进行结算，依然存在交易成本高，等待确认时间长的用户体验问题。如何把 Bitcoin 上的资产跨到 L2，这方面当前业界有几种方案：
+直接在 Bitcoin L1 进行结算，依然存在交易成本高，等待确认时间长的用户体验问题。如何把 Bitcoin 上的资产跨到 L2，当前业界有几种方案：
 
 1. 托管跨链桥的模式。这种模式广泛使用，如何利用 Bitcoin 来保证桥的安全以及去中心化依然是探索的一个方向，Rooch 会和专门的跨链桥项目进行合作，实现资产的桥接，以及通过 Rooch 提供的编程能力增强桥的安全性。
 2. 非托管模式：这是 Rooch 主要探索的方向，比如类似 [statechains](https://bitcoinops.org/en/topics/statechains/) 。
 
-而针对 Bitcoin 上的新协议的资产，我们会尝试一种跨层资产迁移协议。
+而针对 Bitcoin 上的新协议的资产，我们会尝试一种资产跃迁协议。如果未来大量的新型资产发行在 Bitcoin 上，需要一种协议实现资产在 Bitcoin 网络和 L2 之间的迁移，降低 Bitcoin 上的状态存储压力。同时，L2 上的新型资产也要能迁移到 Bitcoin 上，从而获取更高的安全以及更广泛的流通能力。
 
-链下的智能合约可以给 Bitcoin 提供计算能力上的扩容，而资产迁移协议则要实现状态扩容。
+**资产跃迁协议的核心思想**
 
-如果未来大量的新型资产发行在 Bitcoin 上，需要一种协议实现资产在 Bitcoin 网络和 L2 之间的迁移，降低 Bitcoin 上的状态存储压力。同时，L2 上发行的新型资产也要能迁移到 Bitcoin 上，从而获取更高的安全以及更广泛的流通能力。
-
-资产迁移协议的核心思想：
-
-RGB/Ordinals 这样的基于客户端验证（Client side validation）的资产，利用 Bitcoin 来登记资产的所有权，但它的有效性在客户端进行验证。
-
-如果我们在协议层定义一种指令，表达出将资产从 L1 迁移到 L2，或者从 L2 迁移到 L1，然后客户端可以同时在两层进行验证，我们就可以实现资产的跨层迁移。
+RGB/Ordinals 这样的基于客户端验证（Client side validation）的资产，利用 Bitcoin 来登记资产的所有权，但它的有效性在客户端进行验证。如果我们在协议层定义一种 `leap` 指令，表达出将资产从 L1 迁移到 L2，或者从 L2 迁移到 L1，然后客户端可以同时在两层进行验证，我们就可以实现资产的跨层迁移。
 
 这种协议比当前的桥模式有几个优点：
 
 1. 不会聚集大量的资产在桥中，避免了集中性风险，资产迁移模式的风险是分散的。资产迁出，以及迁入，都是用户触发的，客户端追踪的是所有权，只要验证迁出的时候的销毁操作和迁入的时候的重新发行操作是匹配的，资产就是安全的。
-2. 资产会真正像“现金”一样在各种网络之间迁移。将资产的存储和资产的应用场景分开，既能解决状态爆炸问题，也能解决新型资产的大规模发行问题。
+2. 资产可以像“现金”一样在各种网络之间迁移。将资产的存储和资产的应用场景分开，既能解决状态爆炸问题，也能解决新型资产的大规模发行问题。
 3. 这种模式要求钱包扮演重要的角色，而不仅仅是当前这种只信任 RPC 的“笨”钱包，需要更“智能”一些。
 
-为此，Rooch 团队设计了基于 Ordinals 的 SFT 协议 [Bitseed](https://bitseed.pro/)，未来会基于 Bitseed 协议来探索资产的迁移协议。
+为此，Rooch 团队设计了基于 Ordinals 的 SFT 协议 [Bitseed](https://bitseed.pro/)，未来会基于 Bitseed 协议来探索资产的迁移协议，更详细的内容请参看 [客户端验证协议](/learn/core-concepts/client-side-validation/) 的资产跃迁协议部分。
 
 ### 安全问题
 

@@ -1,5 +1,6 @@
 {
   "getting-started": "Getting Started",
+  "bitcoin": "Extending Bitcoin",
   "rooch-framework": "Rooch Framework",
   "sdk": "SDK",
   "example-guides": "Example guides",

@@ -1,5 +1,6 @@
 {
   "getting-started": "开始入门",
+  "bitcoin": "扩展 Bitcoin",
   "rooch-framework": "Rooch Framework",
   "sdk": "SDK",
   "example-guides": "示例指南",

@@ -0,0 +1,11 @@
+# Extending Bitcoin
+
+Rooch, as the application layer of Bitcoin, provides a programmable environment for Bitcoin through off-chain smart contracts. Developers can use Rooch to extend the Bitcoin protocol and develop applications within its ecosystem.
+
+Rooch offers several ways to extend the Bitcoin protocol or to interact with Bitcoin:
+
+- **[Programming with Bitcoin blocks and transactions](./bitcoin/programming_with_block_and_tx)**: Developers can access Bitcoin blocks and transactions within contracts and use the data contained in them for programming.
+- **[Bitcoin Asset Protocol Extension](./bitcoin/ordinals_metaprotocol_extension)**: Developers can deploy contracts to Rooch to extend the Bitcoin asset protocol, such as by deploying a new asset protocol based on Ordinals.
+- **[Programming with Bitcoin UTXO and Inscription](./bitcoin/programming_with_utxo_and_inscription)**: Rooch has automatically parsed Bitcoin UTXO and Inscription through the bitcoin-move system contract, allowing developers to directly use these assets for programming.
+
+There are many more scenarios to explore, and we welcome everyone to join in the development of Bitcoin ecosystem applications.
@@ -0,0 +1,14 @@
+# 扩展 Bitcoin
+
+Rooch 作为 Bitcoin 的应用层，通过运行于链下的智能合约为 Bitcoin 提供可编程环境，开发者可利用 Rooch 扩展 Bitcoin 协议并开发生态应用。
+
+Rooch 提供了几种方式来扩展 Bitcoin 协议或者和 Bitcoin 交互：
+
+- **[通过 Bitcoin 区块以及交易编程](./bitcoin/programming_with_block_and_tx)**: 开发者可以在合约中读取到 Bitcoin 区块以及交易，利用区块和交易中携带的数据来进行编程。
+- **[Bitcoin 资产协议扩展](./bitcoin/ordinals_metaprotocol_extension)**: 开发者可以通过部署合约到 Rooch 来扩展 Bitcoin 资产协议，比如通过部署一个合约来实现一个新的基于 Ordinals 的资产协议。
+- **[通过 Bitcoin UTXO 以及 Inscription 编程](./bitcoin/programming_with_utxo_and_inscription)**: Rooch 已通过 bitcoin-move 系统合约自动解析 Bitcoin UTXO 和 Inscription，开发者可以直接使用这些资产来进行编程。
+
+更多的场景需要大家一起来探索，欢迎大家一起来参与 Bitcoin 生态应用的开发。
+
+
+
@@ -0,0 +1,5 @@
+{
+  "ordinals_metaprotocol_extension": "Ordinals Metaprotocol Extension",
+  "programming_with_block_and_tx": "Programming with Block and Tx",
+  "programming_with_utxo_and_inscription": "Programming with UTXO and Inscription"
+}
@@ -0,0 +1,5 @@
+{
+  "ordinals_metaprotocol_extension": "Ordinals Metaprotocol 扩展",
+  "programming_with_block_and_tx": "通过区块和交易编程",
+  "programming_with_utxo_and_inscription": "通过 UTXO 和 Inscription 编程"
+}
@@ -0,0 +1,15 @@
+# Ordinals Metaprotocol Extension
+
+import { Callout, FileTree } from 'nextra/components'
+
+Rooch offers a plugin mechanism that allows developers to extend the Ordinals Metaprotocol using Move.
+
+[Bitseed](https://bitseed.pro) is an SFT protocol based on an extension of Ordinals, currently under development. We will use Bitseed as an example to demonstrate how to extend the Ordinals Metaprotocol using Move, implementing an asset validator for the Ordinals Metaprotocol, and facilitating asset transitions between Bitcoin and Rooch.
+
+<Callout>
+TODO: This section of the document needs improvement
+
+1. Specifications for extending contracts of the Metaprotocol.
+2. Specifications for the asset validator.
+3. Specifications for asset transitions.
+</Callout>
@@ -0,0 +1,15 @@
+# Ordinals Metaprotocol 扩展
+
+import { Callout, FileTree } from 'nextra/components'
+
+Rooch 提供了一种插件机制，开发者可以通过 Move 来扩展 Ordinals Metaprotocol。
+
+[Bitseed](https://bitseed.pro) 是一种基于 Ordinals 扩展的 SFT 协议，当前还在开发中，我们会以 Bitseed 为例，展示如何通过 Move 来扩展 Ordinals Metaprotocol，实现 Ordinals Metaprocol 的资产验证器，以及资产在 Bitcoin 和 Rooch 之间的跃迁。
+
+<Callout>
+TODO: 这部分文档需要改进
+
+1. Metaprotocol 的扩展合约的规范
+2. 资产验证器的规范
+3. 资产跃迁的规范
+</Callout>
@@ -0,0 +1,21 @@
+# Programming with Bitcoin Blocks and Transactions
+
+import { Callout, FileTree } from 'nextra/components'
+
+Rooch incorporates the [bitcoin-move](https://github.com/rooch-network/rooch/tree/main/frameworks/bitcoin-move) framework, which allows developers to read Bitcoin blocks and transactions through the bitcoin-move framework and use the data carried in them for programming.
+
+## Reading Bitcoin Blocks and Transactions in Contracts
+
+<Callout>
+TODO: This section of the document needs improvement
+
+1. How to read transactions, including explanations of transaction fields.
+2. How to read blocks, including explanations of block fields.
+3. An explanation of how Bitcoin hashes are expressed and differ in Move is required.
+</Callout>
+
+## Application Scenarios
+
+1. Use a Bitcoin hash as a random number seed to implement a random number generator. Note, this scenario requires using the hash of future blocks to prevent predictability.
+2. Embed application data in Bitcoin via OP_RETURN, then read the OP_RETURN data from the transaction using a Move contract for processing.
+3. Validate Bitcoin transaction scripts in Move to enable mixed programming with Move and Bitcoin Script. This feature is still in development, and progress can be tracked at [Issue #1651](https://github.com/rooch-network/rooch/issues/1651).
@@ -0,0 +1,21 @@
+# 通过 Bitcoin 的区块和交易编程
+
+import { Callout, FileTree } from 'nextra/components'
+
+Rooch 内置了 [bitcoin-move](https://github.com/rooch-network/rooch/tree/main/frameworks/bitcoin-move) 框架，开发者可以通过 bitcoin-move 框架来读取 Bitcoin 区块以及交易，利用区块和交易中携带的数据来进行编程。
+
+## 在合约中读取 Bitcoin 区块和交易
+
+<Callout>
+TODO: 这部分文档需要改进
+
+1. 如何读取交易，以及交易字段说明
+2. 如何读取区块，以及区块字段说明
+3. 需要说明 Bitcoin 哈希在 Move 中的表达方式以及区别
+</Callout>
+
+## 应用场景
+
+1. 利用 Bitcoin 哈希作为随机数种子，实现一个随机数生成器。注意，这种场景需要使用未来的区块哈希，避免被预测。
+2. 将应用数据通过 `OP_RETURN` 写入 Bitcoin 中，然后通过 Move 合约读取交易中的 `OP_RETURN` 数据，进行处理。
+3. 在 Move 中校验 Bitcoin 交易的 Script，实现 Move 和 Bitcoin Script 混合编程。这个特性尚在开发中，可以跟踪 [Issue #1651](https://github.com/rooch-network/rooch/issues/1651)。