Post
Bitcoin 的 Layer2 应该怎么做
从一条做过又放弃过的路线出发,反过来解释什么更重要。
Bitcoin 上做通用计算智能合约的 Layer2 一直是个难题,因为无法依赖 Bitcoin 网络来保证智能合约安全。我们 18 年的时候尝试过让 Bitcoin 闪电网络支持 WASM 智能合约,但也需要第三方来提供仲裁,最后放弃了这个路线。
今年 Ordinals、BRC20 等 BTC 生态火爆的时候,展示了另外一种可能。它们只将 BTC 作为 DA,技术解决方案类似主权 Rollup,但得到了市场和用户的认可。然而,如果想进一步扩展生态,就会发现难题重重,Bitcoin 网络作为 DA 的成本还是太高了。
于是我就想到:能不能换一种思路?Bitcoin 网络作为一种源 DA,而 Layer2 自己的 DA 通过另外的方式来解决,于是有了 Rooch 当前的方案。

Rooch 作为 Bitcoin 的 Side Rollup
核心组件与交互
- Bitcoin:主链,其区块信息被同步到 Rooch,为 Rooch 提供验证数据。
- Rooch:作为 Side Rollup,包含以下核心组件。
- Bitcoin 轻客户端:在 Rooch 中使用 Move 智能合约实现,负责校验从 Bitcoin 同步过来的区块头信息。
- Relayer:定期将 Bitcoin 最新的区块头信息同步到 Rooch 的 Bitcoin 轻客户端。任何人都可以承担 Relayer 的角色,确保至少有一个诚实的 Relayer 可以保证整体安全性。
- Rooch Sequencer:与 Rooch 中的应用合约交互,用于验证交易证明并处理相关应用逻辑。
- Rooch Full Node:存储完整的 Rooch 链数据,并与 DA 交互同步交易信息。
- Client:用户或应用客户端,从 Bitcoin 网络获取交易证明,并与应用合约交互。
工作流程
- Relayer 定期将 Bitcoin 的区块头信息同步给 Rooch 的 Bitcoin 轻客户端。
- Bitcoin 轻客户端在 Rooch 中校验并保存这些区块头信息。
- 开发者可以使用 Move 智能合约在 Rooch 中创建应用,这些应用可以处理和验证 Bitcoin 交易,因为轻客户端可以提供验证交易的 Merkle Tree 证明。
- 客户端从 Bitcoin 获取交易证明,并与应用合约交互。
应用场景
- 触发式应用:例如,当 Bitcoin 网络上完成某种交易时,自动触发 Rooch 中某个合约的执行。
- 数据复制与再执行:例如,将 Bitcoin 上的 Ordinals、BRC20、GRC20 等标准定义的 JSON 在 Rooch 中再次执行,使 Rooch 充当去中心化的 Indexer 服务。这样,任何人都可以部署一个 Rooch 节点,同步并重新执行交易,创建自己的 Indexer 服务。
这个方案的关键点
- Bitcoin 作为源 DA,它为 Layer2 提供时间和关键数据源,用户的 Ordinals 交易直接发送给 Bitcoin 网络。
- Rooch 作为 Bitcoin Layer2,会通过智能合约执行 Bitcoin 网络上的 Ordinals 交易。
- Rooch Layer2 可以发行 Layer2 上的 coin 以及应用,围绕 Bitcoin 构建扩展生态。
- Layer2 自己的交易,可以通过写入另外一个 DA 来实现可验证,任何人都可以运行一个节点来校验 Indexer 提供的数据。
- 如果生态进一步发展、安全需求提高,则可以接入一个仲裁层,通过欺诈证明或者有效证明的方式增强安全性。比如由 Ethereum 来提供仲裁。
这个方案是在不修改 Bitcoin 机制的前提下,实现 Bitcoin Layer2 并提供应用支持的一种可行方案。
以前大家会限于门户之见,但我认为行业正在从叙事逻辑转向应用逻辑。以应用为中心,基础设施只是提供支撑,就不会有那么强的门户之见了。
后面我又补了一版设计,开始把全量 Bitcoin 状态也纳入进来,包括 BlockHeader、UTXO 以及各种协议的 Balance。这样一来,开发体验会更简单,也让这个方向越来越接近后来 Ethereum 社区讨论的 Booster rollups。

回头看,这条路线的关键并不只是“跨到 Layer2”,而是 Layer2 如何在不改动 Bitcoin 机制的前提下,继承 Bitcoin 的数据与约束,同时把应用生态真正做起来。