链上扩展与链外扩展：比特币可编程性的未来

比特币的可编程性扩展方案主要分为两个方向：链上扩展和链外扩展。

比特币链上扩展

比特币链上扩展一直受限于其脚本的编程能力。诸如 Bitvm 的方案试图通过 Taproot 树来模拟电路，实现图灵完备的计算。然而，比特币 L1 的更大限制在于其脚本是无状态的。无论计算多么复杂，对状态的所有权只能表现为时间锁、哈希锁、私钥锁，无法表达“状态锁”，而这是实现复杂应用的前提。

举个例子，假设将比特币的脚本替换为图灵完备的虚拟机，其他条件不变，设计一个计数器，使得任何用户发送交易都可以使其加一，你会发现这种限制。

计数器场景有什么用呢？在典型的铭文刻写场景下，需要一个计数器来计算资产的总量。如果链上能表达计数器，就不会出现打废铭文的情况了。

用通俗的比喻来解释“状态锁”：如果将比特币脚本理解为一个对 UTXO 的智能锁，这个智能锁可以通过密码解锁，可以通过指纹解锁，但它内部不能记录脚本执行后的结果，因此无法实现解锁几次后就不能再解锁的功能。

因此，如果链上扩展能配合一次性签名设计出仲裁和挑战机制，就已经非常有突破性了。

比特币链外扩展

由于链上扩展存在瓶颈，只能寻求链外扩展。为了避免 L2/侧链，on-chain/off-chain 的歧义，统称为链外扩展。

链外扩展需要在几个选项之间取舍：

1. 选择什么智能合约和虚拟机。

2. 如何在智能合约里读写比特币上的状态（数据和资产）。

3. 交易写到哪里，如何保证可用性。

例如，在 AVM 的方案里：

选择 Bitcoin Script。

通过增加新的 OP code 来实现。

交易写回比特币 L1。

而 EVM 侧链方案一般是：

选择 EVM。

通过桥跨资产。

用独立的共识网保证。

RoochNetwork 方案详解

智能合约及虚拟机： 使用 Move 和 MoveVM。

如何读写比特币上的状态： 在 L2 执行比特币 L1 的所有交易，将比特币的状态（UTXO/Inscription 等）表达为 Move Object。

这样有几个好处：

1. 智能合约中可以读取所有比特币上的状态（UTXO/Inscription 等），包括交易和区块头。

2. L2 的状态可以通过 Object 的动态字段，绑定到比特币的状态上（原子绑定），所有权归比特币资产的所有者。举几个典型场景：L1 的状态表达地块，L2 上盖房子；L1 的状态表达域名，解析记录在 L2。

3. 通过在 L2 的智能合约中生成比特币脚本和比特币交易，提供交易的可编程性。

如何保证可用性：

RoochNetwork 的交易可用性依赖第三方 DA。由于 Rooch 的方案中，L2 包含所有 L1 的交易，因此不能再写回 L1，只需将 L2 状态树的根定期写回比特币即可。这也保证了 L2 的交易成本足够低，为更复杂的应用提供基础设施。

总结

比特币生态期待可编程性的扩展方案已久，众多路线和方案不断尝试。比特币 L1 的可编程性有限，但其优势在于所有状态都是全局的，不存在合约间的割裂。因此，无论任何扩展方案，只要该方案在比特币上写入数据，就能与其他方案结合，优势互补，最终涌现出独特的生态系统。