The application layer of bitcoin (#1615)

* fix typo for stackable-l2

* the-application-layer-of-bitcoin

* english version

* fix #1614

* refactor the article

* fix format

* Add blog cover

* fixup

---------

Co-authored-by: Joe Chen <[email protected]>

README.md

@@ -9,7 +9,7 @@
 
 [![Check-Build-Test](https://github.com/rooch-network/rooch/actions/workflows/check_build_test.yml/badge.svg)](https://github.com/rooch-network/rooch/actions/workflows/check_build_test.yml)
 [![License](https://img.shields.io/badge/license-Apache-green.svg)](LICENSE)
-[![LoC](https://tokei.rs/b1/github/rooch-network/rooch?category=lines)](https://github.com/rooch-network/rooch)
+<!-- [![LoC](https://tokei.rs/b1/github/rooch-network/rooch?category=lines)](https://github.com/rooch-network/rooch) -->
 
 ## Usage
 

docs/website/pages/blog/stackable-l2.zh-CN.mdx

@@ -17,7 +17,7 @@ import PostHeader from "/components/blog/postHeader";
 
 这个方案在 Vitalik 在他的文章 《Deeper dive on cross-L2 reading for wallets and other use cases》中有详细的探讨。Rooch 最早设计的多链结算方案中，也是用类似的技术，L2 嵌入 L1 的轻节点，验证 L1 的区块来获得 L1 的状态根。但这套方案用在 Bitcoin 上的时候，会遇到难题。
 
-1. Bitcoin 上的 UTXO 并没有状态树，不能之间证明某个 UTXO 在某个区块高度是否被消费了，只能通过交易证明，证明某个交易是否包含在某个区块中。
+1. Bitcoin 上的 UTXO 并没有状态树，不能证明某个 UTXO 在某个区块高度是否被消费了，只能通过交易证明，证明某个交易是否包含在某个区块中。
 2. 同时要支持 Bitcoin 上的 UTXO 附加的信息的证明，比如 RGB，铭文（Ordinals），还需要证明交易的 Input 和 Output 之间的关联关系，这个挑战更大。
 
 这里补充一下 Bitcoin 的一个基础知识，Bitcoin 的共识协议验证区块的时候，只检查 Input 和 Output 的 BTC amount 是否匹配，并不关心 Input 和 Output 的对应关系。

docs/website/pages/blog/the-application-layer-of-bitcoin.zh-CN.mdx

@@ -0,0 +1,168 @@
+---
+title:  Rooch Network - Bitcoin 的应用层
+description: "给 Bitcoin 上的所有资产提供索引，交易以及应用场景的以资产为中心的基础设施"
+author: jolestar
+date: 2024/04/24
+category: Technology
+---
+
+![The Application Layer of Bitcoin](/blog/bitcoin-application-layer/bitcoin-application-layer-cover.zh.jpg)
+
+## Rooch Network 是什么？
+
+Rooch Network 是 Bitcoin 的应用层，给 Bitcoin 上的所有资产提供索引、交易以及应用场景的以资产为中心的基础设施。
+
+## 为什么需要 Rooch Network？
+
+2023 年 Bitcoin 生态涌现出了各种新型资产协议，这些新型资产的特点是只在 Bitcoin 上登记资产的所有权，有效性在链下验证，可以统称为基于客户端验证（Client side validation）的资产。
+而这些新资产协议预示的 Bitcoin 生态的远景是什么？业界存在着不同的看法，我们认为 **Bitcoin 上的新型资产协议预示着一种新的应用生态构建范式**。
+
+客户端验证资产将资产的有效性放在链下验证，所以可以设计出一种跨层资产迁移协议，真正实现资产从链上到链下的迁移，在数字世界模拟出“现金”效果。
+这样为资产提供使用场景不在受限于链的可扩展性难题，是一种新的扩容方案，也为应用提供了无限可能。
+
+同时，这种模式也预示着一种可能的应用生态的启动模式。通过应用内资产先吸引用户，构建用户社区，然后社区中诞生应用，解决应用冷启动难题。
+
+那这种模式需要什么样的基础设施来支持呢？
+
+1. 首先，需要一个链下可扩展应用环境。这个环境既可以给链上资产协议提供校验服务和扩展性，也可以运行应用，给资产提供应用场景。
+2. 其次，需要一个资产跨层迁移的协议，以实现资产从链上到链下迁移。
+3. 最后，需要一个网络将链下应用互相连接起来，保证应用间的互操作能力。
+
+这是 Rooch Network 要探索和尝试的方向。
+
+## 技术方案和路线图
+
+### 可验证应用容器（VApp Container）
+
+链下的应用环境首先要保证可验证，可验证是去中心化的前提条件。我们把**可验证应用（Verifiable App）**简称为 **VApp**。
+
+**智能合约来保证计算的可验证，状态树来保证状态的可验证，组合起来就是可验证应用容器**。
+
+Rooch 团队经过一年时间的开发，完成了 Move 语言的 VApp 容器，它包括以下模块：
+
+![VApp Container](/blog/bitcoin-application-layer/vapp-container.svg)
+
+1. MoveOS：包括 MoveVM 以及堆叠的状态树，给应用提供执行环境，以及保存应用的状态，保证计算和状态的可验证性。
+2. Move 基础库以及框架：包含 Move Stdlib, MoveOS Stdlib, RoochFramework, BitcoinMove 等，给应用提供账户抽象，资产定义，Bitcoin 协议执行等基础功能。 
+3. 基础的开发工具，RPC 接口，索引服务，以及 SDK。
+
+基于这个应用容器，应用开发者几乎可以把大多数 Web2 应用通过 Move 语言实现，变成可验证应用。Rooch 同时引入了 WASM 虚拟机，Move 虚拟机运行应用逻辑，管理状态，WASM 虚拟机提供扩展能力，方便开发者复用已有编程语言的库。
+
+### Root 到 Bitcoin
+
+有了 VApp 容器后，我们需要和 Bitcoin 结合起来。Rooch 采用的方案是直接在 VApp 容器中执行 Bitcoin 网络上的所有区块，验证 UTXO 以及 UTXO 之上附加的扩展协议，转换成 Move 的 Object，为 Bitcoin 提供一种链下智能合约的 Layer2 解决方案。
+
+这个智能合约层主要提供三种能力：
+
+1. 给 Bitcoin 生态应用提供 Bitcoin 的状态证明。因为 Bitcoin 上的状态，包括 UTXO 以及 Inscription 等都会包含在状态树里，我们把状态树的根（Root） 写到 Bitcoin 网络上，就可以给 Bitcoin 生态应用提供 Bitcoin 的状态证明。可以证明在某个区块高度，用户是否拥有某个 UTXO，或者某个 Inscription。
+2. 给 Bitcoin L1 的资产协议提供扩展能力。基于已有的资产协议扩展新协议，主要的工作是定义和实现新协议的验证规则，而这些可以通过智能合约协议插件的方式来实现。这样开发者就不需要构建新的索引器。
+3. 给 Bitcoin 上所有的数据以及资产提供可编程能力，创造应用场景。
+
+有了 Bitcoin 的全量状态后，我们再上面再堆叠一层 L2 的状态，就可以基于 Bitcoin 上的数据和资产来创建应用场景，主要有几种方案：
+
+**用 Bitcoin L1 资产结算**
+
+主要有“[原子交换](https://en.bitcoin.it/wiki/Atomic_swap)”，“[PSBT](https://github.com/bitcoin/bitcoin/blob/master/doc/psbt.md)”，“链上支付触发链下结算” 三种模式。这几种模式都适合交换或者支付场景，直接在链上结算，所以需要一种异步编程模型来降低开发者的门槛，这方面 Move 社区已经有 async Move 的扩展尝试，我们可以继续探索这个方向。
+
+**原子绑定**
+
+通过 UTXO 和 Move Object 的原子绑定，绑定 L2 的资产到 Bitcoin L1 的资产之上，实现 L2 上的资产的所有权随着 Bitcoin L1 资产转移而转移。
+比如在 L1 上有一个 Inscription 来表达一块土地。然后在 L2 上盖一个房子，所有权绑定到 L1 的地上，转移土地的时候，房子也随着转移。
+
+**衍生资产**
+
+通过 Bitcoin L1 的资产来衍生新的资产，相当于基于已有资产发行新资产的一种模式。比如持有某种 L1 的资产，可以获得某种 L2 的资产。
+
+**道具和身份标志**
+
+在应用中将 Bitcoin L1 的资产作为道具或者身份标志。比如某种 Inscription 代表游戏中的装备，直接在 L2 中的游戏中使用。或者用 L1 的资产进行投票治理。
+
+更多的模式还需要探索，我们把这种模式叫做**“堆叠式”的应用构建模式，应用在链的状态之上堆叠一层状态，来实现对已有的数据和资产的复用**。关于“堆叠式”模式的详细方案请参考 [Stackable L2](./stackable-l2)。
+
+### 分布式状态树协议（Distributed State Tree Protocol - DSTP)
+
+VApp 容器都是独立的，如何将它们连接成一个网络？并且实现状态和资产的互通？这是分布式状态树协议需要解决的问题。
+
+分布式状态树协议的思路是通过把堆叠状态树的不同子树，分散到 P2P 网络的节点上，以实现扩容和并行计算。
+通过分布式状态树协议，可以让整个网络可以支持无限多的应用，实现并行水平扩容，但同时能通过全局状态来共享数据和资产，以及实现应用的互操作性。
+
+基于“堆叠式”的状态模式，每个 VApp 节点都会包含 Bitcoin 和 Rooch 的状态，它们是全局状态。
+而应用的状态是全局状态树的一个子树，可以只存在特定的节点上。
+如果某个交易只修改了应用的状态，而没有修改全局状态，那个交易就不需要广播到网络中，应用只需定时将自己的状态根同步到全局状态中即可，相当于一种基于应用的分片。
+
+这样就形成了一个 **Root 在 Bitcoin 上，数据分散在各应用节点上的分布式状态树**。应用内的资产可以在状态树之间移动，也可以和 Bitcoin 上的资产互通。
+
+![Distributed State Tree Protocol](/blog/bitcoin-application-layer/dstp.svg)
+
+分布式状态树协议还可以向两个方向扩展：
+
+1. 融合状态通道。状态通道可以理解成一种特殊的有生命周期的状态树。当多方参与者的状态通道开启的时候，状态树创建，状态通道结算的时候，应用可以将状态树中的状态丢弃或者结算到上一层。这种场景配合 P2P 网络，非常适合多人即时交互类的应用（游戏）。
+2. 支持其他格式的状态树。理论上已有的状态树都可以作为子树挂载到分布式状态树中，比如 git 仓库。这样应用可以直接读取 git 仓库中的文件。
+
+### 跨层的资产迁移协议(CrossLayer Asset Migrate Protocol)
+
+直接在 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 上，从而获取更高的安全以及更广泛的流通能力。
+
+资产迁移协议的核心思想：RGB/Ordinals 这样的基于客户端验证（Client side validation）的资产，利用 Bitcoin 来登记资产的所有权，但它的有效性在客户端进行验证。
+如果我们在协议层定义一种指令，表达出将资产从 L1 迁移到 L2，或者从 L2 迁移到 L1，然后客户端可以同时在两层进行验证，我们就可以实现资产的跨层迁移。
+
+这种协议比当前的桥模式有几个优点：
+
+1. 不会聚集大量的资产在桥中，避免了集中性风险，资产迁移模式的风险是分散的。资产迁出，以及迁入，都是用户触发的，客户端追踪的是所有权，只要验证迁出的时候的销毁操作和迁入的时候的重新发行操作是匹配的，资产就是安全的。
+2. 资产会真正像“现金”一样在各种网络之间迁移。将资产的存储和资产的应用场景分开，既能解决状态爆炸问题，也能解决新型资产的大规模发行问题。
+3. 这种模式要求钱包扮演重要的角色，而不仅仅是当前这种只信任 RPC 的“笨”钱包，需要更“智能”一些。
+
+为此，Rooch 团队设计了基于 Ordinals 的 SFT 协议 [Bitseed](https://bitseed.pro/)，未来会基于 Bitseed 协议来探索资产的迁移协议。
+
+### 安全问题
+
+前面的方案描述中并没有涉及安全方案，在 Rooch 网络中，安全主要包含两个方面：
+
+1. 应用端的安全方案，主要是应用状态根的更新权限。
+2. 客户端的安全方案，客户端需要有状态校验能力。
+
+应用端的安全需要由应用根据场景以及发展阶段来自定义，主要有几种选项：
+
+1. 基于 Bitcoin 的时间片轮换节点 + 数据可用层 + 欺诈证明：通过时间片轮换来实现多节点切换，保证应用的高可用以及去中心化，欺诈证明用于惩罚作恶的节点。这是 Rooch Network 会采用的方案，我们会尝试和合作伙伴一起探索如何利用 Bitcoin 来作为安全源。
+2. PoA 节点 + 数据可用层：该类型的应用可以保证数据的可验证性，任何人都可以运行一个独立的节点对数据进行校验。
+3. PoA 节点：该类型的应用可以对外提供状态证明，用户钱包可以校验自己的数据，但由于没有数据可用层保证交易的可用性，存在数据隐藏风险。它可以作为 Web2 应用到 Web3 应用的中间过渡。 
+4. 所有参与者多签：适合状态通道类的应用。
+
+客户端验证资产要求钱包不再完全信任 RPC 节点，而是要求钱包具备一定的校验能力，可以称为智能钱包。
+
+1. 客户端钱包需要有能力接入 P2P 网络，发现网络中的应用的节点，并通过随机抽样机制，校验应用的状态树的根，甚至可以本地运行智能合约虚拟机校验自己的交易。
+2. 客户端钱包需要有能力追踪资产的迁移，至少要验证资产迁移的有效性。
+
+这样就形成了**基础设施，应用，用户三方的博弈机制，在扩展性和安全性之间寻求一种平衡**。应用可以先通过偏中心化的方案，验证市场，然后逐渐过渡，让渡权限，采取一种渐进式的去中心化路线。
+
+## 阶段性路线
+
+Rooch VApp 容器的研发即将发布一个新的稳定版本，我们会基于这个版本启动 Rooch Network 的先行网。
+
+在先行网上，我们会先尝试跨层资产协议的设计，主要包括两个方向：
+
+1. 通过自锁仓衍生资产的模式，发行一种链下的新资产，并尝试从链下迁移到链上。
+2. 尝试基于 Bitseed 资产从链上到链下的迁移。包括 NFT 和 FT 两种用 Bitseed 的 SFT 标准发行的资产。
+
+同时，我们会尝试基于 Bitcoin 资产的游戏，也鼓励开发者来构建游戏和应用，构建 VApp 模式的应用生态，通过游戏和应用来给用户分发 Rooch Network 主网代币的期权资产，未来可以用来兑换主网代币。
+
+然后我们会接入 P2P 网络，接入数据可用层，实现节点的去中心化，寻求合作伙伴一起研发基于 Bitcoin 的安全方案，将先行网升级为主网。
+
+## 总结
+
+这篇文章介绍了 Rooch Network 蓝图以及目标，还有尝试验证的途径，它不是一个完备的白皮书。
+
+VApp 给应用提供运行环境，分布式状态树协议将应用通过 P2P 网络连接起来，资产迁移协议让资产在 Bitcoin 和应用之间流动，我们就有了一个完整的 **Bitcoin 应用层蓝图**。
+
+![Bitcoin Application Layer](/blog/bitcoin-application-layer/bitcoin-application-layer.svg)
+
+当然距离这个蓝图的实现还有许多待解决的问题，但我们认为很多技术方案都是根据实践演化出来的，而不是规划设计出来的。
+我们像是大航海时代探险者，大致知道宝藏的方向和价值，但具体的途径需要寻找和摸索。
+我们只能先做一些假设，然后设计最小化的协议和产品，在市场中进行验证，解决难题，调整方向，不断循环，最终我们会寻找到那个 **One Piece**。